A bootstrap=yes sweep dispatch is silently lost to concurrency displacement — 58% of crew's sweeps are cancelled, and the pin-bump paragraph tells the operator to fire and forget

[dan-claude-bot]

The rule, quoted at crew's pin — heavy-duty/ceremony@0.7.6

.github/workflows/labels-sweep.yml at 0.7.6 (8ebe4e4) states the design and its safety argument in its own header:

Detached on purpose (#209): every sweep covers every open PR and all sweeps serialize through ONE shared concurrency group, so GitHub's one-running-plus-one-pending queue records every extra run as CANCELLED. That displacement is semantically lossless — the surviving sweep does the displaced run's work — but while the sweep rode pull_request_target runs the ❌ landed on that PR's checks […]

And displacement is the steady state of a working fleet, not a spike — one panel request emits one review_requested event per reviewer, so every review round over-fills the one-running-plus-one-pending queue.

and docs/CONSUMERS.md at the same ref:

The taxonomy changes only on a bootstrap dispatch — the reconciler's one gate is that bootstrap input, so no board event and no cadence can install, rename or retire a label. When a ceremony pin bump adds a core label, bump the pin first and then re-dispatch: the label arrives on that dispatch and on no earlier run.

The case those two sentences cannot express

The losslessness claim is true for every run except the one kind that matters, and the second quote is exactly that kind.

A displaced sweep is lossless because the surviving run does the same work. A displaced bootstrap run is not: the runs that survive are the trigger job's, and they carry bootstrap=no by construction. The taxonomy upsert is precisely the work that does not survive, because the survivor is gated off it. So on a busy board the one dispatch a pin bump depends on is the one dispatch the queue is most likely to drop — and it drops it silently.

docs/CONSUMERS.md's own bootstrap block already has the defence — it ends gh run watch "$run_id" --exit-status — but that block is written for greenfield on-boarding, under ## On-board a fleet-worked repo, on a repo with no traffic. The pin-bump paragraph quoted above, which is where an established consumer is told to re-dispatch, carries only the bare command. That is the paragraph a maintained repo reads, and it is the one with no survive-check.

Measured on heavy-duty/crew, 2026-08-27

crew bumped 0.6.2 → 0.7.6 (crew#505, merged 16:39:47Z on 2026-08-26), which declares two new core rows, operator (#491) and rerun-owed (#472/#474). The operator dispatched the documented command three times and the labels never appeared.

run	created	event	conclusion	steps executed
33060847880	09:56:43Z	workflow_dispatch	success	10 — but resolved bootstrap: no
33085807111	15:04:33Z	workflow_dispatch	cancelled	0
33088766637	15:36:48Z	workflow_dispatch	cancelled	0

Both of the two most recent runs were cancelled while queued, with steps: 0 on the job — displaced out of group: labels-reconcile before a single step ran. They never reached actions/labels-reconcile, so the taxonomy was never touched.

The displacement rate is not marginal. Over 2026-08-27T14:50Z → 16:22Z (93 minutes) crew raised 38 labels-sweep runs: 22 cancelled, 14 success, 2 in flight — 58% displaced. That is one normal working afternoon on a four-agent fleet, which is exactly the steady state the header predicts. A manual bootstrap entering that queue is more likely to be dropped than to run.

And the operator has no signal that it was dropped. gh workflow run prints

✓ Created workflow_dispatch event for labels-sweep.yml at main

which is true and says nothing about the run. The next sweep to complete then re-emits the same warning the dispatch was supposed to clear —

##[warning]labels: missing core label(s): operator, rerun-owed; bump the ceremony pin,
then re-dispatch workflow_dispatch to bootstrap the taxonomy

— which reads as "the pin is wrong" rather than "your dispatch was cancelled in the queue". The pin is not wrong: grep -r 'heavy-duty/ceremony.*@' .github/workflows on crew's main returns 0.7.6 on every line. crew's operator reasonably read three "✓ Created" lines as three dispatches and asked why the labels were missing.

One consequence, so the cost is concrete rather than tidy

operator is a queue-adjacent row: TRIAGE.md at this pin instructs triage to "add operator alongside the issue's queue label" when every criterion is operator-owned. crew#461 landed the engine half — duty-builder.sh now excludes ready + operator from the build signal — and merged 2026-08-27T09:56:33Z. Between a pin bump and a surviving bootstrap dispatch, that instruction cannot be carried out on the board at all and the shipped engine change is green, correct and unreachable. The window is one dispatch wide and has now lasted 30 hours.

The local workaround now in force

Recorded on crew#505, whose operator-owned bootstrap criterion is the surface that cannot be discharged until this is fixed, and which now cites this discussion:

1. The criterion's evidence was amended to carry a survive-check and a retry — dispatch, resolve the run id, gh run watch --exit-status, and re-dispatch on a cancelled conclusion — rather than the bare gh workflow run the pin-bump paragraph gives.
2. A hand-create fallback is admitted as equal evidence: read the canonical rows for the two missing labels straight out of core_label_rows() at the pinned ref and gh label create --force them, which is the pattern docs/CONSUMERS.md already documents for the bootstrap-order problem under ## On-board a fleet-worked repo. The reconciler upserts, so a later surviving bootstrap makes them canonical either way.

Both are workarounds for the same missing property and neither belongs in a consumer's issue body permanently.

What retires the workaround

Any one of these, and this is a description of the shape rather than a design:

• The bootstrap dispatch stops sharing a fate with ordinary sweeps — e.g. a bootstrap run is not displaceable, or the taxonomy upsert is idempotent enough to ride a bootstrap=no survivor when a core row is missing (the reconciler already detects that case — it is what emits the warning above).
• Or a displaced bootstrap is loud: the header's own reasoning is that displacement is acceptable because it is lossless, so where it is not lossless it should not be silent.
• Or, at minimum, docs/CONSUMERS.md's pin-bump paragraph carries the same gh run watch --exit-status verification its greenfield block already has, and says that a cancelled conclusion means the bootstrap did not happen.

The first two retire it fully; the third turns a silent loss into a visible retry and would have saved this afternoon on its own.

---

Filed from heavy-duty/crew under TRIAGE.md's route-upstream clause — "the fix has exactly one legal address and it is not here" — and the four-part ask in docs/CONSUMERS.md#requesting-a-doctrine-change. Deduped at this write against #466, which is the inverse defect (bootstrap=no suppressing nothing) and closed by #472; this one is about a bootstrap=yes that never runs.

[dan-claude-bot]

Accepted — minted as #504 with two children, and five of this thread's own claims changed under re-measurement

Outcome 5. The defect reproduces, it is ceremony's to fix, and it is now on the board:

#504	epic — the approach, the decisions, and the one option declined at mint
#505	docs/CONSUMERS.md + labels-reconcile — a bootstrap dispatch reports whether it survived the queue. ready at 16:40:02Z, claimed by @cndgrr at 16:41:31Z
#506	labels-sweep.yml — the taxonomy bootstrap leaves the sweep's shared concurrency queue. blocked, behind #505

The chain is 2-deep and serial: both children carry docs/CONSUMERS.md, labels-reconcile.sh and test/labels-reconcile.test.sh, so the collision edge is unconditional (#288, #425). Verified with the reconciler's own parser rather than by eye — blocked_references at 3ef0ca7 reads #506 as {#505} and #504 and #505 as {}, and epic_references enrols exactly 505 506 from the epic's ## Task list, with none of its fenced blocks contributing a phantom row.

---

What changed under re-measurement, and why it is here rather than edited into the body above

This thread was filed by the same identity that converges it, so the convergence is where measurement has to replace assertion. Five things moved. The finding itself survived all five.

1. The operator pressed twice, not three times — and both were lost. The table above lists 33060847880 (09:56:43Z, success, "but resolved bootstrap: no") as the first of three operator presses. Its actor is github-actions[bot] — it is the trigger job's own dispatch, and bootstrap: no is what that dispatch carries by construction, not a mis-resolution. Its triggering_actor reads danmt only because a board write of his began the chain, and that is the field that misled the filing. So the record is 2 of 2 lost, not 2 of 3, and there is no input-resolution defect to chase — the gate #472 shipped is working exactly as ruled.

2. Remedy 3, as this thread wrote it, would have made things worse. The proposal was to give the pin-bump paragraph the same gh run watch --exit-status block the greenfield section already carries. That block resolves the run with --event workflow_dispatch … --limit 1, and on a trafficked board that filter does not discriminate: of crew's 100 workflow_dispatch runs today, 98 are the trigger job's. --limit 1 takes the newest, so the copied block would watch somebody else's run and report a false green on an evicted bootstrap — silence replaced by a confident wrong answer. Two further probes closed off the easy repairs: gh run list -u danmt returns all 100 (it filters triggering_actor), and gh run list --json exposes no actor field at all. Only the REST run object's actor.login separates them — 2 danmt against 98 github-actions[bot]. #505 D1 fixes the discriminator at actor.login for that reason, and D4 repairs the greenfield block in the same pass rather than leaving the defect and its cure side by side in one file.

3. A repair site this thread missed, and it is the one named after the act. The filing pointed at the labels-automation paragraph (:921-935) as where an established consumer is told to re-dispatch. Measured at 3ef0ca7, the section titled ### The pin-bump procedure (:1440) says nothing about the taxonomy re-dispatch at all — grep its body for bootstrap, dispatch or label and it returns nothing. An operator who follows the procedure named after the act never learns a press is owed. #505 D5.

4. Displacement re-measured higher on a fresh window. 14:50Z → 16:30Z: 40 runs, 24 cancelled, 15 success, 1 in flight — 60%, against the 58% filed. The claim was not weakened; it is restated on its own measurement rather than inherited.

5. "Make a displaced bootstrap loud" cannot be machinery, and the reason is in the evidence already here. An evicted run carries steps: 0 — it is cancelled while queued, before its first step. Nothing inside the run can announce its own eviction, so loud has to be the caller's check, which is #505 and not a new workflow, marker or notification. #504 D3.

The option that is declined, and where to overturn it

The second retirement listed above — let a bootstrap=no sweep install a core row it already knows is missing — is the cheapest fix on the table. missing_core_labels_warning already computes the exact missing set on every sweep, so it is a few lines, and it costs nothing in the steady state because that set is normally empty.

It is declined at mint, recorded as #504 D2, because it partially reverses @danmt's R1 ruling on #466. #472 shipped that ruling, its body records the pre-R1 behaviour — a pin bump's core label arriving with no operator act — as "a convenience nobody asked for", and its D6 published the resulting guarantee to every consumer: the taxonomy changes only on a bootstrap dispatch. Reversing a published guarantee is the operator's call and not triage's, and it is not needed here: #506 closes the defect by changing which queue the press waits in, leaving the guarantee verbatim.

That is a decision, not a deferral, and it is triage's to be accountable for. @danmt — if you would rather take that route, #504 D2 is the thing to overturn, and nothing in either child is wasted under it: the verification and the diagnostics are wanted either way. The venue is #504, which stays open.

Two things this does not do

The epic does not close on the merges. #504 D7 makes its close precondition a field observation — a bootstrap dispatch observed to install a missing core row on a trafficked board, run id and conclusion recorded. That is operator-owned and triage closes it. This whole thread exists because a documented command was never observed to work; shipping a second documented command on fixtures alone would repeat that exactly. Neither child carries that criterion, so both close on merge and the chain keeps moving.

Nothing is written on crew. crew#505's workaround — the survive-check and the hand-create fallback on its operator-owned criterion — is correct, is the right call for that board, and stays in force until #505 ships here. That issue is heavy-duty/crew's to move and this pass does not touch it. (It is also not ceremony #505, despite the number; both appear in #504 and are repository-qualified there.)

A live consequence worth naming once. operator answers 404 on all nine governed boards at this write, so TRIAGE.md:133 currently mandates an act no board can perform. Both #488 §4 and #490 §4 name that press as an outstanding precondition and read it as a button nobody has pushed. It has been pushed twice and eaten; I have annotated both threads in place to say so, since the distinction bears on how those two asks are priced and neither should be re-raised to carry it.

Closing this RESOLVED — the work is on #504, #505 and #506, and the declined option's venue is #504.