Lesson 3: The bounded change, watched task by task
Objective
The starter passes all nine tests through a sequence of bounded changes,
the workspace Git state proves nothing else moved, and you can explain
every edit without reading the solution first.
Why this lesson exists
This is the lesson people skip — and the one that builds the actual skill.
Letting an agent rewrite the file in one shot teaches you nothing and
leaves you a change you cannot honestly review. Supervising small changes,
each pinned to a contract line, is how the code stays yours. ZCode keeps
the Git state next to the execution — after each task you can see exactly
what moved, which makes “did it stay in bounds” a look, not a guess.
The lesson
With the goal and task list from Lesson 2 approved, let execution begin —
one task at a time, with python verify.py starter between tasks as the
plan says.
Hold it to the contract’s boundaries:
- Only
starter/report_tool.py changes. Check the Git state after every
task: if tests/, solution/, or scenario/ moved, stop the goal and
use its recovery to back up rather than stacking corrections.
- No new imports outside the standard library.
- Each task should move toward one contract line. Reject drive-by
refactors (“while I was here I renamed…”).
- If the agent wants to change a test, the answer is no. Tests are the
contract; the code moves.
Review deliberately between tasks. The Git state shows the diff; read the
hunks, not just the task’s self-report. A change you cannot explain is a
change you recover away from — Goal Mode’s job is managing exactly that:
restart the step with a tighter instruction instead of piling fixes onto
a bad state.
Expect the failing count to drop task by task: 7 → 5 → 4 → 3 → 2 → 0.
Exercise
Pick one change the agent made — ideally the validation-isolation step —
and find it in the Git diff. Explain it back: “this hunk does X; that
satisfies contract line Y.” If you cannot, have the agent walk you through
that hunk before the next task runs.
Checkpoint
Run python verify.py. This checkpoint’s code appears only when
the starter suite is green. You pass the lesson when you can answer:
- How many tasks did the bounded change take, and what made each task
bounded?
- Which change did you reject or recover from, and why?
- Point at the hunk that implements “isolate invalid rows with reasons”
— where is it in the diff?
Expected evidence
A green python verify.py starter run, a Git diff confined to
starter/report_tool.py, and your hunk-by-hunk explanation of it.
