Published and updated 31 July 2026 · Portfolio Capstones
Published and updated 31 July 2026 · Portfolio Capstones
Portfolio Capstones: Three Production-Grade Frontend Projects connects the essential decisions in this stage of frontend engineering. You will learn each browser or framework model from first principles, apply it to the progressive Learning Atlas product, diagnose a realistic failure from evidence, and direct an AI collaborator with explicit constraints. The goal is independent judgment, not memorized syntax.
You will advance an independent portfolio-grade product. By the end, you can explain every topic in this chapter, implement one focused slice per topic, adapt those slices under new constraints, and defend the result with browser evidence, strict types, accessibility checks, security boundaries, and a production build.
Bring forward a new repository with its own product brief, architecture decision record, app, tests, and runbook and the verification notes from the preceding chapter. Create a narrow Git branch, read the repository rules, and inspect existing changes before editing. When a tool or file is introduced for the first time, its purpose is explained before its syntax.
Use these project-orientation commands:
Before beginning Portfolio Capstones: Three Production-Grade Frontend Projects, stop if the working tree contains files you do not understand. Do not delete, reset, or rewrite another person's work to make the lesson cleaner.
A capstone proves judgment, not typing speed. Begin with users and constraints, design the information and trust boundaries, ship vertical slices, and preserve evidence that another engineer can review and operate. The topics below are ordered because each creates evidence needed by the next. Experienced readers may jump to a topic, but should still complete its failure investigation and adaptation task.
Build a portfolio that lets a hiring manager or collaborator find expertise, inspect evidence, and navigate projects without visual or motor assumptions. The hard part is trustworthy information architecture, semantic publishing, responsive reading, and measurable performance—not decorative effects.
The current artifact for capstone one: accessible personal knowledge portfolio is capstone/product-brief.md. Before editing, predict the visible behavior and name the source of truth. Then implement or study this complete focused slice:
Scenario: The portfolio looks polished but project filters are mouse-only, case studies lack evidence, and the contact route loses user input on failure.
Evidence to collect: Run the primary journey by keyboard and screen reader, verify claims against artifacts, test form failure/recovery, and measure the real LCP page.
Minimal repair rule: For accessible personal knowledge portfolio, correct the first boundary that violates the documented model, preserve the rest of the working path, and add a regression check based on the observed evidence.
Write the brief and route map without choosing a visual design, then prototype the most uncertain user journey as semantic HTML.
Build a knowledge portfolio for a clearly named primary user. The product must solve one complete workflow rather than imitate a gallery screenshot. Write three user stories in the form As a … I need … so that … and attach an observable acceptance criterion to each.
Create an information map for the knowledge portfolio before components. Define the nouns, their relationships, stable identifiers, ownership, retention, and which fields are sensitive. Then write a route table containing purpose, rendering strategy, data owner, loading state, empty state, error state, and authorization rule.
The complete knowledge portfolio workflow must work by keyboard at 320 pixels and 200% zoom. Provide one H1, logical headings, named landmarks, persistent labels, useful errors, predictable focus, status announcements, reduced motion, and sufficient contrast. Test with a screen reader; automation alone is insufficient.
For the knowledge portfolio threat model, list assets, actors, entry points, trust boundaries, abuse cases, controls, and residual risk. Validate on the server, authorize every protected action, keep secrets out of the browser, escape untrusted output, set safe headers, rate-limit costly operations, and redact logs.
Set knowledge portfolio budgets before implementation: LCP under 2.5 seconds at the 75th percentile, INP under 200 milliseconds, CLS under 0.1, and a justified client-JavaScript budget for the main route. Record the baseline, test with realistic data and network conditions, and explain any exception.
Use separate knowledge portfolio prompts for discovery, specification critique, route skeleton, one vertical slice, accessibility review, security review, test gaps, and release readiness. Each prompt must attach the relevant files and forbid broad unrelated changes.
Test knowledge portfolio domain functions, components with user behavior, server boundaries, permissions, and the primary end-to-end path. Include malformed input, slow networks, empty data, concurrent changes, forbidden access, keyboard use, zoom, and recovery. Deploy an immutable build to preview, verify environment values, rehearse migration and rollback, run smoke tests, then observe errors and core user actions.
Build an operations dashboard where an authorized team can investigate status, filter work, act safely, and understand consequences. Emphasize data ownership, permissions, dense accessible tables, URL state, optimistic conflicts, audit trails, observability, and rollback.
The current artifact for capstone two: production saas operations dashboard is capstone/architecture.md. Before editing, predict the visible behavior and name the source of truth. Then implement or study this complete focused slice:
Scenario: The dashboard hides a destructive action by role in the client, but its server action trusts the submitted tenant ID and permits cross-tenant change.
Evidence to collect: Replay direct requests across tenants, inspect session-to-tenant binding, data queries, audit events, optimistic rollback, and forbidden response caching.
Minimal repair rule: For production saas operations dashboard, correct the first boundary that violates the documented model, preserve the rest of the working path, and add a regression check based on the observed evidence.
Threat-model one destructive workflow and implement it end to end with confirmation, authorization, idempotency, audit, and recovery.
Build a operations dashboard for a clearly named primary user. The product must solve one complete workflow rather than imitate a gallery screenshot. Write three user stories in the form As a … I need … so that … and attach an observable acceptance criterion to each.
Create an information map for the operations dashboard before components. Define the nouns, their relationships, stable identifiers, ownership, retention, and which fields are sensitive. Then write a route table containing purpose, rendering strategy, data owner, loading state, empty state, error state, and authorization rule.
The complete operations dashboard workflow must work by keyboard at 320 pixels and 200% zoom. Provide one H1, logical headings, named landmarks, persistent labels, useful errors, predictable focus, status announcements, reduced motion, and sufficient contrast. Test with a screen reader; automation alone is insufficient.
For the operations dashboard threat model, list assets, actors, entry points, trust boundaries, abuse cases, controls, and residual risk. Validate on the server, authorize every protected action, keep secrets out of the browser, escape untrusted output, set safe headers, rate-limit costly operations, and redact logs.
Set operations dashboard budgets before implementation: LCP under 2.5 seconds at the 75th percentile, INP under 200 milliseconds, CLS under 0.1, and a justified client-JavaScript budget for the main route. Record the baseline, test with realistic data and network conditions, and explain any exception.
Use separate operations dashboard prompts for discovery, specification critique, route skeleton, one vertical slice, accessibility review, security review, test gaps, and release readiness. Each prompt must attach the relevant files and forbid broad unrelated changes.
Test operations dashboard domain functions, components with user behavior, server boundaries, permissions, and the primary end-to-end path. Include malformed input, slow networks, empty data, concurrent changes, forbidden access, keyboard use, zoom, and recovery. Deploy an immutable build to preview, verify environment values, rehearse migration and rollback, run smoke tests, then observe errors and core user actions.
Build a research workspace that streams progress and prose while preserving source identity, uncertainty, cancellation, cost boundaries, feedback, and recovery. The interface must distinguish model output from verified citations and remain usable through partial failure.
The current artifact for capstone three: ai-native research workspace with streaming and citations is capstone/stream-protocol.ts. Before editing, predict the visible behavior and name the source of truth. Then implement or study this complete focused slice:
Scenario: The workspace merges citations by display order; a retry changes order and attaches a credible source to the wrong claim.
Evidence to collect: Inspect stable source IDs, stream event ordering, claim-citation mapping, retry semantics, terminal states, persisted partial work, and cost logs.
Minimal repair rule: For ai-native research workspace with streaming and citations, correct the first boundary that violates the documented model, preserve the rest of the working path, and add a regression check based on the observed evidence.
Specify the stream protocol and citation model before UI, then simulate disconnect, duplicate event, stale retry, unsafe tool request, and cancellation.
Build a research workspace for a clearly named primary user. The product must solve one complete workflow rather than imitate a gallery screenshot. Write three user stories in the form As a … I need … so that … and attach an observable acceptance criterion to each.
Create an information map for the research workspace before components. Define the nouns, their relationships, stable identifiers, ownership, retention, and which fields are sensitive. Then write a route table containing purpose, rendering strategy, data owner, loading state, empty state, error state, and authorization rule.
The complete research workspace workflow must work by keyboard at 320 pixels and 200% zoom. Provide one H1, logical headings, named landmarks, persistent labels, useful errors, predictable focus, status announcements, reduced motion, and sufficient contrast. Test with a screen reader; automation alone is insufficient.
For the research workspace threat model, list assets, actors, entry points, trust boundaries, abuse cases, controls, and residual risk. Validate on the server, authorize every protected action, keep secrets out of the browser, escape untrusted output, set safe headers, rate-limit costly operations, and redact logs.
Set research workspace budgets before implementation: LCP under 2.5 seconds at the 75th percentile, INP under 200 milliseconds, CLS under 0.1, and a justified client-JavaScript budget for the main route. Record the baseline, test with realistic data and network conditions, and explain any exception.
Use separate research workspace prompts for discovery, specification critique, route skeleton, one vertical slice, accessibility review, security review, test gaps, and release readiness. Each prompt must attach the relevant files and forbid broad unrelated changes.
Test research workspace domain functions, components with user behavior, server boundaries, permissions, and the primary end-to-end path. Include malformed input, slow networks, empty data, concurrent changes, forbidden access, keyboard use, zoom, and recovery. Deploy an immutable build to preview, verify environment values, rehearse migration and rollback, run smoke tests, then observe errors and core user actions.
Goal: Advance an independent portfolio-grade product through one learning outcome at a time while keeping the implementation understandable and reversible.
Context to attach: the current portfolio capstones outcome, the product brief, repository rules, package versions, relevant files and callers, shared types or tokens, the current Git diff, and the latest observed failure or command output.
Constraints: while advancing an independent portfolio-grade product, preserve concurrent work; use semantic HTML and strict TypeScript; keep Server Components as the default in Next.js; validate untrusted data on the server; do not expose secrets; include loading, empty, error, success, disabled, and partial states when relevant; make one bounded change.
Acceptance criteria: the portfolio capstones adaptation works from 320 pixels upward; keyboard and focus behavior are complete; color is not the only signal; authorization and validation are enforced at authoritative boundaries; the relevant type, lint, build, and browser checks pass.
Reusable prompt:
We are implementing one outcome from “Portfolio Capstones: Three Production-Grade Frontend Projects” in the Learning Atlas. Read the attached repository rules, outcome text, relevant files, current diff, and verification evidence. Restate the user-visible result, source of truth, trust boundary, valid states, and unknowns. Propose the smallest reversible vertical slice. Implement only that slice. Then report the exact diff, criterion-to-evidence mapping, remaining risks, and the next discriminating check. Stop before dependency installation, destructive action, public-contract change, authentication decision, or deployment unless explicitly authorized.
For Portfolio Capstones: Three Production-Grade Frontend Projects, inspect the response without relying on its summary. Read every changed line, compare it with the actual source of truth, and reproduce the evidence yourself. Reject unexplained assertions, broad client boundaries, missing states, invented APIs, suppressed errors, or tests that merely restate implementation details.
Choose one capstone's core workflow and inject a forbidden request during a slow partial response. Prove authorization, accessible recovery, telemetry, data consistency, performance budget, and rollback. Write exact reproduction steps and expected versus observed behavior. Follow the value across every relevant boundary until you find the first contradiction.
Within the design and verify stage of Portfolio Capstones: Three Production-Grade Frontend Projects, change one cause, not several symptoms. Rerun the original reproduction, one adjacent failure case, keyboard navigation, and the focused static checks. The lab is complete only when you can explain why the repair works and which regression check would have failed before it.
Run the scripts that this project actually defines:
If your learning project later defines a test script, run it as an additional gate; do not report tests as passing when no test command exists. In the browser, demo the acceptance criteria, explain major tradeoffs, pass accessibility and security reviews, and deploy with a tested rollback. Repeat the primary journey at 320, 768, and wide desktop widths, at 200% zoom, in both themes, by keyboard, and with reduced motion. For networked work, simulate slow, malformed, unauthorized, empty, and failed responses.
Close Portfolio Capstones: Three Production-Grade Frontend Projects and draw its models from memory. Pick two outcomes and explain how a decision in the first can cause a failure in the second. Then complete three levels of practice:
You have treated portfolio capstones as a connected engineering system rather than isolated syntax. The durable result is not the example code; it is the ability to predict behavior, expose assumptions, collect evidence, bound AI work, and repair the first broken boundary. Carry the product files and evidence log into the next stage.