the reviewer is load-bearing

the reviewer agent is the single load-bearing primitive of direct-build mode. across the 22 direct-build PRs of iteration 12 in the 2026-05-21 session, the reviewer caught at least one real defect on roughly 41% of them. each catch was a defect the foreman had missed at build time. the direct-build pattern works because the reviewer is independent and adversarial; without it, the pattern would ship bugs at the same rate the reviewer is catching them.

the catches were not bikeshed comments. they were:

#361 — docstring rot. module docstring + test docstring still said
       "no current emitter" for codes that this PR started emitting.
#374 — missing tests and loose assertions on a reason-code change.
#383 — broken grep pattern in a CI gate. flagged twice (once on a
       follow-up PR that reintroduced the pattern).
#382 — installer-shim gap that would have left fresh installs
       silently degraded.
#385 — sweep-setup regression in a touched template.
#376 — false-positive YAML scanner output that would have masked
       real findings.

each catch was a class of defect the foreman demonstrably missed during direct-build despite reading the diff carefully before opening the PR. that is not foreman incompetence; it is the consequence of a single agent both authoring and self-reviewing. the author’s mental model of the change is the model that produced the bug; the same model is unable to see the bug. an independent reviewer comes to the diff with a different model.

the structural property the reviewer relies on is independence. the reviewer agent’s context contains no authoring history. it reads the diff cold, against the issue body and the host repo’s standards, and applies a fixed verdict policy: approve, request changes, or reject. it does not know what the foreman was thinking. that is the entire point. a reviewer that inherited the author’s context would inherit the author’s blind spots and would catch nothing.

the verdict policy is calibrated differently from the plan-reviewer. the plan-reviewer requires zero unresolved Criticals to approve; the code-reviewer can approve with minor fixes. that policy gap is the reason direct-build ships work while the planner pipeline deadlocks on m+ work — the reviewer’s higher tolerance for incremental tactical fixes is the mechanism by which the loop closes. lowering the reviewer’s bar to match the plan-reviewer’s would break direct-build. raising the reviewer’s bar without that policy gap would push the deadlock into the review phase.

a representative reviewer-rejection flow:

1. foreman direct-builds PR, opens with builder agent skipped
   (lights-on mode).
2. reviewer agent dispatches with fresh context.
3. reviewer reads diff against issue body + validate[] output.
4. reviewer finds docstring referencing "no current emitter" for a
   reason code this PR adds an emitter for.
5. reviewer posts verdict: request changes.
6. foreman reads the request, fixes the docstring, pushes a follow-up
   commit.
7. reviewer re-reviews with the same fresh context; approves.
8. /loswf:ship auto-merges.

the loop is short. one round of “request changes” is the common case for direct-build PRs; one to three rounds for m work shipped as a single slice. iteration 12’s 41% re-review rate is dominated by the one-round case; the multi-round PRs are the ones that should have been decomposed before shipping.

the operational rule that follows: re-review count is a retrospective sizing signal. zero rounds on a PR means the size was correct or generous. one round means the size was tight but workable. two or three rounds means the PR was probably mis-sized — should have been broken into smaller children. the decomposer’s sizing rubric now uses re-review count as an audit signal; a size label that produces multi-round PRs systematically gets bumped up on similar future issues.

three sub-patterns the reviewer caught repeatedly across the iteration:

docstring rot. when a feature change modifies the behavior of a symbol whose docstring still describes the old behavior, the docstring lies. iteration 12 saw this on #361 and again on #374. the recurrence promoted the pattern to a checklist item: before committing a direct-build, grep docstrings and comments referring to the symbol you just modified. the heuristic is cheap and catches the same class of bug on subsequent direct-builds.

rebase artifacts on shared-file PRs. #383’s diff bled in #382’s changes because the factory branch had been cut from main before #382 merged. the reviewer flagged it as “out-of-scope changes” — accurately, in that the changes were not part of the issue scope, but the underlying cause was the missing rebase. the checklist item that fell out: before opening any new PR for a tactical fix, git fetch origin main && git rebase origin/main so the diff is clean against current main.

tests that exist but do not assert. #374 had tests, but the assertions were loose enough to pass even when the behavior was wrong. the reviewer caught it by reading the test bodies, not by reading the test names. test names that read as if they test the right thing can hide tests that do not. the heuristic that followed: when the reviewer sees test-name optimism, it reads the assertion line.

a related operational pattern: when reviewer rounds stack up beyond three on a single PR, the signal is that the foreman is rushing. the discipline call in that case is to slow down or hand the PR to a fresh builder, not to pressure the reviewer toward approval. an approve verdict produced by reviewer fatigue is approval theater, and the next bug it lets through will be a real defect. iteration 12’s worst PRs both hit three reviewer rounds; both were eventually approved, both were genuinely fixed, but the foreman noted afterward that decomposing them earlier would have avoided the fatigue cost on both sides.

the reviewer also produces second-order value the merge-gate frame does not capture: every reviewer-rejected PR contributes back to either a feedback memory or the kaizen log. the rejection itself is the kaizen signal — what the foreman missed becomes a checklist item for next time. that is why iteration 12’s audit guide grew faster than any other iteration in the session; 22 direct-builds with 41% re-review produced a high density of rejection-grounded patterns. the reviewer is not just a gate; it is the input edge of the kaizen loop.

the meta-lesson is that auto-merge gates have to honor the reviewer’s independence as a non-negotiable. the user’s standing instruction is that reviewer approval auto-merges and advances phase without operator intervention. that instruction works because the reviewer’s verdict is grounded — a fresh-context agent reading the diff against the issue body and the host repo’s standards. if the reviewer were folded back into the builder’s context to “save tokens” or “reduce dispatches,” the verdict would lose the independence property that makes it trustable. the cost of the reviewer dispatch is real; it is also the cost of having an auto-merge surface that ships work without shipping bugs. an autonomous factory that wants to ship code without an operator in the loop pays that cost on every PR, and the cost is the price of admission to operating without supervision.