Build and review Field Notes

Finish the project by connecting the pieces: a notes list, dynamic note pages, a new-note form, useful loading and error states, and a health endpoint.

Review it as a system, not a set of screenshots. Write a route map that names what runs at build time, on the request-time server, and in the browser. Confirm Client Component boundaries contain only the interaction that needs them and receive serializable props.

Test direct URL loads and client navigation because they exercise different paths. Request a valid note, an unknown note, invalid parameters, and a deliberately failing data source. Slow the data request and check that the loading boundary appears without replacing more of the page than necessary.

Exercise mutations separately. Submit valid and invalid forms, repeat a request, and confirm authorization and validation run on the server. Check that committed data becomes visible through your chosen invalidation strategy. A failed write should not redirect or claim success. A disabled button improves feedback. Idempotent server behavior protects data.

npm run lint
npm run build
npm start

Run those commands from the project root. Lint should exit 0. Build should finish with route output listing your pages and /api/health. Start the production server and walk through create-note flow again. Development success is not production evidence: rendering, caching, and error output can differ.

Build once with a missing environment value and confirm the app fails fast with a clear config error. Inspect HTML and browser JavaScript for secrets. Check image candidates, font downloads, keyboard navigation, focus after errors, response statuses, and server logs.

Complete the application and write a short README with routes, runtime boundaries, configuration, cache decisions, and verification commands. Ask someone else to create and open a note using only the UI, then note every place their path differed from yours. Deployment is a separate topic covered by the Vercel course.