A repo that adopts the board half and never releases has nowhere to put the pin — the pin lives in release.yml, and state repos have no release.yml

[dan-claude-bot]

The rule, quoted at 0.7.7

docs/CONSUMERS.md § Version pinning, third bullet:

One pin governs machinery and doctrine. The ref in the consumer's
release.yml uses: line is the single pin: docs-sync reads it from
exactly there and verifies the .ceremony/ mirror against it — there
is no second pin to fall out of sync (#19).

And it is not only prose. actions/docs-sync/docs-sync.sh:73 at the same tag:

WORKFLOW=".github/workflows/release.yml"

Hardcoded, single-valued, no fallback.

The case the rule cannot express

A repository that adopts the board half and never releases anything has nowhere to put the pin.

heavy-duty/infra is a state repository. Its own README opens: "State, not code. This repo is the instance… It executes nothing." No VERSION, no CHANGELOG.md, no changelog.d/, no build, no artifact, nothing to tag. A release workflow there would be a file that never legitimately runs, created for one uses: line so that a doc-mirror checker can find a string in it.

It does need the board half. It is fleet-worked — triage mints here, builders build here, PRs land here — and the queue taxonomy is what that flow runs on.

What that repository looks like today, measured 2026-08-28:

.github/	absent entirely — no workflows, no labels.conf, no labeler.yml
labels present	the nine GitHub defaults only: bug, documentation, duplicate, enhancement, good first issue, help wanted, invalid, question, wontfix
labels absent	every core row — ready, blocked, claimed, post-merge, needs-triage, epic, needs-ruling, attention, operator, offsite, release, every state:*, every blocker:*, every scope:*
Discussions	disabled
open issues carrying a queue label	0 of 7

LABELS.md says the defaults "are deleted at bootstrap — a question is a discussion, not an issue." All nine are still there, which is the cleanest single proof that no bootstrap has ever run on this repository.

The visible consequence is on heavy-duty/infra#20, #26, #38, #43, #45, #46 and #47: seven open issues, none of which can carry ready or blocked, because those labels do not exist and no fleet identity can create them ("push": false, by the design FLEET.md states — "the agents team holds the triage role, not write"). The issue-flow sweep has never run there, so nothing reconciles them either. TRIAGE.md's issue contract closes on "exactly one of ready / blocked", and on that board that line is unsatisfiable.

It is a class, not one repository. heavy-duty/la-familia-infra was stood up this month (infra#44, re-homed to la-familia-infra#3) as the same kind of repository, and has no .github/ either. Of the nine governed repos I checked, all nine that carry labels-sweep.yml also carry release.yml; the only two without the sweep are the two state repos. There is no prior art for board-only adoption because the doctrine has no shape for it.

§ On-board a fleet-worked repo does not cover it. That section solves the bootstrap-order problem — operator hand-creates six labels, builder lands the automation, operator dispatches — and it is exactly right as far as it goes. It assumes throughout that the repo will also carry a release workflow, and says nothing about a consumer for which that assumption is false.

The local workaround now in force

On heavy-duty/infra, until this is answered:

1. Queue state is carried in issue-body prose, not in a label — a **Queue state:** line naming the label the issue would carry, in the body, with a citation to this discussion. It is a lie-shaped thing pretending to be a state machine, it is invisible to every sweep, and it is what exists instead of nothing.
2. The board's own onboarding is minted as an ordinary issue rather than raised as a discussion, because Discussions are disabled on that repository and cannot be enabled by anyone below admin. Triage's stated refusal route — "their idea is welcome, the door is over there" — currently points at a door that is not there.
3. The security label that heavy-duty/infra#20 has been asking for since 2026-07-14 ("the operator will add it; I lack label-admin on this repo") is still unwritten, 45 days on.

Each of those carries a link to this discussion in the body it ships in, per the half this route asks of me.

What retires the workaround

A documented way for a repository with no release workflow to carry the pin and be verified against it. Concretely, any one of:

• docs-sync reading the pin from the labels-sweep.yml caller when release.yml is absent — the sweep caller carries a uses: heavy-duty/ceremony/.github/workflows/labels-sweep.yml@<ref> line with identical shape, so this is a fallback rather than a second pin, and the same-tag rule keeps holding;
• or a named board-only adoption in CONSUMERS.md that says where the pin lives for such a repo and what verifies the mirror there;
• or an explicit ruling that a state repository should not vendor .ceremony/ at all, and that its agents read doctrine from ceremony directly — which would be a fine answer, and would retire the workaround just as completely, but it needs saying, because the board half is genuinely wanted there regardless.

When one of those lands, heavy-duty/infra drops its prose queue-state lines and its citations of this discussion in the same PR as the pin bump that carries the fix.

What I am not asking for

Not the release ceremony in a repository with nothing to release, and not a second pin. Both make the tree worse than the workaround does.

---

Raised per docs/CONSUMERS.md § Requesting a doctrine change and TRIAGE.md's upstream-routing rule (#492), by triage on heavy-duty/infra. Quotes taken at 0.7.7, the tag that board would adopt; it has no pin of its own today, which is the ask.

[dan-claude-bot]

🧭 needs-ruling — a repository that runs the board and never releases: does it carry the .ceremony/ doctrine mirror, and if it does, where does docs-sync read its pin?
Options: A — docs-sync falls back to the labels-sweep.yml caller's pin when release.yml is absent, and board-only repos mirror like every other consumer B — name a mirrorless board-only class in CONSUMERS.md: the two board callers carry the pin, no .ceremony/, agents read doctrine from ceremony at that pin C — every governed repo carries a release.yml, stub included, and nothing in ceremony changes
Recommend: B, because it needs no machinery in ceremony, keeps "one pin governs machinery and doctrine" literally true rather than adding a fallback to it, and a governed board with no .ceremony/ mirror is already live and working — heavy-duty/martin-reyes-barbershop.
Blocked: the mirror half of heavy-duty/la-familia-infra#4 alone — unclaimed and unassigned — whose vendored file set shrinks under B and stands under A or C. What continues: everything else there, all of heavy-duty/infra#48 (which already routes to B by deferring the mirror and naming this thread as what retires the deferral, so it waits on nothing), the operator's bootstrap press on both, and this board's whole queue. Nothing on heavy-duty/ceremony is gated by this, and this convergence mints nothing here. (This line was corrected in place 2026-08-29T00:2xZ; it originally named both issues as blocked. See the last note in the analysis.)
Default: none — hard block. The adoption shape for a class of repositories is org policy, which BUILDER.md's template makes a hard block by construction. And a discussion carries no needs-ruling label and no labeled event, so no rung of the ladder ever falls due here (#526): silence has no timer, and nothing expires against you.

Analysis — three claims in the filing above did not survive re-measurement, and the gap is narrower than its own title says

@danmt — I filed this thread wearing heavy-duty/infra's triage hat, under TRIAGE.md's upstream-routing rule. Converging it here is the step where measurement replaces assertion, and the filing is a proposal rather than a finding, so I re-derived every load-bearing claim in it. Measured 2026-08-29T00:2xZ against main = 6bf868d and the live fleet.

1. "Nowhere to put the pin" is too strong — the gap is the mirror, not the pin

I read every consumer's pin this pass off labels.yml alone, without opening a single release.yml: ten repositories call heavy-duty/ceremony/.github/workflows/labels.yml@<tag>, plus ceremony itself running its own action — the eleven governed boards. A board-only repository's two callers carry a pin exactly the way every other uses: line does, and the same-tag rule already governs them.

What has nowhere to look is docs-sync, and only docs-sync. At main:

actions/docs-sync/docs-sync.sh:73   WORKFLOW=".github/workflows/release.yml"
actions/docs-sync/docs-sync.sh:107  [ -f "$WORKFLOW" ] || die "docs-sync: no $WORKFLOW — the pin lives there …"

and consumers reach it from release-guards.yml, not from CI generally (crew's, at 0.7.6, line 53). So the decision in front of you is not where the pin lives. It is whether a repository with no release workflow gets a doctrine mirror — because the mirror check is the only thing that reads that file. My title says otherwise and it is wrong; this comment restates the ask.

2. There is partial prior art, and it is the argument for B

The filing said there is no prior art for board-only adoption. There is no documented class, but the shape is already live — governance and vendoring are separable in this fleet today:

board	labels.yml	labels-sweep.yml	.ceremony/	release.yml
martin-reyes-barbershop	@0.3.0	absent	absent	present
cast	@0.1.0	absent	6 files	present
the other nine	@0.7.4–@0.7.7	present	7 files	present

martin-reyes-barbershop is a governed board with no mirror at all and nothing red about it. That is the measured case for B: it does not invent a class, it names one that exists.

3. What survived intact, and is the whole of the case

All eleven governed boards carry release.yml — stronger than the filing's "nine of nine", and it holds for the two that carry no sweep caller. Both state repositories (heavy-duty/infra, heavy-duty/la-familia-infra) still have no .github/ at all and only the nine GitHub default labels, so no bootstrap has ever run on either. infra now carries nine open issues, not the seven the filing counted (#48 and #49 were minted after it). Discussions are disabled on infra and enabled on la-familia-infra, so the "the door is over there" refusal route exists on one of the two and not the other.

4. Workaround item 2 is partly answered by a rule that landed three hours before I filed

TRIAGE.md at ed2effd (#524, merged 2026-08-28T17:47:01Z) says a board's own missing taxonomy is operator-owned and "passes no mint door … then stop and mint nothing." infra#48 was minted at 20:30:48Z and asks for both the two caller files (builder work) and a bootstrap=yes press (operator work, no mint door) — which under #525's D5 is two owner classes in one issue. That repair is infra's board and mine to make there; it is recorded here only because this thread's workaround paragraph describes the mint and would otherwise stand uncorrected. It does not move the ask: the caller files are buildable under every option and only the .ceremony/ half waits. Item 3 — the security label infra#20 has asked for since 2026-07-14 — is operator-owned under the same rule and is 46 days unwritten.

One pointer gap of my own: infra#48 cites this thread three times, la-familia-infra#4 cites it zero times while asking for .ceremony/ explicitly. I am adding that citation there, so both adoption issues resolve to this venue.

What each option costs

• A — the fallback. A real build in ceremony: actions/docs-sync/docs-sync.sh, test/docs-sync.test.sh, docs/CONSUMERS.md, then a tag, then a pin bump on the adopting repo before it can use any of it. It also wants a release-guards.yml in a repository whose other guards — changelog-armed, changelog-monotonic, drill-recorded — have nothing to guard. Its strength is real: the mirror invariant stays universal, and every agent reads doctrine from a tree CI proves is byte-identical to the pin.
• B — the named class. One docs/CONSUMERS.md section and one clause in AGENTS.md, whose router currently says the vendored set sits "in a governed repo under .ceremony/" — under B that is true of most governed repos rather than all. No machinery, no tag, no pin bump: infra could adopt against 0.7.7 today. Its honest cost is that nothing verifies which ref that repository's agents read doctrine at — there is no mirror to drift and equally no check that anyone is current.
• C — the stub. A release workflow that never legitimately runs, in a repository with no VERSION, no CHANGELOG.md, no changelog.d/ and nothing to tag, created so a mirror checker can find a string in it. I am not recommending it, but it is the third cell of the axis and it is the only option that needs no doctrine change at all.

Added in place 2026-08-29T00:2xZ, after posting: C is not hypothetical — it is what my own mint currently instructs. la-familia-infra#4, which I minted at 21:05:56Z — 37 minutes after filing this thread — tells a builder to vendor .ceremony/ and release.yml and to leave docs-sync --check green, on a state repository with nothing to release. So one board is already being pointed at C while the question is open, which is a cost the option rows above did not price. I have annotated that issue: its taxonomy half is buildable today under every option, its mirror half waits here, and this thread is named as what retires the note.

Second in-place correction, same tick, and it is the more useful of the two: my two adoption issues have taken opposite routes on this open question, and I asserted above that infra#48 needed the same annotation. It does not — I checked it after writing that sentence. infra#48's D1 already says it does not vendor .ceremony/ and does not add AGENTS.md, "because there is nowhere here to put the pin that would govern them", and it carries the workaround citation and the retirement pointer to this thread in three places. That is option B, implemented by deferral, on the board this thread was raised from — while la-familia-infra#4 instructs C. So the fleet is currently building both answers to an unanswered question, which is the sharpest argument for ruling it rather than leaving it to sit. I have corrected the Blocked: line above accordingly: infra#48 waits on nothing.

What this convergence does not do

It mints nothing on this board, deliberately: every option changes what would be minted, so minting now would pre-empt you, and under the standing reading of your 13:23:09Z gate on #528 a mint here would also push the 0.7.8 cut further out for a question that gates nothing on this board.

The workaround stands meanwhile — prose **Queue state:** lines on infra's issues, invisible to every sweep — and this thread stays open as its retirement owner, which is why this is an escalation in place rather than a close and a re-ask: infra#48 names this discussion as what retires it, and closing it would restale that pointer in the same instant.

[dan-claude-bot]

📎 Retraction — item 4's claim about heavy-duty/infra#48 does not survive measurement, and the repair it promised is not being made

@danmt — no new question, and this changes nothing about the ask, the three options, or the recommendation above. Everything in the A/B/C ruling stands exactly as filed. This corrects one side note in my own analysis, because it asserted a defect on a board you are being asked to rule about and promised a repair I have now decided against.

What item 4 says

infra#48 … asks for both the two caller files (builder work) and a bootstrap=yes press (operator work) — which under #525's D5 is two owner classes in one issue. That repair is infra's board and mine to make there.

Why it is withdrawn

I wrote that against main. Both grounds landed after 0.7.7 was cut and neither has shipped:

ground	commit	in 0.7.7?
#488 — "builder-owned or operator-owned, and never both … split where it stands"	on main	⛔ no
#524 — "passes no mint door … then stop and mint nothing"	ed2effd · 2026-08-28T14:14:25Z	⛔ no

0.7.7 is fc6325e, cut 2026-08-27T23:40:30Z — about fourteen and a half hours before #524 merged. merge-base --is-ancestor puts neither in the tag; main's VERSION is 0.7.8-dev. At 0.7.7 the governing rule is #491's and it says the opposite: mixed ownership is legal, classified per criterion, operator marked only when every criterion is operator-owned. main's own #488 paragraph concedes the collision in the word "replaces".

infra#48 is a legitimate mixed-ownership issue at the ref that board runs at. Its criteria stay where they are, and it does not split. It now carries the same > ⚠️ note its five siblings carry, and the pass is recorded at infra#48.

The part worth your attention, because it is a class and not a slip

The 2026-08-29 passes corrected this same defect on five heavy-duty/infra surfaces — #20, #43, #47, #50, #51 — censused at #548. #48 was missed by every one of them, because its false claim was not in its body — it was here. A workaround or a finding routed upstream under TRIAGE.md's routing rule leaves a claim standing in a venue the originating board's own hygiene sweeps never read. Five of six were caught by body sweeps; the sixth needed somebody to read the citation back. If that is worth a rule, it is #548's or a successor's, not this thread's — I am not minting anything for it here, and this thread's ask is unchanged.

Unchanged by this note

The A/B/C question, the recommendation of B, the Blocked: line (infra#48 waits on nothing; the mirror half of la-familia-infra#4 alone stops), and Default: none — hard block all stand as filed. No rung of any ladder has fallen here — a discussion carries no needs-ruling label and no labeled event (#526) — so this is a correction of record on my side, not a nudge, and nothing expires against you. This thread remains the retirement owner of heavy-duty/infra's prose **Queue state:** workaround; whether 0.7.7 or main governs an unpinned board is #548's question, not this one's.

[dan-claude-bot]

⚖️ Board-level ruling recorded — @danmt takes C on heavy-duty/la-familia-infra. This does not answer the thread.

@danmt ruled 2026-08-29, asked directly and scoped to that board: heavy-duty/la-familia-infra carries a release.yml, a .ceremony/ mirror, and the changelog/drill scaffolding underneath them, like every other governed board. Landed in la-familia-infra#7, with the reasoning written into that repository's CONTRIBUTING.md rather than left implicit: a release there stamps a version on the state, so a cast run can name what it applied and a drill record can name what it rehearsed. Nothing is published; the version is still worth having.

The Blocked: line clears. The mirror half of la-familia-infra#4 — this thread's only blocked item — is unblocked and built. Nothing waits on this thread any more.

What is unchanged, and why this thread stays open.

The ask here is the adoption shape for a class of repositories, which is org policy and a hard block by construction under BUILDER.md's ruling template. One board's operator answering for one board is not that. heavy-duty/infra is still on B by deferral (infra#48 D1), and its prose **Queue state:** workaround is still in force with this thread as its retirement owner.

⚠️ So the divergence this thread's own analysis named — "the fleet is currently building both answers to an unanswered question, which is the sharpest argument for ruling it" — is now in the trees rather than only in the issue bodies. Both state repositories are built, and they disagree:

	heavy-duty/infra	heavy-duty/la-familia-infra
.ceremony/	absent (B, deferred)	6 files + marker, at 0.7.7
release.yml	absent	present, version-source: file
VERSION / CHANGELOG.md / changelog.d/ / drills/	absent	present, 0.1.0-dev
docs-sync in CI	not wired	wired, green against the published tag
retirement pointer	this thread	this thread

That is a sharper input to the ruling than the pre-build state was, and it is the reason to record it here rather than only on that board.

The recommendation above is unchanged and is still B, and I am not withdrawing it on the strength of one board's ruling. Two things the build measured are worth having on the record before you rule the class, both of which cut against C as a general answer:

1. C is not free even where it works. docs-sync needs release.yml only for a string, and the file it justifies subscribes push: branches: [main] and tags: ["**"] on a repository with nothing to release. It is inert today because VERSION carries -dev, but it is a live door on every tag push, and the thing standing between it and a spurious release is the version stamp rather than the absence of a workflow.
2. The scaffolding is the larger half. release.yml alone is not C; changelog-armed needs VERSION, CHANGELOG.md and a changelog.d/ marker, and drill-recorded needs drills/. Ruling C for the class means every board-only repository carries a changelog and a drill doctrine for releases it will never cut. That cost belongs in the option table above, which priced C as "a release workflow … created so a mirror checker can find a string in it" — measured, it is six files and two doctrines, not one file.

If you rule B for the class, la-familia-infra reverses in one PR — delete the mirror, the release caller and the scaffolding, drop the docs-sync guard step. If you rule C, infra#48 adopts the same shape and CONTRIBUTING.md's local-exception framing there becomes doctrine. Either way this thread is what retires the divergence, so it stays open.

[dan-claude-bot]

📐 Axis correction from the operator, and it narrows this thread rather than answering it

@danmt, 2026-08-29, on why la-familia-infra takes C:

i want to track the version of the infra without publishing any installer and what not. so this repo has versions, changelog, etc… what it doesn't have is a "deploy". but still needs versioning as it lets me know in which version we are sitting and the entire progress.

This thread has been asking the wrong question of the class, and I wrote it that way. Every framing above — my title, the three options, infra#48's D1 — rests on "a repository that runs the board and never releases." That premise is false for at least one of the two repositories it was raised about, and the operator's sentence is what shows it.

The word "release" bundles two things this fleet keeps confusing:

	what it is	who wants it
the version	cut a tag, stamp VERSION, assemble a CHANGELOG.md section from fragments	"lets me know in which version we are sitting and the entire progress" — wanted by a state repository as much as by a CLI
the publication	the artifact hook: an installer, an image, a package, anything uploaded	not wanted here, and the hook is simply never wired

So the axis that actually separates the class is publishes an artifact / does not — not releases / does not release. la-familia-infra is on the releasing side of the first axis and the empty side of the second, and the ceremony already supports exactly that shape with no change: the artifact hook is optional, and a release with nothing behind it cuts a tag and stamps a version, which is the whole of what was wanted.

What this changes for the three options

• C stops being a fiction where the version is genuinely wanted. The option table above priced it as "a release workflow that never legitimately runs … created so a mirror checker can find a string in it." On la-familia-infra that description is now simply wrong: the workflow runs on a real tag, for a real version, that a human reads. The pin lands in release.yml as a side effect of a release that was wanted anyway — which is the cheapest possible answer, and it needs nothing from ceremony.
• B narrows to a smaller class than I claimed. It is right for a repository that wants neither half — no version, no publication. martin-reyes-barbershop is still the live example of a governed board with no mirror, and this thread should say so about that class rather than about "board-only" repositories generally.
• A is unaffected, and is still the only option that keeps the mirror invariant universal.

The one thing that stays broken, and it is smaller than the title says

⚠️ docs-sync reads the pin from a file named for the publication, not for the version. That is the actual defect this thread found, and it survives the correction: a repository that wants a version but has no release.yml — because it stamps versions some other way, or because its release caller is named something else — has nowhere to put a pin, and docs-sync.sh:73 will not look anywhere else.

Measured against 0.7.7 this pass: no doctrine anywhere requires a governed repo to carry release.yml. Zero occurrences across AGENTS.md, RELEASES.md, LABELS.md, TRIAGE.md, BUILDER.md, REVIEWER.md and FLEET.md. The requirement is entirely an artifact of that one hardcoded constant, introduced under #19 to make a second pin unrepresentable — a drift argument, and a good one, which silently also assumed every consumer publishes something. Option C has therefore been the status quo by accident and was never ratified, which is why one agent wrote B on one board and C on another on the same day.

Recorded, not ruled

la-familia-infra's CONTRIBUTING.md now carries the operator's framing under "This repository releases. What it does not have is a deploy." (la-familia-infra#7).

Default: none — hard block still stands for the class, and my recommendation moves: B for repositories that want neither half, and no doctrine change for repositories that want the version — they already fit. The question left for you is narrower than the one I filed: should docs-sync keep reading its pin from a file named release.yml, or from the version flow generally?

[dan-claude-bot]

🔧 Retraction — @danmt did not rule this thread. I asked a bad question and then labelled the answer as a ruling on it.

Two comments up I wrote "@danmt takes C on heavy-duty/la-familia-infra", and put the same claim in a PR title, a commit message and a CONTRIBUTING.md heading. Withdrawn. Nothing here has been ruled, Default: none — hard block still stands, and the three options are exactly as unanswered as when I filed them.

What actually happened

I asked @danmt to pick A, B or C for one board. They answered by describing what they wanted:

i want to track the version of the infra without publishing any installer and what not… what it doesn't have is a "deploy". but still needs versioning as it lets me know in which version we are sitting and the entire progress.

That is not a choice among A, B and C. It is a report that the board was never an instance of the question, and I should have heard it as one instead of filing it under the nearest letter.

Why it is not C

C is "every governed repo carries a release.yml, stub included, and nothing in ceremony changes" — a file that never legitimately runs, created so a mirror checker can find a string in it. That was the option's whole character, and it is the reason I did not recommend it.

heavy-duty/la-familia-infra has no stub. It has a release caller that runs on a real tag, for a real version, that a human reads to know which state the fleet is sitting on. The pin lands in release.yml as a side effect of a release that was wanted anyway — which is not C, or any other row in the table above. The board simply falls outside all three.

The class, restated

All three options — and my title, and infra#48's D1 — rest on "a repository that runs the board and never releases." Measured against what the operator actually wants, that premise was false for the board I raised it about.

"Release" bundles two things: the version (a tag, VERSION, an assembled CHANGELOG.md section — the progression a human reads) and the publication (the artifact hook: an installer, an image, a package). A state repository wants the first as much as a CLI does. It has no use for the second, and the ceremony already supports exactly that: the hook is optional, and a release with nothing behind it cuts a tag and stamps a version.

So the axis that produces this thread's class is wants a version / does not — and only the second side has nowhere to put a pin. That is a strictly smaller class than "board-only", and it may have one live member:

board	versions anything?	mirror	the question
la-familia-infra	yes — 0.1.0-dev, armed changelog	present, 0.7.7	⛔ not in the class
martin-reyes-barbershop	no	absent	✅ the live example
infra	unmeasured — and this is now the load-bearing unknown	absent	⏸️ depends

⚠️ The two state repositories are not in disagreement, and my previous comment's "they disagree in the tree" table was the same mistake in another form. If heavy-duty/infra wants no version, infra#48's D1 deferral is simply right for it and contradicts nothing. That is a question for @danmt about infra, not a defect in either board — and it is now the thing that decides whether this thread has one member or two.

What is left, which is narrower and mechanical

The defect this thread found survives all of the above, and it is the only part I would still ask you to rule:

docs-sync reads the pin from a file named for the publication rather than for the version. docs-sync.sh:73 hardcodes .github/workflows/release.yml, and no doctrine anywhere requires that file — zero occurrences across AGENTS.md, RELEASES.md, LABELS.md, TRIAGE.md, BUILDER.md, REVIEWER.md and FLEET.md at 0.7.7. It is entirely an artifact of #19's drift argument, which is a good argument that silently also assumed every consumer releases something. So a repository that wants a mirror and no version has nowhere to put a pin — and that, not the adoption shape of a class, is the sentence my title should have carried.

Recommendation, revised: no doctrine change for repositories that want a version — they already fit. B for repositories that want neither half. And the open mechanical question is whether the pin should keep living in a file named release.yml.

Blocked: still nothing. la-familia-infra#4's mirror half is built and its PR is green; that clears regardless of how this is answered, and reversing it under B would be one PR.

Corrected in place

la-familia-infra#7 — title, body, commit message and CONTRIBUTING.md no longer claim a ruling. The section now says what is true: this repository releases and does not deploy, and #542 does not govern it.

[dan-claude-bot]

🏁 The class is empty. @danmt has removed both of its candidate members, and this thread is now answered by fact rather than by a ruling.

Two facts from @danmt, 2026-08-29:

1. heavy-duty/martin-reyes-barbershop will be deprecated and removed from the infra.
2. heavy-duty/infra will have versions too — no deploy, but versions.

Set against the corrected axis two comments up, that leaves nothing in the class:

board	wants a version	in this thread's class
la-familia-infra	yes — 0.1.0-dev, armed changelog, mirror landed	⛔ never was
infra	yes, per @danmt above	⛔ no longer
martin-reyes-barbershop	no — the one live example	⛔ being removed

Every governed board in the fleet either wants a version or is going away. So the question "does a repository that runs the board and never releases carry the .ceremony/ mirror" has no subject left to be asked about, and A, B and C are all moot — including the docs-sync build A would have required, and the CONSUMERS.md class B would have named.

⚖️ Recommend closing this thread as retired by fact, not answered. Nothing is being ruled and no doctrine changes; the fleet's shape moved out from under the question. Yours to close — I am not closing a thread that carries your Default: none — hard block.

The three loose ends, so closing this drops nothing

1. The workaround this thread owns is retired, and not by an answer. heavy-duty/infra's prose **Queue state:** lines, and infra#48's D1 deferral of the mirror, both cite this discussion as their retirement owner. Both are retired by fact 2: with versions, infra gets a real release.yml, the pin arrives with it, and the mirror is verifiable. I have amended infra#48 in place — D1's premise is marked false, D9's "no release workflow" falls with it, and the citation now points here for the reason rather than for a pending answer. That issue is unclaimed and unassigned, so nothing was interrupted; its task list still describes the board half only and awaits @danmt's word on whether the mirror lands in it or in a sibling.

2. The mechanical defect stands but is now theoretical, and needs no build. docs-sync.sh:73 still hardcodes .github/workflows/release.yml as the sole pin source, and no doctrine anywhere requires that file — zero occurrences across AGENTS.md, RELEASES.md, LABELS.md, TRIAGE.md, BUILDER.md, REVIEWER.md and FLEET.md at 0.7.7. With an empty class no repository is hurt by it, so option A's fallback should not be built: it would be machinery for a case the fleet does not have. Worth knowing the coupling exists; not worth a tag. If a future repository wants a mirror and no version, this thread is the record of why that shape has no path — and re-raising it then is cheaper than building for it now.

3. martin-reyes-barbershop's removal touches a live issue elsewhere, and it is not this thread's. infra#51 carries two operator tasks to verify that repository's client-site registry rows against the live control plane, and one acceptance criterion naming it alongside lafamilia-site. Under fact 1 those rows are a removal, not a verification. That is infra's board and triage's to repair there; flagged here only because this thread is where fact 1 was stated, and a fact stated upstream that never reaches the originating board is the exact miss this thread's own retraction recorded a month's worth of.

What this does not do

It mints nothing, here or anywhere. It rules nothing: Default: none — hard block is untouched and there is simply no longer a decision behind it. And it does not reverse la-familia-infra#7 — that board releases, wanted the mirror, and is green.

[dan-claude-bot]

📌 The one thing worth keeping from this thread is minted — #553

Not option A. The hardcode stays and no fallback is built — with the class empty, that would be machinery for a case the fleet does not have.

What #553 fixes is the part that actually cost something: docs-sync enforces a requirement that no document states. Measured — zero occurrences of release.yml across AGENTS.md, RELEASES.md, LABELS.md, TRIAGE.md, BUILDER.md, REVIEWER.md, FLEET.md and CONSUMERS.md § Prerequisites. The requirement exists only as docs-sync.sh:73.

That gap is what produced this thread, its wrong axis, option B on infra#48 and option C on la-familia-infra#4 on the same day, and a split build. Three edits close it: RELEASES.md states that a repository publishing no artifact still releases and that the artifact hook is the optional half (vendored, so it reaches all eleven boards' mirrors); CONSUMERS.md § Prerequisites states the coupling and its one-pin reason; and docs-sync's refusal message says it at the moment somebody hits it. No behavior change, no new input.

Minted after @danmt's 12:43:12Z freeze, so it does not move the 0.7.8 cut. Whether it rides that cut under the "really worth fixing" carve-out is @danmt's call and triage did not make it.

This thread can close — recommended two comments up, retired by fact. #553 carries forward the only durable finding in it.