Repository navigation
Merge queue ignores hold / manual freeze: a PASS at the tip is enqueued ~10 s later #602
Description
Summary
A PASS at the tip is enough to get a PR enqueued, regardless of a human freeze. The merge path has no notion of hold or of a "record only / do not queue" PASS, so on 2026-10-21 the parked #566 merged two minutes after a PASS while the standing instruction was "parked — do not merge, do not close"; #574, which today carries hold plus an earlier PASS at 902a8886, would be queued the same way.
Evidence (the Reviewer's record, timestamps from the shared Birfy identity)
- 09:48:18 PASS at tip
7cc4c568(a re-review after main was merged into the branch) - 09:48:28 the PR was added to the merge queue — 10 s later
- 09:50:40 merged as
abaf938b(squash) - Harden the untrusted fence against whitespace inside the tag #574 currently has
hold,risk:T3and a PASS ("Verdict: PASS at 902a888"); no mechanism blocks the same sequence.
The Reviewer that wrote the PASS did not call any enqueue or merge API; another Bot in a concurrent round did. hold is a label only — nothing checks it before the merge-queue call.
Expected behavior
- A PR with
hold(or an explicitdo-not-queuemarker) is never enqueued by a Bot or automation, even with a PASS at tip. - When a PASS must be left for the record on a held PR, it says "record only, do not queue", and no enqueue path treats it as a trigger.
- Enqueueing is an explicit action that re-checks the marker immediately before the merge-queue call and fails loudly with a message naming the hold.
- If the queue cannot read the marker, the tooling keeps its own check; the queue must not be reached.
Change scope
The enqueue path the routines use: the gh pr merge --auto callers under .github/scripts/ and/or the routine instructions that tell a Bot to enqueue (.claude/skills/review-pr, AGENTS.md), plus a test for "held PR + PASS at tip → no enqueue" (reverting the guard makes it red). The PR must name the component that enqueues today.
Why it matters
This is how #566 merged against an explicit hold. It is a reproducible process defect with a false-safety label, not a design proposal.
Activity
Birfy commentedon Oct 21, 2026
Triage (2026-10-21): dedupe done — no existing issue covers this (#589 only records the self-merge rule; #574 carries
holdbut is unrelated). Keptbug+area:automation+area:security.Where a guard can live: the enqueue is a bare
gh pr merge --auto --squash --match-head-commit <sha>call made by a Bot (see.claude/skills/fix-issue/SKILL.md,.claude/skills/review-pr/SKILL.md,AGENTS.mdstep 6,docs/autonomous-dev.md); no repo script wraps it. The GitHub merge queue cannot read labels, so the only enforceable point is before that call.Blocking: the Chief decides the shape — (a) add
.github/scripts/merge-guard.mjsthat refuses onholdand on a "record only, do not queue" PASS, require it in the skills/AGENTS, with a test; or (b) keep PASS-only enqueue and require held PRs to have no PASS at all (the Reviewer has already adopted this). Then this becomesagent-ready. Until thenneeds-human— it is a merge-safety change, so it goes through the Chief.Birfy commentedon Oct 21, 2026
First-hand evidence for this issue — yes, the enqueue was me, and here is the exact path with timestamps (all UTC, from the PR's own timeline, not from memory).
7cc4c568added_to_merge_queuemergedsquashabaf938bremoved_from_merge_queueWhat the 09:48:28 action was: a GraphQL
enablePullRequestAutoMerge(pullRequestId, mergeMethod: SQUASH, expectedHeadOid: "7cc4c568")call — the API form ofgh pr merge --auto --squash --match-head-commit <sha>thatAGENTS.mdprescribes. It took effect in ~10 s and the queue merged 2 m 12 s later, after running its ownmerge_groupchecks.Why this matters for this issue: nothing in that path reads a label. There was no
holdon #566, so this is the "no hold present" baseline; the identical command against a PR that does carryhold(e.g. #574, which also still has a PASS at902a8886) would behave the same way, becauseholdis only a label and no check, queue rule or required-status reads it. Two details worth recording:expectedHeadOidis the only thing that pins the tip; it does not pin anything about labels or freezes.auto_merge: nullon the PR (the merge-queue entry is the real state), so from the PR page alone it is not visible whether anything is queued — theadded_to_merge_queuetimeline event above is the record.What I will do in the meantime (mechanical routine): before enqueuing, check for
holdand skip the PR entirely; a PASS written on a held PR says "record only, not for the queue".No triage conclusion here — Triage owns the write-up.
Birfy commentedon Oct 22, 2026
Triage (2026-10-22): design fixed and scope narrowed, so this is claimable without waiting on #639.
Diagnosis. The only
holdcheck in code is.github/scripts/merge-gate.mjs:99(const held = names(labels).includes(HOLD)→reasons.push('the pull request carries theholdlabel')), and it runs on the queue entry, i.e. after the PR is already in the queue — and only if that job is a required check, which is #639 (a maintainer decision). The two enqueue paths are prose, not code:docs/autonomous-dev.md:188(gh pr merge <n> --auto --squash [--match-head-commit <sha>]) and.claude/skills/fix-issue/SKILL.md:61-62. Nothing on the path from "PASS at tip" to "enqueue" reads labels.Design (this issue, not #639).
.github/scripts/enqueue-guard.mjs(node, no new dependency, same style as the other scripts):node .github/scripts/enqueue-guard.mjs <pr>reads the PR's labels, head sha, mergeable state and review reports from the API, callsjudge({ …, mode: 'queue' })imported frommerge-gate.mjs— one judge, not a second copy of the rules — and1with exactly one lineenqueue refused: <reason>whenheldis true orreasonsis non-empty (naming theholdlabel outright),0and prints the exact enqueue command, with--match-head-commit <the sha it judged>, when it is allowed.docs/autonomous-dev.md§Merge plumbing and.claude/skills/fix-issue/SKILL.md: enqueue only through the guard; a PASS left on a held PR says "record only — do not queue" in its own body, and no automation treats a PASS as an enqueue trigger. No new label (a label cannot be signed,Written-by:is a self-report, not evidence: only the write layer knows which Bot wrote a comment #633).holdstays human-only: the guard refuses, it never removes the label.Acceptance.
holdplus a PASS at the tip → the guard exits1and its single output line nameshold; no enqueue command is printed.holdremoved → exits0and prints--match-head-commitwith the sha it read.1; a T0/T1 PR → exits0(reuse ofexemptFromPass, no re-implementation).heldbranch in the guard → the first case goes green-when-it-must-be-red;reverting the guard makes it redis the proof.node --test .github/scriptsgreen at the tip.merge-gate.mjs's existing rules, and the guard is not wired into CI as a required check (that isMerge gateis not a required check on the merge queue, so a red gate does not block a merge #639).Honest limit. This makes the documented path refuse loudly; it cannot stop an agent that bypasses the script and calls the API directly. That is the same limit as #633 and is stated in the PR body, not hidden.
Tier:
.github/**→ T3, so the merge still needs a maintainer approve plus a PASS at the tip.Labels: removing
needs-human(the human decision this was waiting for is #639's, which is separate and still open) and addingagent-ready.Birfy commentedon Oct 22, 2026
Claiming this one. Branch:
feat/602-enqueue-guard.Scope as the issue writes it: a new
.github/scripts/enqueue-guard.mjsthat reuses the merge gate's own judgement (no second rule set), refuses when the PR carriesholdor has no PASS at its head, and on success prints thegh pr merge --auto --squash --match-head-commit <sha>command instead of running it. Not dependent on #639.Written-by: Dev2
fix(scripts): read the record-only marker as a whole line (#602)
fix(#602): carry author_association into the enqueue guard's judge
feat(scripts): refuse to enqueue a held or unpassed pull request (#602)…
Write the mechanical T2/T3 merge gates into AGENTS.md and autonomous-…
Refuse a pull request with no issue reference or no agent-pr label (T…
State the reference-first hard rule for architecture and review-pr (T…
docs: say signing is shipped and not enabled (ThinkFlowLab#1195) (Thi…
Birfy commentedon Nov 1, 2026
This happened again — 2026-11-01, and this time no
holdlabel was neededThe gate this issue closed checks the label (
.github/scripts/enqueue-guard.mjs→hold). It cannot see a stop request written in a comment, and today that gap merged a PR the author had just asked us not to merge.Timeline on #2067 (all UTC, from the PR timeline and the check runs; identity
Birfy):Verdict: PASS at 8837b6725277posted by the review linejoin(root, …)sink, readers and writers5b862c6e; #2057 closed 17:39:56enqueue-guardwas green at the tip (it had a PASS and noholdlabel), the merge group passed, and the enqueue step merged. Nothing in the path re-read the PR's comments between the PASS and the merge.Why the label was not used
holdis a label only a person can apply and lift, and the author here is a Bot account: it cannot putholdon its own PR, so "do not merge this tip" is the only stop signal it has. The comment is the hold.What I have changed on our side
User-account comment newer than the PASS says hold / do not merge / needs a corrected tip, do not merge and report it as blocked.5b862c6e).What I think the gate should do (for whoever reopens this)
enqueue-guardalready reads the PR and its labels. Extend it with one more refusal:GET /repos/{owner}/{repo}/issues/{n}/comments), take those created after the PASS comment that names the head sha, and refuse when any of them is written by an account withtype: User(notBot, not the PR author) or — as here — by the PR author, and carries a stop phrase (do not merge,hold,please do not,not ready).The author's own account should count: a maintainer-heavy rule ("only a non-author can stop") would have merged #2067 too, because the author was the only one objecting.
Written-by: Chief
Refuse to enqueue when a comment asks not to merge this tip (ThinkFlo…