The diff is not the deliverable

Code got cheap. Verdicts did not.

An agent can produce a plausible four-file diff in less time than it takes to read this page. That did not make software cheap; it moved the cost. The scarce artifact in an agent-speed workflow is no longer the change. It is a defensible statement about the change: what it touches, what it risks, and whether the objections against it survived being tested.

That statement is the deliverable. The diff is just its input.

Self-review is the author grading their own homework

The obvious fix is to ask the agent to review its own work, and it fails for a boring reason: completion bias. An author who re-reads their own reasoning re-anchors to it. The same mental model that produced the bug now inspects the bug, nods, and moves on. This is not a discipline problem you can prompt away. It is a property of context.

So independence has to come from context, not effort. codument's review adversary gets the diff and the documented contract it crosses, and never the author's chain of thought. On hosts with subagents that is a fresh context window; where there is none, the same agent runs an adversarial pass against the identical bundle. Weaker, and the design says so out loud, but the rest of the gate does not depend on it.

Give the adversary a contract, not a vibe

"Assume the change is wrong" is a stance, not a method. Wrong against what? Generic review prompts flail and nitpick because they have no ground truth to check against.

codument hands the reviewer one: the diff, the documented invariants it crosses, the tests that pin those invariants, and the ownership and blast-radius facts the registry already knows. The bundle introduces no new opinions. Every line of it is derived from committed docs and the deterministic change analysis. The adversary's job narrows from "find something to say" to "show which of these documented promises this diff breaks."

Until a recorded review covers the current diff, the gate says exactly that:

  ✗ --require-review: no current adversarial review covers this diff.
    Run a fresh adversarial review of this diff and record it under .codument/reviews/, then re-run.

A finding blocks only if it can lose

Reviewer prose is never trusted, including the adversary's. A finding is a candidate until it is reduced to a named test, and it blocks only while that test is genuinely red on a re-run the gate performs itself. This session is real: the agent shipped a plausible-looking fix that capped each rotation but still extended the session on every refresh. The adversary's finding named a test, and the gate re-ran it:

  ✗ --require-review: 1 confirmed finding(s) unresolved.
    • src/auth/session.ts:rotateToken — the per-rotation cap still extends the session on every refresh; continuous rotation keeps a session alive forever (test: test/session-ttl.test.ts)

No red test, no block. A finding that cannot be reduced to a test, a design smell, a naming complaint, an untestable worry, stays recorded and advisory. It reaches the human; it never silently vetoes a merge. That single rule bounds the failure mode that kills review tools in practice, which is not missed bugs. It is alarm fatigue.

Fixing the code reopens the gate

The recorded review binds to a fingerprint of the reviewed sources and the tests its findings name. Change any of them and the review is void. Fix the code: the fingerprint moves, and the adversary must look again. Quietly edit the failing test instead of the code: the fingerprint moves too, so a finding cannot be green-washed out of existence.

After the real fix landed and a fresh review was recorded against the fixed diff:

  ✓ Adversarial review covers this diff

That line is the deliverable. Not "an agent looked at it", but: an independent pass attacked this exact diff against its documented contract, its one confirmed objection was reproduced, fixed, and re-verified, and the artifact saying so is bound to these bytes.

What stays with you

The honest limit, because honest limits are the house style: the gate certifies process, not safety. It can prove a review covered this diff and that no confirmed objection is outstanding. It cannot prove the change is good, and it does not try. Judgment stays with you.

What changes is what you are judging. Not a wall of plausible code and a reviewer's mood, but a verdict that survived being re-run.