bootstrap=no suppresses nothing: the composite drops the input and the script gates on the event name, so every trigger-woken sweep re-upserts the whole taxonomy

[dan-claude-bot]

Triage finding, 2026-08-17T07:2xZ, measured at 663ba83 (main). Filing rather than minting — see the last section for why, and for what I am not asking anyone to decide today.

The finding

actions/labels-reconcile's bootstrap input cannot suppress the bootstrap. It works in one direction only:

action.yml:39-43

if [ "$BOOTSTRAP" = yes ]; then
  export GITHUB_EVENT_NAME=workflow_dispatch
fi
bash "$GITHUB_ACTION_PATH/labels-reconcile.sh"

and the script's only gate is the event name — grep -n BOOTSTRAP actions/labels-reconcile/labels-reconcile.sh returns nothing, so the variable action.yml carefully places in the step's env is read by no line of the subject:

labels-reconcile.sh:1151-1154

if [ "${GITHUB_EVENT_NAME:-}" = workflow_dispatch ]; then
  log "workflow_dispatch: bootstrapping the taxonomy"
  bootstrap_labels
fi

A trigger-woken sweep already arrives as workflow_dispatch — that is how labels.yml:138 wakes it, and the anti-recursion exemption that lets it do so with no PAT is the whole reason it is a dispatch:

gh workflow run "$SWEEP_WORKFLOW" -R "$GITHUB_REPOSITORY" -f bootstrap=no

So yes forces a state that no is powerless to leave. The input is dead: the operator's manual full-board bootstrap and an event-woken sweep are indistinguishable to the script, which is the exact thing the input was added to fix.

The design says otherwise, in three places

1. labels-sweep.yml:23-27 — "The trigger job's dispatches carry bootstrap=no — ~20 label upserts per sweep is too chatty for every board event, the same reason cron runs never bootstrapped."
2. labels-sweep.yml:104-110 — "the event name alone no longer separates the operator's manual full-board bootstrap from an event-woken sweep — the caller's bootstrap dispatch input does: the trigger passes "no", a bare manual dispatch defaults to "yes"."
3. docs/CONSUMERS.md:815-817 — "Scheduled and trigger-driven runs only reconcile; they do not repeatedly upsert the taxonomy (the trigger's dispatch carries bootstrap=no)." Published to every consumer, and false in its second clause.

The caller itself is correct and does real work computing a value nothing consumes — labels-sweep.yml:115 and its dogfood twin at :125 both evaluate

bootstrap: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.bootstrap != 'no' && 'yes' || 'no' }}

The cron path is fine, and that is worth stating precisely: a schedule event is not workflow_dispatch, so the scheduled sweep genuinely does not bootstrap. Only the trigger-woken runs are affected — which is nearly all of them.

Measured live, in this repository, four minutes ago

Not carried from my #423 incubator measurement — re-measured here, in ceremony, on run 32004881752, which my own issue-body write at 07:13:32Z woke:

07:13:48.9203840Z   BOOTSTRAP: no                                    ← the step env
07:13:48.9415231Z labels: workflow_dispatch: bootstrapping the taxonomy   ← 21 ms later
07:13:58.5042495Z HTTP 404: … /labels/duplicate                      ← upserts done, retires begin
07:13:59.2563001Z labels: retire: 'good first issue' … — continuing
07:14:01.9738396Z labels: reconciled.
                  duration_ms=13063                                  ← the whole reconcile step

The input said no; the taxonomy was bootstrapped anyway, 21 milliseconds later.

What it costs

• ~10.3 s of the 13.1 s reconcile step is the bootstrap — the upserts alone run 07:13:48.94 → 07:13:58.50, and the six retire probes follow. Roughly four fifths of the step.
• 28 labels in this repository's taxonomy today (gh api /repos/heavy-duty/ceremony/labels --paginate), upserted on every trigger-woken sweep.
• ~10 sweeps an hour here: the last 200 dispatches of self-labels-sweep.yml span 2026-08-16T11:05:26Z → 2026-08-17T07:17:11Z, 20 h 12 m. Not every dispatch pays it — concurrency cancels a displaced run — but a completing one pays it in full.
• It is per-repository, and every governed repo runs the same caller.

Why it matters beyond the runner minutes

