Your First Typed Next.js App

Build a typed Next.js screen with a Go service boundary and private release.

Introduction

30 Second Summary

Changing careers becomes easier to defend when you can show the decisions behind your work. A working screen gains credibility when its evidence tells the same story.

In this project, you will ship a private Next.js 16 screen backed by the given Go service. You will use Cursor with Grok for one controlled draft while you keep ownership of every engineering decision.

What You'll Build

When you demo the finished project, you can send hello from the browser through a typed server boundary to the given Go service.

By the end of this project, you'll have:

A working full-stack screen that changes from status: checking to status: ok when the service responds. The page also shows reply: hello.
Clear boundary evidence proving that the browser calls only the Route Handler. The typed api stays server-only with the service address.
A validation record covering the green checks plus both deliberate failures. The project returns to green after each boundary test.
A review trail that separates Grok's untouched draft from your changes. A private GitHub release named v0.1.0 includes your two-minute recording.

Are there any prerequisites?

You need the supplied commands, files, prompts, examples, and a GitHub account. You will use the fixed scaffold without adding another version, installation step, file, or project.

Before We Start

Before any hands-on work, commit to a reviewed contract that guides the screen through a server-only boundary. You will also define the evidence that makes the private release ready for an interview.

Set Up the Project

Your full-stack path crosses a Next.js 16 app and a Go service. The supplied scaffold freezes that path so five tool checks can prove your machine is ready without adding versions or setup work.

The workflow also relies on Git, GitHub CLI, and Cursor with Grok. In this step, you will prepare the supplied project exactly as given.

In this step, get ready to:

Prepare the supplied first-screen scaffold in your home folder.
Pass the five supplied tool checks.
Open the supplied file tree in Cursor with Grok available.

Prepare the supplied scaffold

The home folder gives everyone the same starting location. Keeping the supplied scaffold unchanged preserves the project contract before any implementation begins.

Press Cmd+Space on macOS or the Windows key on Windows to open your search bar.
Use your application launcher on Linux.
Type Terminal on macOS or Linux and press Enter.
Type PowerShell 7 on Windows and press Enter.
Run the supplied scaffold command exactly as printed in the Setup section of your project materials.
Wait for the supplied scaffold command to return control to your terminal.
Move into the fixed project folder by running this command:

cd ~/first-screen

Why start every terminal here?

Every later command expects first-screen to be the current folder. Starting in the same place keeps commands pointed at the supplied scaffold.

The supplied scaffold output should finish without a reported failure. Your terminal is now working from ~/first-screen.

Pass the five supplied checks

Each supplied check confirms one part of the fixed toolchain. A matching result means you can follow the pinned workflow without introducing another version or installation path.

Return to the five supplied check lines in your project materials.
Run each supplied check exactly as printed.
Compare each result with the supplied expected result.
Choose the tab that matches what your terminal reports.

✔️ All five checks match

Good work. Your five checked tools match the reproducible path required by this project.

ⓧ A check shows the wrong supplied version

A version mismatch means that tool falls outside the supplied project path.

Match the failed check to its supplied setup instruction.
Apply only that supplied setup instruction.
Start a fresh terminal if the supplied instruction requires it.
Begin the fresh terminal with the project-folder command shown above.
Run the failed supplied check again.

ⓧ A command is unavailable

An unavailable command identifies the one missing tool that needs attention.

Match the unavailable command to its supplied setup instruction.
Install only the missing tool through that supplied instruction.
Start a fresh terminal if the supplied instruction requires it.
Begin the fresh terminal with the project-folder command shown above.
Run the missing supplied check again.

What the supplied setup readies

Node.js and npm provide the runtime and package path for Next.js 16.
TypeScript checks the generated contract types across the application boundary.
openapi-typescript generates the declarations stored in src/lib/schema.d.ts.
openapi-fetch provides the typed client used by api.
Vitest runs the supplied component unit tests.
Playwright drives the supplied browser test through Chromium.

Run the supplied project-library setup lines exactly as printed.
Run the supplied test-browser setup line exactly as printed.
Rerun all five supplied checks.
Compare the final results with the supplied completion notes.

All five checks should now match their supplied results. The supplied setup should also report completion for the required libraries and Chromium.

Still seeing a failed check?

Match the failed result to the corresponding supplied setup entry.
Run only the setup entry for that failed result.
Start a new terminal after a setup change that affects your shell.
Return to ~/first-screen with the folder command from the previous substep.

