enqueue-guard: a lift comment that quotes the PASS it answers is dropped as a conclusion, so the stop never clears #2281

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: 53e06ea4ea3b4a09a83b41cbd9fa52c7
Branch: dev/4-enqueue-lift-verdict-cite
Base: 910f630
At: 2026-11-03T06:37:55Z

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

What is wrong

enqueue-guard tells an author whose tip is held to "clear it on the record with a newer comment
that lets this tip merge". The reader that decides that, stopRequestAt in
.github/scripts/enqueue-rules.mjs, first drops every comment whose body parses as a conclusion:

.filter(({ r }) => !parseReport(r?.body).verdict)

parseReport (.github/scripts/review-gate.mjs) reads a conclusion out of any body that carries
a conclusion line, so a lift written as "here is the PASS it answers — you may merge this tip now"
is classified as a conclusion and dropped. The stop it was answering stays standing, and the guard
keeps asking for the very comment it refuses to read.

Observed on #2246 (2026-11-03, tip 51040d46): PASS comment 6596712952 at 06:05:19Z, hold
6596354014 at 05:38:25Z, lift 6596858166 at 06:15:25Z quoting the PASS line → the guard still
reports the 05:38 stop. The same lift with the quoted conclusion line removed clears it.

Reproduction (live main 910f6302)

$ node --test .github/scripts/enqueue-guard.test.mjs     # new case only, base rules
not ok 105 - P-479 (2026-11-03): a lift that quotes the PASS it answers still clears the stop
  error: a comment asks not to merge this pull request: comment 6596354014 … says "please do not merge"
# tests 106 / # pass 105 / # fail 1

The case builds: a PASS at the head, the hold comment, then a lift whose body quotes the PASS line
plus "You may merge this tip now" — all three written through the same helper the other gate cases
use, so it exercises the real reader.

Expected behaviour

A comment that parses as a conclusion but only asks to lift a stop — it carries a lift phrase and no
stop or hold phrase of its own — clears the stop. A parked PASS that says "record only — do not
merge" is still not a lift, and a conclusion-shaped comment without a lift phrase still does not
clear anything (both as tests).

Scope

• .github/scripts/enqueue-rules.mjs (+12/−2): a responseOnly(body) predicate next to the other
  readers, used as the one exception in the conclusion filter. It composes the existing
  LIFT_REQUEST / STOP_REQUEST / HOLD_LINE readers rather than adding vocabulary.
• .github/scripts/enqueue-guard.test.mjs (+43): the lift case and its reverse — a
  conclusion-shaped comment with the lift phrase removed must still leave ok === false and still
  name the stopping comment.
• No change to merge-gate.mjs: it calls the same stopRequestAt, so one fix covers both readers.

Readings with the fix on the same tree: enqueue-guard.test.mjs 106/106, merge-gate.test.mjs
51/51, review-gate.test.mjs 68/68, the two existing record only — do not merge cases 2/2.

Tier by .github/agent/risk-rules.json: .github/** is T3, so this PR needs the reviewer's formal
verdict at its exact tip.

Duplicate check

Searched open and closed issues for "enqueue-guard hold lift", "enqueue hold filter", "lift comment
enqueue": #2073, #602, #2084, #2085, #2091, #2092 (closed) are the stop-request readers this
extends; no issue covers a stop-clearing comment being discarded because it quotes a conclusion.