Lesson 3: The bounded change, one contract line at a time
Objective
The starter passes all nine tests through a sequence of bounded changes,
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 edits,
each pinned to a contract line, is how the code stays yours. Kimi Code’s
lane split helps: explore and plan cannot touch files at all — every
edit funnels through coder, the one lane you watch.
The lesson
With the plan from Lesson 2 in hand, tell kimi:
“Execute the plan against starter/report_tool.py with the coder
subagent. One failing test group at a time: JSON loading, then validation
isolation, then rounding, then atomic writes, then the end-to-end tests.
After each group, run python verify.py starter and show me the edit
before continuing.”
Hold it to the contract’s boundaries:
- Only
starter/report_tool.py changes. If an edit touches tests/,
solution/, or scenario/, stop and ask why.
- No new imports outside the standard library.
- Each change 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 steps. Read the actual edit, not just the
agent’s summary of it — when the two disagree, the diff is the truth. A
change you cannot explain is a change you do not keep; roll it back and
re-dispatch the step with a tighter instruction.
Expect the failing count to drop group by group: 7 → 5 → 4 → 3 → 2 → 0.
Exercise
Pick one edit coder made — ideally the validation-isolation change —
and explain it back: “line N does X; that satisfies contract line Y.” If
you cannot, ask for a walkthrough of that edit before the next step 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 steps did the bounded change take, and what made each step
bounded?
- Which edit did you reject or re-dispatch, and why?
- Point at the edit that implements “isolate invalid rows with reasons”
— where is it?
Expected evidence
A green python verify.py starter run, and your edit-by-edit explanation
of the change that earned it.
