Three core labels exist only in ceremony — and the one set the machine can never notice is exactly the hand-set set

[dan-claude-bot]

Verified 2026-07-24 00:20–00:35Z across all five repos.

LABELS.md opens by saying the taxonomy is "core and identical everywhere, created by the labels workflow's bootstrap dispatch". Three labels are not:

label	ceremony	rig	incubator	box	cast
needs-ruling	✅	❌	❌	❌	❌
offsite	✅	❌	❌	❌	❌
attention	❌	❌	❌	❌	❌

(gh label list on each. The state:*, blocker:*, work-queue and release rows are present everywhere, as documented.)

Why: the bootstrap that runs is 0.1.0's

Consumers call ceremony's labels workflow, which pins its own action source at CEREMONY_SELF_REF: "0.1.0". The bootstrap table at that tag is fifteen rows and contains none of the three — needs-ruling (#51), offsite (#68) and attention (#84) all landed after it. The rows exist only on main, at L400-L402.

So this is not a missed dispatch. A consumer re-dispatching bootstrap today still gets fifteen rows — exact-pin doctrine working exactly as designed. The remedy is sequenced through a release, which is fine; what is not fine is the two things below.

1. The blind spot is exactly the hand-set set — by construction

The reconciler does warn about a missing label, but only one it is trying to apply (L521-L526):

#$n: WARNING: missing label(s)$missing — state still converged; dispatch the workflow to bootstrap

needs-ruling, offsite and attention are precisely the three labels the machine never writes — LABELS.md says so of each of them, and lib/ruling.sh is pinned by a test that the sweep never touches the ruling flag. The machine can only notice the absence of labels it applies. The set it cannot notice is identical to the set that is missing. It reads the repo's full label list on every sweep (L598) and has the authoritative table in the same file — it holds both halves of the evidence and compares neither.

This is #101's shape again: the run already knows and throws it away.

2. It is costing real behaviour today, in two different ways

Triage cannot flag an escalation on rig. TRIAGE.md requires that when a ruling gates something on the board, needs-ruling goes on it "so the board shows where the human's turn is". Two live escalations — rig#124 gating rig#110, rig#118 gating rig#103 item 2 — have no flag. dan-claude-bot holds triage there, which cannot create a label either (POST /repos/heavy-duty/rig/labels → HTTP 404). Both are recorded in prose on the issues instead; the board itself is silent about where the human's turn is.

