Lesson 37.1 changed the scoreboard: judge work by delivery — promised behavior plus evidence — not by generation speed. What does a solo builder actually *do* about that, without hiring a QA department?

The five steps

Memorize this loop. It fits on an index card and handles most solo work:

1. Describe the user-visible change.
2. Inspect the affected area and agree the plan.
3. Make the smallest coherent change.
4. Review what changed and test the promised behavior.
5. Save a checkpoint and record what remains uncertain.

Each step has a job. Skip one and the cost reappears later.

1. Describe the user-visible change. One or two sentences, in user terms, before any file is touched. "On the research brief page, show each source's publication date beneath its link; sources without a date show 'Date unavailable.'" If you cannot describe the visible outcome, the task is not ready.

2. Inspect the affected area and agree the plan. Ask the model to read the relevant files and propose a minimal plan — which files, what data exists, what stays untouched: "Inspect these files. Explain the current flow. Do not change anything." You approve before edits begin. For the source-date feature, this answers the early question: does the record already carry a date, or must the data path change?

3. Make the smallest coherent change. One promise, one change, no drive-by improvements. If the model discovers the plan was wrong — the date field does not exist, the export breaks — it stops instead of improvising (see the plan-change rule below).

4. Review what changed and test the promised behavior. Read the changed-file list. Run the checks. A test is any repeatable check of expected behavior: an automated test, a deliberate browser walkthrough, a validating command, or a checked API response. Match depth to stakes.

5. Save a checkpoint and record what remains uncertain. A checkpoint is a recoverable saved version of your working files. Part X teaches the formal machinery: version history, commits, branches, and pull requests. For now: save the working state, note the evidence, write down what is still unknown.

Walk it once: the source-date feature

1. Describe: "Each citation shows its source publication date; missing dates show 'Date unavailable'; the existing export still works." 2. Inspect and plan: the model reads the research-record shape and the citation component: dates exist in the record but never reach the renderer. Plan: pass the field through, render it, handle the missing case. No fetching or navigation changes. 3. Smallest change: the model edits the mapping and the citation component only. 4. Review and test: check the changed-file list for unrelated edits, then preview three cases — dated sources, one dateless source, an empty brief. Run the export. Verify the dates against their sources rather than trusting the model's memory. 5. Checkpoint and uncertainty: save the working version and note: "Export verified manually; automated missing-date test not yet written."

No mystery about what was proven and what was not.

Five review questions anyone can ask

You do not need to understand every line of syntax to review well. Ask these five after every change:

1. Did it change only the agreed area? Any file outside the plan needs an explanation or a revert. 2. Can the AI explain each important change? "Show me the file and line for the date rendering." Vague answers fail. 3. What happens with missing, invalid, or empty input? No date. Malformed date. Empty brief. Somebody will hit each one. 4. Which evidence was actually run? "Tests pass" is not evidence. The command output, screenshot, or checked response is. 5. What remains untested? Write it down. Untested work is work whose promise is still uncovered.

Seven security questions for meaningful changes

Any change to a real application — anything beyond a throwaway mockup — also gets this second pass. A single "yes" moves the task into deliberate review:

1. Did it broaden who can read or write data? A new route, a loosened check, a shared link with the wrong default. 2. Did it put a secret in a file, browser bundle, log, or screenshot? Check the diff, the built output, and anything pasted into a chat or screenshot. 3. Did it accept untrusted input without validation? Event submissions, search boxes, uploads, webhook payloads — what happens with hostile input? 4. Did it add a dependency or external service? Who maintains it, what does it access, what happens if it disappears? 5. Did it change authentication or authorization? Login, sessions, roles, who-may-see-what — always earns direct review. 6. Did it touch payments, uploads, background jobs, or scheduled work? Money and unattended execution multiply the blast radius. 7. Did it change production permissions, settings, or infrastructure? If it affects the live system, it needs a recovery plan before it ships.

Test the events finder against these: public event submissions triggers 3 and 4; saved favorites with accounts triggers 1 and 5; a nightly "email me Saturday picks" job triggers 6 and 7.

Write the definition of done first

A definition of done is a short checklist, specific to the job, written before work starts. It stops "looks good" from becoming the only quality control.

For the source-date feature:

# DONE: source dates on brief page

- [ ] Every citation shows its publication date beneath the link.
- [ ] Sources without a date show "Date unavailable" — no blank space, no crash.
- [ ] Existing brief export still works (manual run attached).
- [ ] Changed-file list reviewed; no unrelated edits.
- [ ] Evidence: preview notes + export output saved.
- [ ] Remaining risk: no automated test for the missing-date case yet.

Five or six lines. Each one checkable. The last line — remaining risk — is mandatory: it turns "untested" from a secret into a tracked item.

Write the checklist first, then ask the AI to propose a test plan, then edit its proposal. Remove checks that do not prove your outcome; add the edge case it missed. You own the definition. The model drafts it.

Close the loop on the roadmap

A validated step leaves three traces: update the checkbox in ROADMAP.md, save the evidence beside it — not in a lost chat scroll — and save a checkpoint before the next step. Future sessions will trust the roadmap, so keep it honest.

When the plan was wrong

Sometimes validation exposes a deeper problem: the date field exists nowhere upstream, or the "simple UI tweak" requires a data-model decision with cost and privacy consequences.

Do not mark the task failed and keep coding around it. Run the plan-change loop from Class 36:

New discovery
  → stop the current task
  → state the impact on behavior, architecture, data, cost, security, and timeline
  → update the durable record (roadmap, product note, architecture note)
  → human approves the changed decision
  → create a newly bounded task and resume

Code that implements yesterday's assumptions is the raw material of spaghetti projects (Class 39). Reconcile the written record before writing more code, so the next task builds on a true plan.

Practical exercise: five lines before the next change

Before your next change — however small — write a five-line definition of done: the visible outcome, two acceptance checks, the evidence you will run, and one edge case. Ask the AI to propose a test plan, prune anything that does not prove your outcome, and add the edge case it missed.

Finish line: a DONE.md with acceptance checks, the evidence run, the result, and one remaining risk or unknown.

Verify: hand the file to a fresh AI session with the project. Can it reproduce your evidence and name what is still uncertain? If yes, the loop held.

Common failure mode: testing only the happy path. Recovery: add one missing-input case and one empty-state case to every definition of done until it becomes reflex.

Check your understanding

1. Recite the five steps. What breaks if you skip inspection? The checkpoint? 2. What is a checkpoint, and what will Part X teach as its formal version? 3. Name four kinds of tests a beginner can run. Which fits the events landing page versus scheduled briefs? 4. Which review question catches unrelated model edits, and which security question fires on public event submissions? 5. Validation shows the planned date field does not exist. What do you do before writing more code?