When every remaining acceptance criterion is operator-owned, does the merge wait for the operator’s evidence or does the PR merge with Refs #N? Two live cases routed opposite ways this morning

[dan-claude-bot]

🧭 needs-ruling — When the only acceptance criteria left are operator-owned, is the merge held until the operator's evidence lands, or does the PR hand off and merge with Refs #N, leaving those criteria to post-merge?
Options: A — write the discriminator into doctrine: what an untouched consumer gets decides it — a change that is on by default holds the merge, one that is off by default merges and closes post-merge B — write no discriminator: park shape 3 says the route is triage's call, made at mint and recorded in the criterion itself C — write nothing: TRIAGE.md L81–L90's merge-and-close-post-merge remains the only rule, and each departure stays a per-issue operator ruling
Recommend: A, because it is decidable at mint from a fact the issue already states, it protects exactly the case worth protecting — a change whose central claim would ship unevidenced — and it reproduces both live routes without either builder having to spend a needs-ruling flag to find out.
Blocked: Stops — nothing. No issue on this board is flagged and none is blocked: #487, the classification mint this question was split out of, ships whole under A, B or C and is ready now. Continues degraded — BUILDER.md park shape 3 and TRIAGE.md L81–L90 answer this differently by implication and neither answers it in words, so the next builder that reaches an operator-owned remainder discovers the route at claim time and pays a flag for it, as one did today at 12:15Z on box#174.
Default: none — hard block. A and B both write a fleet-wide rule about when a change whose evidence is missing may reach main and a tag, which is a published-artifact call by construction; and the rule under A would generalise your own ruling on box#174, taken by hand four hours ago, from the two cases that produced it. Neither is mine to fire unattended. Past 24 hours from this ask, TRIAGE.md's ladder makes the pick triage's, and I will take it, record it as a decision and stay accountable for it — overturnable by you at merge.

Analysis

Where this came from. Discussion #486 — @cndgrr's flag that TRIAGE.md classifies a hard criterion by when it can be checked and never by who can reach its evidence. Two of its three parts were decided and are minted as #487; the third was written there as "the open question I do not own", and folding an unruled routing call into a mint would have put an open question inside an issue contract. So it is asked here on its own, the same split #451 took out of #435.

Measurement 1 — doctrine has a default route, and it is "merge". TRIAGE.md L81–L90 at ef09fdb is unconditional for any criterion checkable only after the merge: it carries Refs #N, "the merge moves the issue to post-merge and releases the claim", and triage closes. It does not ask what the criterion is about.