Still blocked? Help me diagnose which supplied tool check is failing.

Open the scaffold in Cursor

Cursor gives you one place to inspect the supplied boundary before the contract work begins. The file tree also proves that the application code and test evidence arrived together.

Press Cmd+Space on macOS or the Windows key on Windows to open your search bar.
Use your application launcher on Linux.
Type Cursor and press Enter to open it.
Open Cursor's folder picker.
Select the first-screen folder from your home folder.
Confirm the workspace name shows first-screen.
Open the AI chat panel from the right sidebar.
Inspect the model selector at the top of the chat panel.
Confirm Grok is available without sending a prompt.

Before you compare the file tree, do you expect every supplied path to be present without creating another file?

Compare Cursor's file tree with the supplied artifact checklist below.

What should the scaffold contain?

The top level contains .gitignore, openapi.yaml, playwright.config.ts, vitest.config.mts, and the README.md skeleton.
The service folder contains go.mod and main.go.
The src tree contains the supplied page, Route Handler, form, unit test, typed client, and generated schema declarations.
The e2e folder contains echo.spec.ts.
The docs folder contains requirements.md, decisions.md, architecture.md, limits.md, pr-1.md, pr-2.md, and the page.png placeholder.

You should see the complete supplied tree in Cursor. You should also see Grok available in the model selector.

✔️ Awesome, I've got everything!

Strong start. Your supplied scaffold is open from ~/first-screen with the checked toolchain ready.

ⓧ I'd like to double check the full code

This setup step keeps every supplied source file unchanged. Compare each file with the original project materials.

.gitignore contains the supplied complete file content from the project materials.
README.md contains the supplied README skeleton to be completed with the actual operating system, real minutes, N, removed any values, review decision, reviewer, and talk-track outline.
e2e/echo.spec.ts contains the supplied complete browser test source from the project materials.
openapi.yaml contains the supplied complete API contract from the project materials.
playwright.config.ts contains the supplied complete Playwright configuration from the project materials.
service/go.mod contains the supplied complete Go module definition from the project materials.
service/main.go contains the supplied complete Go echo service source from the project materials. It runs with go -C service run . and listens on 127.0.0.1:8080.
src/app/api/echo/route.ts contains the supplied complete Next.js Route Handler source from the project materials.
src/app/page.tsx contains the supplied complete Next.js page source from the project materials.
src/components/echo-form.test.tsx contains the supplied complete EchoForm unit test source from the project materials.
src/components/echo-form.tsx contains the supplied complete EchoForm source from the project materials.
src/lib/api.ts contains the supplied complete typed server-only API client source from the project materials.
src/lib/schema.d.ts contains the supplied complete generated TypeScript schema declarations from the project materials.
vitest.config.mts contains the supplied complete Vitest configuration from the project materials.

Your reproducible scaffold is ready. Next, you will place the design documents and reviewed contract ahead of the screen implementation.

Design the Contract

Your first-screen setup is ready. The remaining risk is letting the screen invent its service boundary during implementation.

Contract-first development puts reviewed design evidence ahead of screen code. This makes the implementation follow a shared boundary from its first commit.

In this step, get ready to:

Confirm the six supplied design documents are present in full.
Create the private review space for two planned issues.
Merge the contract pull request before the screen branch exists.

Place the design documents

Each supplied design document captures one part of the boundary before implementation begins. The openapi.yaml file turns those decisions into a reviewable API agreement.

Complete the documentation part of the supplied Design commands exactly as provided.
Compare docs/requirements.md with the supplied complete requirements document.
Compare docs/decisions.md with the supplied complete decision-record document.
Compare docs/architecture.md with the supplied complete architecture document.
Compare docs/limits.md with the supplied complete limits document.
Compare docs/pr-1.md with the supplied contract pull-request evidence document.
Compare docs/pr-2.md with the supplied screen pull-request evidence document.

Good progress. The six design files now tell one consistent story before any screen branch exists.

Why contract-first development?

An OpenAPI contract gives both sides the same field names. It defines Echo around the message field.

The generated src/lib/schema.d.ts lets the api typed client carry that agreement into Next.js. Reviewers can catch contract drift before the browser depends on it.

The architecture document keeps the Go service at 127.0.0.1:8080 behind a server-only boundary. The browser reaches it through the Route Handler.

Create the private review space

Delivery evidence needs a private home where planned work stays visible. A private GitHub repository holds the review history.

