Human-only rebuild checkpoint

Why this matters

Yesterday an agent wrote most of a working slice and you read every line of it. Reading is not the same as knowing. Recognising correct code is easy; producing it from an empty file is the skill that carries you through Day 89 when something breaks at the worst moment and there is nothing to read.

Today is a human-only checkpoint: AI tools closed for the whole hour. The purpose is not penance. It is measurement — it verifies your actual understanding and recall by testing whether you can reason and write code without generated answers, while the project is still small enough that a gap is fixable.

Recall and reconstruction

There are two ways to "know" a piece of code, and they feel identical from the inside.

• Recognition — you read it and nothing surprises you. This is what happens during a diff review, and it is real but shallow. Recognition fails the moment the code is not in front of you.
• Reconstruction — you can produce the thing from a blank file, given only its purpose. This is what debugging and extending require, because in both cases the code you need does not exist yet.

Recognition passes quizzes. Reconstruction ships software. The gap between them is invisible until you try to close it, which is what today's exercise is for.

The method has three steps, and doing them in order is what makes it a measurement rather than a copying exercise.

1. Write the contract first, from memory, in words. Before any code: what goes in, what comes out, what changes in the world, and what each failure case does. If this part is vague, stop — you have already found the gap, and no amount of typing will close it.
2. Write the code in a blank file, with the original closed. Documentation is allowed; documentation is how professionals work. Your own project files are not, because that is copying.
3. Compare afterwards, and write down the differences. Not to score yourself — to name them. Every difference is either a thing you did not know or a choice you would defend.

Dependency understanding

The fastest place to find a hole is at the top of the file. Open the unit you are about to rebuild and read its imports. For each one, answer without looking anything up:

• What does this give me — a function, a type, a client object?
• What breaks if I remove it?
• Did I choose it, or did the agent introduce it?

That last question matters. A dependency you did not choose is one nobody evaluated. Every import in your project should trace back to a decision — yours from Day 80, or one you consciously approved yesterday. If you find a library you cannot justify, note it; you will decide tomorrow whether it stays.

The same applies inside your own code. If src/routes/calibrations.ts imports a validate helper, you should be able to say what it returns when validation fails, because your acceptance criteria depend on the answer.

Debugging ownership

Your reconstruction will not run the first time. That failure is the most valuable part of today, because with the AI closed you must debug it the way the failure itself directs, using evidence rather than a suggestion:

1. Read the error text word by word. It names a file, a line, and a reason. Beginners skim it and start changing things; the error is usually more specific than any guess you can make.
2. Say what you expected and what happened. Out loud, in one sentence each. Often the gap becomes obvious in the saying.
3. Narrow it. Print or log at the point before the failure and at the point after the last thing you are sure about. Move those two points closer together until the bug is between them.
4. Change one thing and re-run. Two changes at once means you learn nothing from the result.

This is debugging ownership: the bug is yours, the evidence is yours, and the fix is one you can explain. A fix you accepted without understanding leaves the same bug free to reappear in a shape you will not recognise.

Walkthrough: rebuild one unit

Pick one unit from yesterday's slice — small enough to finish in twenty-five minutes. Good candidates: one API route handler, one SQL query with its constraints, one React component, or one test file. The route handler is the best choice, because it sits at the boundary where most of your understanding lives.

Make a scratch folder outside your source tree so nothing is at risk of overwriting your work:

cd ~/calibration-tracker
mkdir -p rebuild

Write the contract first, in rebuild/contract.md, from memory:

POST /api/instruments/:id/calibrations
In:      params.id (number), body { calibratedOn, technician, notes? }
Out:     201 + the created record
Changes: one new row in calibrations
Fails:   400 if calibratedOn missing or in the future
         400 if technician missing
         404 if the instrument does not exist

Now close everything and write rebuild/calibrations.ts from blank. When it is done — or when the time is up, whichever comes first — compare:

diff -u src/routes/calibrations.ts rebuild/calibrations.ts

diff -u prints a unified diff: lines starting - are in the original only, lines starting + are in yours only. Read every difference and sort it into one of three piles:

• I did not know that. The real finding. Write it down.
• I did it differently and mine is defensible. Also fine — say why in one sentence.
• I forgot it exists. Usually error handling. This is the most common pile, and the reason your failure cases deserve a second look.

Your turn

No AI for any step. Documentation and your own error output are allowed and encouraged.

1. Choose the unit and write its name at the top of docs/rebuild-notes.md. Choose the one you are least confident about, not the one you understand best.
2. List its dependencies from memory — imports, helpers, environment variables. Then open the file and compare. Note anything you missed, and anything you cannot justify.
3. Write the contract in rebuild/contract.md: in, out, changes, fails. Before any code.
4. Close every AI tool, including editor completions.
5. Write the unit from a blank file in rebuild/. Give it twenty-five minutes.
6. Make it run, and debug any failure with the four-step method above. Record the first error text verbatim in your notes, plus what it actually meant.
7. Diff against the original and sort every difference into the three piles.
8. Write the notes: what you did not know, what you would defend, what you forgot. Three sentences minimum on the first pile.
9. Commit both the reconstruction and the notes: docs: human-only rebuild of the calibration route.

Common pitfalls

• Choosing a trivially easy unit. A three-line component proves nothing. Pick the file that makes you slightly uncomfortable.
• Peeking "just to check one thing". One peek converts reconstruction back into recognition and the measurement is lost. Write the question down and look it up afterwards.
• Treating differences as failure. A difference is information. The only bad outcome is a reconstruction so guarded it reveals nothing.
• Skipping the contract because you want to start typing. The contract is where the gap usually shows first, and it takes four minutes.

Verify it yourself

Open today's reference, MDN's Dynamic scripting with JavaScript, and find the pages covering whichever language feature your reconstruction leaned on hardest — async functions, error handling with try/catch, or working with objects.

1. Find one behaviour of that feature you got wrong or were unsure about, and write MDN's answer in your own words in docs/rebuild-notes.md.
2. Find one thing the documentation covers that your original code does not handle at all. Decide whether it matters for your acceptance criteria, and add it to the backlog if it does.

Learning it from the documentation, unaided, at the exact moment you discovered you did not know it — that is the loop this whole course is built around, and today is the day you run it on your own code.