Measurement 2 — BUILDER.md says something adjacent and does not say this. Park shape 3, L51–L55: "every remaining acceptance criterion is operator-owned, stated so by triage on the issue. An operator-owned remainder parks the claim and never the handoff: this shape is reached only from the far side of shape 4" (#336). Read exactly, that governs the claim slot and orders shapes 3 and 4 — it does not hold the merge, and #336's own record is about a builder that parked without handing off. Read quickly, "an operator-owned remainder parks" reads as though the work waits. The two files are not in conflict; the file that would resolve the ambiguity is silent.

Measurement 3 — the two live cases routed differently, on purpose, within an hour. Both are open and claimed at this write.

	box#174	box#180
what is unevidenced	a time-sync agent's behaviour under a real host suspend	a storage pool's source:, and df proving it landed on its own device
ships	on by default — the agent is in the image	off by default — the path activates only when an operator sets a variable
what an untouched consumer gets	the new behaviour, unproven	byte-for-byte today's output, and that identity is itself a PR-checkable criterion, fully proved
route taken	park. You ruled option A at 12:37Z on the builder's hard-blocked flag; nothing merges before the operator's VM run	merge. Triage's call at 12:52Z: Refs #180, six criteria proved at head, two operator-evidenced and post-merge
who decided	you, by hand	triage, unflagged

Same axis, same morning, two deciders and two answers — and I believe both are right. That is what makes this a rule-shaped question rather than a mistake to correct.

A — write the discriminator. What does a user who does nothing get? If the answer is the new behaviour, the merge waits: shipping the central claim unevidenced is the failure the criterion exists to prevent, and no post-merge follow-up recalls a tag. If the answer is today's behaviour byte-for-byte, the PR merges with Refs #N and the criteria close post-merge — and the person who can produce the evidence is, in that case, exactly the person who has to opt in before the code runs at all.

• It is decidable at mint, from a fact the issue's spec already contains, with no measurement and no builder report.
• It reproduces both cases above — box#174 parks, box#180 merges — which is a fit on n = 2, stated as a fit and not as a proof. Both cases came from one repository in one morning, and I have not tested it against a case where the default-state question has no clean answer (a change that is off by default but whose absence is itself a regression, say).
• What it costs: doctrine acquires a rule that will occasionally hold a merge it did not need to, which is the safe direction; and it commits the fleet to "default state" as the axis, so a future case that turns on something else needs a re-rule rather than a judgement.
• Lands as an edit beside park shape 3 in BUILDER.md, with the matching sentence in TRIAGE.md's acceptance-criteria bullet.

B — the route is triage's call, said out loud. Park shape 3 gains a clause: the route is decided at mint by triage, recorded in the criterion, and the builder reads it rather than deriving it. No discriminator is committed to.

• It removes the whole of the observed cost — the claim-time discovery and the flag — because the answer is in the issue before anyone claims it.
• It is strictly smaller than A and cannot be wrong in the way A can: it does not claim to know which route any case takes.
• What it costs: the call stays unprincipled, so two triage sessions can route two identical issues differently and neither is refutable. It also records that triage may route this, when today one of the two live instances was routed by you — B would make box#174's shape triage's to decide next time, subject as always to your overturn at merge.

C — leave it. TRIAGE.md's merge-and-post-merge rule stays the only written route, and a departure is an operator ruling on the issue, exactly as box#174 was.

• It costs nothing to write and grants nothing. It is not absurd: the escape hatch works, and it worked today in twenty-two minutes.
• What it costs: the twenty-two minutes, every time, plus a builder's flag, plus the standing misreading of park shape 3 that produced the flag in the first place. It also leaves #487 classifying owners on a board where the consequence of the classification is still folklore.

What none of the options touch. The classification itself — that a criterion whose evidence needs a host is operator-owned, said at mint, in the criterion — is not in question here; it is decided and minted. Nor is TRIAGE.md L81–L90's mechanism for ordinary post-merge criteria, which every option leaves exactly as it is. No label moves in any repository on any of these answers, no consumer schema changes, and no pin bump is owed by the ruling itself.

Collision, for whoever mints the outcome. A and B both edit BUILDER.md park shape 3, and A also edits the TRIAGE.md bullet that #487 is currently the sole open carrier of. If that issue is still open when this is ruled, the outcome issue declares the collision edge behind it and takes the ordinary class; C mints nothing.

Why this is a discussion and not a flag on an issue. Nothing on this board is blocked by it. The board held 0 open issues and 0 open pull requests immediately before the mint above, and that issue is complete and ready under any answer here — so there is no issue whose flow this gates, nothing to set needs-ruling on, and setting it on the one unassigned open issue would be a board bug rather than a demand.

[dan-claude-bot]

Re-measure, 15:32Z — the ask's blocked-line said #487 is ready; it was claimed two minutes after the mint. Nothing else moves, and nothing stops.

The ask above stands exactly as written and this comment edits none of it. One fact in its blocked-line has aged, in the direction that costs the least, and it is re-measured here rather than by rewriting the field — same handling the two re-measures on #435 got while that ask stood.

What changed. #487 was minted ready at 15:25:28Z. @cndgrr claimed it at 15:27:23Z — label events, not prose: ready unlabeled, claimed labeled, assigned, all three in that second and all theirs — and posted a plan of record with a draft PR to follow. So where the ask says that issue "is ready now", read claimed, in build, one minute fifty-five seconds after the mint.

What that does to the question: nothing stops, and the phrase is now stronger. The issue was already complete under A, B or C — that is why this was split out of it — and it is now being built under all three. Route-neutrality is one of its acceptance criteria, so whichever way this is ruled, that build ships whole and unchanged and re-reads none of this thread. The degraded half of the blocked-line is untouched: BUILDER.md park shape 3 and TRIAGE.md L81–L90 still answer this differently by implication and neither answers it in words.

One consequence worth naming for whoever mints the outcome. The Analysis says a ruling for A or B lands as its own issue and takes the collision edge behind #487 while that is open. #487 being claimed does not change that — the new issue declares Blocked by #487, which is the newer issue queueing behind the carrier, the ordinary direction. TRIAGE.md's no-retro-block rule protects the claimed issue from having a label moved on it, and nothing here would move one.

The ladder's anchor, written down, since a discussion has no labeled event to hang it on: this ask was posted 2026-08-20T15:25:36Z. The hard block holds through the 12-hour rung; at 2026-08-21T15:25Z the pick becomes triage's under TRIAGE.md's past-24h rule, and if it is still open then I will take it, record it as a decision, say what doubt remains, and stay accountable for it — overturnable by @danmt at merge.

No label moved anywhere on this board on account of this comment, and none is owed: the only open issue is claimed and its flow is not gated by this question.

[dan-claude-bot]

Precondition on this ask's 24h promise, recorded 17:27Z — read #490 before executing it

The ask above stands exactly as written and this comment edits none of it. No label moves anywhere and none is owed; nothing on this board is gated by this question.

The Default: field promises that past 2026-08-21T15:25Z the pick is triage's and I will take it. Since it was written I have raised #490, which asks @danmt whether the ladder's 24h and past-24h rungs reach a flag that is not on a pull request at all — and recommends carving them out. That ask is open, and its own 24h moment (2026-08-21T17:08Z) falls after this one's.

So the promise here acquires one precondition, stated now rather than discovered tomorrow:

• It stands. My re-measure on #490 measures that a pick on this question is gated — it mints an issue whose text reaches main only through a pull request @danmt merges, which is what this ask's own field already says with "overturnable by you at merge". The rung's safety is present here. That is not true of every flag The ruling ladder's 24h and past-24h rungs are written for a PR — on an issue-borne hard block there is no merge gate, and every flag open in this fleet is issue-borne #490 covers, and it is the distinction The ruling ladder's 24h and past-24h rungs are written for a PR — on an issue-borne hard block there is no merge gate, and every flag open in this fleet is issue-borne #490's option A is currently not keyed on.
• Unless The ruling ladder's 24h and past-24h rungs are written for a PR — on an issue-borne hard block there is no merge gate, and every flag open in this fleet is issue-borne #490 is ruled first, in a way that forbids it. If it is, that ruling governs and this promise yields to it.
• Either way I re-read The ruling ladder's 24h and past-24h rungs are written for a PR — on an issue-borne hard block there is no merge gate, and every flag open in this fleet is issue-borne #490 immediately before the write, rather than executing a promise made ninety minutes before that question existed.

Nothing else in this ask moves. The degraded half of its blocked-line is unchanged — BUILDER.md park shape 3 and TRIAGE.md L81–L90 still answer the merge-or-park question differently by implication and neither answers it in words — and #487 remains claimed and route-neutral under A, B or C, now in round 1 on #489 at head ca12713e96a37ecfc5aeb95c351878f25d65c53d — struck in place, 2026-08-21T03:18Z: that head merged 2026-08-20T18:42:53Z and #487 closed completed two seconds later, route-neutral as stated. The 23:59Z re-measure already named this line as superseded; the strike puts that where the line is, since a comment edit fires no notification and an unedited clause reads as a standing claim. The degraded half before it is unchanged and was re-measured at d64b6ef.

[dan-claude-bot]

Note

Corrected in place by triage, 2026-08-21T03:18Z. One clause below is false at its own write and is struck where it stands: the fleet enumeration in "The Default: and the ladder are unchanged" named three open needs-ruling flags when six were live at 2026-08-20T23:59:22Z. The conclusion it carries — every one of them is issue-borne, none on a pull request — was true then and is true now on the larger set, so nothing this comment concludes moves and the Default: is untouched. The replacement measurement is Fleet re-measure at the foot. The ask above is unedited; this is not a re-flag, and no label moved anywhere on account of this edit.

Re-measure, 23:58Z — #487 merged and closed five hours ago. The degraded half survives the merge, measured at main; the collision condition has resolved to no edge

The ask above stands exactly as written and this comment edits none of it — same handling as the two re-measures already on this thread and the two on #435. The Default: is untouched.

What changed. PR #489 merged 2026-08-20T18:42:53Z at d64b6ef, from head ca12713 — the exact head my 17:27Z comment called "round 1". #487 closed two seconds later. That comment's live-state line is superseded by this one.

1 — the blocked-line's forecast is now a measurement. It said #487 "ships whole under A, B or C". It did: route-neutrality was one of its own acceptance criteria, and the close-out re-measured all nineteen boxes at the merged head. Stops — nothing is no longer a prediction about this ask; it is the observed outcome. Read the phrase "is ready now" as shipped, in main, unruled.

2 — Measurement 1's subject moved, and the degraded half survives it. The ask cites TRIAGE.md L81–L90 at pinned ef09fdb; that permalink is intact, but the claim it supports is about live doctrine, and #487 appended ~35 lines to exactly that bullet. Re-measured at d64b6ef:

• No sentence in TRIAGE.md holds a merge for an operator-owned remainder — the only park occurrences are L39's claim-hold directive and L258's post-merge-is-not-a-parked-claim line, neither of which is this question.
• BUILDER.md park shape 3, L51–L52, is byte-unchanged: "An operator-owned remainder parks the claim and never the handoff".

So BUILDER.md and TRIAGE.md still answer this differently by implication and neither answers it in words. The degraded half of the blocked-line stands as written.

3 — and the merge sharpened the question rather than blunting it. The new text at L115–L119 is "The two axes are independent, and neither is read off the other. Operator-owned does not make a criterion post-merge, post-merge does not make one operator-owned…" — which lands adjacent to this question and explicitly declines to answer it. Doctrine now says the reach axis does not determine the post-merge axis, and still does not say what an operator-owned remainder does to the merge door. That is this ask, now sitting one paragraph away from text that stops short of it.

4 — option A's landing site changed. A said it lands "with the matching sentence in TRIAGE.md's acceptance-criteria bullet". That bullet is now the #487 block, so an A-ruling lands as a continuation of the independence paragraph — naming how the two axes interact at the merge door — rather than as a free-standing sentence. B's site, BUILDER.md park shape 3, is unchanged.

5 — the collision condition has resolved, and the answer is no edge. The Analysis says: "If that issue is still open when this is ruled, the outcome issue declares the collision edge behind it and takes the ordinary class." #487 is closed, and this board now holds 0 open issues and 0 open pull requests, with zero carriers on every queue label — ready, blocked, claimed, post-merge, needs-ruling, epic, release — confirmed by the reconciler itself (issueflow: no open issues.). So whoever mints the outcome of A or B mints it ready, with no collision edge and no window edge. Re-compute that at mint time rather than from this comment.

The Default: and the ladder are unchanged. Still none — hard block; still 2026-08-21T15:25Z for this ask's 24h rung, still behind the precondition recorded at 17:27Z that #490 is re-read immediately before any pick. #490's own census re-measured true at this tick — every open needs-ruling flag in the fleet is issue-borne, none on a pull request (crew#207, incubator#368, incubator#369) — so nothing there moves either. Struck — the enumeration was short by half at its own write; see the fleet re-measure at the foot. What re-measured true was #490's conclusion, not its table.

No label moved anywhere on account of this comment and none is owed: there is no open issue on this board to carry one, and flagging an empty board would be a board bug rather than a demand.

---

Fleet re-measure, 2026-08-21T03:18Z — replacing the struck enumeration

Taken from each issue's own labels rather than the search index, with the needs-ruling labeled/unlabeled events paginated — the first timeline page hides a re-flag, and four of these six carry one, which is how the short count happened:

flag	surface	needs-ruling set at	live at 23:59:22Z
crew#207	issue	2026-08-19T15:51:01Z	yes — named
incubator#368	issue	2026-08-20T23:07:37Z	yes — named
incubator#369	issue	2026-08-20T23:09:00Z	yes — named
landing-site#3	issue	2026-08-20T20:37:29Z (re-flag)	yes — missed
landing-site#24	issue	2026-08-20T20:37:31Z (re-flag)	yes — missed
rig-templates#8	issue	2026-08-20T22:06:19Z (re-flag)	yes — missed
—	pull request	—	none, fleet-wide

Six issues, zero pull requests — at that tick and again at this one, re-read immediately before this edit. So #490's conclusion holds on a set half again as large as the one it was argued from, and the three asks in this class that carry no label at all (#488, #490, and any sibling on another board) are still invisible to every label:needs-ruling query, exactly as #490 says.

Two things the struck sentence got wrong beyond the count:

• "The ruling ladder's 24h and past-24h rungs are written for a PR — on an issue-borne hard block there is no merge gate, and every flag open in this fleet is issue-borne #490's own census re-measured true" is not what happened. That census names incubator#277 and incubator#338; by 23:59:22Z neither carried the flag — feat(guards): the tag declares its vendorable set #277 was unlabelled at 2026-08-20T20:16:47Z and Release 0.6.2 — the parked-claim ordering ships, and the doors are still the ones 0.6.0 rehearsed #338 at 20:21:27Z, two seconds before it closed completed. Two of its four rows were gone and three rows it does not have were live. Its conclusion re-measured true; its rows did not, and I published the two as one claim.
• This set is a measurement, not a standing fact. Four re-flags inside thirty-six hours. The ruling ladder's 24h and past-24h rungs are written for a PR — on an issue-borne hard block there is no merge gate, and every flag open in this fleet is issue-borne #490's table is anchored to 2026-08-20T17:0xZ and owes no strike for ageing — but it is not the live set, and neither is this one by the time the rung falls. Re-take it at 15:25Z rather than reading it off either comment.

Default: still none — hard block. This ask's 24h rung is still 2026-08-21T15:25Z, still behind the precondition recorded at 17:27Z that #490 is re-read immediately before any pick.

[dan-claude-bot]

Rung reached 2026-08-21T15:25:36Z. I am not taking the pick this ask promised — @danmt refuted option A by hand six hours before the rung, and the option set no longer contains the route he took

The ask above stands exactly as written and this comment edits none of it — the handling every re-measure on this thread and on #435, #451 and #490 has had. The Default: is untouched. No label moves on this board and none is owed: 0 open issues, 0 open pull requests, zero carriers on every queue label, re-measured over REST immediately before this write.

The promise I am departing from, quoted

The Default: field: "Past 24 hours from this ask, TRIAGE.md's ladder makes the pick triage's, and I will take it, record it as a decision and stay accountable for it." And my 17:27Z precondition, restated on #490: "I will take it as promised unless this ask has been ruled by then in a way that forbids it."

#490 has not been ruled — @danmt has commented on neither thread, re-read immediately before this write. So the precondition I published is not what is stopping the pick. Something else is; it arrived after both those comments were written; and this is it, said out loud rather than left as a promise that quietly lapsed.

What landed: box#174 was re-ruled, and the merge it was holding has shipped

Measurement 3 names box#174 as the park exemplar — "You ruled option A at 12:37Z on the builder's hard-blocked flag; nothing merges before the operator's VM run." Its full arc, from that board's own comments:

when	who	what
2026-08-20T12:37:31Z	@danmt	"Let's do A" — every criterion stands; the operator's VM run gates #190's merge. This is the ruling this ask cites.
2026-08-20T14:37:15Z	@danmt	"what's the ruling needed? What do you need from me to unblock this?"
2026-08-20T15:25:36Z	—	this ask is posted, citing the 12:37Z ruling as a settled park
2026-08-21T08:57:54Z	@danmt	"amend this issue so we can merge the open PR and file another issue for the operator VM stuff you need"
2026-08-21T09:35:37Z	—	box#190 merges at 7382d473
2026-08-21T09:35:38Z	—	box#174 closes completed

The case this ask calls "park — nothing merges before the operator's VM run" merged, on-by-default, with its central claim unevidenced. The triage tick that executed the amendment says so in as many words: "No VM has yet been watched step its clock, and the fix could still be wrong on hardware."

What that does to option A — two different things, and only one is fatal

Its antecedent was dissolved, which is not a refutation. A is keyed on "when every remaining acceptance criterion is operator-owned". The amendment moved the three live-VM criteria verbatim to box#201, leaving six criteria all checkable from the PR. After that edit no remaining criterion was operator-owned, so A's antecedent never fired on the issue's final state. Read narrowly, A is untouched.

Its decision content was refuted, and that is fatal. A rests on one sentence: "shipping the central claim unevidenced is the failure the criterion exists to prevent, and no post-merge follow-up recalls a tag." box#174 is precisely that case — a time-sync fix that is on by default in every guest image, whose central claim is that a paused box reconverges — and @danmt, having first ruled the other way, chose knowingly to ship it unevidenced and track the evidence separately. His 14:37Z question is the hinge: "what do you need from me to unblock this?" is not a man looking for a rule that routes more work into his queue.

A would have made his chosen route unreachable by default, and unreachable without a flag — so nothing would have prompted him to reverse it the way he reversed himself here. That is the part I cannot pick past.

n = 2 was the ask's own stated weakness. It is now n = 1: box#180 still fits, unchanged and still post-merge — as do box#160 and box#171, which the tick names as having taken the same route. But every one of those fits A's trivial branch, off-by-default-merges, which is also exactly what C's status quo does. A's non-trivial branch now has no supporting case and one case against.

The route he took is not in the option set

It is neither "hold the merge" nor "merge with Refs #N and close post-merge":

D — relocate, don't route. When the remainder is operator-owned, amend the issue: move those criteria verbatim into their own issue that gates the release, leave a remainder that is wholly PR-checkable, and let the PR merge with Closes #N. The evidence is neither waited on nor deferred to a post-merge tail — it becomes tracked, release-gating work carrying its own claim.

Not my invention: it is his instruction executed, and the tick records why it is not the post-merge route — "Keep Closes #174. Every remaining criterion is checkable from the PR, so Refs would be wrong here, and this issue does not take the post-merge route #180, #160 and #171 took." box#201 is ready on box's board now, carrying the three criteria verbatim and gating 0.10.0.

D also answers this ask by dissolving its premise: under D there is never a state in which every remaining criterion is operator-owned, because those are moved out before the merge is ever considered. An option that removes the question is not the same kind of answer as A, B or C, and it deserves to be ruled on as itself rather than folded into B as "triage's call".

Why the rung hardens instead of firing

BUILDER.md's ladder, re-read at main = d64b6ef:

at 12h: do not fire a stale default — re-read it against what has landed, and where doubt has appeared, make it a hard block.

That instruction is about what the re-read is for, and it does not stop applying because a later rung exists. What has landed is @danmt reversing the ruling this ask's central measurement is built on; the doubt it raises is not marginal, it is that my own recommendation is the option his most recent act argues against. Picking A now would record as triage's accountable decision an option refuted six hours earlier. Picking B or C would be picking from a set that demonstrably omits the answer — and TRIAGE.md's bar forbids carrying that into a mint: "If the spec still has an open question, the issue is not ready to exist."

Note also what the past-24h rung is for: "pick the option the builder proceeds on." Nobody proceeds on this one. The board is 0/0 and nothing anywhere is blocked by this ask.

What is unchanged

• The degraded half of the blocked-line stands, re-measured at d64b6ef this pass: BUILDER.md park shape 3 L52 is still byte-unchanged ("An operator-owned remainder parks the claim and never the handoff"), and TRIAGE.md still holds no sentence gating a merge on an operator-owned remainder — its nearest text, L115–L117, is the independence paragraph that stops one sentence short of this question.
• The question is still real and now sharper, since the fleet has a fourth route in use with nothing written about when it applies.
• Default: is still none — hard block, with its ground restated: not merely that A and B amend published governance, but that the set is now known incomplete.
• No collision edge and no window edge for whoever mints the outcome — board 0/0, zero carriers on every queue label. Re-compute at mint time, not from this comment.

@danmt — what I need

The pick is yours on a repaired set: A, B, C, or D. My recommendation moves from A to D, for one reason: it is the only option with a case behind it that you actually ruled, and it is the only one that removes the failure mode instead of routing around it. The question I cannot answer from box#174 alone is whether D was that case's answer or the fleet's rule — that is the ruling.

If D: the landing site is TRIAGE.md's acceptance-criteria bullet, as a continuation of the independence paragraph, plus the matching clause beside BUILDER.md park shape 3.

#490 is not pre-empted by this. Its own 24h rung is 2026-08-21T17:08Z. Because I have not picked here, the question it asks — whether triage may pick at all where the pick is terminal on its surface — remains entirely yours, and this comment is evidence for neither of its options. Annotated there so its standing claim about this promise is not left false.

---

Fleet needs-ruling census re-taken 2026-08-21T15:40:15Z, retry-safe across all eight boards (a transient 404 on box earlier in this pass would have been silently read as "no flags" — it was retried, not swallowed): 4 flags, 4 issues, 0 pull requests — crew#207, landing-site#3, landing-site#24, rig-templates#8. incubator#368 and #369 cleared since the 03:18Z re-measure. #490's conclusion holds on a third distinct row set; its rows have now turned over completely twice in 36 hours, which is why it is re-taken and never read off a comment.

[dan-claude-bot]

Re-measure 2026-08-22T00:4xZ. The rung comment's count against option A is false — it said one case against; there are four. Route D became box's standing practice inside fifteen hours, and four of its five applications are mine rather than yours

Nothing in the ask above is edited and nothing new is asked of you. Anchor still 2026-08-20T15:25:36Z; A, B and C stand as written, D stands as the rung comment added it; Default: still none — hard block. Board re-read over REST at 00:47:55Z: 0 open issues, 0 open pull requests, zero carriers on every queue label, the issue-flow reconciler answering issueflow: no open issues. on a DRY_RUN this pass. No label moves here and none is owed.

I would not write again to restate the rung. I am writing because the number I used to move my own recommendation from A to D was true when I wrote it and is not now — and because the question I closed that comment with has been answered by conduct rather than by a ruling.

---

1. What is false

The rung comment ended its option-A section: "A's non-trivial branch now has no supporting case and one case against."

There are four. All on heavy-duty/box, all merged between 09:35Z and 22:30Z yesterday, every one a change an untouched consumer receives without opting in — A's non-trivial branch, the branch A says must hold the merge:

original	merged	keyword	what an untouched consumer gets	evidence moved to
#174	PR #190 cfb5343 09:35:37Z	Closes #174	a time-sync agent in every guest image	#201
#177	PR #203 b2c54a1 15:46:24Z	Closes #177	no passwordless sudo in a newly minted agent box	#204
#178	PR #206 1c2f06b 17:15:58Z	Closes #178	a 1 GiB /tmp cap and a 4 GiB swapfile in a new mint	#207
#159	PR #209 e7014d4 22:30:21Z	Closes #159	the four agent seeds deleted, --role/--size at mint	#210

Every one carries Closes, never Refs, so none took the post-merge route — and #180, #160 and #171, which did take it, remain exactly what Measurement 3 said they were: off-by-default, A's trivial branch, where A and C give the same answer.

The nuance I am not eliding: #177 and #178 reach newly minted boxes only — cloud-init's users: block runs once, so an existing box keeps what it was minted with. A's test is what a consumer who does nothing gets, and a consumer who mints a box after those merges gets the new behaviour unasked. I read all four as non-trivial-branch cases; if you read the mint-time ones as trivial, the count is two, not four, and the correction still stands.

A fifth application exists ahead of its build: #215, minted 21:12:10Z and held behind #214, which is claimed with PR #217 open.

2. Who generalized it — the disclosure that matters most here

The rung comment closed: "The question I cannot answer from box#174 alone is whether D was that case's answer or the fleet's rule."

Measured from the artifacts: you ruled it once, on #174 at 08:57:54Z. The other four are mine — #204, #207, #210 and #215 were all minted by dan-claude-bot, each body citing the previous ones as the precedent for the next, and box#182's membership rows say so in as many words ("applying the #174 → #201 split shape").

So the answer to my own question is not that the fleet converged on D. It is that I turned a single instruction into a standing route on a governed board in fifteen hours, unruled, and the chain of citations makes each application look better supported than the one before it. That is not corroboration of my recommendation; it is the reason this ask needs an answer rather than more practice. Stated against my own interest, as the 22:4xZ note on #490 had to be.

3. D's costs, now measured rather than forecast

The rung comment recommended D on one ruled case and named no costs. Four applications later they are visible:

1. The wait relocated; it did not disappear. Six issues — #155, DRAFT: what ceremony is for, if the engine does the coordinating — enforcement vs coordination, and the conformance contract #201, docs: explain sweep cadence and manual dispatch #204, release: cut 0.4.0 #207, fix: checks_state never grades the label machine's own runs (#208) #210, What ceremony is for, if the engine does the coordinating — enforcement vs coordination, and the conformance contract #215 — are now operator-owned and waiting on one real-host session with no date, and docs: a directive hold ends on the labels, and stale hold prose is triage's to correct #155 makes that session a 0.10.0 release gate. Under C those criteria ride post-merge tails; under A they hold four pull requests. Under D they hold the tag.
2. Relocation before the merge is a route; after it, it is a repair. BUILDER.md — a park is declared once and stands; a nothing-changed resumption posts nothing #178's three fresh-mint criteria were not re-scoped in time, so it closed on criteria no check on that board runs. release: cut 0.4.0 #207 exists to say so, and box#182's row records it as triage's error — mine.
3. Relocated bodies rot against later merges in the same window. lib/changelog.sh + changelog-armed — the one-shape rule fails the PR that introduces the drift #159's merge deleted five seed directories that DRAFT: what ceremony is for, if the engine does the coordinating — enforcement vs coordination, and the conformance contract #201, docs: explain sweep cadence and manual dispatch #204, release: cut 0.4.0 #207 and checks_state — exclude the labels workflow's own runs from the rollup verdict (a displaced sweep sets blocker:ci-red on a green PR) #208 named, forcing a four-body correction tick at 23:0x.
4. A relocated issue can strand. fix: checks_state never grades the label machine's own runs (#208) #210 is ready and explicitly not schedulable: epic Release 0.4.1 — the displacement fixes, so consumers can shed the cancelled reconcile checks #212's D7 holds its disposition until release: cut 0.4.1 #214 merges, because its criteria witness a --role shape you ruled back out.

None of this makes D wrong. It makes D a route with a price that A, B and C's write-ups do not carry, and you should have it before choosing.

4. What genuinely changes the ask's shape: D makes A unreachable

A is keyed on "when every remaining acceptance criterion is operator-owned". Relocation dissolves that antecedent by construction — after the move, no remaining criterion is operator-owned, so A never fires. I noted this narrowly for #174 at the rung; it has now happened four times, which makes it structural rather than incidental.

So A and D are not peer options. Ruling A while relocation stays permitted leaves A decorative: any issue can be made A-proof by moving its criteria out the day before the merge, which is precisely what happened four times yesterday without anyone intending to evade a rule. If A is what you want, it needs a companion clause saying when the split is not allowed — and that clause, not A's discriminator, is the load-bearing sentence.

5. Reach, so the cost of each answer is visible

A or C reaches backwards. Both say those four merges should not have happened as they did — four commits already on box's main, one of them the whole mint path. I am not asking you to revisit them and nothing on that board is flagged or waiting on this; I am saying it out loud because a ruling that implicates shipped work should not do so silently.

B and D reach forwards only. B makes the route triage's call, said at mint. D makes relocation the route and needs §3's costs written beside it.

6. What this asks of you

Nothing new. A, B, C or D, on the ask above. My recommendation stays D, with §2 attached to it: most of D's evidence is my own conduct, and I would rather you rule against it knowing that than for it without.

If D: the landing site is unchanged — TRIAGE.md's acceptance-criteria bullet as a continuation of the independence paragraph, plus the clause beside BUILDER.md park shape 3 — and §3's four costs belong in it, particularly that relocation must precede the merge.

Default: remains none — hard block. The rung has passed and I am not picking; §2 is the reason, and it is a stronger one than the rung comment had.

#490 is not pre-empted by this comment, and no part of it is evidence for either of that ask's options. Its own census re-taken this pass across all eight governed boards, retry-safe with a known-positive control: 1 flag, 1 issue, 0 pull requests — crew#207 alone, unchanged since 22:39Z. I have written nothing on box this pass; those calls are that board's.

[dan-claude-bot]

Re-measure 2026-08-22T07:2xZ. The fifth application stopped being a forecast — it merged at 06:22:41Z, so the count on A's non-trivial branch is five; and the audit that came with it produced a fifth cost, which cuts against my own recommendation

Nothing in the ask above is edited and nothing new is asked of you. Anchor still 2026-08-20T15:25:36Z; A, B and C stand as written, D stands as the rung comment added it; Default: still none — hard block. Board re-read over REST at 07:29:16Z: 0 open issues, 0 open pull requests, zero carriers on every queue label, with the issue-flow reconciler answering issueflow: no open issues. on a DRY_RUN this pass. No label moves here and none is owed. I have written nothing on box this pass — that board's calls are its own, and it had already taken every one of them before I looked.

I am writing because the 00:49Z comment closed §1 with a sentence now false in all three of its particulars, and because the close that falsified it exposed a defect in route D I had not measured.

---

1. The fifth application merged

§1 ended: "A fifth application exists ahead of its build: #215, minted 21:12:10Z and held behind #214, which is claimed with PR #217 open."

clause	measured 07:2xZ
"#214 … is claimed"	closed 06:22:42Z
"with PR #217 open"	closed unmerged 05:01:22Z at the round cap — the ledger of six rounds, closing nothing
"#215 … held behind #214"	blocked → ready at 06:24:16Z, 94 seconds after that close, unaided

The row that belongs in §1's table:

original	merged	keyword	what an untouched consumer gets	evidence moved to
box#214	PR #218 d92974b 06:22:41Z	Closes	box new mints blank — no rig hook, pin, stamp or seeds' installer	box#215

So §1's headline is five, not four; §4's "it has now happened four times" is five; and §5's "four commits already on box's main" is five, the fifth being the mint path itself.

The round-cap detail bears on the keyword claim, not only the count. #217 carried no closing keyword and closed nothing; #218 opened seven seconds later on the same branch, head and tree, and carried Closes. One application that took two PR numbers — not two applications.

2. Classify before incrementing — what did not move

§2's disclosure is unchanged: four of the five applications are still mine. The fifth was already counted as an application at 00:49Z, as a forecast; what changed is its status, not the roster. Reading one event into two different counts is the error the 22:43Z note on #490 refused, and I am not making it here.

Two things are genuinely new:

• This is the first relocation performed before the build rather than during or after it. box#215 was minted 2026-08-21T21:12:10Z, 9h10m before the merge. §3's cost 2 drew exactly this line — "Relocation before the merge is a route; after it, it is a repair" — so this is the first clean instance of the route as D would have it written.
• A deferred disposition fired and was discharged in the same tick (§3).

3. §3's costs, re-measured — one discharged, one new

Cost 1 — "six issues … waiting on one real-host session with no date" is now five. box#155, #201, #204, #207, #215. box#210 closed not_planned at 06:48:51Z.

Cost 4 — discharged, and the mechanism worked. #210 was "ready and explicitly not schedulable" pending epic box#212's D7, whose trigger was #214's merge. The trigger fired at 06:22:41Z; that board closed #210 obsolete against #215 in the same tick, dispositioning all nine of its criteria one at a time. A deferred disposition with a named trigger is not a cost D has to carry — I listed it as one, and it resolved exactly as specified.

Cost 5 — new, and it is the one that cuts against D. That same audit found two criteria carried by no issue at all — the --size resolution on the instance, and --user reaching the guest — while box#215's own ## Dependencies asserted they were already carried. That assertion was false. Only a criterion-by-criterion disposition caught it, and the two were added to #215 before the close rather than promised after it.

This is the second bookkeeping defect the route has produced — cost 2 was #178's un-rescoped criteria — and both are mine. Under A the criteria never move, so this failure mode does not exist; under D it is live and recurring. It does not make D wrong. It says that if D is ruled, the clause that lands must require a relocation to enumerate the moved criteria one at a time against the original, because twice in two days a relocation has mis-stated what it carried.

4. Where that leaves the recommendation

Still D. §4's structural argument is untouched and remains the strongest thing in this thread: relocation dissolves A's antecedent by construction, so A and D are not peer options, and ruling A without a companion clause on when the split is disallowed leaves A decorative.

But §2's disclosure now has a sharper edge, and I would rather write it than have you find it: most of D's evidence is my own conduct, and both defects that conduct has produced are bookkeeping failures inside the relocation itself. A ruling for D on this record is a ruling that the route is worth a price I have now paid twice.

5. A correction I owe on this thread's numbers — and on what I said about them elsewhere

The 00:49Z comment's closing paragraph read: "across all eight governed boards … 1 flag, 1 issue, 0 pull requests — crew#207 alone." Re-derived from the label at 07:29:16Z: 9 governed boards, 3 flags, 3 issues, 0 pull requests — crew#207, incubator#277, landing-site#3.

Worse, and it is mine: at 03:13Z I wrote on #490 that "#488 was re-checked this pass and nothing in it staled." That was wrong when I wrote it. #490's own census one minute earlier had already measured 3 flags across 9 boards — which falsified this thread's closing paragraph in the same breath. I checked #488's four-row table and its box facts and never re-read its last paragraph. I have struck that clause in place on #490 rather than posting there, so a correction belonging here does not bury that ask.

The Blocked: half holds on a sixth re-take, on a sixth distinct row set: zero PR-borne flags anywhere in the fleet, now 3/3 rather than 1/1.

Two anchors on this thread resolve nowhere, and both point at option D's provenance. Checked against the discussion's own comment ids this pass: the 00:49Z comment links the rung as discussioncomment-18107996 (the rung is 18107912), and the rung comment links my 17:27Z precondition as discussioncomment-18096711 (it is 18096639). A wrong anchor lands a reader at the top of the thread rather than erroring, so nothing announces it — and both send someone checking where D came from to the wrong place. Corrected in the link above; I have not edited the two comments, because the text around each is accurate and an in-place edit fires no notification to tell you it happened. The #490 link cited in the rung comment (18096635) is correct.

6. What this asks of you

Nothing new. A, B, C or D on the ask above; my recommendation stays D, with §3's now-five costs attached and cost 5 written into whatever lands. Default: remains none — hard block — D amends published governance for every governed repository, so this ask fires at no rung and waits for you.

[dan-claude-bot]

Re-measure 2026-08-27. Doctrine landed on this ask's own axis — #491 legislates the mint-time half and stops short of the merge door, and in doing so it gives route D a shipped destination

Nothing in the ask above is edited and nothing new is asked of you. Anchor still 2026-08-20T15:25:36Z; A, B and C stand as written, D stands as the rung comment added it; Default: still none — hard block. Board re-read over REST this pass: 0 open issues, 0 open pull requests, zero carriers on every queue label. No label moves here and none is owed.

I am writing because this thread's central measurement — "BUILDER.md and TRIAGE.md answer this differently by implication and neither answers it in words" — has survived a doctrine change to the exact axis it is about, and because that change re-prices the option set. Nobody has touched this thread since 2026-08-22T07:32Z; everything below landed underneath it.

---

1. What landed

#491 merged 2026-08-24T14:30:51Z (PR #493, cca550d) and is an ancestor of tag 0.7.6, published 2026-08-26T14:07:58Z. It added to TRIAGE.md's acceptance-criteria bullet, at :133 on main:

When every acceptance criterion is operator-owned at mint, add operator alongside the issue's queue label. That issue's body names the evidence surface, the command or observation that produces the evidence, and the wake condition. 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.

operator is now a taxonomy row (A371F7, issue-only), and LABELS.md places it on the human axis beside this ask's own subject: "needs-ruling says a human owes a decision, operator says an operator owes the work."

2. The degraded half stands — byte-checked at 3ef0ca7

• BUILDER.md park shape 3 is byte-unchanged. "An operator-owned remainder parks the claim and never the handoff." The only BUILDER.md edit in this window is two lines in ## Picking, adding operator to the never-pick list.
• TRIAGE.md still holds no sentence gating a merge on an operator-owned remainder. Its new text is keyed on mint, not on the merge door.

So the ask's core is intact, and this is the second time doctrine has landed adjacent to this question and stopped short of it — #487's independence paragraph was the first, and #491 now sits directly beneath it legislating the neighbouring case. Doctrine now says what to do when an issue starts all-operator-owned, and still does not say what to do when it ends that way.

3. What it does to the options

D gets a shipped destination, and this is the strongest new argument in the thread. D relocates the operator-owned remainder into its own issue. That issue is, at its own mint, all-operator-owned — which is now precisely the artifact TRIAGE.md :133 mandates: operator alongside its queue label, with evidence surface, command and wake condition in the body, plus a 7-day quiet nudge implemented in issueflow-reconcile.sh (9439a7c, 38 lines of script against 112 lines of fixtures).

When I recommended D on 2026-08-21, its output was an ad-hoc issue — box#201, carrying three criteria and gating a release because that board chose to. It is now a named class with its own label, its own body contract and its own clock. That arrived without anyone ruling on this thread, and it is not something I argued for.

A's landing site moved again — third time. A said it lands as "the matching sentence in TRIAGE.md's acceptance-criteria bullet". That bullet now ends with the :133 block, so an A-ruling lands after the mint-time rule rather than after #487's independence paragraph. B's site is unchanged (park shape 3, byte-identical). C mints nothing.

4. One thing that cuts the other way, and it is a precondition rather than an objection

The operator label does not exist anywhere. Re-measured this pass by name across all nine governed boards, each with needs-ruling as a control row that passed: box, ceremony, crew, incubator, lafamilia-site, landing-site, martin-reyes-barbershop, rig, rig-templates — operator answers 404 on every one. It ships in 0.7.6 but a core-label row reaches a board only on a manual bootstrap dispatch, and that button has not been pressed. Ceremony's own sweep carries the annotation on its latest green scheduled run (33039116832, 2026-08-27T04:20:30Z): labels: missing core label(s): operator.

So TRIAGE.md currently mandates an act no board can perform. If D is ruled, its output depends on that press — ceremony needs only a bare self-labels-sweep.yml dispatch, since its running registry already knows the row; the eight consumers need the 0.7.6 pin bump first. Naming it here so the dependency is in the ruling rather than discovered by the first builder to hit it.

Annotated in place 2026-08-27T16:4xZ by the author. Nothing in the ask, the options or the Default: is edited, and this asks you for nothing new. §4 above says the bootstrap press "has not been pressed." That is wrong in the direction that matters. On heavy-duty/crew today the operator pressed twice — 33085807111 15:04:33Z and 33088766637 15:36:48Z — and both were cancelled while queued, with steps: 0, evicted from the sweep's shared concurrency group before a single step ran. gh workflow run prints ✓ Created workflow_dispatch event either way, so nothing told the operator. So §4's precondition is not operator inaction; it is a defect, and the sentence should be read as "the press cannot currently be made to land on a trafficked board." Converged today as #504 with children #505 (claimed) and #506, out of discussion #503. What it does to this ask: nothing. §3's argument that route D now has a shipped destination is unchanged — TRIAGE.md:133 and the 7-day clock are merged and tagged either way — and the label's 404 is unchanged too. Only the reason for it moved, from an unpressed button to a broken one, and it now has a named repair rather than an open-ended wait. Annotated rather than posted as a new comment so a correction of mine does not bury the ask.

Second annotation, 2026-08-27T19:0xZ, same comment, same reason — and it corrects the annotation directly above. That note said the press is "a broken one … with a named repair" and named #505/#506 as that repair. The repair is incomplete as stated. A press that survives the queue still cannot install this label: the operator row's description in core_label_rows() is 106 characters against GitHub's 100-character cap, so bootstrap_labels takes a 422 at row 13 of 21 and the run aborts partway through the taxonomy. Measured on heavy-duty/la-familia-incubator, run 33105011717, conclusion: failure on the operator's own dispatch at 18:44:56Z; that board is sitting on twelve of twenty-one core rows right now, and the twelve present are exactly rows 1–12. So §4's operator 404 has two causes stacked, not one — the press is evicted (#505/#506), and when it is not evicted it aborts on this row. Brought to contract this evening as #508, classed front row, claimed, with PR #509 open; it is ordered ahead of #505/#506 at merge. Two census corrections while I am here: the governed roster is ten boards, not nine — la-familia-incubator carries the taxonomy — and operator answers 404 on all ten. What it does to this ask: still nothing. §3's argument that route D has a shipped destination is untouched, TRIAGE.md:133 and the 7-day clock are merged and tagged either way, and the Default: is unchanged. Only §4's precondition got one more named repair in front of it.

5. Fleet census

Re-derived from the label this pass: 9 governed boards, 2 open flags, 2 issues, 0 pull requests — crew#207 and landing-site#3. The Blocked: half holds again: zero PR-borne flags anywhere in the fleet, on every re-take this thread has recorded.

6. What this asks of you

Nothing new. A, B, C or D on the ask above; my recommendation stays D, now with a shipped destination behind it and §4's press named as its precondition. The §3 cost disclosed on 2026-08-22 is unchanged and still stands: most of D's evidence is my own conduct, and both defects that conduct produced were bookkeeping failures inside the relocation itself.

Default: remains none — hard block — D amends published governance for every governed repository, so this ask fires at no rung and waits for you.

Third annotation, 2026-08-27T20:5xZ, same comment, same reason — the second annotation's board facts have all completed, and §4's precondition now has a dated route rather than a repair list. The 19:0x note above said #508 "is claimed, has [PR #509] open, and is ordered ahead of #505/#506 at merge." Every clause of that has resolved, in the order it forecast: #509 merged and #508 closed 19:11:41Z — the 422 at row 13 is fixed on main — #505 closed 19:14:27Z (PR #507), the sweep flipped #506 to ready at 19:14:43Z, and @cndgrr claimed it at 19:15:59Z with PR #511 open and in review. What §4's precondition now waits on is three named steps with an owner: #506 merges, the 0.7.7 tag publishes, a consumer re-pins and re-bootstraps. #510 is that cut — minted 19:18:50Z at @danmt's direction, gated on #506 alone — and its D6 and its post-merge acceptance criterion make the first completed live bootstrap (on heavy-duty/la-familia-incubator, whose taxonomy is sitting on rows 1–12) the release's own proof rather than a courtesy check.

A correction to the annotation above, and it is mine: it said "the governed roster is ten boards, not nine — la-familia-incubator carries the taxonomy." That is wrong, and the probe is why. needs-ruling is row 12 of core_label_rows(), so it sits inside the prefix a 422-aborted bootstrap leaves behind — it cannot distinguish an adopter from a half-built board. Re-derived this pass by probing a late row instead: la-familia-incubator answers needs-ruling and 404s on ready, epic and operator. It is the failure, not a tenth adopter. The roster is nine — box, ceremony, crew, incubator, lafamilia-site, landing-site, martin-reyes-barbershop, rig, rig-templates — each answering epic, and operator answers 404 on all nine, unchanged.

§5's census has also turned over completely. Both rows it named closed this afternoon: crew#207 unflagged 17:23:09Z and closed 17:23:12Z as a gate three releases obsolete, and landing-site#3 ruled 17:09:07Z and superseded by that board's #32. One flag is live fleet-wide — incubator#172, labeled 18:17:42Z, issue-borne — so the Blocked: half holds on a seventh distinct row set: zero PR-borne flags anywhere in the fleet, on every re-take this thread has recorded. What all of this does to this ask: nothing. §3's argument that route D has a shipped destination is untouched, and the Default: is unchanged.

[danmt]

D all the way. I'd go further and say that an issue simply cannot be for builders AND operators, its one or the other. And maybe we need that "builder-owned" and "operator-owned" maybe? The Ref thing and keeping issues open post-merge with huge walls of text is just retarded. also, we should use them as gates, if a fix needs a builder-owned and then an operator-owned then whatver the fix gates is gated by both, or even the latter only, in a graph builder-owned -> operator-owned -> gated issue. This also brings up the question, do we need an oeprator-owned action per issue? could we batch them? i guess some times but not all the time. @dan-claude-bot

[dan-claude-bot]

Ruling recorded and closed out by heavy-duty/ceremony triage: D, minted as #525 — plus one answer I take on my own authority and one new ask

@danmt ruled at 2026-08-28T12:37:00Z. That comment carries three decisions and two questions, and they are handled separately below rather than folded together. The escalation on the ask as filed is closed out; this thread stays open as the venue for §4's new ask. No label moves anywhere: no issue on this board carries needs-ruling, and a discussion cannot.

---

1. The three decisions, minted as #525

D — relocate, don't route. When an issue's remaining acceptance criteria include operator-owned ones, triage amends the issue: those criteria move verbatim into their own issue, the original is left wholly PR-checkable, and its PR merges with Closes #N. The evidence is neither waited on nor deferred to a post-merge tail. Relocation precedes the merge — before it, a route; after it, a repair, and box#178 is the worked case of the repair. And a relocation enumerates the moved criteria one at a time on both issues: that clause is mine rather than yours, and it exists because the route has produced exactly two defects and both were bookkeeping failures inside the relocation, box#215's ## Dependencies having asserted coverage of two criteria that no issue carried.

One owner class. "An issue simply cannot be for builders AND operators, its one or the other." An issue that would carry criteria of both classes is split at the mint; one found mixed later is split where it stands.

⚠️ That reverses a shipped sentence, and #525 makes the reversal explicit rather than additive. TRIAGE.md L136–L139 currently reads "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)." Under your rule that criterion does not stay — it relocates. The sentence is replaced and the replacement cites (#491, #488). #525's sixth criterion fails any build that adds the new rule while leaving the old sentence standing, and its first must-fail case is exactly that build. What survives untouched is the criterion-level independence paragraph: operator-owned still does not make a criterion post-merge, and vice versa. What collapses is the issue level.

The gating graph. builder-owned issue → operator-owned issue → the gated issue. The gated issue may declare the operator-owned issue alone, because it reaches the builder-owned one through it — the same transitivity the Dependencies bullet already applies to a front-row insertion. Declaring both is not wrong; the single edge is the house form.

One consequence you did not name but the ruling forces: BUILDER.md park shape 3 is today "An operator-owned remainder parks the claim and never the handoff" — the state a builder ends in. D abolishes that terminal state. #525 rewrites shape 3 as the transient park while triage performs the relocation, and keeps its number, because ## Claiming and ## Handoff cite shapes by number and a renumbering would silently point at the wrong one.

2. ✅ Answered on my own authority, overturnable by you: "maybe we need that 'builder-owned' and 'operator-owned' maybe?"

No new label is minted, and here is the reasoning so you can reject it cheaply. Both terms already exist in doctrine as written words — TRIAGE.md L110 and L115 define operator-owned and builder-owned — and operator already exists as a taxonomy row. Under the one-owner-class rule an issue is operator-owned exactly when it carries operator, so the classification is already visible on the board. A builder row would be true of every other issue in the repository: it partitions nothing that operator's presence and absence do not already partition, and a row that matches everything costs the same silence as a missing one while adding a wrong answer.

If you want the builder row anyway for symmetry, say so and I mint it — a bare yes is enough and I will treat it as the trigger.

3. ⚠️ A scope call I made, disclosed rather than buried, because your sentence is broader than the option you ruled

The Ref thing and keeping issues open post-merge with huge walls of text is just retarded.

I read that as D's rationale and scoped #525 to the operator-owned remainder, where D abolishes the Refs #N + post-merge route by construction. I left the mechanism standing for criteria that are post-merge but builder-owned — a tag publishing, a consumer's docs-sync --check — because #488 never asked about those, and because two issues on this board are live under it right now: #510 and #508, both post-merge. #525's tenth criterion holds the build to leaving it alone, and its second must-fail case is the build that deletes it on the strength of that sentence.

If you meant the wider thing — that post-merge goes entirely — say so and I re-mint. It is a materially bigger change: it strands those two issues' remaining criteria and needs a route for them, and I would rather ask than guess it into a contract.

4. 🧭 The ask your own comment raises, and it is the one thing #525 cannot decide for itself

This also brings up the question, do we need an oeprator-owned action per issue? could we batch them? i guess some times but not all the time.

"Some times but not all the time" is a decision in substance with the discriminator missing, and under D that discriminator is needed at every relocation. Without it, triage improvises — which is exactly how route D itself became this fleet's practice on five citations and one instruction, the disclosure I published on this thread before the ruling.

And there is a live instance, measured immediately before this write. heavy-duty/box carries five open issues, every one blocked, every one produced by a relocation, and every one whose title says "witnessed on real hardware": #155, #201 (chronyc tracking on every template), #204 (sudo refused in a fresh agent box), #207 (a fresh mint's /tmp cap and swapfile), #215 (a blank mint converged by hand). One operator session, one evidence surface, five issues — and #155 makes that session a 0.10.0 release gate.

🧭 needs-ruling — May one operator-owned issue carry the relocated evidence of several fixes, and what decides when it may?
Options:  A — one per fix, always: every relocation mints its own operator-owned issue. An operator ticking several
              in one sitting is scheduling, not structure, and nothing in doctrine changes.
          B — batch by evidence surface: relocations naming the same surface and the same command may land on one
              operator-owned issue, which then names every originating issue and gates them all; different
              surfaces never share.
          C — triage's call at each relocation, recorded with its reason in the operator-owned issue's body;
              no discriminator is written down.
Recommend: B. It is the only option with a stated discriminator, and it is decidable at relocation time from a
           fact the issue is already required to state — TRIAGE.md already makes an operator-owned issue name its
           evidence surface and the command that produces the evidence, so B adds no new field and no new
           judgement. It is also what "some times but not all the time" measures out to on the one live instance:
           box's five would collapse to roughly one per surface rather than to one or to five. A is honest but
           pays a body, a wake condition and a nudge clock per fix for evidence one command produces. C is the
           status quo dressed as a rule, and this thread's own record is what a triage-discretion route produces
           when nobody rules on it.
Blocked:  Nothing. #525 ships under every answer and carries an acceptance criterion saying so — its eleventh
          criterion forbids the build describing any batching mechanism, and its third must-fail case is the
          build that adds one. box's five issues are `blocked` and waiting on an operator session either way;
          what a ruling changes is whether the next relocation has a rule or improvises.
Default:  none — hard block. It is a sentence in TRIAGE.md published to nine boards, so org policy by
          construction; and it decides how much of a release gate one operator sitting can discharge, which is a
          cost that lands outside the work. No timed default.

No anchor is written and no ladder runs here. A discussion carries no labeled event, the ladder is anchored to one, and #526 — closing out today's ruling on #490 — makes that explicit. Silence on this ask has no timer and I am promising no pick in either direction.

5. What ships, and what does not move

#525 — documentation, scope:docs, blocked behind #524. Third in a four-issue chain — #523 → #524 → #525 → #526 — the four rulings @danmt delivered this afternoon, all editing the vendored doctrine set and therefore colliding on file, all ordinary class.

One disclosure #525 carries rather than discovers: operator answers 404 on every governed board, this one included — 28 labels here and operator is not among them — so D's output is an artifact no board can currently label. That is #510's outstanding operator-owned half, not this issue's, and the doctrine lands ahead of the label exactly as #491's did.

No cut is minted. Consumers get this at a pin bump; a release window is @danmt's to open. No attention is set — #525 is unassigned and blocked, and flagging on that basis would be a board bug rather than a demand.

Closed out by heavy-duty/ceremony triage, 2026-08-28.

[danmt]

I'd go B @dan-claude-bot

[dan-claude-bot]

Ruling recorded and closed out: B, minted as #532

@danmt ruled at 2026-08-28T13:39:47Z — "I'd go B". Recorded as the decision; the §4 escalation is closed out. This thread stays open, for the reason in §3 below. No label moves anywhere: no issue on this board carries needs-ruling, and a discussion cannot.

---

1. The rule, stated so a consumer reading only this comment has it

Relocations naming the same evidence surface and the same command or observation may land their operator-owned criteria on one issue, which names every originating issue and gates them all. Different surfaces never share.

Four things #532 pins down that the option text left implicit, because each is a way a builder could ship B and get it wrong:

• It permits, it does not compel. Eligible relocations may share; triage may still mint one per fix. That is the ruled option's own word may and your own "some times but not all the time". This clause is mine rather than yours — it is the one place B could honestly have been read the other way — and it is flagged as mine in the issue.
• "The same command" is one invocation, not one sitting. Two different commands run on the same host in the same afternoon are not one command; that is scheduling, which is option A's correct observation and it survives under B. Without this the batch key degrades to "anything one operator could do in an afternoon", which nobody can check.
• A batched issue enumerates per originating issue. #525 D3 already forbids asserting coverage in a summary sentence, because box#215's ## Dependencies claimed two criteria no issue carried. Batching scales exactly that hazard — one body now speaks for several fixes — so the enumeration duty is per originating issue, and TRIAGE.md and BUILDER.md — an operator-owned remainder relocates before the merge, and an issue has one owner class #525's sentence is held byte-unchanged by an acceptance criterion.
• The gating graph fans in. TRIAGE.md and BUILDER.md — an operator-owned remainder relocates before the merge, and an issue has one owner class #525 D8's builder-owned → operator-owned → gated becomes several chains converging on a shared middle node, and each gated issue still declares that node alone. A reader holding only the linear picture would not know a shared node is legitimate.

B adds no new field, which is what made it decidable at relocation time — verified against main rather than assumed. TRIAGE.md L133–L136 already requires an all-operator-owned issue to name "the evidence surface, the command or observation that produces the evidence, and the wake condition". The two facts B keys on are already mandatory text on exactly the issues B governs.

2. The live instance, re-measured rather than carried forward

The ask cited heavy-duty/box as five relocated issues on one surface. That board has moved and the figure in the ask is stale: it holds 15 open issues today. Five are still blocked relocation products waiting on an operator session — box#155, #201, #204, #207, #215 — of which four name real-hardware evidence in their titles and #155 is about the drill record the next cut must carry rather than waive.

And the honest consequence for B: they collapse by surface, not to one. The ask said "roughly one per surface"; under D6's strict reading of "the same command" that is a smaller collapse than "one operator session, one issue" would give. Re-shaping that board is its own call and #532 touches no other repository.

3. Two things from your 12:37Z comment are still open, and this thread is why they have not expired

Neither is re-asked here — a bare repeat asks nothing — but both would otherwise lapse silently when a venue closes, so they are recorded:

• §2, the builder label. I answered no new label on my own authority and said a bare yes from you is enough to trigger the mint. You have not said it, so nothing is minted. The offer stands.
• §3, the scope call. I read "the Ref thing and keeping issues open post-merge with huge walls of text" as D's rationale and scoped TRIAGE.md and BUILDER.md — an operator-owned remainder relocates before the merge, and an issue has one owner class #525 to the operator-owned remainder, leaving Refs #N + post-merge standing for criteria that are post-merge but builder-owned. If you meant the wider thing — that post-merge goes entirely — that is a materially bigger change and I re-mint on your word. Two issues on this board were live under that mechanism when I wrote it; both have since closed, so the cost of the wider reading is lower today than it was at 13:09Z.

That is why this thread stays open. It is now the venue for those two offers rather than for §4.

4. What ships, and what does not move

#532 — documentation, scope:docs, blocked behind #526. It edits TRIAGE.md only, and the text it appends to does not exist on main yet: it is the route-D block #525 ships. So the collision edge and the substantive dependency coincide, and one edge is declared rather than three — #526 reaches #525 and #524, and fanning the chain would add nothing the sweep does not already resolve.

No machinery. No sweep change, no guard, no new label, no new queue state, nothing that recognises a batched issue as a distinct kind. Every existing mechanism reads it as an ordinary operator issue with more than one originating citation.

No cut is minted. Consumers get this at a pin bump; a release window is yours to open. #528 gates on #532 under your 13:23:09Z ruling, and that is recorded on the cut rather than here — with the disclosure it owes you, since #532 is triage's own mint.

No attention is set — #532 is unassigned and blocked, and flagging on that basis would be a board bug rather than a demand.

Closed out by heavy-duty/ceremony triage, 2026-08-28.

[danmt]

§2, the builder label. I answered no new label on my own authority and said a bare yes from you is enough to trigger the mint. You have not said it, so nothing is minted. The offer stands.
§3, the scope call. I read "the Ref thing and keeping issues open post-merge with huge walls of text" as D's rationale and scoped TRIAGE.md and BUILDER.md — an operator-owned remainder relocates before the merge, and an issue has one owner class #525 to the operator-owned remainder, leaving Refs #N + post-merge standing for criteria that are post-merge but builder-owned. If you meant the wider thing — that post-merge goes entirely — that is a materially bigger change and I re-mint on your word. Two issues on this board were live under that mechanism when I wrote it; both have since closed, so the cost of the wider reading is lower today than it was at 13:09Z.

those two probably should have their own discussions so we can close this thread @dan-claude-bot

[dan-claude-bot]

Split and closed — the two residuals now have their own venues

@danmt Done, in the order you asked for: the residuals moved first, so nothing lapses with the close.

residual, as it stood in §3 of 15:39Z	its venue now
the builder label — "maybe we need that 'builder-owned' and 'operator-owned' maybe?", answered no new label on triage's own authority, with a bare yes from you as the trigger to mint	discussion #535
the scope call — whether "the Ref thing and keeping issues open post-merge" abolishes Refs #N + post-merge entirely, or only for the operator-owned remainder as built	discussion #536

Each carries the question in your words, what triage answered and on whose authority, what a yes would mint, and what silence costs. Neither is a bare repeat: both ask one thing, and #536 corrects a cost figure this thread published.

The correction, because it changes the answer's price. At 15:39Z I wrote that the wider reading was cheaper today because "two issues on this board were live under that mechanism … both have since closed". That was measured on this board, and this board is not where the mechanism lives. Re-measured across the nine governed boards at 19:0xZ: 18 open post-merge issues — crew 7, incubator 5, box 4, lafamilia-site 2, ceremony 0. The wider reading has to dispose of every one of them, and the disposition is the expensive part, not the doctrine edit. #536 carries the table.

What this thread produced, for the record

ruling	when	shipped as
D — relocate, don't route	12:37:00Z	#525 — claimed, in flight at PR #533
B — batch relocated criteria by evidence surface	13:39:47Z	#532 — blocked behind #526

Both issues cite this thread for their provenance in past tense, and those citations keep resolving after the close. The two that pointed here for a live question — #525's header and its D10 exclusions, and #532's builder label exclusion — are repaired in this same tick to name #535 and #536 instead, so no open issue tells a reader the question lives on a closed thread.

Marking answered and closing. Nothing here is unspent: both rulings are built or building, and both residuals are open elsewhere with their triggers intact.

Closed out by heavy-duty/ceremony triage, 2026-08-28.