A private GitHub Project keeps both issues together. Those issues define the work that the two pull requests deliver.

Switch back to the terminal from setup.
Complete the private repository part of the supplied Design commands exactly as provided.
Open the resulting repository in your browser to confirm its visibility is private.

You should see first-screen identified as a private repository.

Return to the terminal from setup.
Complete the two-issue part of the supplied Design commands exactly as provided.
Complete the private project part of the supplied Design commands exactly as provided.
Open the resulting GitHub Project in your browser.
Count the issues shown in the project.

You should see exactly two issues in the private project. Neither issue needs to be closed during this design step.

You have the review queue in place. Both planned changes now have a private path from issue to pull request.

Private review space incomplete?

Confirm each supplied GitHub command completed before you moved to the next command group.
Check that the GitHub CLI session uses the account where you expect first-screen to live.

If the repository or either issue is missing, help me diagnose the incomplete private GitHub setup.

Merge the contract before screen exists

In Git, branch order records when implementation became possible. Merging contract first proves the screen follows a reviewed boundary.

Return to the terminal from earlier.
Complete the contract branch and pull-request part of the supplied Design commands exactly as provided.
Open the contract pull request in the private first-screen repository.
Confirm src/lib/schema.d.ts expresses the generated contract declarations.
Confirm api remains server-only.
Confirm Echo contains message.
Confirm 127.0.0.1:8080 stays behind the Route Handler boundary.
Confirm the browser boundary ends at the Route Handler.

What is this review proving?

The generated schema preserves the field names defined by the API contract.
The api client can reach the Go service without exposing its address to browser code.
The Route Handler gives the browser one controlled endpoint for the echo request.

Complete the supplied review step for the contract pull request.
Merge the contract pull request through the supplied Design workflow.

Before the final supplied verification, which implementation branch do you expect to be absent?

Complete the final verification part of the supplied Design commands exactly as provided.

You should see the contract pull request recorded as merged. The branch list should contain contract without screen.

The private GitHub Project should show two issues. Cursor should still show all six design documents in full.

The reviewed boundary should define src/lib/schema.d.ts from the API contract. It should keep api server-only.

The Echo type should expose message. The Go service address should remain 127.0.0.1:8080 behind the Route Handler.

That is the design gate cleared. Your repository history now proves the contract landed before screen work began.

Your reviewed boundary is now fixed in the repository history. Next, you will build the screen through separate commits that preserve authorship decisions.

Build the Typed Screen

Contract-first development has fixed the Echo shape before screen exists. The merged contract pull request in GitHub gives the implementation a reviewed boundary from its first commit.

Grok drafts only EchoForm. A dedicated untouched-draft commit preserves that handoff.

Separate commits prove what you typed. The final review commit shows what changed after your line-by-line review.

In this step, get ready to:

Establish the screen branch with a dedicated typed-client commit.
Preserve the untouched Grok draft with its recorded count N.
Complete the remaining commit sequence through the reviewed form.

Create the screen branch and typed client

The typed client api connects the generated TypeScript contract to the Go service. Its server-only boundary keeps the service address out of browser code.

Switch back to the terminal in ~/first-screen from the previous step.
Run the supplied Build command that refreshes the merged contract state.
Run the supplied Build command that creates screen from that state.
Confirm the terminal names screen as the active branch.

Why branch timing matters

Creating screen now proves the contract landed first. The screen history therefore starts from the reviewed API agreement.

Switch back to src/lib/api.ts in Cursor.
Compare the file with the supplied complete source.
Confirm api uses the generated declarations in src/lib/schema.d.ts.
Confirm the service address comes only from the supplied server-only environment variable.
Create the dedicated typed-client commit by running the supplied Build command.
Check the source-control history in Cursor.

You should see a new commit dedicated to src/lib/api.ts. That first checkpoint now proves the server boundary existed before the screen.

Typed-client commit missing or mixed

Confirm the active branch is screen.
Use the supplied Build sequence again if the commit contains files beyond src/lib/api.ts.
Compare the file with the supplied complete source if api or the server-only boundary is missing.

Still stuck? Help me diagnose why my typed-client commit does not contain only src/lib/api.ts.

Capture the untouched Grok draft

A Client Component owns the form state and browser event handlers. Preserving Grok's first draft creates a baseline you can inspect before applying engineering judgment.

Switch to the Grok panel in Cursor.
Start the constrained draft request by pasting this exact first line:

