A PASS posted as a review body is still silent: refuse it in a write-less pull_request_review job, never in pass-label #801

The gap

#767 closes one door and leaves the other open. A Verdict: PASS at <sha> whose Written-by: names someone outside writers is refused by review-gate and merge-gate, and #797 makes pass-label say so — but only for a verdict posted as a comment. A verdict posted as a review body still gets nothing: no label, and no note.

What main (fd205c40) does today:

• .github/workflows/pass-label.yml fires on issue_comment (types [created]) and workflow_dispatch only; the job is gated on github.event.issue.pull_request != null and passes PR / COMMENT_BODY / ASSOCIATION from the comment payload.
• .github/scripts/pass-label.mjs:99-109 (--comment) reads exactly those three values. The review body is read only by historyFrom() (:85-91), which the backfill path uses (:112-118) — and backfill only looks at pull requests with merged_at. So an open pull request whose PASS lives in a review body produces no pass label and, after #797, no refusal note either.

Why the obvious fix is refused

"Add pull_request_review to pass-label.yml" is not a two-line change; it is a permission change, and it hands the workflow file to the pull request:

• For pull_request_review, GITHUB_REF is refs/pull/<n>/merge and GITHUB_SHA is the last merge commit — the workflow definition runs from the merge ref, not from main. A pull request that edits the workflow file changes what runs on its own review events.
• pass-label.yml holds issues: write and pull-requests: write. Our Bots push branches inside this repository, so that token is write-capable (a fork pull request gets a read-only token; ours do not). A write-capable job whose steps come from the merge ref is a hijack path, not a trigger.
• The workflow's own comment already states the rule for the comment path: "The comment body is untrusted text: it is only parsed, never run, and the label is added from base-branch code. pull_request on a comment would run PR code, so this stays an issue_comment workflow." review-gate.yml says the same from the other side: "pull_request (never pull_request_target), read-only token, no secrets."

So the write-capable version is an owner decision (it widens the security surface), and this issue does not take it.

Scope: a write-less door, in its own workflow

.github/workflows/review-verdict.yml, separate from pass-label.yml on purpose:

• on: pull_request_review: types: [submitted] (plus workflow_dispatch for a manual check of one pull request, optional).
• permissions: contents: read. No issues:, no pull-requests:, no secrets. Then a pull request editing this file can only change what its own review job prints.
• Checkout main (not the merge ref) and run .github/scripts/review-verdict.mjs, so the logic is always main's, even though the workflow file may not be.
• The script reads github.event.review.body, github.event.review.author_association, github.event.pull_request.number; refuses a Correction from … first line; parses with the shared parseReport and the writers list from .github/agent/review-policy.json; when the verdict is a PASS at a tip and the writer is not listed, it emits ::warning title=… naming the writer, the tip and the file to edit, and appends the same sentence to the run summary. Otherwise it prints nothing and exits 0.
• Always exits 0: this is a report, like review-gate; a job that turns red is a job people learn to ignore.
• Empty review body (an approve with no text), a non-PASS verdict, a listed writer and an outsider's review with no Verdict: line all end in silence.

Out of scope

• Any write from a review-triggered workflow: no label, no comment, no check run with a conclusion. If the owner later wants the label or the note on review bodies too, the safe shape is a two-step relay: this no-permission workflow runs, then a workflow_run workflow — whose definition comes from main and which may hold write — does the commenting. That is a separate decision, and the docs' warning about artifacts applies ("do not extract in the workspace dir that may contain executable scripts").
• pull_request_target, and any repository_dispatch from GITHUB_TOKEN (an event created with GITHUB_TOKEN does not start another workflow).
• Changing review-gate (it must stay continue-on-error, out of branch protection and out of tests-ok's needs), and changing #797.
• Inline review comments (pull_request_review_comment): those are the line-level discussion, not a conclusion.

Done when

• .github/workflows/review-verdict.yml exists with permissions: contents: read and nothing writable.
• .github/scripts/review-verdict.mjs + .github/scripts/review-verdict.test.mjs (picked up by the existing node --test ".github/scripts/*.test.mjs" in npm run verify) cover: stranger PASS → warning text names the writer, the tip and .github/agent/review-policy.json; listed writer → silence; Correction from Reviewer: … quoting a PASS → silence; empty body → silence; outsider association → silence; comment-path behaviour of pass-label.mjs unchanged.
• A new test asserts the workflow file grants no scope other than contents: read (parse the YAML, fail on any : write).
• A run against a pull request whose review body carries a stranger PASS shows the warning in its job summary with the writer and the tip; the job is green.

Kill conditions (each must turn a test red)

• Drop the association check → an outsider's review warns → test red.
• Drop the writers check → a listed writer warns → test red.
• Add issues: write to the new workflow → the permissions test red.
• Let the job exit non-zero on a stranger PASS → the "always green" test red.
• Check out the merge ref instead of main → a pull request can change the script that runs → the checkout assertion red.

Relation to #767

Same defect, different door: #767 is the comment path (merged by #797), this is the review path. The boundary was recorded by Dev in #767.