Moving a consumer between ceremony versions is a hand-written 12-to-19-file PR, twelve times per release — and two boards are 15 and 17 releases behind

[dan-claude-bot]

🧭 needs-ruling — moving a consumer between ceremony versions is 12–19 files and a review round, twelve times per release. Eighteen releases in, three boards are 1, 15 and 17 releases behind. What replaces the hand-written pin-bump PR?

Options: A — ceremony upgrade <tag>, a command in ceremony run against a consumer checkout · B — a reusable upgrade workflow a consumer dispatches with a target tag, which opens its own PR · C — release-time fan-out: ceremony's own release dispatches B into every registered consumer · D — a fleet duty in crew that sweeps consumers and opens the PRs

Recommend: A, then B, with C as the payoff. A is the whole substance; B is a thin wrapper around it; C is a for loop over repos.txt. D re-implements B and C on a different engine and makes the fleet a dependency of the ceremony.

📌 And a second, cheaper half that is already built and unused: labels-sweep.yml takes auto_merge at 0.7.7 and zero of the twelve consumers set it. See § 5 — that half is a ruling, not a build.

Blocked: nothing, and nothing is minted anywhere for this. Not a member or gate of #528 — @danmt's 12:43:12Z freeze means nothing minted after it joins that cut.

Default: none. How the fleet moves between versions is org shape. No rung falls here — a discussion carries no needs-ruling label and no labeled event (#526).

---

Analysis — the measurement, why sed is the wrong tool, and what each option costs

@danmt, 2026-08-29:

having a bootstrap of sorts would be interesting imo. something we can ran in any repo and get certain version of ceremony. because we have like 10 repos using ceremony at this point, and one release means going through each with an issue, PR, review rounds, etc… it would be great if getting a given version of ceremony was running a script or something, or flow, idk. but overall having an easier way to move between versions.

Filed separately from #552 at @danmt's framing — "regardless of the template stuff". #552 asks how a new repository arrives governed; this asks how an existing one moves. They converge on one command (§ 6), and that is an argument for building it, not for merging the threads: the hard parts are different, and this one is recurring where #552's is one-time.

1. The cost, measured

Eighteen releases: 0.1.0 0.2.0 0.3.0 0.4.0 0.4.1 0.5.0 0.6.0 0.6.1 0.6.2 0.6.3 0.7.0 0.7.1 0.7.2 0.7.3 0.7.4 0.7.5 0.7.6 0.7.7. Twelve governed boards.

A pin bump is not a one-liner. Six real ones:

PR	files	reviews	open for
box#183 — 0.7.4	19	0	27 min
box#220 — 0.7.6	16	3	2 h 35
rig#202 — 0.7.4 → 0.7.7	13	3	4 h 13
incubator#232 — 0.7.4	12	3	44 min
landing-site#41 — 0.7.4 → 0.7.7	14	3	1 h 29
la-familia-incubator#7 — 0.7.7	9	0	1 min 39

12–19 files, usually three review verdicts. It is every ceremony uses: in the tree (7 to 12 of them, and the same-tag rule means all or none), plus the .ceremony/ mirror re-sync, plus — sometimes — a migration.

2. The drift is the proof that this cost is real and unpaid

pin	boards	releases behind
0.7.7	infra, la-familia-infra, la-familia-incubator, landing-site, lafamilia-site, rig, box, incubator, rig-templates	—
0.7.6	crew	1
0.3.0	martin-reyes-barbershop	15
0.1.0	cast	17

Nothing noticed, because nothing looks. cast has been on the first release ever cut for the entire life of this repository — it predates the two-caller split, triage-actors=, panel[<login>]=, the issues: trigger and fragment-mode changelogs. crew — the fleet itself — is behind by one and has been since 0.7.7 shipped.

3. ⚠️ Why sed 's/0.7.4/0.7.7/g' is the wrong tool, and this is the load-bearing finding

docs/CONSUMERS.md carries ten "available at X and later" notes. Those are migrations, not substitutions, and several are silently destructive if a pin moves past them without the accompanying edit:

• 0.4.1 (labels.yml — detach the reconcile sweep from PR-triggered runs so queue displacement never lands a cancelled check on a PR #209) — the two-caller split. "One atomic PR with exactly four edits": bump every ref, add a new labels-sweep.yml, move the hourly cron off the labels caller (never copy — "a consumer that copies the sweep caller and leaves the old schedule gets DOUBLE sweeps"), and add actions: write. A bare pin bump past 0.4.1 takes the trigger job red on every PR and issue event and stops event-woken sweeps entirely.
• 0.2.0 (feat: reconcile the issue work queue #32) — triage-actors= becomes mandatory. Its absence is a parse failure, not an ignored setting.
• 0.5.0 (actions/labels-reconcile + BUILDER.md/REVIEWER.md — per-author review panels: labels.conf gains panel[<login>]=, resolved at the one point the required set is computed #224) — panel[<login>]= rows. On an earlier pin a bracketed row is "a parse failure, not an ignored setting… the reconcile job dies on every PR event and every sweep until the row is removed, so the whole label board goes down."
• 0.3.0 (labels/scope clobbers a label written while it runs — the ceremony PR can silently lose release #130) — .github/labeler.yml's accepted shape narrows. Any other labeler key now fails the run loudly instead of being half-honoured.
• 0.6.0 (RELEASES.md — the release-management doctrine: epic ladders, gates, release-init, primary windows — one flow for the family #248) — RELEASES.md joins the vendored set, so the mirror gains a file.

So cast's 0.1.0 → 0.7.7 move crosses at least four migrations, two of which take its board down if done naively. A tool that only rewrites refs would break the two consumers that need it most.

⚖️ That is also the design: the real content of this tool is a per-tag migration ladder, and ceremony already has one — written as prose in CONSUMERS.md. The work is turning those paragraphs into ordered, executable steps that a machine applies and that refuse rather than guess where a human decision is genuinely owed (a runner tier, a new panel row). That is a real build, and it is the reason this is worth doing once centrally instead of twelve times by hand.

4. What each option costs

• A — ceremony upgrade <tag>. A command in this repository, run against a consumer's checkout: rewrite every ceremony uses: to one tag, run docs-sync --fix, apply each intervening tag's migration in order, refuse loudly where a decision is owed, print what it did. The builder reviews the diff and opens the PR. All the substance lives here, tested here, released here — the same place the migrations are written. Cost: a real build (the ladder, tests, docs, a tag) and it still needs somebody to run it twelve times.
• B — the reusable upgrade workflow. A consumer dispatches it with a target tag; it runs A on a runner and opens the PR itself. No local checkout, no toolchain, works from the Actions tab — and the operator can move all twelve without cloning anything. Costs one reusable workflow and one caller stub per consumer, which is itself a migration (chicken-and-egg: a consumer needs the caller before it can be upgraded by it — so the first adoption of B is still a hand PR, once, per repo).
• C — release-time fan-out. Ceremony's release job dispatches B into every consumer in a registry. One tag ⟶ twelve PRs already open and green when a human looks. This is the payoff and it is a for loop once B exists; the honest costs are that ceremony gains a cross-repo write (a PAT, or a GitHub App, since GITHUB_TOKEN cannot reach another repository) and a registry of consumers it does not currently have.
• D — a fleet duty in crew. shared/bin/duty.sh exists and repos.txt is already the registry, so this is the cheapest to start. But it puts ceremony's migration knowledge in a second repository, re-implements C on a different engine, and makes the ceremony's upgrade path depend on the fleet being up. It also inherits the fleet's own constraint: fork PRs plus triage-only tokens.

5. 📌 The review half is already built and nobody turned it on

labels-sweep.yml at 0.7.7 declares auto_merge (off | merge | squash | rebase) and auto_merge_release, with off the default. Measured across all twelve consumers this pass: none sets either.

A generated pin-bump PR is exactly the class this exists for — its diff is machine-written and machine-verified (docs-sync --check proves the mirror matches the pin; ci proves the guards pass), and the fleet is already treating these as low-review, just informally and inconsistently: box#183 and la-familia-incubator#7 merged with zero verdicts, the latter 99 seconds after opening, while rig#202 and landing-site#41 took a full three-bot round for the same mechanical change.

⚖️ So the second question, and it needs no build: may a generated pin-bump PR take a reduced panel or auto-merge once green? That is the difference between twelve PRs to draft and review and twelve PRs that land themselves, and it is worth ruling whichever way — the status quo is that this decision is being made per-PR by whoever is around.

6. How this meets #552

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; a fresh repository is the degenerate case where every migration applies to an empty tree.

So A is the first milestone of both threads. #552 recommends a thin template repo whose init workflow calls a bootstrap in ceremony; that command and this one are one command with two entry points. Neither thread should be built without the other's ask in view, and neither is blocked by the other.

7. What this does not propose

• Not automatic merging of anything today. § 5 is a ruling to make, not a default to change.
• Not a moving pin. Every option writes an exact tag. @main and floating majors stay forbidden (#1 D2).
• Not a change to consumption by reference. Workflows and actions stay fetched from the pin at run time; the tool writes caller files and the mirror, nothing else.
• Nothing minted, here or anywhere: all four options change what would be minted, so minting now would pre-empt the ruling.

[danmt]

I agree with the suggestion @dan-claude-bot

[dan-claude-bot]

Ruled — minted as #560 + #561. And § 5 is still open: your agreement does not reach it, and I am not picking it for you.

@danmt 2026-08-29T15:02:38Z, "I agree with the suggestion" — A, then B, with C as the payoff. Taken as ruled, and built in that order.

The build

One epic with #552, not two. You ruled that thread's B four minutes later, and bootstrap and upgrade are the same operation with one of them starting from empty. Two builds would put the migration ladder in two places.

• #560 — the epic. Six rows: the command, the ladder, bootstrap-from-empty, the reusable workflow (your B), the thin template (A new repository should arrive already governed — a template repo, and the question is whether it carries the tree or just the button #552's B), the fan-out (your C).
• #561 — A, and the only child minted today. bin/ceremony-upgrade <tag>: rewrite every ceremony uses: to one tag, re-sync the mirror by calling docs-sync --fix rather than reimplementing it, and refuse where a migration is owed.

§ 3 is what shaped it. The refusal ships before a single migration does, so on the day #561 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, and three of its six must-fail builds exist to kill the optimistic, partial-write and sed versions. A move whose interval contains 0.4.1 must name the two-caller split, the cron move and the actions: write grant specifically; a generic "a migration is owed" does not discharge that criterion.

The later rows are deliberately not minted yet. Their specs depend on #561's shipped refusal table — that table is what tells us what a ladder step has to look like — and TRIAGE.md's bar is that a builder who has read only the issue can succeed. Guessing them today would mint incomplete specs, which splitting never justifies.

Two acts in the epic are yours and pass no mint door: creating the template repository and marking it is_template, and a cross-repo write credential for the fan-out. Nothing is due from you today — the four rows ahead of them are all buildable here.

---

🧭 needs-ruling — may a generated pin-bump PR take a reduced panel, or auto-merge once green?

Re-asked, because it is a second question and a bare agreement with the § 1–§ 4 recommendation does not answer it. § 5 was flagged as "a ruling, not a build" and it needs no build at all: labels-sweep.yml has taken auto_merge (off | merge | squash | rebase) and auto_merge_release since 0.7.7, with off the default. Measured 2026-08-29T14:5xZ across all twelve consumers: none sets either. The machinery is built, shipped and switched off everywhere.

Options:
A — no change: every generated pin-bump PR takes the full three-bot panel, as today · B — a reduced panel for a PR whose diff is machine-written and machine-verified: fewer verdicts, still a human-visible round · C — auto_merge on for pin-bump PRs once every required check is green, no verdicts · D — auto_merge on for release PRs too (auto_merge_release), which is a strictly larger claim and worth separating from C

Recommend: B, and not C yet. A generated pin-bump's diff is machine-verified — docs-sync --check proves the mirror matches the pin, ci proves the guards pass — so a three-bot round on it is largely ceremony. But C removes the last human-visible step from a change that lands in twelve repositories, and it should not be the first thing this fleet automates end to end. B captures most of the saving and keeps a round that a person can read.

⚖️ The status quo is not "A". It is "whoever is around decides per-PR", and that is the real argument for ruling this either way: box#183 and la-familia-incubator#7 merged with zero verdicts — the latter 99 seconds after opening — while rig#202 and landing-site#41 took a full three-bot round for the same mechanical change. Same class of PR, opposite treatment, in the same week.

Blocked: nothing. No board waits on this and nothing is minted anywhere for it. #560 and #561 are correct under every option — the tool opens PRs and says nothing about who reviews them — and this changes no ceremony code either way: it is a value in twelve consumers' caller stubs.

Default: none — hard block. Who may merge what without review is org policy, and its cost lands outside the work. Under #526 the 24h and past-24h rungs do not fire on a hard block and triage never picks it; what I owe instead is a published re-read of this default against what has landed. And no rung falls here in any case: a discussion carries no needs-ruling label and no labeled event, so nothing expires against you and silence has no timer.

---

This thread stays open — it is where the § 5 question now lives, and #560 is where the ruled half lives.

Answered by heavy-duty/ceremony triage, 2026-08-29T16:5xZ. #560 and #561 are minted after your 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 + the re-read I owed on § 5 — the ruled half moved to #568, and the hard block still holds

@danmt No new question, and nothing about your 2026-08-29T15:02:38Z agreement changes. Two things: a pointer of mine that now resolves to a closed issue, and the published re-read my own Default: none — hard block obliges me to post rather than let silence stand in for.

---

1. The pointer — #560 is closed, and this thread must not be read as discharged

My 2026-08-29T16:5xZ answer ends: "This thread stays open — it is where the § 5 question now lives, and #560 is where the ruled half lives."

#560 closed 2026-08-30T15:21:45Z as not planned. A reader checking whether the ruled half survived finds a closed epic with no merged PR and could reasonably conclude the arc was abandoned. It was not.

Where it went. You ruled on 2026-08-30 that the arc gets a release window and that the 0.7.9 epic carries it, so #560 was closed as absorbed rather than left standing beside its own window. #568 carries #560's text verbatim between ## Why one epic and not two and ## Why this order and not a faster one — the two rulings it was minted on (this thread's and 552's), the nine decisions F1–F9, and the six task rows. Only the preamble, #561's tick and ## Dependencies differ.

So: the ruled half now lives on #568, not #560. § 5 still lives here, unchanged. Row 1 shipped — #561 closed 2026-08-30, bin/ceremony-upgrade on the release path at 2b948a7 — and rows 2–6 are unminted, deliberately, as that epic's own note says.

(Same repair is owed on discussion 552, whose keep sentence names #560 as its close condition; it is posted there in this same tick.)

---

2. The re-read of § 5's default, as promised

My ask carried Default: none — hard block — who may merge what without review is org policy and its cost lands outside the work. I also wrote: "what I owe instead is a published re-read of this default against what has landed." TRIAGE.md at main now states that duty in doctrine rather than leaving it my own commitment: on a hard block the 24h and past-24h rungs do not fire, triage never picks, and a published re-read is what is owed at each rung (#526). This is that post. It asks nothing new.

What has landed since 2026-08-29T16:5xZ:

fact	then	now (2026-08-31T23:4xZ)
consumers setting auto_merge or auto_merge_release	0 of 12	0 of 13 — re-measured across every board carrying a ceremony uses: line, plus ceremony's own caller, which passes no with: block either
the toggles themselves	shipped since 0.7.7, off by default	unchanged in 0.7.8 — no merge-toggle entry in that release's changelog section, and labels-sweep.yml's inputs are byte-identical
new instances of the PR class	box#183, la-familia-incubator#7 at zero verdicts; rig#202, landing-site#41 at a full round	none. No board has bumped to 0.7.8: the twelve pin-bump PRs this release owes are all still ahead

The default still holds, and I am not picking it. Nothing that landed makes the decision reversible-inside-the-PR, which is the only thing that would move it off a hard block. The re-measurement is neutral: the class has gained no member, so the "same class of PR, opposite treatment, in the same week" evidence is exactly as strong and no stronger than when I posted it.

Two things did change the picture slightly, and both are worth your eye rather than being buried:

• The twelve bumps this release owes are not ordinary bumps. #588, minted today off discussion #585, measures that bin/ceremony-upgrade cannot perform a single move to 0.7.8 from any of the 18 source tags — 0.7.8 carries a MIGRATIONS row of its own, so every consumer's next bump crosses it and is refused. So the 0.7.8 wave is hand-written, not machine-written, which weakens option B's premise for this wave specifically: B's argument was that a generated diff is machine-verified. It does not weaken B for the waves after the ladder lands, and it is not a reason to prefer C.
• martin-reyes-barbershop is a thirteenth board, at 0.3.0, missed by my 2026-08-29 census of twelve. It changes no argument here; it makes the fan-out one board larger.

Blocked: still nothing. #568's rows are correct under every option — the tool opens PRs and says nothing about who reviews them — and no issue anywhere is gated on this. No rung falls: a discussion carries no needs-ruling label and no labeled event, so nothing expires against you and silence has no timer. I will post the next re-read if something lands that moves it, and not otherwise.

This thread stays open — § 5 is unanswered and this is its venue.

Written 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.

[dan-claude-bot]

🔁 Re-read — the sentence that weakened option B is now false, and § 5 has become a live question with a price

@danmt My 2026-08-31T23:5xZ comment ends "I will post the next re-read if something lands that moves it, and not otherwise." Something landed. No new question, no change to the accept, and nothing is asked of you by a timer — this is the re-read that comment promised.

What I wrote, and why it is no longer true

The twelve bumps this release owes are not ordinary bumps. #588 … measures that bin/ceremony-upgrade cannot perform a single move to 0.7.8 from any of the 18 source tags — 0.7.8 carries a MIGRATIONS row of its own, so every consumer's next bump crosses it and is refused. So the 0.7.8 wave is hand-written, not machine-written, which weakens option B's premise for this wave specifically.

That was correct when written and is now false. #602 merged 2026-09-03T06:00:51Z at 5677d46 and mechanised the 0.7.8 row — the tag's guarded-scaffold block turns out to be written by the docs-sync --fix call the command already makes on the way out of every run, so the crossing needed a truthful plan rather than a writer.

Re-measured live this tick, running the shipped command at origin/main against a constructed consumer at each of the ladder's eighteen source tags, target 0.7.8:

source pin	result
0.7.0 – 0.7.7 — 8 tags	performs the whole move: LEAVES THE PIN AT 0.7.8
0.4.1	performs one rung, to 0.5.0
0.1.0, 0.2.0, 0.3.0, 0.4.0, 0.5.0, 0.6.0–0.6.3 — 9 tags	still refused, at 0.2.0/0.3.0/0.4.1/0.6.0/0.7.0 respectively

So "not a single move" has become nine of eighteen source tags perform something, and eight of them land at 0.7.8 itself — and the eight are exactly the pins the fleet is actually sitting on. Every board stalled at 0.7.7 (box, crew, incubator, lafamilia-site, rig, rig-templates, la-familia-incubator, la-familia-infra) is now a one-command move. 0.7.8 the tag carries docs/SCAFFOLDED.txt, so the fetching route works and this does not depend on --source.

And it holds against a real tree rather than a fixture. Fed martin-reyes-barbershop's own two caller files verbatim, the command plans its 0.3.0 → 0.4.1 crossing concretely — relocating [{cron: "*/15 * * * *"}] into a new sweep caller, deleting the two moved keys by line, and rewriting actions: read to actions: write — so the ladder's reach is measured on the artifact, not derived from the table.

What that does to § 5, which is the only thing still open here

B's premise for this wave is restored. B's argument was that a generated diff is machine-verified; the 0.7.8 wave is now machine-written for eight of the twelve boards, so the argument applies to it rather than only to "the waves after the ladder lands". That is a re-read of my own objection, not a new one.

It also gives § 5 a concrete price for the first time. The question — may a generated pin-bump PR take a reduced panel or auto-merge once green? — now stands over eight identical, machine-generated diffs, each currently owed a draft and up to three verdicts, on boards where zero of twelve consumers set auto_merge or auto_merge_release. I have not re-measured the toggles this tick; they were off everywhere on 2026-08-31 and nothing in 0.7.8 touched them. The status quo remains that this is being decided per-PR by whoever is around.

I am not re-asking, and I am not recommending anything new. § 5's options and my recommendation stand exactly as written; only the fact that weakened one of them has gone.

Where the arc stands, so the pointer resolves to a state

The ladder is three of eight MIGRATIONS rows mechanised — 0.4.1 (#597), 0.5.0 (#600), 0.7.8 (#602) — and the fourth is minted as #605 for 0.6.0, ready and unclaimed. Three crossable tags remain after it. Rows 3–6 of #568 — bootstrap, the reusable workflow, the template repo, the fan-out — are still unminted, deliberately, on the argument this thread's own answer made. 0.7.9 release-init has not run and is held on your explicit request by name, so no window stands.

Blocked: still nothing. #568's rows are correct under every § 5 answer, #605 and #606 are claimable now, and no issue anywhere is gated on this. No rung falls: a discussion carries no needs-ruling label and no labeled event (#526), so nothing expires against you and silence has no timer.

This thread stays open — § 5 is unanswered and this is its venue.

Written by heavy-duty/ceremony triage, 2026-09-03. The eighteen-tag sweep and the barbershop run were both executed in this tick against origin/main, not carried from any body. No label moves and no attention is set: #568 is an unassigned epic and this comment delivers no assignee's next move.