Using @src/lib/api.ts, write only src/components/echo-form.tsx from the five points below. Run no commands. Edit no other file.

What does this prompt control

The file reference grounds the draft in the typed client you just committed.
The one-file limit prevents Grok from changing the page or server boundary.
The command restriction keeps execution decisions with you.

Append the supplied numbered list of five form requirements beneath the prompt without changing its format.
Send the complete request to Grok.
Decline every command Grok offers.
Apply only the draft for src/components/echo-form.tsx.

Protect the draft baseline

The next commit captures Grok's output before your review. Keeping it untouched makes every later improvement visible in the history.

Leave the generated form unchanged before counting it.
Run the supplied counting step against the untouched draft.
Record N here: your untouched draft count.
Create the untouched-draft commit by running the supplied Build command.
Confirm the source-control history shows a dedicated Grok draft commit.

You now have an inspectable AI baseline with its count preserved. Your later review can change the form without rewriting its origin story.

Draft changed extra files

Use the supplied restore step for any Grok change outside src/components/echo-form.tsx.
Resend the exact prompt if Grok explains the form without producing the requested file.
Recount N if the draft changed before its commit.

Need help protecting the baseline? Help me preserve the untouched Grok draft without changing other files.

Complete and review the typed path

The Next.js 16 page uses Cache Components to preserve its prerendered shell. The Route Handler owns request-time communication with api.

Switch back to src/app/page.tsx in Cursor.
Follow the supplied page instructions to place the complete source exactly.
Save src/app/page.tsx.
Confirm the page uses Cache Components with EchoForm.
Create the dedicated page commit by running the supplied Build command.
Check the source-control history for the new page commit.

You should now see the typed-client commit, untouched-draft commit, and page commit as three separate entries.

What the page contributes

The page supplies the prerendered shell around the interactive form. Request-time service communication stays behind the Route Handler.

Switch back to src/app/api/echo/route.ts in Cursor.
Follow the five supplied prose steps in their original order to type every Route Handler line yourself.
Save src/app/api/echo/route.ts.
Confirm the file exports POST(req: Request).
Confirm the handler validates message against the contract.
Confirm the handler calls api on the server.
Create the dedicated Route Handler commit by running the supplied Build command.
Check the source-control history for the new Route Handler commit.

You should now see four build commits. The browser-facing form still has no direct path to 127.0.0.1:8080.

What stays at the server boundary

The browser submits to /api/echo. The Route Handler validates the request before using api to contact the Go service.

The service address remains in the supplied server-only environment variable. Browser code receives only the response defined by the contract.

Use the supplied review sequence to present the current diff to Grok.
Start the strict review by pasting this exact prompt:

Review this pull request diff as a strict senior engineer. List at most three findings, each one line: the file, the problem, the fix. Do not edit files and do not run commands.

What does this review prompt control

The three-finding limit keeps the review focused on the highest-value problems.
The one-line format makes each finding answerable.
The final restriction preserves your responsibility for every edit.

Send the review prompt to Grok.
Decline every command Grok offers.
Assess each finding against the contract and server boundary.
Apply accepted fixes yourself in src/components/echo-form.tsx.
Remove every any from the reviewed form.
Use Cursor search to confirm src/components/echo-form.tsx contains zero any matches.
Confirm the reviewed form submits only to /api/echo.

What the line-by-line review proves

The untouched commit records the AI draft. The review commit records the engineering judgment you applied afterward.

Your decision record explains one accepted or rejected choice. That explanation is stronger evidence than a silent code change.

Record one line-by-line review decision in docs/decisions.md.
Add the same review decision to the supplied field in README.md.
Compare both decision entries for consistency.
Enter your actual operating system in the supplied README field.
Enter your real elapsed minutes in the supplied README field.
Confirm both environment fields display your actual values.

What the README records

The README connects the source history to your delivery evidence. It records the conditions under which you built and reviewed the screen.

Enter your untouched draft count in the supplied N field.
Enter the number of removed any values in the supplied README field.
Preserve the supplied named-reviewer placeholder for the Close-out step.
Add the supplied talk-track outline to README.md.
Review the completed README fields for missing evidence.
Create the reviewed-form commit by running the supplied Build command.
Confirm the commit includes the reviewed form and its decision evidence.

Before you check the finished history, do you expect every authorship boundary to appear as its own commit?

Run the supplied final Build verification sequence.

What should I see

Your history should show five separate build commits.

