Rework is a list, not a feeling
Watch what the gate hands back on a REWORK: not "needs another pass," not "not quite there" — a list of check ids. ["C1", "C3"]. That list is the rework instruction, and it's a better one than any prose you'd write at 6pm, for a reason specific to AI builders:
AI converges on named failures and thrashes on vague ones. Send back "the report needs to be tighter" and the model rewrites everything — including the four sections that already passed, which now need re-review, which means your second review costs as much as the first. Send back "C1 failed: these three citations don't resolve; C3 failed: exec summary runs 5 pages, limit is 2" and the model fixes those two things and touches nothing else. The named-check rework note is the difference between iteration that converges and iteration that churns. You learned to write testable checks in lesson one; here's where the investment pays out a second time — every check you wrote is also a rework instruction, pre-drafted.
Count the loops
Add one number to every deliverable's record: the attempt count. It's the cheapest early-warning signal in delivery, and almost nobody tracks it, because with human teams rework was diffuse — a comment thread here, a hallway fix there. With an AI builder every rework cycle is discrete: attempt 1, attempt 2, attempt 3. Countable.
The rule this chapter takes a position on: two failed attempts against the same check means stop building. Not "try once more with a better prompt." A check that survives two targeted fix attempts is almost never a builder problem — it's a spec problem (the check is ambiguous after all), a frontier problem (the task was outside, and fluency hid it — remember the 19-point penalty), or a dependency problem (the builder can't see the system the check runs against). All three are PM problems, and all three are invisible if you're not counting attempts, because each individual retry feels reasonable. The third attempt is where "one more pass" quietly becomes the bottleneck — you, feeding a loop that isn't converging, one hopeful prompt at a time.
So the escalation is mechanical: attempt 3 with the same failing check → the ticket leaves the build lane and comes back to you for respec or re-triage. The checkpoint bakes this into the gate, which is exactly where it belongs. Rules you have to remember under deadline pressure are rules you'll break under deadline pressure. Rules in the gate just run.