fix(queen): a required check that refuses the pull request takes the acceptance back - #507
Merged
Conversation
…acceptance back
Measured 2026-09-22 on gHashTag/t27: the review accepted #4385, publish
opened #4578, and the required parse-ratchet refused it ("parse error in
fn 'is_coq' near line 17"). The pull request sat red for ever, the issue
stayed open with an accept on it, and the Queen skipped it every round as
"the work already landed". 42 issues were in that state while the swarm
ran 2 bees of 20, and no bee ever saw the error.
Each round now asks GitHub about up to eight accepted issues, oldest-asked
first: is there an open pull request for the branch, and did a REQUIRED
check (read from the base branch's rules) come back red on its head? If so
the accept becomes a sendBack whose note is the check's own ##[error] line,
which the next bee reads in its brief (judged_note). The second refusal
escalates, the review's own ceiling.
It decides nothing on a running or advisory check, takes nothing back when
the required list cannot be read, leaves closed and merged pull requests
alone, and runs as housekeeping: a failure is logged and the round goes on
to start bees.
Verified against live gHashTag/t27: required checks read as validate,
check-linked-issue, parse-ratchet; queen-4385 -> #4578 open, parse-ratchet
red, error line extracted; a merged pull request and a missing branch are
left alone. Queen suites: 628 pass (614 before + 14 new), 0 fail.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
❌ Tests failed — 1/2453 failed
Failed tests
|
This was referenced Sep 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why the reviews jam
On gHashTag/t27 on 2026-09-22, the review accepted #4385 and publish opened #4578 for it. The required
parse-ratchetcheck refused it: parse error in fn 'is_coq' near line 17. The PR sat red for ever. The issue stayed open with anaccepton it, and the Queen skipped it every round as "the work already landed". 42 issues were in that state while the swarm ran 2 bees of 20, and no bee ever saw the error.What changes
queen-ci-verdict.ts, called each round right after the review. For up to 8 accepted issues (oldest-asked first, tracked in the newci_checked_atcolumn):queen-Nand reads the required checks from the base branch's rules.sendBack. Its note is the check's own##[error]line, which the next bee reads in its brief (judged_note). The second refusal escalates to a person, the review's own ceiling.Verified
validate, check-linked-issue, parse-ratchet.queen-4385resolves to #4578 (open) withparse-ratchetred, and the error line is extracted. The merged #4579 and a missing branch are left alone.🤖 Generated with Claude Code