The first commit contains the server-only typed client named api.
The second commit preserves the untouched Grok-drafted EchoForm with its recorded N.
The third commit adds the Next.js page using Cache Components.
The fourth commit adds your learner-written POST(req: Request) Route Handler.
The fifth commit contains the reviewed EchoForm with its decision evidence.

The final source should contain api, Echo, EchoForm, POST(req: Request), message, and Send.

The required UI text should remain status: checking, status: ok, status: unreachable, reply: hello, and problem: the service did not answer.

The browser-facing form should call only /api/echo. The Route Handler should use api without exposing the service address.

History or boundary does not match

Compare the commit order with the five checkpoints above.
Compare each changed file with the supplied complete source.
Use the supplied Build correction sequence if one commit contains another checkpoint's files.

Need help checking the evidence? Help me compare my five build commits with the required authorship boundaries.

✔️ Awesome, I've got everything!

Your five commits now separate the typed client, untouched draft, page, Route Handler, and reviewed form. Double check that every changed file is saved.

ⓧ I'd like to double check the full code

The supplied complete files remain the source of truth. Compare these artifacts with them line by line.

Compare src/lib/api.ts with the supplied server-only typed-client source.
Compare src/components/echo-form.tsx with the supplied reviewed form source.
Compare src/app/page.tsx with the supplied Cache Components page source.
Compare src/app/api/echo/route.ts with the supplied learner-written Route Handler source.
Compare docs/decisions.md and README.md with the required review evidence.

Your typed screen now has a traceable path from browser form to server-only client. Next, you will prove that path with green checks and deliberate red cases.

Validate the Boundary

Your reviewed screen now sends browser requests through the Next.js Route Handler to the typed Go service. The service address stays on the server.

Green checks show that the complete feature works. One deliberate red case proves that TypeScript rejects contract drift.

The other deliberate red case proves that the server-only build guard blocks browser imports. You will undo both changes before this step ends.

In this step, get ready to:

Establish a green baseline across every supplied check.
Prove both service states through the browser.
Trigger both guardrails before restoring the reviewed implementation.

Establish a green baseline

A baseline combines the typecheck with Vitest component tests. Playwright then checks the browser path in Chromium.

The production build confirms that Cache Components preserve a prerendered shell. These results give each deliberate failure a trusted comparison point.

Return to the terminal in ~/first-screen from the previous step.

Before you run the baseline, do you expect all four checks to agree? Hold that prediction while you test the reviewed implementation.

Run the supplied typecheck command.
Run the supplied Vitest command.
Run the supplied Playwright command for Chromium.
Run the supplied production build command.

Your typecheck contains no error TS line. Vitest prints Tests 2 passed (2).

Playwright prints 1 passed. The build marks / as Partial Prerender.

That baseline is locked in. Every later failure can now be traced to the single deliberate change that caused it.

What Does Partial Prerender Prove?

The Partial Prerender marker means the route has a prerendered HTML shell. Request-time content renders when it is needed.

This confirms that the page preserves the Cache Components design while still supporting the live service check.

Baseline Checks Not Green?

Compare the file named by the failed check with the supplied project version.
Rerun the supplied browser setup from the setup step if Playwright cannot use Chromium.

Still stuck? Help me diagnose which validation check is failing.

Prove both service states

The live check follows the complete request path. The browser calls only /api/echo while the server reaches the Go service at 127.0.0.1:8080.

The service process keeps its terminal busy until you stop it. Use the app terminal from earlier for the supplied Next.js command.

Start the Go service from the terminal in ~/first-screen by running:

go -C service run .

What Does This Command Do?

The -C service part changes into the service directory before Go runs the package.
The run . part compiles the current Go package before starting it.
The running process listens at 127.0.0.1:8080 for requests from the server-only typed client.

Service Does Not Start?

Confirm that the terminal is inside ~/first-screen.
Stop any earlier copy of the Go service before retrying the command.

Need another set of eyes? Help me debug the Go service startup.

Leave the service terminal running.
Switch back to the app terminal from earlier.
Start the Next.js app with the supplied validation command.
Open the local page at the address printed in the app terminal.
Enter hello in the form field.

Before you submit the form, which parts of the request path do you expect to run? Keep your prediction in mind while the browser tests the boundary.

Click Send.

You will briefly see status: checking. The completed request shows status: ok with reply: hello.

Capture only the browser window.
Save the screenshot as docs/page.png inside ~/first-screen.

