3 Days of Spec-Driven Development

Day 2 wrap-up

Day 2: Loops and your environment · Wrap-up · 12 min

This morning you approved each edit. Now a procedure runs without you and stops in three named ways, a critic reads what it did not write, and your environment is written down, with permission rules and one write path to match.

Review

Answer from memory before you read the recap below, then check yourself against it; there is no answer key. A question you cannot answer names, in brackets, the lesson to re-read.

  1. Name the four places drift enters the loop and one detector for each. (Lesson 1)
  2. What are the three exits a runner can take, and what different action does each one ask of you? (Lesson 2)
  3. Rewrite Is this okay? as a gate, using the three parts a gate needs. (Lesson 2)
  4. Why does the runner keep its history in a file rather than in the conversation? (Lesson 2)
  5. Your auditor returns findings on a change you already accepted. What does that cost you, and what do you fix? (Lesson 3)
  6. What does the net-zero line cap require before a new line stays in CLAUDE.md, and what is the alternative to adding the line at all? (Lesson 3)
  7. You claim your workflow change halved the iteration count. What must you have done for that claim to mean anything, and what qualifier belongs on it? (Lesson 3)
  8. Settings allow Bash(gh pr view *) and deny Bash(gh *). Which applies, and what rule of evaluation decides it? (Lesson 4)
  9. A teammate answered don't ask again last week and you are still prompted. Which file holds a rule kept to one person, and what has to happen for the team to get it? (Lesson 4)
  10. List the five properties of a vetted write wrapper and say which one a reviewer asks about first when the wrapper changes. (Lesson 4)

What you learned

Challenges

No reveals, no solutions; one is enough.

1. A gate on quality, not correctness

The gate you wrote in Exercise 1 was mechanical: a count, a file list. Replace it with one that fires when a new test asserts the behavior the code has rather than the behavior the spec names, which the runner can only judge by reading intent. Write its question, evidence and answers, then run Change B (Exercise 1's spec) in a fresh day2-work and see whether it fires on a run you would have accepted.

2. Three runs, and what three runs prove

Run the same spec three times, each in a fresh day2-work, with three CLAUDE.md variants and everything else identical: the shipped file, the shipped file plus one line you would add after today, and the shipped file minus one line you think does no work. Copy each run-log.md into ../work/ before the next reset. Write five sentences on what n = 3 does and does not let you conclude, including what changed between runs that you did not control.

3. An auditor you can trust twice

Tune .claude/agents/spec-auditor.md until it catches all six reference findings from Exercise 2 (the defects in the finished run its catch-up block copies in) and returns nothing on a change you already accepted. Record which single change did the most work.

Before you close the laptop

Day 3 starts in day3-work, a fresh copy of the shipped lane, so nothing in day2-work travels. Copy the keepers into ../work/ first: .claude/settings.json, the runner or auditor if you edited them, and your wrapper change.

To clean up, quit Claude Code, then from inside day2-work run this line. It leaves ../work/ and your keepers alone. Keep ../work/ itself: Day 3 writes its map and answers there too.

cd .. && rm -rf day2-work

Only if you do the challenges: reset instead of cleaning up, and do Challenge 3's silent half first, before any reset or cleanup, because it needs the change you accepted in your current day2-work. Quit Claude Code, then from inside day2-work run your lane's line. It also leaves ../work/ alone.

Swift lane 
cd .. && rm -rf day2-work && cp -R sandbox/swift day2-work && cd day2-work
Kotlin lane 
cd .. && rm -rf day2-work && cp -R sandbox/kotlin day2-work && cd day2-work

A fresh day2-work is the shipped lane and nothing else. For challenge 1 or 2, re-run Exercise 1's setup block, pasting only its lines after cd day2-work. Challenge 3's silent half runs in your current day2-work, before any reset: it holds the change you accepted in Exercise 2. For the six findings, reset, cd .., and paste Exercise 2's setup block, then its catch-up block; they put back the auditor, the spec and the reference run the six were scored against. Then copy your tuned auditor back from ../work/.

Sources