You've run Gates 3 and 4 live and met every verifier on the menu. This is the synthesis: which gate, when — and how the pieces stack into one loop.
⏱ ~9 min🎯 The decision framework🔗 Synthesizes Lessons 1–8
1 · The two gates you haven't formally met
Lessons 3–4 took you deep on the heavy gates. The light ones matter just as much, because most work doesn't deserve a hook:
Gate 1 — in one prompt. The check rides along with the task in the same message: "write validateEmail… run the tests after implementing and fix failures." Claude "does the work, runs the check, reads the result, and iterates until the check passes" — all inside one turn. Zero setup, scoped to exactly this task, gone when the turn ends. This should be your reflex for everyday work — most of this course's verifiers were introduced as Gate 1 ride-alongs for a reason.
Gate 2 — a /goal condition. Session-scoped: you set the check as a goal, and "a separate evaluator re-checks it after every turn and Claude keeps working until it holds." (best practices) Think of it as a Stop hook's advisory cousin: re-checked every turn like a hook, but evaluated rather than script-enforced — right for conditions that need judgment ("the README accurately describes the new flag") or that you don't want to write a script for.
2 · Choosing: scope × enforcement
Gate
Scope
Enforcement
Reach for it when…
1 · In-prompt
One task
Words (this turn)
Default for everyday tasks; the verifier exists and is cheap to run.
2 · /goal
Session
Evaluator, every turn
A condition must hold across many turns of meandering work; scripting it is awkward.
3 · Stop hook
Every turn, every session
Script — deterministic
"Must happen every time with zero exceptions": green suite, honest ledger, no secrets in diff.
4 · Subagent
On demand
Fresh-context judgment
The criteria need judgment AND the worker shouldn't grade itself.
The rule of thumb: escalate on cost of a wrong "done", not on availability. A hook you could build but don't need is latency tax on every turn (Lesson 4's design rules); a hook you need but skipped is how a lying ledger ships. Start at Gate 1; promote a check up the ladder the first time its absence bites.
3 · Composition — the full-stack loop
Real loops stack verifiers the way real codebases stack tests. Here's the reference stack, assembled entirely from things you've already run:
🧪
TDD core (Gate 1)
Failing tests committed first — the unambiguous inner feedback signal (Lesson 1). Cheapest loop, runs constantly.
📜
Environment evidence (Gate 1)
World-state queries, log tails, golden diffs ride along in prompts where the work touches the world (Lesson 8).
⛔
Stop hook floor (Gate 3)
Suite green + ledger honest, enforced by script on every turn end (Lessons 4–5). The model can't undercut the floor.
🕵️
Adversarial ceiling (Gate 4)
diff-grader judges what scripts can't — requirements met, no tests weakened — from a fresh context (Lesson 3), with its judgment calibrated (Lesson 6).
📋
Ledger horizon (cross-session)
features.json carries "done" across context windows for long work (Lesson 5).
Two more composition patterns from the best-practices page worth knowing: writer/reviewer — parallel sessions where one Claude writes and another reviews; and test-writer/implementer — "have one Claude write tests, then another write code to pass them," which keeps the test-author's blind spots out of the implementation. Both are organizational versions of Lesson 3's principle: separate the doing from the grading.
4 · Anti-patterns — the ways loops rot
The slow gate. A 90-second suite in a Stop hook taxes every turn. Gate on the fast tier; run the slow tier on demand or in CI. Speed is what lets the loop iterate (Ronacher).
The flaky gate. A randomly-failing check in a hook is a randomly locking door — and it trains everyone (model included) to distrust the gate. Quarantine flakes before gating.
The unbounded reviewer. A reviewer told to find problems "will usually report some, even when the work is sound" — bound the rubric to correctness/requirement gaps or it manufactures endless busywork (Lesson 3's diff-grader does this in one line).
Verifying the narration. Any check that reads the agent's claims instead of the environment's state — Lesson 8's whole subject. If the check could pass while the world is wrong, it's transcript-tier.
The silent-pass verifier. A check that passes when it measured nothing — the zero-match trap from demo 03, the regenerated golden from Lesson 8. Verify your verifiers: deliberately corrupt the thing once and confirm the check fails.
5 · Design the loop — four scenarios
Loading…
💬 One lesson left: the capstone turns this framework into a worksheet that generates a verification-loop plan for your project. If you already know which project you'll use, tell me now and I'll pre-load context for it.