You now have browser-only proof of the successful path. The screenshot captures the result without exposing the service address or terminal output.

Switch back to the service terminal.
Press Ctrl+C to stop the Go service.

The service terminal returns to its prompt. The browser can no longer receive a reply from 127.0.0.1:8080.

Return to the browser page.

Before you submit again, do you expect the browser to expose a server error? Watch how the Route Handler turns the stopped service into controlled UI text.

Click Send again.

The page shows status: unreachable. It also shows problem: the service did not answer.

Still Seeing the Successful State?

Confirm that the Go service terminal returned to its prompt after Ctrl+C.
Submit the form again after the service has stopped.

If the old response remains, help me verify the stopped-service test.

Prove the guardrails and restore green

A deliberate contract mismatch proves that generated types catch drift before release. A deliberate client import proves that the server-only boundary is enforced during the build.

Each failure belongs on the main validation path. Undoing each supplied change returns the reviewed implementation to its original state.

Return to Cursor.
Apply the supplied deliberate form change to src/components/echo-form.tsx.
Save src/components/echo-form.tsx.

Before you run the typecheck, do you expect the changed form to satisfy the generated contract? Hold that prediction while TypeScript compares the two.

Run the supplied typecheck command.

The typecheck produces error TS2339: Property 'message' does not exist on type '{ text?: string | undefined; }'. at the form. This failure is intentional.

Why This Failure Matters

The generated schema defines which properties the request accepts. The deliberate form change no longer matches that contract.

The typecheck blocks the mismatch before it reaches the service. That is contract drift caught at the boundary.

Undo the deliberate form change in Cursor.
Save src/components/echo-form.tsx.
Run the supplied typecheck command again.

The restored typecheck contains no error TS line. The reviewed form matches the generated contract again.

Apply the supplied deliberate client import to src/components/echo-form.tsx.
Save src/components/echo-form.tsx.

Before you run the build, do you expect a Client Component to accept the server-only import? Keep your answer in mind while the build checks the module boundary.

Run the supplied production build command.

The build produces 'server-only' cannot be imported from a Client Component module. This failure is intentional.

What Did the Build Protect?

The deliberate import crosses the boundary from server code into a Client Component. The build guard stops that module from entering the browser bundle.

This keeps api on the server. The browser continues to call only /api/echo.

Undo the deliberate client import in Cursor.
Save src/components/echo-form.tsx.

Before the final verification, do you expect every baseline result to return? Use the same checks to prove that no deliberate change remains.

Run the supplied typecheck command.
Run the supplied Vitest command.
Run the supplied Playwright command for Chromium.
Run the supplied production build command.

The typecheck again contains no error TS line. Vitest again prints Tests 2 passed (2).

Playwright again prints 1 passed. The build again marks / as Partial Prerender.

That is the full recovery proved. The implementation is back to its reviewed state after both guardrails did their job.

Use the supplied README.md skeleton to record your observed validation evidence.
Save README.md.
Confirm that docs/page.png appears in Cursor's file list.

The README.md validation evidence now records the green checks with both deliberate failures. The project also contains the browser-only docs/page.png evidence.

Your boundary now has positive evidence from the working feature and negative evidence from both enforced failures. Next, you will take that proof through named review before packaging the release.

Review and Release the Project

Your restored green checks prove that the typed screen works across the contract boundary. The remaining work turns that local proof into private delivery evidence.

A pull request records the proposed change plus the review decisions around it. A named reviewer closes the judgment gap before you publish the two-minute release evidence.

In this step, get ready to:

Complete a named review for the screen pull request.
Confirm both issues are closed in the private GitHub Project.
Publish v0.1.0 with the two-minute recording attached.

Complete the named review

The current implementation is already green. The review now tests whether another engineer can understand the choices you made.

Return to the screen pull request in GitHub from the previous step.
Confirm the pull request description includes Closes #2.
Request a review from an actual reviewer.
Record the reviewer's displayed name here: your reviewer's displayed name.

Allow Time for Human Review

A human response may not be instant. That pause is part of a real review workflow.

Read every finding when the review arrives.
Classify each finding as accepted or rejected.
Apply each accepted fix through the supplied project workflow.
Run the supplied validation sequence after every accepted fix.
Reply to each accepted finding with accepted plus the fixing commit.
Reply to each rejected finding with rejected plus the reason.

What Makes a Review Response Complete?

An accepted response points to the commit that resolves the finding. A rejected response explains why the current implementation should remain.

