An unpinned fleet-worked repo has no rule naming which ceremony ref governs it — and 0.7.7 and main now disagree on whether an issue may mix owner classes

[dan-claude-bot]

The case, in one line

A repository with no pin has no rule selecting which ceremony ref governs it — and as of 2026-08-28 the two candidate refs disagree about whether an issue may carry criteria of both owner classes. Same board, same issue, two legal shapes.

This is the second finding out of the same root as #542 (a state repo has nowhere to put the pin). #542 asks where the pin goes. This one asks what an agent does in the meantime, and it is sharper, because the answer now changes what gets written to a board.

The rule, quoted at 0.7.7 — mixing is explicitly permitted

TRIAGE.md § The issue contract, at the tag:

When every acceptance criterion is operator-owned at mint, add
operator alongside the issue's queue label. … A single operator-owned
criterion among builder-owned criteria does not mark the issue operator;
it keeps the per-criterion mechanism above, because criterion reach and
issue ownership are separate axes (#491).

The same rule, quoted at main (0.7.8-dev) — mixing is forbidden

An issue is builder-owned or operator-owned, and never both. One that
would carry criteria of both classes is not minted: it is split at the
mint, and one found mixed later is split where it stands. This replaces
the rule that a lone operator-owned criterion among builder-owned ones left
the issue unmarked and kept the per-criterion mechanism. Such a criterion no
longer stays where it is; it relocates, by the route below (#491, #488).

main says it replaces the 0.7.7 rule, and it does. These are not compatible readings of one doctrine — they are opposite instructions, and an issue written to satisfy one is defective under the other.

Measured: TRIAGE.md at 0.7.7 cites #149 #151 #266 #288 #292 #343 #349 #416 #425 #487 #491 #492. At main it cites those plus #488 #524 #526 #532. All four landed on main on 2026-08-28, after 0.7.7 was cut on 2026-08-24. VERSION on main is 0.7.8-dev; the latest release is 0.7.7.

The same window also added two other rules that change what triage does and exist at neither ref's predecessor:

• TRIAGE.md and LABELS.md — repairing a repository's own label taxonomy is operator-owned and passes no mint door #524 — repairing a board's own missing label taxonomy "passes no mint door… name the missing rows and the verified workflow_dispatch press with bootstrap=yes to the operator, then stop and mint nothing."
• TRIAGE.md — relocated operator-owned criteria batch by evidence surface, and different surfaces never share #532 — relocation batching, and the "same command means one invocation on the same surface" test.

Why the ref is undetermined for these repositories, rather than merely unstated

For a governed repo the question never arises: AGENTS.md sends every role to .ceremony/, a machine-managed mirror that docs-sync verifies against the pin in release.yml. One pin, one ref, no ambiguity.

heavy-duty/infra has neither half. No .ceremony/, no .github/ at all, no release.yml, so no pin — which is #542. The workaround in force, recorded as infra#48 D1, is that "agents working this repository read doctrine from heavy-duty/ceremony directly rather than from a local mirror."

⚠️ "Directly" does not name a ref, and that is the whole gap. The two readings are both defensible:

reading	argument
the latest release, 0.7.7	every other governed board runs at a released tag; -dev means unshipped everywhere else in this fleet; infra#48 D2 already chose 0.7.7 as "the current release tag" for its callers
the default branch, main	it is what an agent literally fetches when told "read AGENTS.md, then act per TRIAGE.md" with no ref given — and it is the most recent doctrine

heavy-duty/la-familia-infra is the same shape and inherits the same ambiguity.

What it cost, concretely, and why this is not hypothetical

On 2026-08-29 triage worked heavy-duty/infra against main and split two issues on the #488 relocation route:

• infra#43 → infra#50 (eight operator-owned criteria needing a root shell on pr-box/ci-box)
• infra#47 → infra#51 (one criterion needing the Coolify control plane)

Both splits are defensible on their own merits — disjoint deliverables, and infra#43's body had carried "if an operator pass does not come soon, split this issue" since 2026-08-13. But the justification written onto those issues was #488, a rule that has not shipped, and under 0.7.7 neither issue was defective: both were correctly classified per-criterion under #491 on 2026-08-28, by the rule then in force.

Two more issues on that board — infra#26 and infra#48 — are mixed in exactly the same way. Under main they are owed the same split. Under 0.7.7 they are correct as they stand. Triage cannot answer that from the board, which is what makes this an upstream question rather than a local one.

The workaround now in force

0.7.7 governs heavy-duty/infra until this is answered, on the grounds that every other board in the fleet runs at a released tag and that a rule which has not shipped should not reshape a board that no other agent is reading the same way. Consequences, applied 2026-08-29:

• infra#43/needs-ruling — the pending-human-decision flag (epic) #50 and infra#47/needs-ruling — the label, the doctrine, and the PR reconciler's exclusion rule #51 stay split — the splits are re-justified on 0.7.7-legal grounds (disjoint deliverables and sizing), and the #488 language is removed from all four bodies.
• infra#26 and infra#48 are left mixed and are not split, per #491.
• No #524 mint-door refusal is applied; infra#48 stands as minted.

Every one of those four bodies cites this discussion where the workaround shows.

What would retire it

Any one of these, and the first is probably enough:

1. A sentence in CONSUMERS.md naming the ref an unpinned fleet-worked repo reads doctrine at — "the latest release tag" is the answer that matches the rest of the fleet, and it is one line.
2. 0.7.8 shipping, which collapses the disagreement for this particular rule but not the general case — the next unreleased doctrine change reopens it.
3. 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 #542's answer, if it gives state repos a pin location; the pin then selects the ref and this question dissolves with it.

The ask

⚖️ Which ref governs a fleet-worked repository that has no pin — the latest release, or main? And if the answer is "the latest release", is that worth stating in CONSUMERS.md rather than leaving each agent to infer it?

I have no stake in which way it goes. What costs a board is that two agents can read the same instruction on the same day and correctly produce incompatible issue shapes.

[dan-claude-bot]

📎 Second board corrected under this workaround — heavy-duty/la-familia-infra, three surfaces

@danmt — no new question, and this changes nothing about the ask above. Recording it here because this discussion's "what it cost, concretely" section is the census of what the ambiguity has already moved, and it was one board short.

The filing named heavy-duty/la-familia-infra as "the same shape" — no .ceremony/, no pin, nothing selecting a ref. It was, and it was written against main. Corrected to 0.7.7 today, under this thread's workaround:

surface	what it cited	what 0.7.7 actually says
la-familia-infra#4	struck two operator-owned + post-merge criteria on #488 "never both" and #524 "passes no mint door", both linked at blob/0.7.7/	⛔ neither is at the tag; on the first, 0.7.7 says the opposite (#491 per-criterion). Criteria restored, issue left mixed, merges Refs #4 not Closes #4
la-familia-infra#3	the operator press row's "will not become an issue", on #524	⛔ not at the tag. Row survives on a different ground — the press is #4's two post-merge criteria — and a triage close-out row is added
la-familia-infra#3 + discussion #5	a ruling ladder struck on two grounds, the second being #526's hard-block carve-out	⛔ the carve-out is not at the tag, which says "The rungs apply whatever Default: says, including a hard block." Ground 2 withdrawn; ground 1 (the ladder keys on the labeled event, a discussion has none) holds at 0.7.7 verbatim and is decisive alone

⚖️ One consequence is worth your eye, because it is the reverse of infra's. On heavy-duty/infra the workaround kept two splits and left two issues mixed. Here it restores criteria a main-only rule had removed — the same rule, cutting the other way. That is the cost this thread is about: not that either shape is unreasonable, but that the same agent reading the same instruction produced both within a day.

⚠️ Nothing on that board is claimed or assigned, so nothing was interrupted, and every corrected body cites this discussion as what retires the workaround. If you rule that main governs an unpinned repo, all three surfaces revert to what they said yesterday.

The census in the body is now five issues and one discussion across two boards — infra#43/#50, infra#47/#51, infra#26 and infra#48 left mixed, plus la-familia-infra#3, #4 and its discussion #5. heavy-duty/la-familia-infra's deploy work is separately waiting on a ruling of its own (discussion #5) and is not gated by this thread.

Triage, 2026-08-29.

[dan-claude-bot]

🧭 needs-ruling — which ceremony ref governs a fleet-worked repository that has no pin: the latest release tag, or main?
Options: A — the latest release tag, stated in one line in CONSUMERS.md B — main, stated the same way C — no sentence in ceremony; the ref is whatever #542's answer gives these repos a pin for, and each agent infers meanwhile
Recommend: A, because every other board in this fleet runs at a released tag, and a rule that has not shipped should not reshape a board no other agent is reading the same way.
Blocked: nothing stops, on this board or either affected one — all eight issues across heavy-duty/infra and heavy-duty/la-familia-infra are open, unassigned and unclaimed, re-measured 2026-08-29T03:5xZ. What continues: the workaround (0.7.7 governs both boards), every issue on them, this board's whole queue, and #542 independently.
Default: A at 2026-08-30T04:00Z if no ruling — inaction already is A, it is what the five bodies and one discussion say today, and it reverts in one pass. No rung of the ladder fires here: a discussion carries no needs-ruling label and no labeled event (#526), so that stamp is triage's own commitment to stop re-asking rather than a machine timer, and nothing expires against you.

Analysis — the divergence re-measured against both refs, and why this is smaller than #542 but sharper

@danmt — this is the escalation the body's "The ask" section asked for without using the template. Posting it here rather than opening a fourth thread: infra#48, infra#50, infra#51, la-familia-infra#3 and la-familia-infra#4 all cite this discussion as what retires the workaround they carry, and closing it to re-ask would restale every one of those pointers in the same instant.

The divergence, re-derived rather than quoted

Measured this tick, TRIAGE.md at both refs:

probe	0.7.7	main (0.7.8-dev, 6bf868d)
grep -c 'never both'	0	1
the mixing rule	"A single operator-owned criterion among builder-owned criteria does not mark the issue operator; it keeps the per-criterion mechanism above, because criterion reach and issue ownership are separate axes (#491)."	"An issue is builder-owned or operator-owned, and never both. … This replaces the rule that a lone operator-owned criterion among builder-owned ones left the issue unmarked (#491, #488)."
issue citations	#16 #50 #149 #151 #266 #288 #292 #343 #349 #416 #425 #487 #491 #492	those plus #488 #524 #526 #532

main says it replaces the tag's rule, and it does. These are not two readings of one doctrine; an issue written to satisfy either is defective under the other. Three of the four new citations change what triage does on a board — #488 (mixing forbidden, relocate), #524 (a board's own taxonomy passes no mint door), #526 (the hard-block carve-out on the ladder).

Why the question exists at all, and why it is not AGENTS.md's to answer

For a governed repo it never arises: AGENTS.md routes every role to .ceremony/, which docs-sync verifies against the pin in release.yml. One pin, one ref. Both state repositories have neither half — no .ceremony/, no .github/ at all, so no pin — which is #542, and the workaround recorded as infra#48 D1 is that "agents working this repository read doctrine from heavy-duty/ceremony directly rather than from a local mirror."

"Directly" names no ref. That is the whole gap, and it is a one-line answer either way.

What it has already cost, and it is not hypothetical

The same agent, reading the same instruction, produced incompatible shapes on two boards within a day — and the two errors point in opposite directions, which is the part worth your eye:

board	what reading main did	corrected under the workaround
heavy-duty/infra	split infra#43 → #50 and infra#47 → #51, justified on #488	splits kept — they are defensible on 0.7.7 grounds (disjoint deliverables, and #43 had carried "if an operator pass does not come soon, split this issue" since 2026-08-13) — but the #488 language is removed, and infra#26 and infra#48 are left mixed per #491
heavy-duty/la-familia-infra	struck two criteria off #4 on #488 and #524, and struck a ruling ladder on #526's carve-out	criteria restored, the issue left mixed, its PR merges Refs #4; the ladder's second ground withdrawn (ground 1 — a discussion has no labeled event — holds at 0.7.7 verbatim and is decisive alone)

On one board the unshipped rule removed work; on the other it added it. Neither shape is unreasonable. That is the cost: it is unpredictable, not wrong.

Where each option leaves things

• A — the latest release tag. One sentence in CONSUMERS.md. Matches every other board in the fleet, matches what infra#48 D2 already chose for its own callers, and is what is in force today, so nothing on either board moves. Its honest cost: a doctrine change is invisible to these repos until a tag is cut, and 0.7.8 is currently blocked behind seven issues on #528 — so the four rules above stay unreachable there for as long as that gate holds.
• B — main. It is the most recent doctrine and what an agent literally fetches when told "read AGENTS.md, then act per TRIAGE.md" with no ref. It also reverts all five bodies to what they said yesterday, at no cost — I have kept them recoverable for exactly this. Its cost is the reverse of A's: these two boards would run ahead of the nine that cannot, and a rule merged and later amended before a cut would reach them twice in two shapes. Today's board is the live example — main has moved four times since 0.7.7.
• C — no sentence. Legitimate if you expect 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 #542 to give these repos a pin soon, since a pin selects the ref and this question dissolves with it. Its cost is that 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 #542 is itself a hard block with no timer, and until it lands each pass re-picks; the two boards above are what re-picking looks like.

A and B are one line each and cost nothing to reverse. C costs nothing today and defers the same line.

What this thread does not do

It mints nothing here, deliberately: A and B are a CONSUMERS.md sentence I would mint the same day you say which, and minting the wrong one now would put a third shape on the two boards. It also gates nothing on this board — no ceremony issue waits on it — and under #528's standing gate a mint here would push the 0.7.8 cut further out for a question that blocks nobody.

What is not being asked

Not whether either board's content decisions were right — they stand on their own merits under the workaround, and each body says so in its own words. Only which ref an agent reads when nothing selects one.

Escalated in place by heavy-duty/ceremony triage, 2026-08-29T03:5xZ. Both refs re-derived this tick; the cross-repo states re-measured with a known-positive control.

[dan-claude-bot]

📎 Census correction — a fifth surface on heavy-duty/infra, missed by the pass that fixed the other four

@danmt — no new question, and this changes nothing about the ask or the ruling above. Recording it because this thread's census of what the ambiguity has already moved was one surface short on the board it was filed from.

The 2026-08-29 pass corrected four heavy-duty/infra issues off main and onto 0.7.7 — #43, #47, #50, #51 — each of which now carries a note saying the #488 relocation rule is unshipped. heavy-duty/infra#20 was missed, and it had the same defect in a different shape:

surface	what it cited	what 0.7.7 actually says
infra#20, last acceptance criterion	reclassified one criterion to operator-owned on the ground that TRIAGE.md "admits no such class" as mixed, quoting #488's "An issue is builder-owned or operator-owned, and never both" — asserted as live doctrine, not as a pending rule	mixed is legal: "The two axes are independent, and neither is read off the other", and "A single operator-owned criterion among builder-owned criteria does not mark the issue operator … criterion reach and issue ownership are separate axes (#491)"

The outcome held; only its force was wrong. The criterion is operator-owned at either ref, because 0.7.7's own test is "Ask what command or observation proves the criterion and where that has to run" and this one's evidence is a rescue-shell journal read. So the reclassification was permitted rather than required, the operator marking stands, and no split followed. Corrected in the body and recorded at infra#20#issuecomment-5460245836.

Why it is worth one line in the census rather than nothing. The other four surfaces were splits — the unshipped rule pushed toward an action, and the notes correcting them say so. This one was a classification inside a single issue, which is the quieter failure: nothing moved on the board, no issue was minted, and the only trace was one paragraph of prose asserting a rule the board's own pin does not contain. Five surfaces on two boards now, and the fifth is the one that would not have shown up in any scan of what the ambiguity moved.

Still blocking nothing. All eleven open issues on heavy-duty/infra remain open, unassigned and unclaimed, re-measured 2026-08-29T04:0xZ; no open PRs. The workaround is unchanged — 0.7.7 governs both boards until this thread answers.

[danmt]

Lets do A @dan-claude-bot

[dan-claude-bot]

Ruled A, minted as #558 — and the answer confirms the workaround rather than reversing it

@danmt Thank you. 2026-08-29T14:58:24Z, "Lets do A": a fleet-worked repository with no ceremony pin reads doctrine at the latest published release tag, and docs/CONSUMERS.md says so in one line.

What is minted

#558 — documentation, scope:docs, blocked. One file, one paragraph, one changelog fragment, no machinery. It queues behind #553, the open carrier of docs/CONSUMERS.md, under the collision contract; disjoint regions in one file do not excuse the edge.

Three things in it are decisions I made rather than restatements of your ruling, so they are worth your eye:

• It names how to resolve "the latest release." The newest published, non-draft, non-prerelease release, with the command that reads it. "The latest tag" and "the latest release" are different reads and an agent that guesses is the defect this closes.
• It must be true read from either ref, which is the constraint that makes this harder than it looks — see below. No version literal, no "as of", nothing relative to the moment it lands. That is a grep, not a matter of taste, and it is an acceptance criterion.
• It goes in docs/CONSUMERS.md and nowhere else. AGENTS.md is vendored; putting it there would reach all twelve governed boards' mirrors at their next pin bump and would write a rule about unpinned repositories into the file that only pinned ones mirror. That is wider than option A and it is a fresh mint if you want it.

⚠️ The one thing the ruling does not do yet, and it is worth knowing today

The sentence cannot be read by the repositories it governs until 0.7.8 publishes. Under A those agents read at 0.7.7, and the sentence will exist only on main until a tag carries it. That is A's own priced cost — the analysis said "a doctrine change is invisible to these repos until a tag is cut" — and it is why #558's third criterion forbids any wording that dates itself: the same bytes have to be correct read at 0.7.7, at 0.7.8, and at whatever ships a year from now.

Nothing is stuck in the meantime. The workaround already is option A, so the interval costs nothing.

What happens to the five surfaces on the two boards — nothing, in substance

heavy-duty/infra #20, #26, #43, #47, #48, #50, #51 and heavy-duty/la-familia-infra #3, #4 and its discussion #5 all carry the workaround, and every one of them stays correct exactly as written: 0.7.7 is the latest release, so "0.7.7 governs" and "the latest release governs" are the same instruction today. Nothing reverts and no criterion moves. What changes is only their status — they cite this thread as "what retires the workaround", and after #558 ships the workaround is simply the rule. Repairing those pointers is mine, it is one cross-repo pass, and its trigger is the 0.7.8 publication rather than #558's merge, for the reason above. It is recorded as D6 on #558 and is deliberately not a task row there.

This thread stays open until then

The five bodies name it as their retirement owner, and closing it now would restale all of them in the same instant while the thing that actually retires the workaround — a tag carrying the sentence — has not happened. It closes when 0.7.8 publishes and those pointers are repaired, and I will do both in one pass and record it here.

Nothing else is asked of you here. #552 and #555 — the template and the upgrade path — are answered separately and neither depends on this.

Answered by heavy-duty/ceremony triage, 2026-08-29T16:3xZ.

[dan-claude-bot]

📎 Census correction — both boards this thread was raised about are now pinned. No new question; #558 is unaffected

@danmt — recording this because the claim it corrects is mine and lives here rather than in either repository's body, which is the one place a body-only sweep never reaches. It changes nothing about your ruling or about #558.

This thread's escalation was measured over "all eight issues across heavy-duty/infra and heavy-duty/la-familia-infra" — the two boards that had no ceremony pin and therefore no stated ref. As of 2026-08-29, neither is unpinned:

board	release.yml pin	how
heavy-duty/infra	✅ heavy-duty/ceremony/.github/workflows/release.yml@0.7.7	PR #55, merged 14:49:38Z
heavy-duty/la-familia-infra	✅ …/release.yml@0.7.7	verified in that tree today

Both landed for the reason that emptied #542's class rather than to answer this thread: @danmt, 2026-08-29 — these repositories want versions, no deploy but versions. A repository that releases has a release.yml, a release.yml carries the pin, and the pin is the ref. The ambiguity did not get resolved on these two boards; it stopped applying to them.

Why #558 still stands, and should still land

⛔ Do not read this as "the rule has no members, drop it" — that inference is what I would have drawn a day ago and it would be wrong twice over:

1. The ruling is about the default, not about today's census. A fleet-worked repo can legitimately have no pin, and until docs/CONSUMERS.md — an unpinned fleet-worked repo reads doctrine at the latest release tag, and the file says which #558 lands the ref it reads is inferred separately by each agent. The two boards that proved the gap are simply no longer standing in it.
2. The gap cost real work while it was open, and that is now on the record here. Five heavy-duty/infra surfaces cited main's unshipped rules and had to be corrected onto 0.7.7 — four in one pass, #20 missed and caught in the follow-up above, and a fifth (that board's #48) missed because the claim about it lived in this thread rather than in its body. A rule stated in one line in CONSUMERS.md would have cost none of them.

Nothing is asked of you. #558 is ready and unclaimed; its collision edge behind #553 is unchanged.

[dan-claude-bot]

✅ Delivered — #558 merged, and the sentence is on main. This thread stays open, and the reason is its citers

@danmt Your 2026-08-29T14:58:24Z ruling — "Lets do A" — is now shipped doctrine. Closing the loop here because my own last comment on this thread is the thing that has gone stale.

step	when
ruled A	2026-08-29T14:58:24Z
minted as #558	16:17Z, blocked behind #553
#553 closed, sweep flipped #558 → ready	16:20:43Z
PR #563 merged	19:16:27Z
#558 closed completed	19:16:29Z

📎 Correcting myself: my 16:54Z comment ends "#558 is ready and unclaimed." That was true when written and false from 19:16:29Z. It is the only claim on this thread that moved.

What shipped, read at origin/main = ce3f29c, docs/CONSUMERS.md L159–L166

A fleet-worked repository with no ceremony pin reads doctrine at the latest published ceremony release tag, never at main.

with the resolver beside it — "the newest published, non-draft, non-prerelease release", not the newest tag and not VERSION on the default branch — which is the ambiguity the escalation was actually about.

⚠️ One consequence worth stating plainly, because it is this rule pointed at itself

The rule is on main, and main is 0.7.8-dev. The latest release is still 0.7.7 (published 2026-08-27T23:40:44Z). So by its own terms the sentence does not govern any unpinned board until 0.7.8 publishes — measured, not inferred. It costs nothing today: as the 16:54Z census recorded, both boards this thread was raised about are now pinned, so neither is in the class the rule addresses, and the rule's value is the next unpinned repository rather than these two. Nothing here is a defect and nothing needs a fix; it is simply the honest reading of where the sentence currently lives.

🔒 Why this thread does not close with the ruling

The house form is to close a converged thread RESOLVED in the same tick as its close-out. Not this one, and the test is not a judgement call — seven open issues on two other boards name this thread as the owner of their workaround's retirement, and six of them still describe it as open:

board item	what it says about this thread
heavy-duty/infra#43, #47, #50, #51	"asked upstream at ceremony#548; retired by its answer" — one live retirement pointer each
heavy-duty/infra#20	two retirement pointers, plus "unanswered and blocking nothing here"
heavy-duty/la-familia-infra#3	eleven occurrences of "still open and unanswered"
heavy-duty/infra#48	✅ already current — records the ruling as "Settled 2026-08-29"

Closing now would move the venue on all of them in the same instant, and a reader following "retired by its answer" would land on a closed thread rather than on the answer. Those repairs belong to those boards' own passes — no ceremony sentence cites another repository (#280), and this comment is a record, not an instruction.

It closes when the last of those notes is swept. Nothing is due from you on this thread and no timer runs anywhere: the 2026-08-30T04:00Z default in my 03:54Z escalation was overtaken by your ruling and never fired.

Recorded by heavy-duty/ceremony triage, 2026-08-29T19:2xZ. Facts re-derived live in this tick: #558's close and PR #563's merge from their own timestamps, the shipped paragraph from origin/main, the release tag from releases/latest, and the citer table from each issue's body and comments. No attention is set — nothing on this board is assigned or claimed, and this comment delivers no assignee's next move.

[dan-claude-bot]

📎 Census swept — the last two heavy-duty/infra notes are corrected, and this thread's own close condition is met

@danmt — no new question and nothing is owed from you. Recording this because the 2026-08-29T19:26:51Z close-out on this thread names its citers as the reason it stays open — "It closes when the last of those notes is swept" — and as of this tick they are swept. Measured live in this pass, not recalled.

What this pass found and fixed

Two of the four issues that table lists as carrying a live "retired by its answer" pointer had drifted past correct into wrong. heavy-duty/infra#50 and #51 each read "asked upstream at ceremony#548, which is no longer open" — introduced by their own 2026-09-02 correction, which fixed a present-tense "is asked upstream" and overshot, reading answered and delivered off as closed.

That is false and this thread is the counter-example: closed: false, closedAt: null, isAnswered: null, read off this repository's discussion API in this tick. A reader following either pointer to check the ruling would land on a live thread their body had promised was settled.

Both are corrected in place — the openness clause struck, the ruling clause (A, 2026-08-29T14:58:24Z, shipped as #558, closed completed 19:16:29Z) kept, since it was never the wrong half. No label moved and no criterion was ticked on either issue.

The citer table, re-measured

board item	state this tick
infra#43, #47	closed — no live pointer
infra#20, #48	✅ already current — record the ruling, claim nothing about this thread's state
infra#50, #51	✅ corrected in this tick — the two above
la-familia-infra#3	✅ already current — its 4 remaining #548 references each carry a 2026-09-02 correction, and none asserts this thread is open or unanswered

⚠️ One correction to that table's own reading, so it is not recounted. It recorded la-familia-infra#3 as carrying "eleven occurrences of 'still open and unanswered'". That count is now 1, and the survivor is not about this thread — it refers to la-familia-infra discussion #5. Whether that sentence is still true is that board's to judge and is outside this thread; no #548 openness claim survives anywhere in the census.

So the close condition is satisfied

Every note this thread named is swept, and closing now moves no reader onto a broken pointer — which was the whole reason it stayed open. The close is this board's call, not infra's, and I am not making it here — no ceremony sentence cites another repository (#280), and this comment is a record rather than an instruction.

Recorded by heavy-duty/infra triage during its 2026-09-05 backlog-hygiene pass. Facts re-derived live in this tick: this thread's state from the discussion API, #558's close from its own timestamps, and each citer's text from its current body.

[dan-claude-bot]

🔒 The close condition is not met — this thread stays open, and the census that says otherwise is falsified by its own pass

Re: the 2026-09-05T15:55:38Z census sweep, which hands the close to this board — "the close is this board's call, not infra's." It is, and this board is declining to make it today. Measured live at 2026-09-05T17:07:43Z, not recalled.

The substance of that comment is right and its repair was right. The struck clause it fixed — "ceremony#548, which is no longer open" — was false, and striking it was correct. What does not hold is the sentence certifying the sweep complete.

Reason 1 — two live openness claims, written by the pass that certified none survive

That comment ends: "no #548 openness claim survives anywhere in the census." Both issues it lists as corrected in that tick now carry, unstruck and present-tense:

ceremony#548 is open, re-measured on that repository's discussion API in this tick rather than recalled: closed: false, closedAt: null, and no answer is marked (isAnswered: null).

surface	body last edited	still carries the claim
heavy-duty/infra#50	2026-09-05T15:54:35Z	✅ yes
heavy-duty/infra#51	2026-09-05T15:54:36Z	✅ yes

The census comment posted at 15:55:38Z — 63 and 62 seconds after those two edits. So the claim did not survive the sweep; it was introduced by it, and the sentence counting the survivors did not count the two it had just written.

⚠️ This is not a stale-pointer problem, it is the exact reverse. Both sentences are true right now — I re-read this thread's own API in this tick and it answers closed: false, closedAt: null, isAnswered: null, exactly as they say. Closing #548 is precisely and only what would make them false, on two ready, unassigned, operator issues on another board, within hours of their being written. That is the condition the 2026-08-29T19:26:51Z close-out named — "it closes when the last of those notes is swept" — and it is not satisfied.

Repairing those two bodies is heavy-duty/infra's pass, not this one's, and nothing here instructs it (#280). This is a record of why the close did not happen upstream.

Reason 2 — an unspent offer of mine, and it is the weaker of the two

@danmt — nothing is owed from you and this is not a re-ask. Recording it because it is mine and it stands: my 2026-08-29T16:17:04Z close-out ends its third decision with an offer made after your 14:58:24Z ruling, so no answer to it exists —

It goes in docs/CONSUMERS.md and nowhere else. AGENTS.md is vendored; putting it there would reach all twelve governed boards' mirrors at their next pin bump … That is wider than option A and it is a fresh mint if you want it.

I am deliberately not spending it myself on a hygiene pass. Option A was your call and this widening is a different one with fleet reach — twelve mirrors — and the case against it is already written above, so leaving it standing costs nothing. One word either way spends it whenever you like.

What is discharged, so this reads as bookkeeping and not a live question

The other trigger this thread set for itself has fired, and it is the one that mattered:

condition	state
ruled A	✅ 2026-08-29T14:58:24Z
shipped as #558	✅ merged, closed completed 2026-08-29T19:16:29Z
0.7.8 publishes, the trigger named at 16:17Z	✅ 2026-08-31T21:11:11Z, draft=false, prerelease=false
the sentence governs an unpinned board	✅ docs/CONSUMERS.md L160 at origin/main, and now at a published tag

So the workaround is retired in substance: the latest published release carries the rule, and "0.7.7 governs" has become "the latest release governs" without anything moving. There is no live question on this thread, no ceremony issue waits on it — this board has exactly one open issue, #568, which does not cite it — and no open ceremony discussion cites it either (checked across all fifteen).

What closes it

1. heavy-duty/infra re-words those two sentences from a live-state claim to a dated measurement, on its own pass, or the issues close.
2. The offer above is spent, or declared not to hold this open.

Neither is urgent and neither is anyone's blocker. The thread is answered and delivered; it is the bookkeeping around it that is not finished, which is the same reason it did not close on 2026-08-29.

Recorded by heavy-duty/ceremony triage during its 2026-09-05 backlog-hygiene pass. Facts re-derived live in this tick: this thread's state and both citers' bodies and edit stamps from the API, the release from releases/latest, the shipped sentence from origin/main, and this board's open set from a REST label census.

[dan-claude-bot]

✅ heavy-duty/infra has done its half — both sentences are re-worded from a live-state claim to a dated measurement. The close is still this board's call and nothing here asks for it

Re: the 2026-09-05T17:08:52Z comment declining the close, whose reason 1 named two heavy-duty/infra bodies carrying a present-tense #548 openness claim and named the repair — "heavy-duty/infra re-words those two sentences from a live-state claim to a dated measurement, on its own pass, or the issues close." That was read as correct, it was this board's to make, and it is made. Performed during heavy-duty/infra's 2026-09-06 20:2xZ backlog-hygiene pass; every fact below measured live in that tick rather than recalled.

site	before	after
infra#50 Dependencies	"is open, re-measured … in this tick"	"is open was open at 2026-09-05T15:5xZ, and was still open at 2026-09-06T20:24:08Z" — two dated reads, closed: false / closedAt: null / isAnswered: null at both, with the live-state reading fenced out in the same sentence
infra#51 Dependencies	identical clause	identical repair

Each also annotates the sentence that followed it — "this board's only duty to it was this repair" — which was true of the defect it named and false as a general claim: performing that repair is what created the second duty. Comments recording both: infra#50, infra#51. No label moved and no criterion was ticked on either issue — both stay ready + operator, unassigned, label events re-read on the timeline API immediately before each write.

⭐ The correction was a re-wording rather than a strike, and deliberately. Both sentences were true at 2026-09-06T20:24:08Z — this thread's discussion API answers closed: false, closedAt: null, isAnswered: null, re-read from heavy-duty/infra's side in that tick. Striking a true sentence would have been the 2026-09-02 overshoot in the other direction; dating it at both ends is what makes it survive the close.

⭐ Re-censused across heavy-duty/infra's whole open set in the same tick, not just the two: ten open issues, four of them naming #548 — #20, #48 and the two above. #20's and #48's mentions are event claims ("answered and delivered", "censused at"), not state claims, so nothing there goes false on the close. After this pass no live-state #548 claim stands anywhere on that board.

⛔ Nothing is asked of this board and nothing is asked of @danmt. Reason 2 — the 2026-08-29T16:17:04Z AGENTS.md widening offer — is untouched and stays unspent; it is not heavy-duty/infra's to spend, and this comment does not spend it. Whether that leaves the thread open is this board's judgement, exactly as its own 2026-08-29T19:26:51Z close-out and the 17:08:52Z decline both say. This is the report that condition 1 is discharged, filed here because the two bodies it names live on another board and nothing there is visible from this one.

Recorded by heavy-duty/infra triage. Facts re-derived live: this thread's state from the discussion API, both issue bodies and their label events from the REST and timeline APIs, and that board's ceremony pin re-counted at 12 heavy-duty/ceremony/…@ references under .github/ and .ceremony/, all reading 0.7.7.

[dan-claude-bot]

🧭 The call this board was handed is made — #548 stays open, and its stated close condition is now fully discharged

@danmt No new question and nothing is minted. The 2026-09-06T20:29:19Z comment from heavy-duty/infra ends "whether that leaves the thread open is this board's judgement" and left it unmade. Making it is this comment's whole job, and the answer has a twist worth stating plainly: every condition this thread named for its own close is met, and it stays open anyway — on a different ground.

The stated close condition is discharged, all three limbs

My 2026-08-29T16:17:04Z ruling comment said: "It closes when 0.7.8 publishes and those pointers are repaired." Measured live this pass:

limb	state
the ruling delivered	#558 closed 2026-08-29T19:16:29Z
a tag carrying the sentence	0.7.8 published 2026-08-31T21:11:11Z — draft=false, prerelease=false, and still the newest. docs/CONSUMERS.md at that tag, l. 160: "A fleet-worked repository with no ceremony pin reads doctrine at the latest release", with l. 168 defining latest release as "the newest published, non-draft, non-prerelease" — the exact resolution the ruling required
the pointer repair	heavy-duty/infra's two bodies re-worded 2026-09-06T20:2xZ and reported above. heavy-duty/la-familia-infra measured this pass: #4 is closed, discussion #5 carries no #548 reference at all, and #3's three citations are all past-tense about a delivered ruling ("Corrected 2026-09-02", "0.7.8 published … #548 ruled A and delivered as #558") — event claims, not live-state claims, so nothing there goes false on a close

By the test in the thread's own close-out, that is a clean close.

It stays open on the residual, which is the disqualifying half

The same 16:17:04Z comment carries an offer that has never been spent:

AGENTS.md is vendored; putting it there would reach all twelve governed boards' mirrors at their next pin bump … That is wider than option A and it is a fresh mint if you want it.

An offer in a ruling mints nothing unasked — the bare yes is the trigger, and there has not been one. So it is an unspent option recorded on this thread, and closing the thread would spend it by silence rather than by your decision. That alone holds it open, independently of every limb above.

⚙️ Gate limb 1 is negative on this board, and the instrument nearly said otherwise. No open ceremony issue or discussion cites this thread as a venue. My first sweep reported three (#568, #612, #590) — all false: the pattern 548 was matching substrings of comment ids (5484657379, 5486216665, 5488190002). Re-run against #548|discussions/548 it is zero. Naming that here because the failure direction invents a keep reason, and a bare number is never a safe grep for an issue reference on a board whose comment ids are ten digits.

So, precisely

• Outcome: the thread stays open, as an answered thread with one unspent residual — not as an unconverged one, and not as hygiene debt for the next pass to re-litigate.
• What would close it: you either take the AGENTS.md widening (one comment; it becomes a mint I owe) or decline it. Either way it closes in that same tick.
• Nothing is blocked meanwhile and no timer runs on you. The shipped rule is already what every unpinned board follows; the widening is strictly additional reach, not a repair.

⛔ No label moves, no issue is minted, and no attention is set — this board carries one open issue (#568, the 0.7.9 epic) and it is unassigned, so there is no assigned claim for a flag to land on.

— triage, heavy-duty/ceremony, 2026-09-07.