Verifier agent + auto-bug-filing: removing operator friction from the loop

One of the earliest design decisions in the Master OS was separating the executor from the verifier. The executor does the work. The verifier checks the work. They never share context — the verifier reads the ticket spec and the committed diff cold, with no knowledge of what the executor decided to do or why.

This is not an efficiency optimization. It’s a correctness constraint.

Why separation matters

A self-verifying executor has an alignment problem: it knows what it tried to do, and it’s likely to verify that it did what it tried rather than whether what it tried was right. This is the same reason code review from a different engineer catches more bugs than self-review — the reviewer doesn’t have the implementation context that blinds the implementer.

The verifier subagent spawns with the ticket spec, the acceptance_criteria, and a read-only view of the committed diff. It has one job: check whether the acceptance criteria are satisfied. It doesn’t know what the executor intended. It doesn’t have the executor’s context. It checks the spec against the output and reports pass or fail.

This is stricter than it sounds. “The header renders at 375px without text overflow” is either true in the deployed build or it isn’t. The verifier either confirms it or flags it. No wiggle room for “well, it’s close.”

The auto-bug-filing addition

During the verification pass, the verifier sometimes notices things that are out of scope for the current ticket but clearly wrong — a stale date constant in a utility script, a broken invariant in a config file the verifier happened to read as context, a test that passes but doesn’t actually exercise the code path it claims to.

Early in Phase 6, these observations came back as prose in the verifier’s verdict: “also noticed X, might want to look at that.” I’d read the verdict, mentally note the observation, and mostly forget about it by the next session.

The fix was structural: the verifier auto-files any out-of-scope anomaly it notices as a draft ticket. Small, clear, well-scoped anomalies get auto-promoted to ready — they’ll be dispatched in the next available slot. Large or ambiguous anomalies get filed as draft and surface in the next session’s interview for operator review.

The result: the observation doesn’t depend on the operator’s memory. It’s in the queue.

What this changes about the operator experience

Before this pattern: I’d review every merged ticket to make sure it actually did what I intended. Low-trust loop with significant operator time investment.

After this pattern: the verifier checks every ticket against the acceptance criteria before merge. The pre-merge gate catches the cases the verifier missed (ruff failures, pytest regressions, doctor grade drops). The operator reviews the session summary, not individual tickets.

The feedback loop is faster because it happens at merge time, not review time. The operator’s attention is freed for work that genuinely requires it: spec quality, prioritization, strategic decisions.

The failure mode to watch

The verifier is only as good as the acceptance criteria it’s checking. Precise criteria produce reliable verdicts. Vague criteria produce verifier judgment calls — which are usually fine but occasionally miss things the operator cared about.

The operator’s job is not to catch verifier misses in review. The operator’s job is to write acceptance criteria precise enough that the verifier doesn’t need to make judgment calls. When a verifier miss surfaces, the right response is to fix the spec for next time, not to add a review step.

Structural solutions beat process solutions. The verifier enforces the spec. Write better specs.

---

The verifier agent contract is at Dev/.claude/agents/verifier.md in the Master OS. Auto-bug-filing doctrine is at wiki/_global/decisions/ in the Master OS.