bc-36xx.34: Pin both halves of a review veto: the dequeue is real - #700
Conversation
…e queue draining on past it Adam's instruction for the review gate is two claims joined by "while": a veto is dequeued and dealt with separately *while* the merge queue continues to drain. They fail independently, so they are pinned independently. The two escalation checks already here assert the raise with a spy, which cannot tell an escalation that hands the bead over from one that merely says it did — so the first of these wires the real raiseMergeCard in, and what it asserts is `merge-queue` coming off the bead and `human` going on. The second puts the veto at the *head* of a three-deep tick, which is the arrangement where a `break` in place of the `continue` would look exactly like a quiet afternoon. The two behind it merge, and go all the way through to their closes rather than being merged and left half-filed. `sweepMergeQueue` sorts the tick by bead id, so the fixture's names are what put the veto first — the draft that named it `zz-veto` sorted it past the merge budget and it was never judged at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
A beadcause worker opened this and does not merge its own work. It is on the merge queue as bc-m5pow. |
|
#700 was merged as 5fb5977 outside the queue. The queue was holding it and has done the bookkeeping the merge would have done.
The queue reports its own half only: how this branch got through, not what was in it. What the advocate actually did — the conflicts, which side it kept, the suites it ran and against which tree — is on bc-36xx.34's merge bead, written by the window that did it. Nothing here is a summary of that; a process that did not watch the merge has no business paraphrasing one. |
NeanderthalMan
left a comment
NeanderthalMan
left a comment
There was a problem hiding this comment.
Approved by Adam via /merge — recorded after the fact: the beadcause merge queue had already picked this up as bc-m5pow and merged it as 5fb5977 at 17:03:35Z, closing bc-36xx.34 and bc-m5pow together.
Recording it anyway so the approval is where the diff is. The review gate is currently off for this workspace (bc-196cz), so this merged without a reviewer's verdict — Adam's approval is the decision that stands behind it.
2 participants
Adam's instruction for the review gate is two claims joined by "while": a veto is dequeued and dealt with separately while the merge queue continues to drain. They fail independently and only one of them was ever in doubt, so this pins them independently — test only, no production code touched.
1. The dequeue is real. The two escalation checks already in
test/mergequeue.mjsassert the raise with a spy, which cannot tell an escalation that hands the bead over from one that merely says it did. This one wires the realraiseMergeCardin, so what is asserted ismerge-queueactually coming off the bead andhumangoing on.2. The drain survives it. Three queued, the vetoed one at the head of the tick — the arrangement where a
breakin place of thecontinuewould look exactly like a quiet afternoon. The two behind it merge in the same sweep, do not lose a merge slot to the veto, and go all the way through to their closes rather than being merged and left half-filed.sweepMergeQueuesorts the tick by bead id (lib/mergequeue.js:404), so the fixture's names are what put the veto first. The draft that named itzz-vetosorted it past the two-merge budget and it was never judged at all — worth knowing before writing any other multi-row tick test.What this settles, and what it does not. "The queue continues to drain" is now proven and needs no further work: it is
continue, notbreak. The whole of the remaining work is the strand, which isbc-i9nz7— still open, still unanswered, and deliberately not started here.Filed on the way past:
bc-uxrix(P1).raiseMergeCardadds thehumanlabel; the sweep's only read isbd.listAgent, which runs--exclude-label human. So a merge-bead leaves the only list the sweep reads the instant it becomes a card.cardedFor— the take-a-card-back loop of bc-91srt/bc-91ft — selects on exactly that label and can therefore never have run in the daemon, andstrandedPrscounts every card as a strand, which is the#661 ... no merge-bead is about itline repeating in the log. Five green tests cover the reclaim becausefakeBd.listAgentreturns its rows unfiltered. Verified against the live workspace. Not fixed here: wakingcardedForup while the review gate is off would take #655 (CLEAN, green) straight back onto the queue and merge it over a reviewer's refusal, which is bc-i9nz7's call, not a side effect to land by accident.Tests: node bin/b7e-gate --json in this worktree over the merged tree: 424/424 green, no reds. test/mergequeue.mjs alone is 77/77, up from 75 — the two new checks are 'A VETO IS DEQUEUED FOR REAL' and 'AND THE QUEUE BEHIND IT STILL DRAINS IN THE SAME SWEEP'.
Worth knowing: Test-only; no production file is touched. The one way it could be wrong is a fixture that does not mean what it says, which is why the first check wires the real raiseMergeCard in rather than a spy, and why the second asserts the merge numbers and the close order rather than just a count.
Left undone: bc-i9nz7 is still unanswered and the strand itself is untouched — #661 and #655 are both still stranded, deliberately. bc-uxrix (P1) is the cause I found and did not fix: cards are invisible to the sweep's own read, so cardedFor has never run and strandedPrs calls every card a strand. It must not be fixed on its own while the review gate is off — it would merge #655 over a reviewer's veto.
Files changed — 1 file · +70 −0 · against `main`
Opened by a beadcause worker session on bc-36xx.34 — Pin both halves of a review veto: the dequeue is real, and the queue drains on past it in the same sweep. It merges itself once the checks report; merging is what closes the bead. If this is still open, something stopped that, and the reason is on bc-36xx.34 and in Adam's inbox.
bead: bc-36xx.34