This is the mechanism behind the thing I published, retracted and re-published on #423 yesterday: a core label added by a pin bump arrives in a consumer's taxonomy with no operator act, on the first board event after the bump. Convenient, undocumented, and the direct opposite of what docs/CONSUMERS.md:817-819 instructs a consumer to do ("bump the pin first and then re-dispatch"). Fixing the input restores the documented world — and missing_core_labels_warning is already there to nag the consumer who has not dispatched, so the machinery for that world is built.

So the repair is not only a saving; it is a consumer-visible behaviour change, and that is the part worth a second opinion rather than my say-so.

Two candidate repairs

R1 — make the script read the input (recommended). labels-reconcile.sh gates on an explicit BOOTSTRAP variable — the one action.yml already exports and nothing reads — and action.yml stops rewriting GITHUB_EVENT_NAME. The caller's computed value becomes load-bearing, which is what every comment above already claims. Nothing else in the script reads GITHUB_EVENT_NAME (grep finds the single site quoted above), so the blast radius is the gate itself plus the fixtures that drive it.

R2 — force the event name in both directions. action.yml exports GITHUB_EVENT_NAME=workflow_dispatch on yes and something else on no. One line, no change to the script or the test surface. But it makes the composite lie about the event to anything that later reads it, and the next reader has to rediscover why.

Recommend R1, on the ground that R2 keeps the defect's shape — a gate reading a fact that is not the question being asked — and this is the second time that shape has cost a wrong published claim.

Class, and what I am not doing

Ordinary, not front row: it breaks no build, mislabels no board, and reds no consumer. It is cost plus a false published sentence, and TRIAGE.md says an uncertain class takes ordinary. Its deliverable is actions/labels-reconcile/labels-reconcile.sh, which #460 is rewriting and #461 extends — so a minted issue takes an unconditional collision edge behind the newest open carrier and lands at the end of that chain. Nothing here asks for a label to move on work in flight.

I have not minted it, and this is not a ruling ask — no options table, no default, no clock. @danmt has a live decision in front of him on #464 and this one holds nothing. If nobody objects to R1, I will converge this and mint on a later pass; if the unasked-label arrival turns out to be behaviour anyone wants to keep, say so here and the repair becomes documenting it instead.

[danmt]

Go with R1 @dan-claude-bot

[dan-claude-bot]

Ruled and minted: #472 — actions/labels-reconcile — the bootstrap gate reads BOOTSTRAP, not the event name.

@danmt took R1 at 2026-08-17T13:28:57Z, so that is the spec: the script gates on the BOOTSTRAP variable action.yml already exports, action.yml stops rewriting GITHUB_EVENT_NAME, and the caller's computed value becomes load-bearing exactly as every comment around it already claims. R2 is spent and the issue records it as such.

Three things the issue carries that this thread did not:

• Two more false sites, found while pinning the census at a47e0dd. labels.yml:118-122 argues a dispatched labels caller "cannot double-fire bootstrap" — it does today, through its own trigger job — and self-labels-sweep.yml:24-26 states the "must not re-upsert" rule the machine does not implement. Five sites, not three; the census criterion is keyed to bootstrap or to the event name, because two of the five argue from the event.
• The input gets validated where it is read — BOOTSTRAP="${BOOTSTRAP-no}" and a validate_bootstrap in validate_auto_merge's shape, empty included. An input that looks like it works and does not is the subject of this issue; the direct-script path is the one place a typo would silently pick a default.
• The behaviour change is stated in docs/CONSUMERS.md and the changelog fragment, not just shipped: after actions/labels-reconcile — the bootstrap gate reads BOOTSTRAP, not the event name: bootstrap=no must suppress the bootstrap #472 a core label added by a pin bump waits for a dispatch instead of installing itself on the next board event, and missing_core_labels_warning is the nag in between. That is the world docs/CONSUMERS.md:817-819 already instructs, and R1 is what makes the instruction true.

Minted blocked behind #468, ordinary precedence: labels-reconcile.sh, action.yml, test/labels-reconcile.test.sh, labels-sweep.yml and docs/CONSUMERS.md are all inside #468's fence, so the newer issue takes the back of the chain (#462 → #468 → #472) and no label on any existing issue moves. Nothing here asks for a queue change on work in flight, and no caller — here or in any consumer — is edited by the repair.

Converged; closing. Further findings on the gate belong on #472.