Build core workflows 2 and 3

Why this matters

On Day 82 you built one vertical slice with Codex, and on Day 84 you reordered the backlog by value and risk. Today you take the top two items off that list and build them — as two separate tasks, two separate Codex sessions, two separate commits — without breaking the workflow that already works.

By the end of the hour your capstone has three complete workflows a user can run start to finish, and your automated checks still pass on all three. That last clause is the hard part, and it is what today teaches.

Issue-sized tasks

An issue-sized task is a piece of work small enough that you can hold all of it in your head while you review it. Three practical tests:

• One user-visible outcome. "A technician can close a maintenance record" is one. "Finish the maintenance module" is not.
• One sentence of done. If you cannot write the finishing condition in a single sentence without "and", the task is two tasks.
• A diff you can actually read. Roughly a few hundred changed lines. Past that, review turns into skimming, and skimming is how defects get committed.

Write the task down before you open Codex. A written task is a thing you can compare the result against; a task that only exists in your head quietly reshapes itself to match whatever you got.

Shared contracts

A contract is an agreement about the shape of data crossing a boundary in your system. You have three of them, and you have been using them since Week 10 without necessarily naming them:

• Database ↔ server — the table and column names and types, from your Week 7 schema.
• Server ↔ browser — the URL, method, request body, response body, and status codes of each endpoint, from your Week 6 API design.
• Inside the frontend — the TypeScript types your components read, from Week 5.

Contracts matter today because a new workflow usually touches all three at once. If you let each layer get built with its own idea of the shape, you get bugs that no single file explains: the server sends created_at, the component reads createdAt, and the screen shows "Invalid Date" with nothing in the logs.

So write the contract first, in the task note, before any code exists:

POST /api/records
  body:     { equipmentId: number, note: string, status: "open" | "closed" }
  201 body: { id: number, equipmentId: number, note: string, status: string,
              createdAt: string }   // ISO 8601 timestamp
  400 body: { error: string }       // validation failed
  404 body: { error: string }       // equipment id does not exist

Twelve lines of text that keep three layers agreeing. They also give Codex something exact to implement instead of something plausible to invent.

Regression checks

A regression is new work breaking something that already worked. It is the most common way a project stops progressing: every feature added costs one feature quietly lost.

The defence is the check command you set up on Day 81 — lint, typecheck, unit tests, integration tests — run at two moments:

1. Before you start, on a clean tree. This gives you a baseline. If checks are already failing and you do not know it, you will spend the hour blaming your new code.
2. After the change, before you commit. Anything that went from passing to failing is your regression, and it is much cheaper to find now than tomorrow.

And this is why each workflow gets its own commit: separate commits are easier to review, easier to revert, and easier to understand later. If workflow 3 turns out to be broken, git revert on one commit removes exactly workflow 3. If both workflows share a commit, reverting throws away work that was fine.

Working with AI today: pair mode

Today's mode is pair. Codex proposes, you verify. The rule has not changed since Day 34: before you accept an AI-generated change, inspect the diff, run your checks, and be able to explain the behaviour. Not "it looked reasonable" — you should be able to narrate each changed section and say what it does.

Walkthrough

Do workflow 2 together, then repeat the same shape for workflow 3.

cd ~/fullstack-journey/capstone
git status --short
npm run check

git status --short printing nothing means the working tree is clean — a clean starting point, so every line in the diff later is yours. npm run check is your Day 81 script; note whether it passes. That is your baseline.

Write the task note. Keep it in the repo so it is reviewable:

mkdir -p docs/tasks

Put the outcome, the done condition, and the contract block into docs/tasks/workflow-2.md. Then open one Codex session, give it the pair-mode prompt above plus the task note, and read the plan.

When the change lands, look at its size before its content:

git diff --stat

 src/api/records.ts        | 48 ++++++++++++++++++++++++++
 src/db/queries/records.ts | 22 ++++++++++++
 src/ui/RecordForm.tsx     | 61 +++++++++++++++++++++++++++++++
 3 files changed, 131 insertions(+)

Three files, 131 lines — reviewable. If it were thirty files, the task was too big; reset and split it. Now read each file with git diff, then run the checks again and commit:

npm run check
git add -A
git commit -m "Add record-closing workflow with validation"

Your turn

Build workflows 2 and 3, one at a time.

1. Run git status --short and npm run check. Write the baseline result in your notes: passing, or passing-except-these.
2. Take the top backlog item from Day 84. Write docs/tasks/workflow-2.md: the user-visible outcome, a one-sentence done condition, and the request/response contract.
3. Open a Codex session with the pair-mode prompt. Read the plan and the assumptions list. Correct any wrong assumption before implementation starts.
4. When it finishes, run git diff --stat, then read the full diff file by file. Anything you cannot explain, ask about — do not accept it.
5. Run npm run check. If something that passed at step 1 now fails, that is a regression: fix it before continuing.
6. Exercise the workflow yourself in the browser, end to end, as a user would.
7. Commit it alone, with a message naming the user-visible outcome.
8. Repeat steps 2–7 for workflow 3, in a new Codex session so the context starts clean.

Common pitfalls

• Both workflows in one commit. It feels tidy and costs you the ability to revert one. One outcome, one commit.
• Letting the response shape drift. Codex invents a field name, the UI is written against it, and now the contract is whatever was generated. Compare the actual response against your written contract before you accept.
• Skipping the baseline run. Without it you cannot tell "I broke this" from "this was already broken", and you will debug the wrong change.
• Trusting green checks instead of reading the diff. Checks only prove the cases you wrote tests for. They do not prove the code does what you meant.

Verify it yourself

Open today's reference, the Codex CLI documentation, and find how it describes reviewing and approving changes before they are applied.

1. What control does the CLI give you over approving edits or commands? Compare that to how you worked today — were you using the strictest useful setting?
2. This lesson claimed a session should cover one task. Find whether the docs say anything about scoping a session or providing project instructions, and note whether they agree.

Record one line in your notes: the setting you use from now on, and why.