The Owner: and Reviewer: lines accept the shared write identity Birfy, so a body can name no Bot and still pass the queue entry #1228

What happens

Owner: and Reviewer: exist to answer two questions: who claims this pull request, and who reviews it. Both accept Birfy, which is the single account every Bot writes as — so a body can pass both lines while naming no workstation at all, and the queue entry reads it as fine.

Three pull requests today carry it as the reviewer:

#1214 is the proof that the queue entry let it through: the body it merged with names the shared identity as the reviewer.

代码事实 (main, .github/scripts/enqueue-rules.mjs)

• :58 const SHARED_WRITE_LOGIN = 'Birfy' — the name every Bot writes as.
• :65-66 logins comes from review-policy.json → reviewers, bots from → writers.
• :74-78 Owner: every name must be in bots. Birfy is in writers, so Owner: Birfy is accepted.
• :86-95 Reviewer: a name passes as soon as it is in logins. Birfy is in reviewers, so Reviewer: Birfy passes without ever reaching the workstation vocabulary.
• .github/agent/review-policy.json on main: reviewers: ["hsliuustc0106", "Birfy"], writers: […, "Birfy"]. Both lists contain the one name that identifies nobody.
• The comment at :47-57 already says the line names a workstation, and that a Bot name can record a PASS only through Birfy. The value Birfy itself was never considered — it is the one value where the two vocabularies overlap.

Repro (main, paste-able)

Run guard() from .github/scripts/enqueue-rules.mjs with the main review-policy.json, labels: ['agent-pr'], draft: false, merged: false, result: { ok: true, reasons: [] }, and only the header lines varied:

A  Owner: Dev3    Reviewer: Birfy          -> header refusals: 0
B  Owner: Birfy   Reviewer: Reviewer       -> header refusals: 0
C  Owner: Dev3    Reviewer: Reviewer       -> header refusals: 0
D  Owner: Birfy   Reviewer: Birfy          -> 1 :: Reviewer names "birfy", who is also the Owner of this pull request
E  Owner: Dev3    Reviewer: hsliuustc0106  -> header refusals: 0

A and B must be refused. C and E must stay accepted. D must stay refused — and gains the shared-identity refusal as well.

Expected behavior

1. Birfy is not a value on either line, with or without @ and in any case (the same normalisation headerNames() already applies). Two refusals, in the voice of missing line: Owner::
   • Owner names "birfy", who is the shared write identity every Bot writes as — name the Bot that claims this pull request
   • Reviewer names "birfy", who is the shared write identity every Bot writes as — name the Bot that reviews
     The name prints as the code prints it today (normalised, lower-case), like Owner names "somebody", who is not a writers Bot name.
2. Nothing else about the lines changes. A writers Bot name on Reviewer: still passes while Birfy is in reviewers (that is the identity the PASS is recorded under, unchanged); an independent login such as hsliuustc0106 still passes; Reviewer: naming the same Bot as Owner: is still refused (The Owner: and Reviewer: headers may name the same Bot, so "Owner: Dev / Reviewer: Dev" passes the new check #951); a name outside both vocabularies still gets both sentences.
3. The checkpoint cannot become the way in. claim is compared with the Owner names (:213-219), so once the Owner line refuses Birfy, a claim: "Birfy" agrees with no accepted owner and is refused by the existing message. A test pins that, no new field check.
4. One implementation. The refusal goes in headerReasons() (:62), which guard() calls at :277; the guard and merge-gate share it, so both readers see the same rule (The fork's main has no ruleset and no branch protection, so a PASS is only advisory and an unreviewed pull request can be squash-merged #812, The merge queue does not require enqueue-guard: a red guard cannot stop an entry, and the pass label is only a record #960).
5. review-policy.json is not edited. Who may record a PASS is a different question, and editing that file is T3. The shared login stays listed; the change is about the value written on the line.

改动范围

• .github/scripts/enqueue-rules.mjs — the refusal inside headerReasons(), beside the existing owner/reviewer name checks.
• .github/scripts/enqueue-guard.test.mjs — new cases, plus the existing Owner: Birfy / Reviewer: Birfy case (:579) whose expectation gains the shared-identity refusal; the assertions stay exact strings.
• AGENTS.md — clause in the enqueue-guard bullet (:178) that lists what the two lines may name.
• docs/autonomous-dev.md — the same clause where the vocabularies are listed (:293-296).

验收 (each one can go red)

• A and B refused with exactly the sentence above; C and E still pass with zero header refusals.
• Reviewer: @BIRFY refused once, not twice (case and @ normalised like every other name).
• Reviewer: Birfy, Reviewer still refused: one unusable name is enough.
• D refused twice over: the shared identity and the owner comparison.
• A checkpoint whose claim is "Birfy" while the Owner line is Birfy is refused.
• Knife: remove the new refusal → exactly A, B, @BIRFY, the mixed list and the claim case go red; C, E and the rest of the suite stay green.

不做

• No policy change: reviewers, selfReview and writers are untouched.
• Not All Bots share one GitHub identity, so an independent review cannot be proved #644 (an author-login Verdict cannot be proved) and not Written-by: is a self-report, not evidence: only the write layer knows which Bot wrote a comment #633 (Written-by: is a self-report): this is only the value written on two body lines.
• No rewriting history: Add a release beat watchdog that files one issue a day when the newest v* tag is not today's #1214 keeps its body as a record. Show who is working in a group turn, read from that room’s board (#1213) #1226 is open, so the Bot that owns it corrects its own line when it next pushes — nothing here edits another Bot's pull request.