Skip to content

Capstone — Production feature synthesis

Objective

Independently design, build, debug, verify, and defend a production-like Angular feature without a file-by-file recipe or early solution.

Change request

Learners need scheduled coaching sessions. Add creation, editing, filtering, persistence, and a dashboard summary. A session can be planned, completed, or cancelled; completed sessions require outcome and notes. Saving can be slow, fail, or conflict with a newer version. The workflow must remain keyboard accessible and observable without logging sensitive notes.

Required behavior

  • lazy /sessions list and /sessions/new or edit routes;
  • strict transport, domain, and form types with boundary mapping;
  • signal-derived summary counts—no synchronized duplicate state;
  • repository interface with local fake, latency, failure, and conflict simulation;
  • unsaved-change navigation protection;
  • optimistic or pessimistic save with explicit rationale and duplicate prevention;
  • loading, empty, stale, error, validation, conflict, retry, and success states;
  • focused domain, component/form, route, and repository tests;
  • no regression to existing tracker behavior.

Production constraints

Address accessibility, XSS-safe rendering, backend authorization assumptions, sensitive-data redaction, correlation/error signals, performance budget, SSR/browser globals, compatibility with an older open client, deployment sequencing, rollback, and data migration.

Working method

  1. Clarify ambiguous product and operational requirements.
  2. Produce a data-flow/trust-boundary sketch and short ADR before implementation.
  3. Record predictions and risks, then implement in small verified slices.
  4. For each failure, separate observation from hypothesis and add the narrowest regression.
  5. Compare the result with the requirements; do not compare with a provided solution.

Deliverables

  1. context, constraints, options, decision, consequences, and evidence that would reverse the ADR;
  2. implementation inside an explicit feature boundary;
  3. data-flow and deployment/rollback diagrams or descriptions;
  4. automated test output plus manual accessibility/failure checks;
  5. before/after performance evidence for one relevant budget;
  6. a five-minute design and operations walkthrough.

Design defense

Explain without notes:

  • state owners, lifetimes, source facts, and derivations;
  • concurrency, stale-write, retry, and conflict policy;
  • runtime validation and trust boundaries;
  • form, route, repository, and rendering choices;
  • test allocation and intentionally untested risks;
  • behavior under slow/offline network, JavaScript failure, keyboard-only use, SSR, failed lazy chunk, partial deployment, and rollback;
  • changes required for 100 users, 100,000 users, multiple tabs, or collaborative editing.

Mastery rubric

Area Practiced Applied Mastered evidence
Correctness happy path works failure states and invariants work adapts correctly to a changed requirement
Angular runtime APIs used correctly reactivity/DI/render consequences explained predicts and diagnoses an unfamiliar interaction
Architecture boundaries exist owners/contracts/trust/lifetimes explicit revises design when constraints change
Debugging fixes observed errors hypothesis and regression evidence recorded isolates a cross-layer failure efficiently
Testing focused tests pass risk-based boundary portfolio tests catch a deliberate behavioral mutation
Accessibility/security basic labels and safe rendering keyboard, announcements, trust boundaries verified identifies residual risk and operational control
Operations build passes telemetry, deployment, rollback considered rehearses failure and names decision signals

A score or completed checklist alone cannot mark a concept Mastered. Update the learning map, then pass a changed retrieval challenge later.

Final verification

cd basics-components
npm run build
npm test
cd ..
mkdocs build --strict

Ask another person to use the feature without explanation. Observe rather than coach. Convert each surprise into evidence, then repeat only the weak scenario with changed constraints.