Both responses preserve your engineering judgment. The pull request becomes evidence of how you evaluate feedback.

Switch back to docs/pr-2.md in Cursor.
Complete the supplied review-evidence fields in docs/pr-2.md.
Switch back to README.md in Cursor.
Replace the named-reviewer placeholder with your reviewer's displayed name.
Complete the supplied release-evidence fields in README.md.
Save the evidence files in Cursor.
Commit the evidence by following the supplied Close-out commands exactly.
Confirm the pull request checks remain green.

Select the merge control on the pull request page.
Confirm the merge when GitHub asks.

That clears the delivery gate. You will see the screen pull request shown as merged with its named review preserved.

Pull Request Not Ready to Merge?

Confirm every review conversation has a response.
Confirm the supplied validation checks still pass.
Use the original supplied workflow for any missing evidence commit.

Still blocked? Help me identify what is preventing my reviewed GitHub pull request from being merged.

Close the issues and record the talk track

The merged pull requests connect implementation work to the two project issues. The private project now provides a visible record that both pieces of work reached completion.

Return to the private GitHub Project from the Design step.
Confirm the contract issue is closed with the status Done.
Confirm the screen issue is closed with the status Done.

Both issues now connect to merged delivery work. Your private project shows a completed path from contract design to reviewed screen.

Why Did Issue #2 Close?

The merged pull request contains Closes #2. GitHub uses that closing keyword to close the linked issue when the pull request reaches the default branch.

The default project workflow moves the closed issue to Done. The issue status now reflects the merged result.

Issue Not Showing Done?

Refresh the private GitHub Project after the merge.
Confirm the merged screen pull request includes Closes #2.
Confirm the project workflow for closed issues is enabled.

Need another pair of eyes? Help me troubleshoot why my merged pull request did not move its linked issue to Done.

The talk track explains the finished boundary in plain language. It answers the server and browser question in Next.js with evidence from your screen.

Switch back to the talk-track outline in README.md.
Rehearse the outline once within two minutes.
Start the recording through the supplied recording method.
Include this exact interview question: What runs on the server and what runs in the browser in Next.js, and how do you decide?.
Explain that the Route Handler runs on the server.

Build the Answer Around the Boundary

The browser runs the interactive form. Its request stops at the Route Handler.

The server-only client connects that handler to the Go service. This separation keeps the service address out of browser code.

Explain that the server-only api connects the Route Handler to the Go service.
Explain that EchoForm runs in the browser.
Describe how Grok produced the untouched form draft.
Describe how your line-by-line review removed every any.
Point to the restored green validation evidence.
Point to the two deliberate failure proofs.
Stop the recording at two minutes.

You now have a concise explanation of the technical boundary plus the judgment behind it. That recording turns the repository history into interview evidence.

Publish release v0.1.0

A release creates a named snapshot of the delivered project. Attaching the recording keeps the implementation evidence and your explanation together.

Return to the release area of the private repository.
Start a new release.
Set the release tag to v0.1.0.
Summarize the restored green checks in the release description.
Summarize the two deliberate red cases in the release description.
Add this exact interview question to the release description: What runs on the server and what runs in the browser in Next.js, and how do you decide?.
Attach the two-minute recording to the release.
Click Publish release.

Before you check the result, do you expect the published release to show both the tag and the recording attachment?

Return to the published release page to verify the result.

You will see v0.1.0 with the two-minute recording listed as an attachment. The release description also contains the exact interview question.

Recording Missing From the Release?

Return to the release editing view.
Attach the recording through the file selector or drag it into the attachment area.
Save the updated release.

Still missing? Help me troubleshoot why my recording is not attached to my GitHub release.

Everything is complete

Your reviewed screen is merged. Both issues are complete. The private release now holds the two-minute recording.

Double-check the release evidence

Confirm the screen pull request includes Closes #2 plus the named actual reviewer.
Confirm every finding has an accepted fixing commit or a documented rejected reason.
Confirm both issues are closed with the status Done.
Confirm docs/pr-2.md contains the named-reviewer findings plus their responses.
Confirm README.md retains the actual operating system plus the real minutes.
Confirm README.md retains N plus the removed any values.
Confirm README.md contains the review decision plus the named reviewer.
Confirm release v0.1.0 contains the two-minute recording plus the exact interview question.

You have turned a typed Next.js screen into reviewed release evidence. The contract history and named review now show how you make engineering decisions.