offsite absent is worse than a missing flag — it is a wrong machine action. The flag exempts a cross-repo claim from the 48-hour reclaim (LABELS.md, #68). A builder on any of the four consumers whose deliverable is a PR in another repo cannot set it, so the sweep comments, unassigns them and restores ready on a claim doctrine says is legitimately quiet. Nobody has hit it yet. The -templates split (rig#110) and every cross-repo pairing like rig#109 / box#158 is exactly the shape that will.

What to decide

attention is dormant (epic #83 is open, so it has no consumer yet). The other two are live doctrine with no label behind them.

A — release, bump, dispatch, and say so in the docs. The next ceremony release carries the three rows; each consumer bumps its pin and re-dispatches. Add to CONSUMERS.md — which today says run dispatch once, on a fresh repo — that a pin bump adding a core label needs a re-dispatch. Cheapest. Relies on whoever bumps the pin remembering, forever, with nothing checking.

B — A, plus make the absence legible. One comparison per sweep: the labels the table declares, minus the labels the repo has, warned once as an annotation. Warn-only, never write. This is the option that would have surfaced the gap the day rig converted instead of the day triage tripped over it, and it costs nothing at run time — both lists are already in memory.

C — bootstrap the taxonomy on every scheduled run, not only on dispatch. Self-healing, no human step. It reverses a stated decision (CONSUMERS.md: "Scheduled and PR-triggered runs only reconcile; they do not repeatedly upsert the taxonomy"), and an upsert on a schedule means a hand-edited colour or description is silently reverted on a 15-minute cron.

Recommendation: B. A alone puts a standing obligation on the pin-bumper with nothing to catch a miss, and this thread is what a miss looks like. C fixes it by taking a self-healing power the family deliberately declined, and the failure mode it introduces — the machine quietly overwriting a human's edit every 15 minutes — is the kind of thing that gets discovered months later. B keeps the human as the actor and makes the machine say the true thing it already knows.

Questions, so an issue can carry a spec rather than a choice:

1. B, or something else? If B, does the warning ride on the existing sweep annotation surface (::warning::), or is a missing hand-set label serious enough to want its own once-per-repo issue comment? My read is annotation-only — it is a repo-configuration fact, not an item-level one, and it has no owner to address.
2. Does attention ship now or wait? Its epic (attention — a state-machine wake for comment-borne demands #83) is open. Creating the row ahead of its machinery costs nothing and is idempotent; leaving it out means a second round of this exact bump when attention — a state-machine wake for comment-borne demands #83 lands. I lean ship-now, since the row is already in the table on main.
3. The interim, which needs your hands either way. Nothing reaches a consumer before the next ceremony release. Do you want the three labels created by hand on rig, incubator, box and cast now — twelve labels, exact rows are in the table linked above — so offsite and needs-ruling become usable this week? Or is waiting for the release the right cadence? A bot with triage cannot do it; this is the one part no answer here removes from you.

Answer 1 and 2 and triage mints; 3 is a yes/no.

@danmt — refs: #51, #68, #84 (the three rows), #101 (same evidence-thrown-away shape, minted today), rig#110 / rig#103 (the two flagless escalations), #90 (the adoption epic, closed — this is the leftover it did not cover).

[dan-claude-bot]

Outcome: accept — #105 is minted.

Questions 1 and 2 are settled here rather than sent up: both sit inside the
work, and the repo's own evidence decides them.

Q1 — B, annotation-only. One comparison per sweep between
core_label_rows() and the label list already in REPO_LABELS, emitted as a
single repo-level ::warning:: and writing nothing. Not an item comment: a
missing label is a repo-configuration fact with no item owner, so nagging every
open PR and issue with it would be per-item noise about a repo-wide truth. Three
things the issue nails down beyond the thread — the check must stay silent
when the label read failed (otherwise a transient API error reports the whole
taxonomy as missing and buries the real warning), it must read the table and
not LABELS.md's prose (which keeps blocker:drill-pending, maintainer-created
because the bot bootstrap 403s on it, correctly out of the message), and the
wording must name pin bump then re-dispatch, in that order — a dispatch
alone is exactly the wrong action, and it is the one somebody acting on this
annotation would otherwise take.

Q2 — ships now, and it costs nothing to say so. attention is already in
core_label_rows() on main; the next release carries all three rows whether or
not #83 has landed its wake. There is no second bump to avoid.

---

Q3 — the interim, sharpened by one thing this thread had wrong

Outcome is accept, so this is an operator action rather than a fifth outcome —
in the house ruling format because the call is yours. No needs-ruling label
is set anywhere for it, deliberately: it gates nothing on any board (#105 and
#104 both proceed), and on the four consumers the label does not exist, which is
the thread's own subject.

The correction: ceremony is not in the same boat as its consumers. The
labels workflow carries a self-consumption bypass — on heavy-duty/ceremony it
runs ./actions/labels-reconcile from the default branch, not the
CEREMONY_SELF_REF: "0.1.0" checkout
(labels.yml L73-L92).
So a workflow_dispatch on ceremony bootstraps from main's eighteen-row
table today, no release needed. I diffed that table against ceremony's live
label set row by row: attention is the only difference — every other core
row matches on name, colour and description exactly, the retired defaults are
already gone, and the scope:* rows come from labels.conf and match. One
dispatch creates one label and changes nothing else. That button is already
tracked as an operator item on #83
and I have posted the verification there.

So the decision below is only about the four consumers.

🧭 Ruling — do the consumer repos get their missing core labels by hand now, or at the next pin bump?
Options:  A — hand-create all twelve (three rows x four repos) now
          B — none by hand; they arrive when each consumer bumps its pin and re-dispatches
          C — hand-create the two that are live doctrine (needs-ruling, offsite) on the four repos — eight labels — and let attention ride the release
Recommend: C, because those two are costing behaviour today while attention's doctrine is not even mirrored to a consumer yet (0.1.0 predates #84/#85), and the pin bump's dispatch upserts all three idempotently regardless — so nothing is deferred, only unhurried.
Blocked:  nothing stops. #105 and #104 are ready and independent; every builder and reviewer path is unaffected. What continues broken: rig#124 and rig#118 stay prose-only escalations with a silent board, and any cross-repo claim on a consumer is exposed to a wrong 48h reclaim.
Default:  none — it needs your hands. dan-claude-bot holds `triage` on every one of these repos, including ceremony, and `triage` cannot create a label (POST /repos/heavy-duty/rig/labels → 404) or dispatch a workflow. No default can fire here.

The exact commands, if C or A

Rows verbatim from
core_label_rows();
--force is the same idempotent upsert bootstrap_labels uses, so a later
dispatch agrees with these byte for byte.

# C — the two live ones, on the four consumers
for r in rig incubator box cast; do
  gh label create needs-ruling -R "heavy-duty/$r" --color D4C5F9 --force \
    --description "A human decision is pending — question, options and a recommendation are in the comment"
  gh label create offsite -R "heavy-duty/$r" --color CFD3D7 --force \
    --description "Issue deliverable is a PR in another repository — claim clock paused"
done

# A — additionally
for r in rig incubator box cast; do
  gh label create attention -R "heavy-duty/$r" --color D93F0B --force \
    --description "A demand is parked here for the assignee: pick up the thread, ack by removing this label"
done

# ceremony, independent of the above and of any release (#83's operator item)
gh workflow run labels -R heavy-duty/ceremony   # creates `attention`, changes nothing else

This thread stays open on Q3 alone. The moment the labels exist on rig I flag
rig#110 and rig#103, and this closes.

[dan-claude-bot]

12-hour re-read of Q3's block. Nothing has moved on the labels themselves; two things moved around them, and one of them sharpens the choice enough to be worth your thirty seconds.

The state, re-read live at 12:50Z rather than re-cited

label	ceremony	rig	incubator	box	cast
needs-ruling	✅	❌	❌	❌	❌
offsite	✅	❌	❌	❌	❌
attention	❌	❌	❌	❌	❌

Identical to the table filed at 00:27Z. The four consumers still have none of the three, and ceremony still lacks attention — the one-button workflow_dispatch from the Q3 correction has not been run. That stays tracked as the operator item on #83, where a second evidence entry landed at 12:23Z today.

What changed, and why it does not shorten the wait

#105 closed at 10:07:16Z and #104 at 09:48:33Z. The sweep now warns when the taxonomy declares a label the repository lacks — the exact annotation that would have surfaced this gap the day rig converted.

It is behind the same gate it describes. A consumer runs labels-reconcile at its pinned 0.1.0, so the warning reaches rig and incubator only after they bump — and only then will it start saying, correctly, that they are missing labels a workflow_dispatch creates.

That gate now has a name: 0.2.0 is in flight (#118), with rig#136 and incubator#51 minted and blocked on it. So option B is no longer "someday".

The sharpening — B does not save you the operator act, it defers it

I framed Q3 at 00:49Z as hand-create now, or wait for the pin bump. That was imprecise about what the pin bump actually does. bootstrap_labels runs only on workflow_dispatch; scheduled and PR-triggered runs reconcile and never upsert the taxonomy (a deliberate decision, CONSUMERS.md). So a consumer bumping its pin gets the rows only if someone then dispatches, and triage can neither create a label nor fire a dispatch.

The real choice is therefore:

• C (recommended, unchanged): eight gh label create calls now, and the later dispatch upserts them idempotently and agrees byte-for-byte.
• B: the same act later, once per consumer, bundled with the pin bump — and carried by whoever remembers to dispatch, which is the standing obligation this thread exists because nobody caught.

Not "now versus free". "Now versus the same thing, later, with a memory dependency in front of it."

What it is still costing, with today's receipts

Both flagless escalations took a fresh ladder rung today and both are still invisible on rig's board: rig#124 gating #110 — where you created heavy-duty/rig-templates at 12:15Z, which re-cut the ruling rather than closing it — and rig#118 gating the README quick start, whose default fires at 23:25Z tonight. Neither issue can carry needs-ruling, so the board says nothing about where your turn is on either; it is prose on a thread, twice.

offsite is still unhit and still one cross-repo claim away from a wrong 48-hour reclaim.

The block stands as posted

Default:  none — it needs your hands. dan-claude-bot holds `triage` on every one of these repos, including ceremony, and `triage` cannot create a label (POST /repos/heavy-duty/rig/labels → 404) or dispatch a workflow. No default can fire here.

Options A / B / C and the recommendation of C are unchanged; the commands are in the collapsed block above and are still correct. This is a rung, not a re-flag.

[dan-claude-bot]

Premise update — two of the four ❌ columns no longer have the pin as their excuse.

The 12:50Z table stands label-for-label, but the path to fixing it shortened twice this evening:

• rig bumped to 0.3.0 (rig#137, merged 19:05Z). One workflow_dispatch of labels there now creates needs-ruling, offsite and attention — the rows the two live escalations on that board (rig#118, rig#124) have been running as prose-only for lack of.
• incubator bumped to 0.3.0 (incubator#52, merged 18:36Z). Same one-dispatch story, with one wrinkle: the bump missed the mandatory triage-actors= conf line, so its labels runs are currently red — incubator#60 is ready with the fix, and incubator#57 is the board-local ask for the button, sequenced after that merge.

box and cast are unchanged: still pinned 0.1.0, still waiting on their adoptions (box#168, cast#144) before a dispatch there can create more than the four queue labels.

Net: the ask of you compresses to one click on rig now, one click on incubator after #60 merges — and the original two clicks on box/cast stay parked behind their adoption PRs. Ladder unchanged; the 24h rung of this escalation is 00:27Z.

[dan-claude-bot]

Closing as resolved — the dispatches landed on the two boards that could take them, the promised follow-through is done, and every remaining ask has a live home.

The table, re-read live at 22:55Z:

label	ceremony	rig	incubator	box	cast
needs-ruling	✅	✅	❌	❌	❌
offsite	✅	✅	❌	❌	❌
attention	✅	✅	❌	❌	❌

What discharged:

• rig: all three rows exist — the one-click dispatch this thread asked for, pressed after the 0.3.0 bump. The follow-through promised at 00:49Z is done: rig#110 carried needs-ruling from 21:10Z until @danmt ruled (21:54Z, recorded on rig#124, closed resolved) — the first board-visible escalation this thread existed to make possible. rig#103 closed at 07:01Z when PR `blocked` is invisible to decide_state — a frozen PR reaches state:needs-human and tells the maintainer to merge it #122 merged; its item-2 escalation lives on rig#118 and gates no open issue, so there is nothing left to flag.
• ceremony: attention exists — attention — a state-machine wake for comment-borne demands #83's operator item, the main-table dispatch from the Q3 correction, pressed.
• incubator: still zero of three, and that ask already has its board-local thread: incubator#57, gate cleared (incubator#60 merged, labels runs green since 20:29Z), one click owed.
• box / cast: unchanged and parked behind their adoption work (box#168, cast#144, both open), exactly as filed — a dispatch there before the pin moves past 0.1.0 cannot create these rows.

Q1 and Q2 shipped as #105 (the sweep now warns when the table declares a label the repo lacks — the annotation that would have caught this the day rig converted). Q3's answer arrived as acts rather than a letter: ceremony and rig dispatched, incubator one merge-then-click sequence from done, box/cast at adoption. This thread has nothing left that is not better tracked where it can act, so it closes.