A new repository should arrive already governed — a template repo, and the question is whether it carries the tree or just the button

[dan-claude-bot]

🧭 needs-ruling — how does a new repository acquire the ceremony? @danmt's idea is a template repository; the question is what goes in it, because the obvious answer freezes the pin.

Options: A — a fat template repo carrying the whole governed tree (callers, labels.conf, labeler.yml, VERSION, CHANGELOG.md, changelog.d/, drills/, .ceremony/) · B — a thin template repo carrying one init workflow, which calls a new bootstrap in ceremony at a resolved tag and opens the setup PR · C — no new repository: a bootstrap command in ceremony, run by a builder from the ordinary issue → PR flow

Recommend: B. It gives the operator what they asked for — a new repo that arrives already governed — without putting a second copy of the caller stubs anywhere, which is the one thing this fleet has measured going wrong.

Blocked: nothing. No board waits on this, and nothing is minted anywhere for it — this is the door, not a build.

Default: none. Which repositories exist and how they are created is org shape, and that is @danmt's. But no rung falls here: a discussion carries no needs-ruling label and no labeled event (#526), so silence has no timer.

---

Analysis — the measurement, the constraint GitHub actually imposes, and what each option costs

@danmt's words, 2026-08-29:

my gut feeling says we need a github template so new repos just come with the latest ceremony and whatever that's "custom" is set during creation, that would be kinda cool. note that the during creation is not a hard requirement, it could be done post-creation via issue -> PR flow as usually goes

Filed here rather than as an issue, per TRIAGE.md: ideas go through the discussion door, and the adoption shape for a class of repositories is org policy. Measured 2026-08-29 against 0.7.7 and the live org.

1. The volume is real, and it is not a theory

heavy-duty has created 13 repositories since 2026-06-11, four of them in August. The current state of the 17 that could plausibly carry a board:

pin	boards
0.7.7	la-familia-infra, la-familia-incubator, landing-site, lafamilia-site, rig, box, incubator, rig-templates
0.7.6	crew
0.3.0	martin-reyes-barbershop
0.1.0	cast
no board at all	infra, ledger-cli, handbook, situation-room, la-familia-project-tracker, heavyduty-site

Eleven governed boards across four different tags, and six repositories with no board. Four of those six were created in the last eleven weeks. Whatever the onboarding path is, it is not keeping up.

2. What onboarding one repository actually costs — measured this week, not estimated

heavy-duty/la-familia-infra was onboarded today. The receipt:

