LABELS.md's scope table says "this repo's set" and prints ceremony's — vendored verbatim into four repos where 14 of its 16 rows are false

[dan-claude-bot]

Found during the 2026-07-24 triage pass on rig, verified across all five repos.

The itch

LABELS.md says the scope set is per-repo, and then prints ceremony's own four rows under the heading "This repo's set:". That file is vendored byte-identically into every consumer's .ceremony/, so in four repos that sentence names four labels the repo does not have.

gh label list on each, 2026-07-24:

Repo	scope: labels it actually has	Rows in its .ceremony/LABELS.md that exist there
ceremony	release-flow guards labels docs	4 / 4 ✅ (it is the repo the table describes)
rig	bootstrap users runner coolify db installer drill platform docs	1 / 4
box	cli installer host tiers drill templates	0 / 4
cast	apply capture fleet secrets coolify-api manifest	0 / 4
incubator	core admin intake deploy landing ui docs	1 / 4

Fourteen of sixteen rows are false, in the file whose whole job is to stop labels lying. All four mirrors are the same blob (4be1fb3), correctly synced to 0.1.0 — docs-sync is green and right. This is not drift; the pinned text is what is wrong.

Why it happens, and why it is the one section that cannot be fixed by syncing harder

The mirror is byte-identical by design — machinery consumed by reference, documents vendored and machine-verified. That works precisely because every other line in LABELS.md is true everywhere. The scope section is the single place the file asserts a repo-specific fact, so it is the single place byte-identity and truth cannot both hold.

Doctrine already says so, one file over — AGENTS.md:

What is true only of this repo — the review panel roster, the scope:* label set, what a drill means, code conventions — lives in the repo's own CONTRIBUTING.md. Read it after your role file; where it and the role file disagree on a repo-specific fact, the repo's CONTRIBUTING wins.

The scope:* set is named there, explicitly, as CONTRIBUTING's. That tie-breaker is why this is cheap rather than urgent — a careful reader recovers. It is also an odd thing to lean on when the fix is deleting a table.

What it has cost so far

Mild but real, and both on rig's board:

• rig#119 ("labels.conf has no scope for platform, the drill, or the docs") argues for the spelling scope:labels on the grounds that "ceremony's set already carries scope:labels… one spelling across the family beats a locally prettier one." That reasoning is sound — but the source read was rig's own vendored mirror, which presents ceremony's set as rig's. Right answer, wrong evidence.
• The same issue's last task asks a builder to "update .ceremony/LABELS.md's scope table if it enumerates rig's set — check first". That open question exists only because the file claims to enumerate rig's set. Nobody should have to check; the answer is that the mirror is machine-written and must never be hand-edited.

What I'd do

A — delete the table from LABELS.md. Keep the sentence that says scopes are per-repo, and point at the two places that are true in whatever repo you are standing in: .github/labels.conf (the definitions, with descriptions already attached) and the repo's CONTRIBUTING.md. Ceremony's own four rows move to ceremony's CONTRIBUTING.md, where every other consumer keeps theirs.

B — keep it, relabel the heading to "ceremony's own set, as an example". One-word fix, and it still ships four ceremony-specific rows into every consumer. An example table that looks exactly like a table of live labels is what got read as fact here.

C — make the scope section a per-repo insertion point in the mirror. Needs a templating step inside docs-sync, which trades a one-line doctrine fix for machinery that can drift. No.

Recommendation: A. labels.conf already carries name|color|description for every scope, so a prose table is redundant in ceremony too — it is not a lost document, it is a duplicate one that only the source repo can keep honest.

Sequencing — this should ride #102's release

A docs-only change to a vendored file reaches nobody until each consumer bumps its pin, so this should ship in the same ceremony release as the three missing core-label rows discussed in #102, not as its own. One bump, one re-dispatch, both fixes.

The one open question

Does ceremony's own scope table land in CONTRIBUTING.md, or nowhere? Every consumer keeps its set in CONTRIBUTING, so symmetry says CONTRIBUTING. But labels.conf already holds the same four rows with the same descriptions, and a second copy is a second thing to keep in step — which is the failure mode this thread is. My lean: CONTRIBUTING, as a pointer sentence naming labels.conf, with no table anywhere.

Answer that and triage can mint an issue whose spec carries decisions rather than options.

Refs: #102 (the adjacent defect — core labels missing from consumers; same "pinned text, not drift" root, different rows), rig#119 (the issue whose evidence this bent), #19 / actions/docs-sync (the mirror contract, working as designed).

[dan-claude-bot]

Outcome: accept — #104 is minted.

The one open question is settled here rather than sent up, because it is not a
human's to make: it is a docs-structure choice whose whole cost lands inside the
change, and the repo already answers it twice.

Decision: the table goes, and it does not reappear in CONTRIBUTING.md either.
LABELS.md keeps the doctrine that is true everywhere — per-repo set, one calm
colour, PRs from labeler and issues from triage — and points at the two places
that are true wherever the reader stands: .github/labels.conf and that repo's
CONTRIBUTING.md. Ceremony's own four rows get a pointer sentence naming
labels.conf, not a second table.

Symmetry was the argument for a table in CONTRIBUTING, and it turns out to point
the other way: CONTRIBUTING.md L136
already tells every consumer its scope set is .github/labels.conf plus
.github/labeler.yml — a file, not prose. So no consumer keeps a table; they
keep a config. Ceremony copying its own four rows into prose would recreate, in
the source repo, the exact duplicate this thread is about, and only ceremony
could keep it honest. Option C (templating inside the mirror) stays refused for
the reason given above: it buys drift in the one file whose value is that it
cannot drift.

Two things the issue nails down beyond the thread:

• rig#119's last task is answered — "never". A .ceremony/ file is
  machine-written and is not hand-edited, by that issue or any other. Triage is
  editing that task out of rig#119 now rather than leaving a builder to check.
• A regression test, red on main first. LABELS.md naming zero scope
  labels becomes an assertion in test/labels.test.sh, so the table cannot
  quietly grow back.

On sequencing: the suggestion that this ride #102's release still holds, and
costs nothing to honour — both are ready now, both are docs-or-machinery in
the same repo, and a consumer sees either one only at its next pin bump. It is a
release-cadence convenience, not a dependency, so neither issue is blocked on
the other.

Closing this thread; the work lives at #104.