FS26
Ctrl K
Phase 06 · Lesson 13

Mastery Capstone Lab

≈ 2 min core reading · 207 source/companion words
Learning contract

What you should be able to do after this

  • Explain Mastery Capstone Lab without relying on framework buzzwords.
  • Connect the lesson to the phase outcome: Connect Next.js and NestJS through an explicit, debuggable HTTP boundary with environment-safe base URLs and correct CORS behavior.
  • Reproduce the relevant behavior and verify it with evidence.
  • Diagnose at least one representative failure instead of guessing.
Figure 6.13 — TaskFlow boundary map
Next.js component/action
API client
HTTP request
CORS/origin rules
NestJS
HTTP response
UI state
This lesson belongs to Phase 06. Keep the full request/data path visible even when today's code changes only one box.
Instructor workflow: predict first → implement the smallest slice → run it → inspect evidence → break one assumption → diagnose → explain it back. Do not copy the whole code block before understanding the first failing boundary.

Mastery Capstone Lab

This is the transfer exercise for Phase 06: Next.js <-> NestJS Communication. The detailed lessons are now closed-book reference material. Your task is to prove that the phase outcome can be reproduced from requirements, repository evidence, and debugging—not by copying a finished implementation.

Target artifact A typed API client boundary that can call the NestJS health/tasks endpoints from the appropriate Next.js execution context.

Acceptance criteria - Write the behavior and constraints before implementation. - Identify the owning layer and every boundary crossed. - Implement the smallest complete vertical slice. - Verify the happy path from outside the implementation. - Demonstrate at least one expected failure path. - Run the phase-relevant quality checks. - Review the diff for accidental duplication, leaked responsibilities, missing validation/authorization, and hidden environment assumptions.

Evidence packet Save the command/request used, expected result, actual result, one failure reproduction, the fix, and a short explanation of why the final responsibility belongs where it does. This packet is more valuable than a screenshot of a green page because it demonstrates repeatable engineering reasoning.

Stretch Change one requirement after the first implementation. Measure which files must change. If a tiny domain change causes unrelated layers to move, use that evidence to discuss coupling before adding another abstraction.

Executable lesson studio · next

Now turn the explanation into engineering skill.

A guided lesson proves you can follow. A capstone proves you can transfer the model to a requirement with fewer cues.

By the end, you should be able to

  • Connect Next.js and NestJS through an explicit, debuggable HTTP boundary with environment-safe base URLs and correct CORS behavior.
  • Produce a reproducible evidence packet for success and failure.
  • Defend the architecture and identify one improvement without overengineering.
Figure 6.13B — Mental model
Next.js component/action
API client
HTTP request
CORS/origin rules
NestJS
HTTP response
UI state
Read left-to-right while implementing. When debugging, walk right-to-left until the first observed fact differs from your prediction.
Code-along sequence

One coherent change at a time

  1. 01

    Define API base URLs per environment instead of hard-coding localhost throughout components.

  2. 02

    Call a public endpoint from a Server Component and inspect where the request originates.

  3. 03

    Call an endpoint from a Client Component and observe browser CORS behavior.

  4. 04

    Configure NestJS CORS for the exact development origin and credentials policy required.

  5. 05

    Centralize response parsing and non-2xx error handling in one API helper.

  6. 06

    Use Network tab plus API logs to trace one failing request end-to-end.

  7. 07

    Run the phase mastery checklist without looking at the provided implementation.

  8. 08

    Perform a short architecture review and document one trade-off you consciously accepted.

txtCapstone evidence packet
Requirement -> implementation diff -> verification -> controlled failure -> diagnosis -> final proof

Do not copy this as a finished answer. Predict what each boundary does, type the smallest useful slice, run it, then compare the result with your prediction.

Verification

Prove the happy path

  1. Can locate a failure on frontend, network, or API side
  2. Can explain CORS as a browser policy
  3. Can configure environment-specific API URLs
  4. Can build one reusable request helper
Break it on purpose

Build debugging memory

  1. Using the browser-only URL from server-to-server code in deployment
  2. Wildcard CORS with credentials
SymptomInvestigation path
You can only continue by copying the reference

Return to the mental model and acceptance criteria. Rebuild one smaller slice from first principles before reopening the source.

Everything seems to work but proof is weak

Choose an external observer: HTTP client, browser, database query, test runner, health endpoint, or deployment log, and capture deterministic evidence.

Closed-reference challenge

Can you transfer the idea?

Extend the phase artifact with one requirement not used in the guided example while preserving the same ownership rules and verification strategy.

Explain-back

Answer these without reopening the solution

  1. What did you build without a transcript?
  2. Which boundary caused the most reasoning effort?
  3. Which failure gave the strongest evidence?
  4. What shortcut did you deliberately avoid?
  5. What would you automate before repeating this in a team?
Lesson studio

Turn the reading into skill

01

Do it

Define API base URLs per environment instead of hard-coding localhost throughout components.

Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.
02

Break it safely

Using the browser-only URL from server-to-server code in deployment

Predict the symptom before causing the failure. Then locate the earliest boundary where reality diverges from expectation.
03

Explain it back

Why does this responsibility live here, what input does it trust, what output proves success, and what would go wrong if another layer owned it?

If your explanation is vague, repeat the boundary trace before moving on.
Exit ticket

Before marking complete

Close the reference. Reproduce the core idea from memory or explain the exact request/data flow aloud. Then check your diff or notes for accidental shortcuts that bypass validation, authorization, error handling, or verification earned in earlier phases.

← Phase Synthesis & Independent ChallengePhase review →