• two builder PRs — #6 (the board half) and #7 (the mirror and release half), together 17 files and ~1,870 insertions, essentially none of it repository-specific;
• two operator acts — hand-creating the six-label minimum set, then the bootstrap=yes press, both requiring push, which no fleet identity holds;
• one open upstream ruling (#542) that split the work in half and made the two state repositories disagree in the tree;
• one unreachable acceptance criterion, because a fork PR installing a repository's first workflows registers zero check suites — reproduced twice (la-familia-incubator lib/version.sh — one version abstraction, two backends #3 → actions/drill-recorded — a release carries its evidence #7, la-familia-infra actions/changelog-monotonic — shipped release headings are append-only #6 → actions/drill-recorded — a release carries its evidence #7).

The genuinely per-repo content in all of that is small: the scope:* set, the panel roster, what a drill means, the version backend, and whether the repository publishes an artifact. Everything else is transcription — which is exactly the shape a template is for.

3. The constraint GitHub imposes, which decides most of this

Two mechanisms exist and neither does what the gut feeling asks for on its own:

• Template repositories copy the tree verbatim. There is no substitution at creation — no variables, no prompts, no per-repo values. Every "custom during creation" template in the wild is really template + an init workflow that runs once on the new repo, rewrites placeholders from ${{ github.repository }} and its own inputs, commits, and removes itself.
• The org .github repository supplies community-health defaults and workflow templates (entries in the Actions "New workflow" menu). It cannot ship an arbitrary tree into a new repository.

So the init workflow is not a design flourish; it is the only place per-repo values can be resolved. That is also what makes @danmt's "could be done post-creation via issue → PR flow" free rather than a fallback: the same entry point serves both, because the init step is a workflow_dispatch either way.

4. Why the obvious version is the wrong one

⚠️ A fat template freezes the pin at snapshot time, and this fleet already demonstrates what that costs. cast sits at 0.1.0 and martin-reyes-barbershop at 0.3.0 — 8 and 4 releases behind — with no mechanism that noticed. A template carrying uses: …@0.7.7 becomes a twelfth consumer to bump, and the one nobody remembers, because it has no board, no CI, and no PRs. Every repository created after it drifts starts life stale, and the drift is invisible until somebody reads two trees side by side.

It is also a second source of truth for the caller stubs, which docs/CONSUMERS.md currently owns. That is precisely the drift shape ceremony exists to prevent: "documents have no runtime… anyone tempted to simplify .ceremony/ back to a pointer is reinventing the sometimes-unread doc." The same argument applies to workflow stubs kept in two places, and the mirror invariant does not cover a template repository.

A thin template has no version to be stale. One init.yml that resolves ceremony's latest release at run time and calls into it carries no pin worth drifting.

5. What ceremony would have to grow, and what it already has

There is no bootstrap command today. bin/ holds changelog-assemble and changelog-section only; docs/CONSUMERS.md § Bootstrap a new repo and § On-board a fleet-worked repo are the procedure, written as prose for a human or an agent to execute by hand. And there is no template repository anywhere in the org — all 30 repositories have is_template: false.

The precedent is actions/docs-sync --fix, which already does the hard half of this: ceremony writing files into a consumer's tree, machine-verified afterwards by --check. A bootstrap would be that pattern widened from six doctrine files to the whole scaffold, and it would make CONSUMERS.md's two bootstrap sections executable rather than transcribed — which is the actual defect the measurement in §2 describes.

The per-repo inputs it needs are small and known:

scopes         the scope:* set (name|color|description rows)
panel          the reviewer roster + triage-actors
drill          what a drill means here — prose, the one thing a tool cannot write
version        file | package-json
publishes      whether the artifact hook is wired  ← see #542

📌 That last line is why this thread and #542 are coupled: a bootstrapper has to know which shape it is writing, and #542 is the thread deciding whether "board-only" is a class at all. It is an input to this, not a blocker on it — every option here works under all three of #542's, and only the generated file set differs.

6. What each option costs

• A — the fat template. Zero-click and immediately understandable. Pays for it with a frozen pin, a second copy of the stubs, and a repository that nobody's CI ever looks at. My measurement in §4 is the whole argument against it, and it is an argument from this fleet's own history rather than from principle.
• B — the thin template + bootstrap in ceremony. The template holds one workflow and a README explaining the button. Everything substantive is fetched at run time from a tag, so nothing drifts and CONSUMERS.md stays the single source. Costs: a real build in ceremony (actions/bootstrap or bin/bootstrap, tests, docs, a tag), plus one new repository to create and keep tidy. The init workflow is fiddly to get right once — resolving the latest tag, opening a PR from a workflow, deleting itself — and easy forever after.
• C — the command with no template. Everything B has, minus the new repository and minus the button. Onboarding stays an issue → PR flow, but the issue becomes "run bootstrap, review the diff, decide the five inputs" rather than 1,870 hand-written lines. Strictly less convenient than B and strictly cheaper; it is also B's own first milestone, since B cannot exist until the command does.

B is the recommendation, and C is its first half. If the init workflow turns out to be more trouble than the button is worth, stopping at C loses the click and keeps every other benefit — which is a good property for a thing to have before it is built.

7. What is not being proposed

• Not a change to how machinery is consumed. Workflows and actions stay consumed by reference at a pin; a bootstrapper writes the caller files, not the machinery.
• Not a retroactive sweep. The six ungoverned repositories in §1 are each their own decision, and heavy-duty/infra in particular is already mid-flight under infra#48.
• Not an issue. Nothing is minted on any board for this, deliberately: all three options change what would be minted, so minting now would pre-empt the ruling — and 0.7.8 is not gated by anything here.

[dan-claude-bot]

🔗 The sibling thread — #555, and it shares this one's first milestone

@danmt raised the recurring half separately from the template question: how an existing consumer moves between ceremony versions, where this thread asks how a new repository arrives governed.

They converge on one command. Bootstrap and upgrade are the same operation, one of them starting from empty — a consumer at 0.1.0 moving to 0.7.7 crosses the same migrations a fresh repository skips by starting at the top, and a fresh repository is the degenerate case where every migration applies to an empty tree. So this thread's option B/C — a bootstrap in ceremony, with or without a thin template repo in front of it — and #555's option A are one command with two entry points.

Neither thread blocks the other, and neither should be built without the other's ask in view.

⚠️ What #555 measured that changes this thread's sizing: docs/CONSUMERS.md carries ten "available at X and later" notes, and several are silently destructive if a pin moves past them without the accompanying edit — 0.4.1's two-caller split takes the trigger job red on every event, 0.2.0's triage-actors= and 0.5.0's panel[<login>]= are parse failures on the wrong side of their tag. So the command's real content is a per-tag migration ladder, not a file writer. That is a bigger build than this thread priced — and it is also a stronger argument for §4's conclusion here, that the substance belongs in ceremony rather than snapshotted into a template that would have to carry the ladder too.

[danmt]

Lets do B then @dan-claude-bot

[dan-claude-bot]

Ruled B, and it is minted as one epic with #555 rather than as its own build — #560

@danmt 2026-08-29T15:03:51Z, "Lets do B then" — a thin template repository carrying one init workflow that calls a bootstrap in ceremony at a resolved tag. And four minutes earlier, on #555, "I agree with the suggestion" — A, then B, with C as the payoff.

Those are two rulings on one build, so they get one epic. Bootstrap and upgrade are the same operation with one of them starting from empty: a consumer at 0.1.0 moving to 0.7.7 crosses the same migrations a fresh repository skips by starting at the top. Building them separately would put the same migration knowledge in two places, which is the drift shape this repository exists to prevent. Both threads said so before either was ruled.

What is on the board now

#560	the epic — the decisions, the ordering, and a six-row task list
#561	the first child, and the only one minted today: bin/ceremony-upgrade <tag> — rewrite every ceremony uses: to one tag, re-sync the mirror through docs-sync --fix, and refuse where a migration is owed

Your B is delivered by three of the six rows, not by one, and the template repository is the last of them for a reason given below.

⚠️ The measurement that changed the sizing, and it is the thing to read

A tool that only rewrote refs would break the two consumers that need it most. docs/CONSUMERS.md carries ten "available at X and later" notes, and they are migrations rather than substitutions:

• 0.4.1 — the two-caller split. Add labels-sweep.yml, move the hourly cron off the labels caller (never copy — a copy gives double sweeps), add actions: write. A bare pin bump past it takes the trigger job red on every PR and issue event.
• 0.2.0 — triage-actors= becomes mandatory; its absence is a parse failure.
• 0.5.0 — a panel[<login>]= row on an earlier pin is a parse failure and "the whole label board goes down."

cast's 0.1.0 → 0.7.7 move crosses at least four. So the real content of this build is a per-tag migration ladder, not a file writer — and that is a stronger argument for the thin template you ruled for, because a fat template would have to carry the ladder too.

Hence the order: safety before capability. #561 ships the refusal before it ships a single migration. On the day it merges it can safely move 0.7.4 → 0.7.7 and safely decline 0.1.0 → 0.7.7, changing nothing — asserted by comparing the whole tree before and after, which is one of its acceptance criteria and three of its six must-fail builds. Only then does the ladder earn the right to touch a consumer's cron, and only after that does anything dispatch itself into twelve repositories at once. Running that order backwards is how a fan-out lands twelve simultaneous broken boards.

📌 Two things in this are yours and pass no mint door

Named in the rows that need them rather than minted, because neither a builder's session nor triage can do them:

• Creating the template repository and marking it is_template — needs admin on the org. Its buildable half, the init.yml and the bootstrap entry point, is minted separately from the act.
• A cross-repo write credential for the release-time fan-out — a PAT or a GitHub App, because GITHUB_TOKEN cannot reach another repository.

Nothing is due from you today and no timer runs on either: the four rows ahead of them are all buildable here.

What the epic explicitly does not do

Not a change to how machinery is consumed — workflows and actions stay fetched by reference at an exact tag, and @main and floating majors stay forbidden (#1 D2). Not a fat template: the pin-freezing argument from §4 of this thread is written into the epic as F5, with cast and martin-reyes-barbershop as its evidence. Not a fleet duty in crew: option D stays rejected, and no row is filed there.

This thread stays open until #560 closes — the epic is where the ruling now lives, and the six rows are the progress view.

Answered by heavy-duty/ceremony triage, 2026-08-29T16:5xZ. #560 and #561 are minted after @danmt's 12:43:12Z gate freeze on #528, so neither joins that gate and the 0.7.8 cut does not move.

[dan-claude-bot]

📎 Correction — this thread's close condition names #560, which closed as absorbed, not as delivered

@danmt No new question, and nothing about your 2026-08-29T15:03:51Z ruling for the thin template changes. Repairing a sentence of mine that now points a future pass at the wrong act.

My 2026-08-29T16:5xZ answer ends: "This thread stays open until #560 closes — the epic is where the ruling now lives, and the six rows are the progress view."

#560 closed 2026-08-30T15:21:45Z as not planned. Read literally, my sentence now says to close this thread — with five of the six rows unbuilt and the template repository not created. That would be wrong twice over.

What actually happened. You ruled on 2026-08-30 that the arc gets a release window and that the 0.7.9 epic carries it. #560 was minted the day before as a standalone epic whose Dependencies read "Release window: none standing", so rather than leave it open beside its own window it was closed as absorbed into #568, which carries its text verbatim — the two rulings it was minted on (yours here, and the one on discussion 555 four minutes earlier), the nine decisions F1–F9, and the six task rows. Only the preamble, #561's tick and ## Dependencies differ, and each difference is stated where it occurs.

The trigger is re-pointed: this thread closes when #568's rows are done, not when #560 closed. Your B — a thin template carrying one init workflow and a README, and not the governed tree — is row 5 of six there, unchanged in substance, and it is still the row that needs an operator act (creating the repository and marking it is_template needs admin on the org, so its buildable half is minted separately from the act). Nothing else in that answer changes.

Where the arc stands, so the pointer resolves to a state rather than just a number: row 1 shipped — #561 closed 2026-08-30, bin/ceremony-upgrade on the release path at 2b948a7 and released in 0.7.8. Rows 2–6 are unminted, deliberately: their specs depend on row 1's shipped shape, which is the argument this thread's answer already made for the ladder. 0.7.9 release-init has not run and is held on your explicit request by name, so no window stands and nothing here is a member of anything yet.

(The same repair is owed on discussion 555, whose answer says "#560 is where the ruled half lives"; it is posted there in this same tick.)

This thread stays open, on its re-pointed trigger.

Corrected by heavy-duty/ceremony triage, 2026-08-31T23:5xZ. No label moves and no attention is set: #568 is an unassigned epic and this comment delivers no assignee's next move.