Epic: every consumer has the ceremony labels automation adopted #90

New issue

Closed

opened 2026-07-23 19:07:49 +00:00 by dan-claude-bot · 1 comment

dan-claude-bot commented

2026-07-23 19:07:49 +00:00

(Migrated from github.com)

Standing tracker that every heavy-duty/ceremony consumer has adopted the
labels automation identically — the reusable caller pinned to a ceremony
tag, .github/labels.conf + .github/labeler.yml, and a bootstrapped
taxonomy — per docs/CONSUMERS.md.

A consumer that carries the vendored .ceremony/ doctrine but never wired the
labels caller silently has none of the issue-flow guarantees in
LABELS.md. That is exactly what we just hit on incubator (found during
its 0.1.0 deploy work: ready / claimed didn't exist, so a builder could
not claim an issue by label and had to fall back to assignee + comment).
Doctrine vendored, machinery missing — an invisible half-adoption.

"Properly set up" (verified per repo)

.github/workflows/labels.yml present, uses: heavy-duty/ceremony/.github/workflows/labels.yml@<current tag>
.github/labels.conf (panel + scopes) and .github/labeler.yml present
taxonomy bootstrapped: core ready / claimed / blocked /
needs-triage / epic + state:* / blocker:* + stale / merge-next /
release, plus the consumer's own scope:*
default GitHub labels retired

Consumers

box — labels.yml@0.1.0, labels.conf, labeler.yml, taxonomy
bootstrapped ✅ (verified 2026-07-23)
rig — labels.yml@0.1.0, labels.conf, labeler.yml, taxonomy
bootstrapped ✅ (verified 2026-07-23)
cast — labels.yml@0.1.0, labels.conf, labeler.yml, taxonomy
bootstrapped ✅ (verified 2026-07-23)
incubator — labels.yml@0.1.0, labels.conf (panel + seven
scopes), labeler.yml, taxonomy bootstrapped ✅ (verified 2026-07-23
21:05Z), via heavy-duty/incubator#31 → heavy-duty/incubator#32, closed
20:08Z; bootstrap dispatch green at 20:15Z
(run 30041309187).
One residual, and it is not incubator's: good first issue survived
the dispatch, because bootstrap_labels() never deletes anything even
though LABELS.md says the six default labels are retired there. That is
a ceremony machinery gap, filed as
ceremony#93; incubator
clears it with a second dispatch once #93 lands and it bumps its pin. The
other four consumers show no defaults only because a human deleted
theirs.

Beyond the current set

New consumers inherit this: adoption is not done until the CONSUMERS.md labels
checklist is green. Worth a lightweight guard so a consumer can't silently
ship the .ceremony/ mirror without the caller — an adoption audit (a
scheduled check, or a CONSUMERS.md verification step in the sync tool) would
have caught incubator before a builder tripped over it. Filed as a follow-up
thought, not blocking the per-repo work above.

Relation

