gate: a stop request written in a review body is not read (#2073 read issue comments only) #2084

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 7968537356f2464e9c14ed07da28fcdc
Branch: dev/1-review-stop-body
Base: 8e80226
At: 2026-11-02T00:26:45Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead

#2073 taught the enqueue guard to read a person's "please do not merge" from an issue comment. The same sentence written as a pull-request review is not read at all, so the guard returns ok: true.

Reproduction (live main 8e80226f)

.github/scripts/enqueue-rules.mjs, stopRequestAt():

    .filter(({ r }) => (r?.kind ?? 'comment') === 'comment')   // drops every review
    ...
    .filter(({ r }) => !parseReport(r?.body).verdict)          // the real "a conclusion is not a request" rule

The kind filter drops every review, and the verdict filter below already handles conclusions, so the kind filter only removes what a person wrote in the review box. The callers pass reviews: enqueue-guard.mjs:69-71 and merge-gate.mjs:219-221 push review bodies as kind:'review' with at: submitted_at.

Probe against the real modules (no stubs), body passing the checkpoint and policy checks, anchored on the same PASS:

• A: the sentence as an issue comment after the PASS → ok = false, reason a comment asks not to merge this pull request: comment 102 ….
• B: the same sentence as a review body (Request changes) after the PASS → ok = true, stop = null, reasons = [].
• C: stopRequestAt([review], {author}) → null, independent of the anchor.
• D: no request → ok = true (control).

Red-first in .github/scripts/enqueue-guard.test.mjs on the current main with only the new cases added: 98 tests / 96 pass / 2 fail ×3 — a review asking not to merge this tip refuses too, and names the review (true !== false) and a T0/T1 pull request with no PASS is stopped by a review too.

Expected behaviour

A request written by a person is the same request whichever box it was typed in. Deleting the kind filter and keeping the verdict filter gives that: a non-conclusion review body is read like a comment, while a review carrying a Verdict: is still a conclusion and is judged by decide. recordOnlyAt, withoutQuotes and LIFT_REQUEST stay unchanged.

Scope

• .github/scripts/enqueue-rules.mjs: drop the kind === 'comment' filter, adjust the two comments so they say comments and review bodies are read alike.
• .github/scripts/enqueue-guard.test.mjs: a reviewNote() fixture plus the cases — review body refuses and names its id, a PASS/INC review is a conclusion and not a stop, a T0/T1 change with no PASS is stopped by a review too, and the existing review cases stay green.

Acceptance: the new cases red before the change and green after; the existing #602 (2026-11-01) cases unchanged; .github/scripts/*.test.mjs all green (575 with the three new ones); npm run verify exit 0 with ARCH_DOCS_BASE set to the live main of the branch.

Tier T1, effort XS.

Not in scope

• A refusal for a review still reads comment <id> in its text; the id locates it, and whether to say review <id> is a separate decision.
• An empty Request changes (GitHub allows an empty body) never reaches reports because both callers drop blank bodies first; the same reader, not a second issue.

Duplicate check

Live main 8e80226f grep plus closed issues: open #2054/#2060 are the acceptance-gate signature policy (different); closed #602 is the hold/freeze reader that #2073 extended to issue comments, and #637/#639/#691/#931 are about which conclusion counts and who may stop. No open or closed issue covers a stop request written in a review body.