A merged PR carrying Refs #N wakes no sweep, so every post-merge transition waits on a cron that fires three times a day

[dan-claude-bot]

A merged PR that carries Refs #N wakes no sweep on this board. The post-merge transition it should trigger — the queue label, the claim release, the transition comment — waits for the hourly cron, and the cron is not hourly.

Measured on main at 50b4235 and off the Actions API immediately before this write, not recalled.

.github/workflows/labels.yml is the event-facing caller; it dispatches labels-sweep.yml within seconds of a board event. Its wake set is:

• pull_request_target: [opened, reopened, ready_for_review, converted_to_draft, synchronize, labeled, unlabeled, review_requested, review_request_removed]
• issues: [opened, closed, edited, reopened]

A Refs merge fires none of them. closed is not in the pull_request_target list, and a Refs merge deliberately leaves the issue open, so there is no issues: closed event either. A Closes merge is covered — the issue closes, issues: closed fires, the sweep runs in seconds. So the gap is specific to the shape this repository uses for every issue with a post-merge criterion.

The fallback is the cron, and GitHub fired it three times in eighteen hours rather than eighteen:

schedule run
2026-08-28T23:54:23Z
2026-08-29T06:15:47Z
2026-08-29T13:01:32Z

labels-sweep.yml declares schedule: [{cron: "0 * * * *"}]; GitHub deprioritises scheduled workflows and this is what that looks like in practice.

What it cost today. PR #242 merged at 15:59:42Z carrying Refs #236. At 17:1x — 71 minutes later — #236 still read claimed with @cndgrr assigned, on work that was merged and done. Triage did the move by hand. #237 and #229 looked prompt only by luck: an unrelated issues event dispatched a sweep within two minutes of each of those merges.

The board-level cost is not the latency itself. It is that a stale claimed with a live assignee is indistinguishable, to a scanning builder, from a claim someone is actually working — and the 48-hour claim-reclaim runs off the same sweep.

The open question, which is why this is a discussion and not an issue

Where does the fix belong, and what is it? Three readings, and I do not think this board can settle it alone:

1. Add closed to this caller's pull_request_target types. One line, in this repository, under box's own control. But pull_request_target on closed runs with the base repository's token on a merged head, and the sweep is a full-board reconcile — worth someone confirming that is the trigger ceremony intends rather than the one that happens to work.
2. It belongs upstream in ceremony, as a documented part of the caller contract every consumer copies. crew, rig and cast presumably have the same hole, and fixing it here alone leaves them holding it.
3. It is not a trigger problem at all — the cron is declared hourly and GitHub is not honouring it, and the honest fix is to stop treating the cron as a wake for anything that matters.

I have no ruling to make here and am not minting an issue: an issue whose spec still has an open question is not ready to exist. Recording the measurement so whoever settles it is not re-deriving it.

Nothing about this blocks 0.10.0. Every transition it delayed today has been done by hand and is recorded on its issue.

[dan-claude-bot]

The counterexample this measurement was missing, delivered on the same board four hours later — and it narrows the open question to one of the three readings

This is evidence, not a ruling. The question here is still open and still not mine; I am putting on this record the control case the original write did not have, because without it reading 3 is indistinguishable from readings 1 and 2.

The control: the same sweep, the same cron, the same caller, 80 seconds

PR #247 merged 2026-08-29T20:19:15Z as 758a2b7 carrying Closes #241. #241 closed two seconds later, and #222 — which named it as its last remaining reference — went blocked → ready at 20:20:37Z, with the sweep's own <!-- issueflow:blockers-cleared --> comment on the thread. 80 seconds, and no hand flip.

Set that beside the case this discussion was opened on: PR #242 merged 15:59:42Z carrying Refs #236, and #236 still read claimed with a live assignee 71 minutes later, when triage moved it by hand.

Same repository, same day, same labels.yml caller, same deprioritised cron, same board. The only difference is the keyword.

What that rules out, and what it does not

It substantially weakens reading 3. "The cron is declared hourly and GitHub is not honouring it" is true — the three-runs-in-eighteen-hours table above stands, re-read and unchanged — but it is not what cost #236 its 71 minutes. The event path was healthy the whole time: a Closes merge fires issues: closed, which is in the wake set, and the sweep answered in 80 seconds. The cron is the fallback that a Refs merge falls through to, not the mechanism that failed. So the honest framing of the defect is narrower than the original write made it: it is not "the sweep is slow", it is "the sweep is never woken for exactly the shape this board uses on every issue with a post-merge criterion."

That distinction matters to the fix. A fix aimed at reading 3 — distrusting the cron, tightening the schedule, adding a second scheduled caller — buys nothing here, because the fast case never touched the cron and the slow case would still not be woken by one that fired on time. Only readings 1 and 2 address the actual hole.

It settles nothing between readings 1 and 2, which is where the open question genuinely lives: whether closed belongs in this repository's pull_request_target types, or whether the caller contract is ceremony's to fix for crew, rig and cast at once. This comment adds no evidence on that and I am not choosing between them.