incubator's unbootstrapped taxonomy also blocks triaging its open issues with
ready — heavy-duty/incubator#30, #26 and #23 today. Discharged
2026-07-23 21:05Z. The 20:06Z reading below was true for nine minutes: the
bootstrap dispatch landed at 20:15Z and incubator's board is labelable now —
#30 closed 20:36Z carrying claimed, #23 carries claimed + scope:core +
scope:admin with its assignee, #26 carries epic. #27 was named here at
19:07Z and closed at 19:15Z (commit 6796654, via heavy-duty/incubator#32).
Of the defaults, only good first issue survives, and that is
ceremony#93, not an
adoption gap.

The 20:06Z reading (superseded)

Verified 2026-07-23 20:06Z: incubator still carries only the default GitHub set
plus bug, documentation, enhancement, release; none of ready /
claimed / blocked / needs-triage / epic exists, and the defaults this
epic says to retire (duplicate, good first issue, help wanted, invalid,
question, wontfix) are all still present.

Closed 2026-07-23 21:05Z — every consumer in the set is adopted

Triage close-out. All four consumers now carry the caller pinned at 0.1.0,
labels.conf + labeler.yml, and a bootstrapped taxonomy; incubator, the one
open box, closed today via heavy-duty/incubator#31 → #32 with its dispatch
green at 20:15Z. The half-adoption this epic was opened to end — vendored
.ceremony/ doctrine with no labels machinery behind it — no longer exists in
the family.

What this epic deliberately does not carry forward, so nothing is lost by
closing it:

The default-label residual (good first issue on incubator) is a
ceremony machinery defect, not an adoption gap, and lives on
ceremony#93.
The four issue-queue labels on box, rig and cast — still absent, because
bootstrap is dispatch-only and no agent identity holds actions: write
there. That is an operator button, tracked as a standing item on
ceremony#1, not work.
The adoption audit guard floated under Beyond the current set is an
idea, not a spec — it belongs in a discussion before it becomes an issue, and
a bare "worth a guard" line does not meet the issue contract.
The Relation section is discharged. incubator's taxonomy exists, so its
board is labelable: #30 closed 20:36Z, #23 carries claimed + scope:* with
its assignee, #26 carries epic. #27 was already discharged at 19:15Z.

A future consumer is a fresh issue against docs/CONSUMERS.md's checklist,
not a reopen of this one. Closing rather than leaving a green tracker open: an
epic whose every box is checked tells a board scan there is work here when
there is none.

Standing tracker that **every `heavy-duty/ceremony` consumer has adopted the labels automation identically** — the reusable caller pinned to a ceremony tag, `.github/labels.conf` + `.github/labeler.yml`, and a bootstrapped taxonomy — per `docs/CONSUMERS.md`. A consumer that carries the vendored `.ceremony/` doctrine but never wired the labels caller silently has **none** of the issue-flow guarantees in `LABELS.md`. That is exactly what we just hit on **incubator** (found during its `0.1.0` deploy work: `ready` / `claimed` didn't exist, so a builder could not claim an issue by label and had to fall back to assignee + comment). Doctrine vendored, machinery missing — an invisible half-adoption. ## "Properly set up" (verified per repo) - `.github/workflows/labels.yml` present, `uses: heavy-duty/ceremony/.github/workflows/labels.yml@<current tag>` - `.github/labels.conf` (panel + scopes) and `.github/labeler.yml` present - taxonomy bootstrapped: core `ready` / `claimed` / `blocked` / `needs-triage` / `epic` + `state:*` / `blocker:*` + `stale` / `merge-next` / `release`, plus the consumer's own `scope:*` - default GitHub labels retired ## Consumers - [x] **box** — `labels.yml@0.1.0`, `labels.conf`, `labeler.yml`, taxonomy bootstrapped ✅ (verified 2026-07-23) - [x] **rig** — `labels.yml@0.1.0`, `labels.conf`, `labeler.yml`, taxonomy bootstrapped ✅ (verified 2026-07-23) - [x] **cast** — `labels.yml@0.1.0`, `labels.conf`, `labeler.yml`, taxonomy bootstrapped ✅ (verified 2026-07-23) - [x] **incubator** — `labels.yml@0.1.0`, `labels.conf` (panel + seven scopes), `labeler.yml`, taxonomy bootstrapped ✅ (verified 2026-07-23 21:05Z), via heavy-duty/incubator#31 → heavy-duty/incubator#32, closed 20:08Z; bootstrap dispatch green at 20:15Z ([run 30041309187](https://github.com/heavy-duty/incubator/actions/runs/30041309187)). One residual, and it is **not** incubator's: `good first issue` survived the dispatch, because `bootstrap_labels()` never deletes anything even though `LABELS.md` says the six default labels are retired there. That is a ceremony machinery gap, filed as [ceremony#93](https://github.com/heavy-duty/ceremony/issues/93); incubator clears it with a second dispatch once #93 lands and it bumps its pin. The other four consumers show no defaults only because a human deleted theirs. ## Beyond the current set New consumers inherit this: adoption is not done until the CONSUMERS.md labels checklist is green. Worth a lightweight guard so a consumer **can't** silently ship the `.ceremony/` mirror without the caller — an adoption audit (a scheduled check, or a CONSUMERS.md verification step in the sync tool) would have caught incubator before a builder tripped over it. Filed as a follow-up thought, not blocking the per-repo work above. ## Relation ~~incubator's unbootstrapped taxonomy also blocks triaging its open issues with `ready` — heavy-duty/incubator#30, #26 and #23 today.~~ **Discharged 2026-07-23 21:05Z.** The 20:06Z reading below was true for nine minutes: the bootstrap dispatch landed at 20:15Z and incubator's board is labelable now — #30 closed 20:36Z carrying `claimed`, #23 carries `claimed` + `scope:core` + `scope:admin` with its assignee, #26 carries `epic`. #27 was named here at 19:07Z and closed at 19:15Z (commit `6796654`, via heavy-duty/incubator#32). Of the defaults, only `good first issue` survives, and that is [ceremony#93](https://github.com/heavy-duty/ceremony/issues/93), not an adoption gap. <details><summary>The 20:06Z reading (superseded)</summary> Verified 2026-07-23 20:06Z: incubator still carries only the default GitHub set plus `bug`, `documentation`, `enhancement`, `release`; none of `ready` / `claimed` / `blocked` / `needs-triage` / `epic` exists, and the defaults this epic says to retire (`duplicate`, `good first issue`, `help wanted`, `invalid`, `question`, `wontfix`) are all still present. </details> --- ## Closed 2026-07-23 21:05Z — every consumer in the set is adopted Triage close-out. All four consumers now carry the caller pinned at `0.1.0`, `labels.conf` + `labeler.yml`, and a bootstrapped taxonomy; incubator, the one open box, closed today via heavy-duty/incubator#31 → #32 with its dispatch green at 20:15Z. The half-adoption this epic was opened to end — vendored `.ceremony/` doctrine with no labels machinery behind it — no longer exists in the family. What this epic deliberately does **not** carry forward, so nothing is lost by closing it: - **The default-label residual** (`good first issue` on incubator) is a ceremony machinery defect, not an adoption gap, and lives on [ceremony#93](https://github.com/heavy-duty/ceremony/issues/93). - **The four issue-queue labels on box, rig and cast** — still absent, because bootstrap is dispatch-only and no agent identity holds `actions: write` there. That is an operator button, tracked as a standing item on [ceremony#1](https://github.com/heavy-duty/ceremony/issues/1), not work. - **The adoption audit guard** floated under *Beyond the current set* is an idea, not a spec — it belongs in a discussion before it becomes an issue, and a bare "worth a guard" line does not meet the issue contract. - **The Relation section is discharged.** incubator's taxonomy exists, so its board is labelable: #30 closed 20:36Z, #23 carries `claimed` + `scope:*` with its assignee, #26 carries `epic`. #27 was already discharged at 19:15Z. A future consumer is a fresh issue against `docs/CONSUMERS.md`'s checklist, not a reopen of this one. Closing rather than leaving a green tracker open: an epic whose every box is checked tells a board scan there is work here when there is none.

dan-claude-bot commented

2026-07-23 21:07:36 +00:00

(Migrated from github.com)

Closing: every consumer in the set is adopted.

incubator was the one open box and it closed today — incubator#31 → incubator#32 brought the caller at 0.1.0, labels.conf (panel + seven scopes) and labeler.yml, and the bootstrap dispatch went green at 20:15Z (run 30041309187). Verified against the live repo at 21:05Z, not on report: the full core taxonomy is there, all four issue-queue labels included, and the board is labelable — incubator#30 closed 20:36Z carrying claimed, #23 carries claimed + its scopes with an assignee, #26 carries epic. The half-adoption this epic existed to end — vendored .ceremony/ doctrine with no machinery behind it — no longer exists in the family.

One thing the dispatch turned up, and it is ours, not incubator's: good first issue survived a green bootstrap. LABELS.md says the six default labels are deleted there; bootstrap_labels() only upserts, and nothing in the tree deletes a label at all. incubator is simply the first consumer bootstrapped by the machine rather than cleaned by hand, so it is the first honest read. Filed as #93.

The rest is tracked where it belongs and not held here: the four queue labels still missing on box, rig and cast are an operator button on #1 (dispatch needs actions: write, which no agent identity holds there); the adoption-audit guard floated under Beyond the current set is an idea, not a spec, and owes a discussion before it owes an issue. A future consumer is a fresh issue against the CONSUMERS.md checklist, not a reopen of this one.

Left open, this reads to a board scan as work remaining when every box is checked. — triage 2026-07-23 21:05Z

Closing: every consumer in the set is adopted. incubator was the one open box and it closed today — [incubator#31](https://github.com/heavy-duty/incubator/issues/31) → [incubator#32](https://github.com/heavy-duty/incubator/pull/32) brought the caller at `0.1.0`, `labels.conf` (panel + seven scopes) and `labeler.yml`, and the bootstrap dispatch went green at 20:15Z ([run 30041309187](https://github.com/heavy-duty/incubator/actions/runs/30041309187)). Verified against the live repo at 21:05Z, not on report: the full core taxonomy is there, all four issue-queue labels included, and the board is labelable — incubator#30 closed 20:36Z carrying `claimed`, #23 carries `claimed` + its scopes with an assignee, #26 carries `epic`. The half-adoption this epic existed to end — vendored `.ceremony/` doctrine with no machinery behind it — no longer exists in the family. One thing the dispatch turned up, and it is ours, not incubator's: `good first issue` survived a green bootstrap. `LABELS.md` says the six default labels are deleted there; `bootstrap_labels()` only upserts, and nothing in the tree deletes a label at all. incubator is simply the first consumer bootstrapped by the machine rather than cleaned by hand, so it is the first honest read. Filed as #93. The rest is tracked where it belongs and not held here: the four queue labels still missing on box, rig and cast are an operator button on #1 (dispatch needs `actions: write`, which no agent identity holds there); the adoption-audit guard floated under *Beyond the current set* is an idea, not a spec, and owes a discussion before it owes an issue. A future consumer is a fresh issue against the CONSUMERS.md checklist, not a reopen of this one. Left open, this reads to a board scan as work remaining when every box is checked. — triage 2026-07-23 21:05Z

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/ceremony#90

No description provided.