# Builder/Adversary example — deferred review (verify after a long segment)

The coarsest point on the **review-cadence spectrum**. Same pattern, same full original prompts as
`../builder-adversary` — only *when* the Adversary verifies changes:

| variant | the Adversary verifies… | handshakes (calculator task) |
|---|---|--:|
| `builder-adversary-lean` | per **gate** | ~12 claim/verify round-trips |
| `builder-adversary` (orig) | per **phase** | ~3 |
| **`builder-adversary-deferred`** | **once, after the whole build** | **1** |

## How it works

The Builder **self-certifies** the build phases (`wc`, then `json`) — builds to each phase's DoD, runs
its own tests until green, writes `## DONE`, and advances *without* waiting for the Adversary. The
Adversary stays out of the build. Only in the final **`review` phase** does it do **one comprehensive
cold-verification of the entire accumulated calculator** (`plans/review.md`): re-run every DoD item
from every phase from a fresh clone, plus cross-feature break-it probes, file all findings at once,
re-verify after fixes, then PASS. That single pass is the only adversary gate in the run.

## The trade-off

- **Cheapest coordination.** One handshake instead of 3–12 — no per-gate/per-phase round-trips, the
  Builder isn't interrupted mid-build. (The benchmark showed coordination round-trips are a real
  token cost; deferring to one pass minimises them.)
- **But the independent check arrives late.** Two risks the per-gate/per-phase cadences guard
  against:
  - **Late discovery / rework.** If the Builder built phase 2 on a wrong assumption from phase 1, an
    early adversary would have caught it at gate 1; here it surfaces only at the end, after more work
    was piled on the flaw — potentially a larger, costlier fix.
  - **Self-certification drift.** The build phases are self-certified, so a bug the Builder
    rubber-stamps survives until the final review. The comprehensive pass is the only safety net, so
    it must be thorough.
- **Better at cross-feature bugs.** Because it verifies the whole system at once, it's positioned to
  catch *interactions* (e.g. `--json` × every flag) that a per-gate view, looking at one item at a
  time, can miss.

So `deferred` trades *early, incremental* assurance for *minimal coordination + one holistic pass*.
It suits work where features are independent and cheap to fix late; it's risky where early decisions
constrain later ones.

```bash
python3 ../../agents.py status --config agents.toml
python3 ../../agents.py up     --config agents.toml      # needs `claude` on PATH
```

> **Prompt base:** the full original `builder-adversary` prompts + a DEFERRED REVIEW CADENCE override
> — so comparing this to `builder-adversary`/`lean` isolates *only* the verification cadence.