enqueue-guard: require Owner:/Reviewer: before the queue, and make a bot account's Verdict: unreadable #943

One issue for both halves, as decided: the gate does not recognise the writer, so it cannot tell a body that names an owner from one that names nobody, and it cannot tell a human account's conclusion from an agent's.

The case that forced it: #940 went from opened to merged in about seven minutes with the largest diff of the day (core/client.js +1415/−1408, patches/ds-bot/0008-client-bundle.patch +3656/−2125), and its body never carried Owner:/Reviewer: at all. The convention did not hold, and no check noticed.

Line numbers on main c7286584.

Part 1 — Owner:/Reviewer: before the queue (enqueue-guard)

The body checks live in guard() (.github/scripts/enqueue-guard.mjs:72), inside if (!mechanicalRelease && !fork) (:80-83) next to the existing Fixes #<n> test (:82, ISSUE_REF at :52) and the agent-pr label test (:83). decidePull calls guard at :147 and already has policy loaded, so pass it in.

Rule:

• In the first 20 lines of the body there is a line starting Owner: and a line starting Reviewer:.
• Every value after Reviewer: (comma-separated, a leading @ allowed, case-insensitive) is a login in the policy's reviewers.
• Only for a non-draft pull request entering the queue, and only when !mechanicalRelease && !fork — both exemptions stay exactly as they are.
• The refusal names the line, not just the defect: missing line: Owner:, missing line: Reviewer:, Reviewer names "x", who is not in reviewers.

This is an enqueue-time body check only. It must not be added to review-gate's or judge's conclusion tests: those read every report on every pull request, and a required header there would refuse reports on pull requests that never had one.

Part 2 — a bot account's Verdict: is never a conclusion

Formulation by account type, not by a login list: a report authored by a GitHub bot account — user.type === 'Bot', or a login ending [bot] — is not a conclusion whatever its body says. It joins judged with counts:false and a reason naming the account, and the real Reviewer voids it at that tip with Correction from Reviewer:.

Why not a login list: Birfy is the account every Verdict: is written by — all Bots share it and Written-by: credits which one — so a list containing Birfy would void the whole pipeline. The bot accounts today are cursor[bot] and its kind.

Where: enqueue-guard.mjs:130-133 builds reports from comments and reviews and already carries association; add type (and the same in review-gate.mjs's report gathering, which reads the same two APIs). decide() refuses such a report before the association test, with its own reason, so review-gate, merge-gate and enqueue-guard all inherit it.

Acceptance

1. A body with both lines missing → the guard is red and the text names which line is missing. Two tests, one per line: a single "missing header" sentence for both does not count.
2. Reviewer: naming a login outside reviewers → red, naming that login; Reviewer: naming a login that is in reviewers → passes.
3. Not retroactive: a merged pull request is never re-judged by this check — Show ticket-seat lines in the room session #940's record stays as it is — and a draft is not refused by it. The check runs on the enqueue request for a live head only.
4. A Verdict: written by a bot account is never read: a test replays the cursor[bot] report at Show ticket-seat lines in the room session #940's tip and asserts counts: false (with its own reason), while the Birfy report at the same tip still counts. Same case in review-gate, merge-gate and enqueue-guard, since they share decide.

Docs

AGENTS.md and docs/autonomous-dev.md state the rule in one sentence each: an agent account's Verdict: counts for nothing, and the real Reviewer voids it with Correction from Reviewer:. Precedent: the #940 correction (PR comment 6381646389).

Out of scope

Touching merged history. Requiring the two lines on forks and on mechanical release pull requests.