Secret mission

Defend One Documented Limit

Choose exactly one item from docs/limits.md. Trace its impact through the shipped boundary. Defend it with the evidence you already released.

Clean Up Your Resources

The local project has no ongoing cost on the verified path used here. Your private GitHub delivery evidence also stays within the verified free path.

The tabs below cover keeping the evidence. They also cover pausing local processes or removing every resource.

Resources you used:

The local ~/first-screen folder used in Cursor.
The browser-only screenshot saved as docs/page.png.
The private first-screen repository on GitHub.
The two closed repository issues.
The two merged pull requests with the named review.
The private GitHub Project showing both issues as Done.
The named reviewer's collaborator access to the private repository.
The release v0.1.0 with the attached two-minute recording.
The local Next.js app process.
The local Go service process.

Keep everything running

No action is needed. This option keeps your private delivery evidence ready for future review.

Keep the local ~/first-screen folder as your working copy.
Keep the private first-screen repository as your reviewed code history.
Keep the private GitHub Project as evidence that both issues reached Done.
Keep release v0.1.0 as the home for your two-minute recording.
Keep collaborator access only while the named reviewer still needs the repository.

Pause - I'll come back to this later

Pausing frees your terminal sessions while every saved artifact remains in place. The private release stays ready for your next session.

If the Next.js process is still running, switch back to its terminal.
Press Ctrl+C to stop the Next.js process.
If the Go service is still running, switch back to its terminal.
Press Ctrl+C to stop the Go service.
Return to README.md in Cursor.
Add your current pause point beside the real minutes already recorded.
Save README.md.
Confirm any server terminals have returned to a prompt.

Delete - I don't want to use this again

Deletion permanently removes the delivery evidence you just built. A separate copy is the only way to preserve any part of it.

If the Next.js process is still running, switch back to its terminal.
Press Ctrl+C to stop the Next.js process.
If the Go service is still running, switch back to its terminal.
Press Ctrl+C to stop the Go service.
Delete release v0.1.0 from the private repository's releases page.
Remove the named reviewer's collaborator access from the repository's access settings.
Delete the private GitHub Project from its project settings.
Delete the private first-screen repository from its repository settings.

Your local folder is now the only remaining project resource. Use the tab for your operating system to remove it.

macOS

Finder can remove the local copy from your home folder. The deleted-items area keeps the folder recoverable until that area is emptied.

Press Cmd+Space to open macOS search.
Search for Finder.
Choose Finder from the search results.
Select your home folder in the Finder sidebar.
Select the first-screen folder.
Press Cmd+Delete to move the folder to the deleted-items area.
Empty the deleted-items area to remove the folder permanently.
Confirm first-screen no longer appears in your home folder.

Windows

File Explorer can remove the local copy from your home folder. Permanent deletion asks for confirmation before the folder disappears.

Press the Windows key to open Windows search.
Search for File Explorer.
Choose File Explorer from the search results.
Select your home folder in File Explorer.
Select the first-screen folder.
Press Shift+Delete to request permanent deletion.
Approve the permanent-deletion confirmation.
Confirm first-screen no longer appears in your home folder.

Linux

Linux file managers use different names for the same deletion controls. Permanent deletion may ask for confirmation before the folder disappears.

Open your application launcher.
Search for your system's file manager.
Open the file manager from the search results.
Select your home folder in the file manager.
Select the first-screen folder.
Choose the file manager's permanent-deletion control.
Approve the permanent-deletion confirmation.
Confirm first-screen no longer appears in your home folder.

That completes the teardown. Your local files plus private GitHub delivery evidence are now removed.

Nice Work!

You did it! You shipped a reviewed full-stack screen with a typed contract and a protected server boundary. Your private v0.1.0 release now carries the evidence behind every engineering decision.

You've learned how to:

Use contract-first development to land the contract pull request before creating screen. Build a reviewed Next.js 16 screen that stays typed from Echo to EchoForm.
Protect the server-only boundary by keeping api and the service address on the server. Make the browser call only the Route Handler through POST(req: Request).
Preserve the untouched Grok draft count N in the commit history. Remove every any during review. Prove correct behavior with green checks. Trigger both deliberate red cases. Restore every check to green.
Deliver a private GitHub release tagged v0.1.0. Attach the two-minute recording. Name the actual reviewer. Answer every finding. Merge the screen pull request with Closes #2. Close both issues. Confirm that both show Done.

Ready to quiz yourself?