# Builder/Adversary example — context-lean + full per-gate review

The [`builder-adversary-stateless`](../builder-adversary-stateless/) variant added **context
hygiene** (compact at each checkpoint, read diffs not trees, lean loads) and, in benchmarking,
happened to also do *fewer* review rounds — so its token saving was partly leaner context and partly
*less scrutiny*. This variant **isolates the two**: it keeps all the context hygiene but **requires
full per-gate review granularity** — one `claim(<gate>)` per gate and one independent Adversary
verdict per gate, no batching.

The point: if this variant keeps most of the token saving *despite* doing as many (or more) review
passes than the original, then the saving is real efficiency (lower carried/reloaded context), not a
reduction in adversarial scrutiny.

So vs the others:

| variant | context hygiene | review granularity |
|---|:--:|---|
| builder-adversary | no | as the agents choose |
| builder-adversary-min | no | as the agents choose |
| builder-adversary-stateless | yes | as the agents choose (tended to batch → fewer rounds) |
| **builder-adversary-lean** | **yes** | **per-gate, enforced (no batching)** |

Everything else — pattern, AI-as-adversary cold verification, the `claim(`/`review(` handoff,
`machine-docs/` coordination — is identical. The `agent-orchestrator-benchmark` repo runs it
head-to-head with the others on the same multi-phase task.

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

> **Prompt base:** these prompts are the **full original** `builder-adversary` prompts plus the additions above — NOT the minimal ones — so that comparing this variant to `builder-adversary` isolates its specific change (context hygiene / review granularity) without the minimal-prompt testing-pressure drop.