Why it is worth the write rather than being left as a snapshot line

The measurement was made at 20:5x on discussion #186, which is a board snapshot — a page that is superseded by construction, several times a day. That snapshot said this belonged on this record and then did not put it here. A counterexample that lives only in a superseded snapshot is not on the record, and whoever settles this question would have re-derived it or, worse, settled it against reading 3 for want of it.

The cost since, re-measured rather than assumed

Unchanged. The Refs-shaped transitions on this board today were #236's and #229's, both done by hand and both recorded on their issues. No further Refs merge has landed since 15:59:42Z: the one merge after it, PR #247, is the Closes case above. The four issues sitting on post-merge right now — #160, #171, #180, #236 — are all unassigned, all correctly labelled, and all waiting on the 0.10.0 drill rather than on a sweep.

Still nothing here blocks 0.10.0, and this remains a discussion rather than an issue: the spec would still carry an open question, and an issue whose spec carries one is not ready to exist.

— triage, 2026-08-29 21:5x

[dan-claude-bot]

Answered, and settled upstream by a route none of the three readings contained — the Refs-shaped merge is gone, so there is nothing left to wake the sweep for

This thread asked one question: "where does the fix belong, and what is it?" It has an answer, it landed on 2026-08-31, and it is neither reading 1 nor reading 2. Ceremony did not make a Refs merge wake the sweep. It removed the merge shape.

The measurement

ceremony 0.7.8 published at 2026-08-31T21:11:11Z. Counted over the doctrine files at each tag in this tick rather than read off the changelog:

file	post-merge	Refs #N
TRIAGE.md @ 0.7.7	7	1
TRIAGE.md @ 0.7.8	0	0
LABELS.md @ 0.7.7	12	1
LABELS.md @ 0.7.8	0	0

The queue state and the keyword are both retired. What replaces them, quoted at the tag — TRIAGE.md:177-189 @ 0.7.8:

Where an issue's remaining acceptance criteria include operator-owned ones, relocate them — do not route the issue around them. The operator-owned criteria move verbatim into their own issue; the original is left with a remainder that is wholly PR-checkable; and its PR merges with Closes #N. The evidence is neither waited on at the merge door nor deferred past it. It becomes tracked work carrying its own claim and its own wake condition, which is the whole of the route: an issue is not held open to remember something a separate issue can hold (#488).

The relocation precedes the merge. Before the merge it is a route; after the merge it is a repair — the same moves, but performed on an issue that has already closed on criteria nothing checked.

The landing commit is 3b643a9a — "docs: split after-close work at the mint, every PR carries Closes #N" — from ceremony#539, with ceremony#567 retiring the queue state's remaining rows in the same 0.7.8 gate. The question of scope — does the shape go entirely, or only for the operator-owned remainder? — was itself a discussion, ceremony#536, closed 2026-08-31T21:05:29Z.

Why that settles readings 1 and 2 rather than choosing between them

Both presuppose a merge that leaves its issue open and therefore needs a wake this event set does not supply. Reading 1 would add closed to this repository's pull_request_target types; reading 2 would put that same line in the caller contract crew, rig and cast all copy. Under 0.7.8 no merge has that shape. Every PR carries Closes #N, which fires issues: closed, which is already in the wake set — and which the control case in the comment above clocked at 80 seconds.

That the fix was doctrinal rather than mechanical is measurable rather than argued: ceremony's own .github/workflows/labels.yml changes exactly one line between the two tags, and it is CEREMONY_SELF_REF: "0.7.7" → "0.7.8". The wake set is byte-identical across the release. Nobody added closed anywhere, in either repository.

Reading 3 was already substantially weakened by that control, and nothing here revives it. The three-runs-in-eighteen-hours table in the opening post stands, re-read and unchanged; it is still not what cost #236 its 71 minutes.

What is left for box, stated so it does not close with this thread

This board pins 0.7.7. Verified in this tick rather than assumed: .ceremony/TRIAGE.md and .ceremony/LABELS.md on main diff byte-identical against the 0.7.7 blobs, so the mirror is correct at the pin and every label on this board is true — 0.7.7 is the doctrine box actually runs under. The gap this thread measured is therefore still live here, and today it costs nothing: post-merge reads empty on this board, drained on 2026-08-30, and no Refs-shaped merge is pending.

The exposure retires when the pin moves to 0.7.8. That bump is not this thread's to decide and is deliberately not minted here. Both prior bumps on this board — #219 (0.7.6) and #237 (0.7.7) — were minted at @danmt's direction, and 0.10.0 has an open cut (#222) whose changelog-assembled criterion replays its merge base, which is what re-did the cut three times already. So the timing of any new member is a release-window call rather than a hygiene one. It is recorded on the board snapshot in discussion 186 in this same tick so it survives this close.

Closing as answered. Nothing here blocks 0.10.0 — which is what the opening post said, and is still true.