[Birfy]

Owner: Dev2
Reviewer: Reviewer
Written-by: Dev2

Fixes #911

Tip SHA: 64dbbb4

What changed

A pull request names its owner and its reviewer in the body, and the review round calls that reviewer. When a round calls somebody else, the named reviewer is never asked and the pull request sits with nobody owning the verdict — #907 did that for four tips. Nothing in the repository noticed.

• .github/scripts/agent-audience.mjs — reads the body's Owner:/Reviewer: lines (whole-line match, so quoting the requirement in prose does not satisfy it) and the comments written after the current tip, and prints one line per disagreement as #<n> @<sha7>: <sentence>. Four checks: a missing line; a declared name outside .github/agent/review-policy.json's roster; a call to a member other than the declared reviewer; and Chief as the escalation exit, whose call is not a wrong call. The roster is the policy file — there is no second list. Comments at or before the tip are ignored: they belong to the tip they were written for.
• .github/scripts/agent-audience.test.mjs — 9 cases. The first replays the fix(rooms): list the host's Bots in a guest's copy of the room (#904) #907 record (a body with neither line, three calls to @Reviewer) and expects exactly two findings; the negative control (body names Reviewer2, comments call @Reviewer2) expects zero; the last reads the workflow and turns red if the checker can again pass without having read anything.
• .github/workflows/agent-audience.yml — pull_request, issue_comment and workflow_dispatch; read-only permissions, continue-on-error: true, findings into $GITHUB_STEP_SUMMARY. It never comments and never labels. It runs the script from the pull request's base commit, so a pull request cannot change the checker that audits it, with the first-run fallback review-gate.yml already uses: the base has no copy yet, so the pull request that introduces the script reads its own copy under the same read-only token.
• docs/testing-layers.json / .md — the workflow's row (workflow-only, layer none, not a gate) and the regenerated tables.

Silence is not detectable and is not attempted: the repository has no "who read this" field, so a round that calls nobody is invisible to this check. That half of the rule is a line in #906's contract, not this script.

The missing-line rule is the primary evidence: a pull request that names no reviewer is unowned by definition, and that is what a live read of #907 reports. Chat-side routing is out of reach for this check altogether — a call written in the delivery group never reaches GitHub — so the mention-mismatch rule answers only for GitHub comments, and the report above claims nothing more.

The first live run found a defect in this pull request

At dc447bc1 the new check reported success while reading nothing: the workflow checked the script out of main, where it does not exist yet, so node exited with Cannot find module '/home/runner/work/FlyBot/FlyBot/.github/scripts/agent-audience.mjs' and continue-on-error turned that crash into a green check. A check that passes without reading is exactly the failure this issue is about, so 64dbbb46 reads the script from the base commit and falls back to the pull request copy; a missing script is now an explicit ::error line, and the new case makes the reverted workflow red (verified by reverting it: not ok 9, restored: 9/9).

Ran

• node --test .github/scripts/agent-audience.test.mjs → 9/9. Red without the fix: restoring ref: main plus the bare node .github/scripts/… run line gives not ok 9 - #911: the workflow cannot pass without having read the checker, and putting the base checkout back gives 9/9.
• node --test ".github/scripts/*.test.mjs" → 334 pass, 4 fail: the four ds-bot-patches cases that shell out to git (this box has none); they fail the same way on unmodified cbad5e58.
• node .github/scripts/testing-layers.mjs --check → every test file and every workflow is classified (343 test files, 15 workflows), and docs/testing-layers.md regenerated by --write.
• Live read of the real fix(rooms): list the host's Bots in a guest's copy of the room (#904) #907 record through the same evaluate(): 1 finding — #907 @b8b582b: pull request body has no Owner: and Reviewer: line. The three @Reviewer calls happened in the delivery group, not on the pull request, so GitHub never carried them; the replay case feeds them as comment bodies and says so.

Not run

• No actionlint locally (not installed); the workflow follows the shapes already here (review-gate.yml, pass-label.yml).
• No npm run verify (needs git and the full harness on this box).

Docs-not-needed: no subsystem doc owns .github/scripts; the routing contract lands with #906, as Triage scoped it.

[Birfy]

Verdict: PASS at 64dbbb4
Written-by: Reviewer
Tip SHA: 64dbbb4

Judged on the merge tree (main 79aa6128 + this PR's five files). The branch's base cbad5e58 is behind main by #910; this PR touches only .github/scripts/agent-audience.{mjs,test.mjs}, .github/workflows/agent-audience.yml and the two docs/testing-layers files, so room-membership.js comes from main unchanged.

The checker does what #911 asks, and the two halves that could have made it decorative are both pinned:

• the #907 record replays into exactly two findings (no Reviewer: line, three calls to a member the body does not name), and the negative control (body names Reviewer2, comments call @Reviewer2) produces none;
• the workflow test is real: putting ref: main back in .github/workflows/agent-audience.yml reds case 9 alone, and the other eight stay green — that is the defect 64dbbb46 fixed, so it is a defect test rather than a guard.

I also checked the trap in the entry guard rather than assuming it: node base/.github/scripts/agent-audience.mjs in the runner gives process.argv[1] as an absolute path, so process.argv[1] === fileURLToPath(import.meta.url) does fire and main() runs. If it did not, the workflow would exit 0 having read nothing, which is the failure this PR exists to catch.

Ran (merge tree as described above):

$ node --test .github/scripts/agent-audience.test.mjs
# tests 9 / pass 9 / fail 0
$ node --test .github/scripts/agent-audience.test.mjs   # knife: the base-checkout `ref:` reverted to `main`
# tests 9 / pass 8 / fail 1 — not ok 9, "the workflow cannot pass without having read the checker"
$ node -e 'console.log(process.argv[1])'                # argv[1] is absolute, so the module-main guard fires
$ node -e 'JSON.parse(...)' on docs/testing-layers.json # parses; the workflow is registered, and `testing-layers.mjs --check` runs in test.yml, green on this tip

Source restored byte-identical after the knife (cmp clean). Tip CI is terminal and green (tests-ok, agent-audience ×3, package, merge-gate, three plugins, Node 24); enqueue-guard is red only for the conclusion this comment supplies.

Non-blocking, no new tip needed:

1. continue-on-error: true also swallows a genuine crash. The missing-script branch exits 1 and prints ::error::, but the step still reports success, so the "loud on purpose" intent lands only as an annotation someone has to open. The clean split is a second, ordinary step keyed on steps.<id>.outcome == 'failure' that fails the job only when the checker could not run — findings stay report-only, a broken checker goes red. Printing read: N pull request(s) into the summary would also make a zero-read run visible.
2. parseDeclarations and mentionsIn read fenced code blocks too. A body pasted from the docs with a Owner: <Bot> template line matches, but the roster check then reports <Bot> as not in the policy, so it is noisy, not silent. Stripping fences before matching would remove the noise.
3. --pr with a non-numeric value becomes NaN and then queries PR NaN; a one-line guard would make the failure legible.

Enqueueing now.