Should builder-owned be a label beside operator, or stay a property of the issue text? — the standing offer split out of #488

[dan-claude-bot]

Split out of discussion #488 at @danmt's direction (2026-08-28T17:55:27Z — "those two probably should have their own discussions so we can close this thread"). #488's two rulings are built; this is one of the two residuals it carried, moved here so it has a venue of its own and does not lapse with the close.

The question, in the words it was asked

On 2026-08-28T12:37:00Z, ruling D on #488, @danmt added:

And maybe we need that "builder-owned" and "operator-owned" maybe?

Read against its own sentence — "an issue simply cannot be for builders AND operators, its one or the other" — the question is whether the one-owner-class rule that ruling produced should be visible on the board as a label, the way operator already is, rather than only in the issue's prose.

What triage answered, on its own authority, and why

No new label, for three reasons, all measurable rather than aesthetic:

1. operator already carries the whole signal. LABELS.md has one operator row; an issue that does not carry it is builder-owned by construction under the one-owner-class rule. A builder row would be the negation of an existing row — true of most of the board, and a label true of most rows locates nothing.
2. Nothing would read it. No sweep, no guard, no workflow and no doctrine sentence branches on such a label. operator's row is read by the reconciler's evidence nudge; a builder row would be read by nobody, and a label nothing reads is a label nothing keeps true.
3. Every board would pay to install it. The taxonomy is bootstrapped per repository by a workflow_dispatch, which triage cannot press (#524). A new row means nine boards, nine presses, and a fleet-wide pin bump before a single issue could wear it.

That answer shipped as a decision not to build: #525 writes the one-owner-class rule into TRIAGE.md in prose, and its eleventh criterion rejects a build that adds a builder row to LABELS.md. #532 says the same in its own exclusions.

What is still open, and what would trigger it

The offer stands: a bare "yes" here is enough to mint it. The answer above is triage's judgement, not a ruling — @danmt asked the question and has not answered it, and an unanswered question closed by the party who answered it on its own authority is exactly the shape that lapses silently when a venue closes. So it lives here now.

If the answer is yes, what gets minted is a taxonomy issue, not a doctrine one: a builder row in .github/labels.conf and LABELS.md, its description, the reconciler's treatment of the pair (mutually exclusive, or independent), the mint-time duty in TRIAGE.md, and the nine-board bootstrap — the last of which is operator-owned and would carry its own evidence and wake condition under #525's rules. Roughly one issue plus one operator-owned relocation, and a pin bump before consumers see it.

Also worth knowing before answering: operator is installed on this board's taxonomy but is currently carried by zero open issues across the nine governed boards, measured 2026-08-28T19:0xZ. The row this one would pair with has not yet had a live subject, so a decision here is being taken on a design rather than on observed use.

What no answer costs

Nothing on any board. No issue is blocked on this, no build waits for it, and both #525 and #532 ship unchanged under either answer — each holds its build to not adding the row, so a later yes mints fresh work rather than invalidating theirs. Silence here has no timer, and triage promises no pick in either direction: this is a taxonomy that every governed repository has to install, which is the operator's call by construction.

[danmt]

If we add this label it will be primarily used by builders to tell what issues they can actually pick. This will require a change in heavy-duty/crew and maybe in some of the base intructions here for BUILDER.md. The idea of operator is to track things that are meant for the operator without cluttering the ones that are meant for builders. Feel free to explore how this fits into heavy-duty/crew @dan-claude-bot

[dan-claude-bot]

Explored, as asked. crew already does the thing you described — with operator alone, and without a builder row. The gap is somewhere else, and it now has a number: #541.

@danmt You wrote:

If we add this label it will be primarily used by builders to tell what issues they can actually pick. […] The idea of operator is to track things that are meant for the operator without cluttering the ones that are meant for builders.

That is a purpose statement, so I went and measured whether it is already served. It is. Read at crew main = 59d090d:

where	what it does
shared/conf/fleet.defaults.conf:41	LABEL_OPERATOR="operator"
shared/lib/duty-builder.sh:22–31	_ready_issue_lines drops every ready issue carrying operator from the pick list — before the board count and before the seen-ledger, so a withheld issue is invisible to both
shared/lib/duty-builder.sh:35–41	the build prompt is told why: "a ready issue carrying operator is operator-owned work, not work for a builder"
shared/lib/duty-builder.sh:87	operator-owned is already one of the four decline reasons a session may return

That is crew#461, and its own comment names the design: "an older fleet with no configured label receives the exact prompt it did before #461, while a configured fleet tells the session what the engine enforced." So "what can I actually pick" is answered today, by exclusion. Under #525's D5 — an issue has one owner class, never both — not carrying operator is exactly builder-owned, so the negation is total and a builder row would be the complement of a filter that already works.

What adding the row would actually change

It would invert the filter from negative to positive, and a positive filter fails in the other direction. Today an unlabelled ready issue is pickable; under a builder row crew would have to select for it, and an unlabelled one becomes invisible — a mint that forgets the row silently withholds work from the whole fleet, forever, with no board symptom. The one-time backfill is small (8 open ready issues across the nine boards right now), but the ongoing exposure is not: it is every future mint.

That is the argument against, and it is a design argument rather than a measurement, so it is worth exactly what you think it is worth. The offer from the first comment stands: a bare "yes" still mints it, as a taxonomy issue with a builder row in the reconciler and LABELS.md, the pair's reconciler treatment, the mint-time duty in TRIAGE.md, a crew issue turning _ready_issue_lines positive, and a bootstrap press on nine boards.

The gap the exploration actually found, and it is not a design question

operator exists on three of the nine governed boards. Measured just now:

board	pin	operator
crew	0.7.6	✅
la-familia-incubator	0.7.7	✅
landing-site	0.7.7	✅
box	0.7.6	❌ press owed — tracked at box#219
ceremony	local	❌ press owed
incubator	0.7.4	❌ pin bump, then press
lafamilia-site	0.7.4	❌ pin bump, then press
rig	0.7.4	❌ pin bump, then press
rig-templates	0.7.4	❌ pin bump, then press

A new taxonomy row is created only by a bootstrap=yes dispatch; the ordinary reconcile pass never creates labels. So on six boards #491's rule has never been applicable, crew's withholding has never fired, and this board — the one that publishes the rule — is among them.

It was disclosed and then stopped being anyone's. #510's D7 owned one instance, la-familia-incubator, and closed correctly against it at 14:17:44Z today. #525's D11 disclosed the rest and said it "is #510's outstanding operator-owned half and is not this issue's to fix" — a sentence that now points at a closed issue. Only box's share is carried anywhere.

So I have minted #541: all-operator-owned, one criterion per board, evidence being each board's live label list rather than anyone's report of the press, and one wake per board. It needs no ruling — the rule is published and released, the label is simply absent — which is why it is a mint and not another question. Two things in it are yours whenever you want them: five bootstrap=yes dispatches, and four pin bumps I am filing as issues on those consumers' own boards.

It also cannot wear the label it is about. operator is not among this board's 28 rows, so #541 goes on the board as ready with the row that names its owner missing, and says so in its own body. If you want one argument for a taxonomy being real rather than documented, that is it — and it is an argument for finishing this rollout before deciding whether to add a second row beside it, because the pair would otherwise be judged on a mechanism that has never run on two thirds of the fleet.

Where this leaves the question

Still yours, still no timer, and triage still promises no pick. Narrowed by the exploration to one thing: given that operator already withholds operator-owned work from every builder's pick list, and given that a builder row inverts a fail-open filter into a fail-closed one, is there something you want the row to do that the exclusion does not already do? If the answer is "no, finish the rollout instead", #541 is that and this thread closes. If it is yes, say so and it is minted the same day.

Nothing is blocked on the answer. #525 and #532 each hold their builds to not adding the row, so a later yes mints fresh work rather than invalidating theirs, and #541 is unaffected either way — it installs the taxonomy a builder row would arrive through.

[dan-claude-bot]

Correction — the governed roster is eleven boards, not nine, and my table above was two short

@danmt A measurement error of mine, found while writing #541's criteria and repaired everywhere it landed.

I identified the governed boards as those carrying a post-merge label. That test reads out any board whose ceremony pin predates that row — which is exactly the two furthest behind:

board	labels.yml pin	operator
heavy-duty/martin-reyes-barbershop	0.3.0	❌
heavy-duty/cast	0.1.0	❌

Both call heavy-duty/ceremony/.github/workflows/labels.yml, so both are governed. The right test is that uses: line, plus ceremony itself, which runs its own action — eleven.

What changes: operator is present on 3 of 11, not 3 of 9, and eight boards are owed the row rather than six. #541's table, its task rows, two more acceptance criteria and its close census are amended, and its R2a now records the flawed test so the next census is not built the same way. The two additions are also the two largest pin bumps on the list, which is worth knowing before anyone prices them.

What does not change: the post-merge count of 18 — neither board has that row either, so neither can carry an issue wearing it — nor the 8 open ready issues, nor anything in the argument above about crew's filter.

The same correction is applied to #538, #539, #540 and #525, which all carried the phrase.

[dan-claude-bot]

📎 Correction — the "finish the rollout instead" branch of my own answer now points at a closed issue

@danmt No new question and no change to the offer. My 19:58Z comment ended: "If the answer is 'no, finish the rollout instead', #541 is that and this thread closes." #541 has since been closed not planned (2026-08-29T00:05:09Z), by me, so that sentence now routes you to a closed issue. Repairing it here because it is the branch of the answer you would take if you take one.

Why it closed, and it is not because the rollout is done. #541 was minted at 19:58:00Z with ten bootstrap=yes press criteria. TRIAGE.md had said since ed2effd — #524, merged 17:47:01Z, two hours before the mint — that a governed board's 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." The mint was mine and it was wrong under a rule I had merged the same afternoon. Closing it is a bookkeeping correction, not progress.

Where the rollout actually lives now. The work was not lost; it was re-routed to where each half belongs.

half	where it is
the four pin bumps (buildable)	incubator#437, lafamilia-site#51, rig#201, rig-templates#19 — each 0.7.4 → 0.7.7, each asserting labels-sweep.yml is among the bumped files
already tracked, not re-minted	cast#144, box#219
the presses (yours, tracked nowhere by construction)	ready today: heavy-duty/ceremony and heavy-duty/box. Not ready until their pin moves: the four above, plus cast. Not pressable at all: martin-reyes-barbershop, pinned 0.3.0 with no labels-sweep.yml caller to dispatch

Nothing is due from you and no timer runs on any of it — that is what the mint-door rule means, and it is why the press half sits in a close-out comment rather than on a board.

What this does not change

The offer stands exactly as written: a bare "yes" here still mints the builder row, and the narrowed question from 19:58Z is unchanged — given operator already withholds operator-owned work from every builder's pick list at crew's _ready_issue_lines, is there something you want a builder row to do that the exclusion does not already do?

The argument for finishing the rollout before deciding is also unchanged, and #541's closure does not weaken it: operator is on 3 of the 11 governed boards, so on the other eight #491's rule has never been applicable and a second row would be judged on a mechanism that has never run. What changes is only the pointer — that rollout is six issues and a handful of presses, not one issue.

Nothing on any board is blocked on this thread, #525 and #532 shipped holding their builds to not adding the row, and silence here still has no timer.

Pointer repaired by heavy-duty/ceremony triage, 2026-08-29T03:5xZ. This corrects a link in my own answer; it takes no option and asks nothing new.

[danmt]

Yes @dan-claude-bot

[dan-claude-bot]

Taken as the standing offer, minted the same day — #562. And the design answers the one objection I had left.

@danmt 2026-08-29T16:06:05Z, "Yes" — the offer this thread carried through four comments was "a bare yes here is enough to mint it", and it is minted. Triage argued against the row three ways and was overruled; that is the correct outcome of the thread and the argument is closed. What is left is how, and one of my three arguments survives as a build constraint rather than as an objection.

(Read either way, the answer is the same. The narrowed question at 19:58Z was "is there something you want the row to do that the exclusion does not already do?" — yes to that and yes to the offer both mint the same issue. If you meant something specific the row should do, #562's D2 is the sentence to argue with.)

The one argument that survives, and what it forced

It would invert the filter from negative to positive, and a positive filter fails in the other direction. […] a mint that forgets the row silently withholds work from the whole fleet, forever, with no board symptom.

So the row is derived, not set at a mint. On every pass, an open issue carrying a queue label and not carrying operator gains builder; one carrying operator has it removed. epic and needs-triage are exempt. Three things follow, and they are the whole design:

• It cannot be forgotten, because no human writes it.
• It is exactly the negation, always. Under #525's D5 an issue has one owner class and never both, so not carrying operator is builder-owned. A derived row cannot drift from the rule it encodes — which is LABELS.md's own standard: a label nothing keeps true is a label nothing keeps.
• It backfills every board on the first pass after adoption, with no census and nothing for triage to sweep by hand.

operator + builder together resolves silently rather than drawing a conflict flag — the sweep can infer intent here, because one is hand-set and the other is derived — and an issue carrying neither draws nothing, because after one pass no such issue exists.

⚠️ Two corrections to what I told you in this thread

1. The row does not go where I said it did. My 19:58Z comment said "a builder row in .github/labels.conf and LABELS.md". labels.conf is the per-repo file — scopes, panel, triage-actors. The governed taxonomy is core_label_rows() in actions/labels-reconcile/labels-reconcile.sh, for the reason its own neighbour states in the tree: "a rule that must hold in every governed repo cannot live in a per-repo file." Putting it in labels.conf is one of #562's must-fail builds.

2. The offer promised an operator-owned issue for the presses, and I may not mint one. The first comment said the mint would be "roughly one issue plus one operator-owned relocation". TRIAGE.md has said since #524 — merged 2026-08-28T17:47:01Z, before that offer was written — that 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." That is the rule that closed #541 not planned. So the press half is named here, in this comment, and nowhere else.

📌 The presses this will owe you — and the rollout has moved a long way since I last reported it

Re-measured live 2026-08-29T17:0xZ, from the uses: lines rather than from any label — operator is on 6 of the 12 governed boards, not the 3 of 11 I have been citing since 2026-08-28T20:04Z:

board	pin	operator today
crew	0.7.6	✅
incubator	0.7.7	✅
box	0.7.7	✅
landing-site	0.7.7	✅
la-familia-incubator	0.7.7	✅
la-familia-infra	0.7.7	✅
ceremony	runs its own action	❌ press owed — this board publishes the rule and does not carry the row
lafamilia-site	0.7.7	❌ press owed, pin is ready
rig	0.7.7	❌ press owed, pin is ready
rig-templates	0.7.7	❌ press owed, pin is ready
martin-reyes-barbershop	0.3.0	❌ pin bump first — 15 releases behind
cast	0.1.0	❌ pin bump first — 17 releases behind

Four boards are one press away today (ceremony, lafamilia-site, rig, rig-templates) and six are already done. The builder row arrives through the same dispatch, so a press made after #562 ships and a pin bumps installs both rows at once — there is no separate rollout for this label.

Nothing is due from you and no timer runs on any of it. That is what the mint-door rule means, and it is why this sits in a comment rather than on a board.

What is deliberately not in #562

heavy-duty/crew is untouched and no doctrine sentence here cites it (#280). Today _ready_issue_lines drops every ready issue carrying operator — a negative filter that already answers "what can I actually pick", and it keeps working unchanged. Turning it positive is crew's own issue, filed there once this lands and crew's pin bumps, in the shape #538's E12 uses for the mirror case. ⚠️ It must not be flipped before the row exists on crew's board — a positive filter against a taxonomy without the row withholds the entire board — and the filing will say exactly that.

#562 is blocked behind #549, the newest open carrier of LABELS.md, TRIAGE.md and the issue-flow reconciler.

This thread stays open until #562 closes, and its close-out will carry the press list re-measured at that moment rather than this one.

Answered by heavy-duty/ceremony triage, 2026-08-29T17:0xZ. The twelve-board roster and the operator column were both re-derived live in this tick; the 3 of 11 figure in my 2026-08-28T20:04Z correction above is superseded by the table here.

[dan-claude-bot]

📎 Correction — my close-out's trigger fired the wrong way: #562 is closed, and this thread must not close with it

@danmt No new question, and nothing about your Yes or about the design changes. Repairing this because the stale sentence is mine and it points a future pass at the wrong act.

My 2026-08-29T17:0xZ close-out ends: "This thread stays open until #562 closes, and its close-out will carry the press list re-measured at that moment."

#562 closed 2026-08-30T13:31:46Z — as not planned, not as delivered. Read literally, my sentence now says to close this thread. That would be wrong: the builder row has not shipped anywhere.

What actually happened. @danmt directed on 2026-08-30T13:5xZ — "i want them in too" — that #562 be folded into #567, the single issue collapsing the 0.7.8 gate. Its contract is carried there verbatim as the 562·D1–562·D9 block, including the D9 missing-row skip. So the work is not cancelled; it moved, and it is in flight right now at PR #569 (green at head, Closes #567).

The trigger is re-pointed: this thread closes when #567 merges and the builder row has reached the boards, not when #562 closed. Nothing else in the close-out changes.

📌 The press list, re-measured as promised — and it moved a long way

Measured live 2026-08-30T18:0xZ, probing each board's taxonomy by name, with crew as a known-positive control and cast as a negative one:

operator present	operator still owed
box, crew, incubator, infra, la-familia-incubator, la-familia-infra, lafamilia-site, landing-site, rig — 9 of 12	rig-templates · cast (no queue taxonomy at all — vendors doctrine only) · ceremony itself — the board that publishes the rule still does not carry the row

That supersedes every earlier figure on this thread — the 3 of 11 of 2026-08-28T20:04Z and the 6 of 12 of 2026-08-29T17:0xZ both. Do not paste this table forward either; it is one measurement and it has now moved three times in three days.

Nothing is due from you and no timer runs on any of it. A new taxonomy row is created only by a workflow_dispatch with bootstrap=yes, which triage may not press (#524) and which passes no mint door — the builder row arrives through that same dispatch, so a press made after #567 merges and a pin bumps installs both rows at once.

Corrected by heavy-duty/ceremony triage, 2026-08-30T18:1xZ. No label moves and no attention is set: #567 is claimed and its assignee's next move is on that issue, not here.

[dan-claude-bot]

🔔 The first half of the re-pointed trigger fired — #567 merged and 0.7.8 published, and the builder row has reached no board

@danmt This thread stays open, and this is the press ask it has been waiting to be able to make. Nothing here is a decision, nothing is minted, and no timer runs on you.

My 2026-08-30T18:1xZ correction re-pointed the trigger to: "this thread closes when #567 merges and the builder row has reached the boards." Half of that is now true:

step	when
#567 closed, carrying the 562·D1–562·D9 block verbatim	2026-08-31T11:45:33Z
0.7.8 published as a full release	2026-08-31T21:11:11Z
the builder row present on any board	not yet — 0 of 13

So the row is shipped and installed nowhere, which is the state #524 describes: a new taxonomy row is created only by a workflow_dispatch with bootstrap=yes, triage may not press it, and it passes no mint door. TRIAGE.md at main makes naming the rows and the verified press the whole of what triage does here, and then stopping.

The press list, re-measured live — 2026-08-31T23:4xZ

Roster derived this pass from the uses: line (heavy-duty/ceremony/…@<tag> in a board's labels.yml or labels-sweep.yml) — the test that answers who receives a taxonomy change when they bump — over all 41 repositories in the org, plus ceremony itself, whose caller uses the local ./.github/workflows/labels-sweep.yml form and therefore tracks main rather than a tag. crew and box are the known-positive controls and both returned operator; rig-templates returned 404 in the same output, so the instrument discriminates.

board	pin	operator	builder
box	0.7.7	✅	❌
crew	0.7.6	✅	❌
incubator	0.7.7	✅	❌
infra	0.7.7	✅	❌
la-familia-incubator	0.7.7	✅	❌
la-familia-infra	0.7.7	✅	❌
lafamilia-site	0.7.7	✅	❌
landing-site	0.7.7	✅	❌
rig	0.7.7	✅	❌
rig-templates	0.7.7	❌	❌
martin-reyes-barbershop	0.3.0	❌	❌
cast	0.1.0	❌	❌
ceremony	local, tracks main	❌	❌

builder: 0 of 13. operator: 9 of 13.

⚠️ A correction to my own 2026-08-30 table on this thread, which said 9 of 12. Nine present was right; the denominator was one short. martin-reyes-barbershop appeared in neither column — it is a governed board by the uses: test, at 0.3.0, and it carries neither row. The nine present are unchanged. As I said there and repeat here: do not paste this table forward — it is one measurement and it has now moved four times in four days.

What a press does, per board — they are not the same act

• ceremony — one bare dispatch installs both rows, today. self-labels-sweep.yml declares workflow_dispatch with input bootstrap (choice, default "yes"), so a bare press bootstraps. Because its caller rides main rather than a tag, that press creates operator and builder in one act. This is the board that publishes the rule and it carries neither row.
• rig-templates, at 0.7.7 — a press today installs operator only; builder is not in that tag's core_label_rows. It needs a press now and another after its pin reaches 0.7.8, or one press after the bump.
• The nine at 0.7.6/0.7.7 — builder arrives only after that board's pin reaches 0.7.8 and a press follows the bump. A bump alone installs nothing; that is the "not finished at the merge" paragraph in docs/CONSUMERS.md.
• martin-reyes-barbershop (0.3.0) and cast (0.1.0) — neither has the queue taxonomy at all, and both need a pin bump first. Worth knowing before that is scheduled: #588, minted today off discussion #585, measures that bin/ceremony-upgrade refuses every forward move for both of them — the next ladder tag above each carries a migration row — so those two bumps are hand-written work until the ladder row of #568 lands.

Nothing is due from you, and the sweep is not broken meanwhile

The derivation is guarded rather than failing: issueflow-reconcile.sh skips the whole owner-class block when the row is absent (562 D2/D9), so on ceremony today #586 carries claimed and no builder, and that is the designed behaviour of a board before its press — not a mislabelled issue. Every sweep run in the last hour is green.

One unrelated leftover on this board while the taxonomy is in view, mentioned once and not asked for: ceremony still carries a post-merge label object, retired from the taxonomy by #536/#573 and now on zero issues. Deleting a label is not what bootstrap=yes does — it only upserts — so it is a separate one-line act whenever it is convenient. It lies to nobody today; no open or closed issue carries it.

Written by heavy-duty/ceremony triage, 2026-08-31T23:5xZ. This thread stays open: the second half of its trigger — the row reaching the boards — is unmet, and the press list is what this thread has owed since your Yes. No label moves anywhere and no attention is set; nothing on this board is gated on the press, and no issue is minted for it, because repairing a board's own taxonomy is operator-owned and passes no mint door (#524).

[dan-claude-bot]

🔔 The second half of the trigger has started to fire — builder is 1 of 13, not 0, and the first live derivation exists

@danmt No new question, nothing minted, no timer runs on you. This thread stays open. My last comment said the row had "reached no board" and told you not to paste its table forward; this is that table re-measured, plus two corrections to my own text in it.

builder has reached its first board

heavy-duty/landing-site carries the row, and it is byte-identical to what core_label_rows() ships at main (labels-reconcile.sh:977) — name, colour BFDADC, and the description "Builder-owned; the complement of operator — derived by the sweep, never hand-set". So this is a ceremony-shipped adoption, not a hand-made label of the same name.

The mechanism my last comment predicted is now measured in both directions, which is the part worth having:

	pin	press	builder
landing-site	0.7.8	✅	present
incubator	0.7.8	❌	absent
la-familia-incubator	0.7.8	❌	absent

Three boards reached 0.7.8; exactly the one that also took a press has the row. "A bump alone installs nothing" was an inference from docs/CONSUMERS.md last time and is an observation now.

The derivation is live there, and it has correctly written nothing

landing-site has zero builder carriers, and that is the right answer rather than a stalled sweep. Its three open issues are #54 and #51 (both operator) and #32 (epic). Running the shipped owner_class_decision at origin/main over each live label set:

enhancement ready scope:deploy operator                        -> KEEP
enhancement ready needs-ruling scope:site scope:deploy operator -> KEEP
enhancement epic scope:content scope:site scope:deploy scope:docs -> KEEP

So the first board to install the row is one where every open issue is operator or epic. The derivation is guarded, live, and silent — three different things that look alike from the label count alone.

The census, re-measured 2026-09-07T02:5xZ

Same instrument as last time — the uses: line naming heavy-duty/ceremony/…@<tag>.

board	pin	operator	builder
landing-site	0.7.8	✅	✅
incubator	0.7.8	✅	❌
la-familia-incubator	0.7.8	✅	❌
box	0.7.7	✅	❌
crew	0.7.7	✅	❌
rig	0.7.7	✅	❌
lafamilia-site	0.7.7	✅	❌
la-familia-infra	0.7.7	✅	❌
infra	0.7.7	✅	❌
rig-templates	0.7.7	❌	❌
martin-reyes-barbershop	0.3.0	❌	❌
cast	0.1.0	❌	❌
ceremony	local, tracks main	❌	❌

builder: 1 of 13 (was 0). operator: 9 of 13 (unchanged). crew moved 0.7.6 → 0.7.7.

⚙️ Instrument disclosure: my script reads labels.yml/labels-sweep.yml and printed NO-CALLER for ceremony, because this board's caller is self-labels-sweep.yml (uses: ./.github/workflows/labels-sweep.yml). Confirmed by hand at origin/main; the row above is the same local, tracks main entry as last time, not a new finding. Do not paste this table forward — it has now moved five times.

⛔ Still not the close condition. The trigger reads "the builder row has reached the boards"; one of thirteen is not that. This thread stays open.

---

Two corrections to my own last comment

1. post-merge is not a leftover, and I should not have offered it as a tidy-up. I wrote that this board "still carries a post-merge label object … a separate one-line act whenever it is convenient." #567's criterion B9 declined that deletion on purpose, and CHANGELOG.md:65 at main ships the wording: "Retired creation of the post-merge queue row while leaving existing consumer label objects in place." Retiring a queue state and deleting its label object were two decisions and the second was refused. Its absence from retired_label_names() is also intended — that registry is the six GitHub defaults (duplicate, invalid, question, wontfix, help wanted, good first issue), and a ceremony row does not belong in it. All nine 0.7.7/0.7.8 boards still carry the object, which is exactly what B9 protects.

2. The supporting fact under it was wrong: "no open or closed issue carries it" is false. Measured this pass on this board:

open   carrying post-merge: 0
closed carrying post-merge: 25   (#508, #510, #499, #482, #423, …)

The conclusion survives — TRIAGE.md's bar is "every label on every open issue stays true", and zero open issues carry it, so it lies to nobody. But the reason is different from the one I gave, and the act is not cheap: deleting the row would strip the label from 25 closed issues that really did pass through that queue state, rewriting their history to say they never did. I withdraw the suggestion rather than restating it.

---

One cross-link, because the same fact is load-bearing elsewhere

la-familia-incubator sitting at 0.7.8 unpressed is precisely the dated tripwire in discussion #617: the day that board takes its bootstrap=yes press — the same press la-familia-incubator#31's last criterion waits on — the builder row arrives and owner_class_decision starts deriving there. That thread is an open escalation to you and this measurement is one of its inputs, so the two are now measured together rather than separately.

⛔ No label moves anywhere, no issue is minted, and no attention is set. Repairing a board's own taxonomy is operator-owned and passes no mint door (#524); triage names the rows and the press and then stops.

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

[dan-claude-bot]

📎 Two additions to the press ask, both measured on ceremony's own board and neither previously disclosed

@danmt No new question, nothing is minted, and no timer runs on you. This thread stays open — one of thirteen is still not "the boards". I am not re-pasting the 2026-09-07 census; that table says not to paste it forward and I did not re-measure the fleet. Only this board was re-measured, 2026-09-09, and it turned up two things the ask has been missing.

1. Ceremony's press is a three-row fix, not two — the third has never been named

The tables in this thread measure presence, so they see the two missing rows and are blind to a third defect the same press repairs. Diffing core_label_rows() at origin/main against /repos/heavy-duty/ceremony/labels?per_page=100 on name, colour and description:

row	state	what the press writes
operator	missing	creates it, A371F7
builder	missing	creates it, BFDADC
ready	description drift	updates it

ready on this board still reads "Triaged, spec complete, unblocked — a builder can start now and succeed". The registry ships "Triaged, spec complete, unblocked; its owner can start now and succeed" — #491's widening, the one that made room for an operator-owned issue to read ready without lying. So the board is currently publishing the pre-#491 semantics of the exact label this thread's design depends on.

It repairs itself in the same press and costs nothing extra: bootstrap_labels upserts every row with gh label create --force, so a drifted description is rewritten by the same call that creates a missing row.

The rest is clean, and the bound is worth having: the other 18 core rows are byte-identical on all three fields, all four scope:* rows from .github/labels.conf are byte-identical, there is zero colour drift anywhere, and none of the six retired GitHub defaults is present, so the delete loop is a no-op. One press, exactly three row-writes, nothing else moves.

2. ⚠️ The command named to you for this board in #541's close-out cannot run

#541's 2026-08-29T00:05:03Z close-out named the ceremony press as:

gh workflow run labels-sweep.yml --repo heavy-duty/ceremony -f bootstrap=yes

At origin/main, .github/workflows/labels-sweep.yml on this board declares workflow_call and nothing else — it is the reusable, not a caller — so gh workflow run refuses it for want of a workflow_dispatch trigger, and bootstrap is not one of its workflow_call inputs either. That command has been the standing ask for this board for eleven days and would have failed at the prompt.

The verified press for ceremony is its own caller, dispatched bare:

gh workflow run self-labels-sweep.yml --repo heavy-duty/ceremony --ref main

self-labels-sweep.yml declares workflow_dispatch with bootstrap as a choice defaulting to "yes", and the reusable's bootstrap job gates on github.event_name == 'workflow_dispatch' && github.event.inputs.bootstrap != 'no' — so the bare dispatch bootstraps. -f bootstrap=yes is equivalent and harmless. This is ceremony-only; consumer boards call labels-sweep.yml from their own caller and their presses are unaffected.

Evidence, not a report: the run's conclusion is success and its job list contains sweep / bootstrap not skipped — a green run whose bootstrap job is skipped installed nothing, which is the false pass already on record at box run 33206974177. Then gh api /repos/heavy-duty/ceremony/labels/operator and /labels/builder answer 200, and ready's description matches the registry.

Why this surfaced now, which is the reusable part

My own board census on #568 yesterday listed operator among "the repo's 28 labels" with zero carriers and concluded "no label on the board lies". Both halves were wrong from one cause: gh issue list --label operator returns 0 for a label nobody carries and 0 for a label that does not exist, with no error. Measuring a roster by carrier count cannot see an absent row. That comment is corrected in place and the authoritative version is here.

⛔ No label moves, nothing is minted, no attention is set, and I have not attempted the dispatch — it is the operator's act under #524 and this actor holds no admin here. The 403 on record is from 2026-08-27 and is cited rather than re-run.

— triage, heavy-duty/ceremony, 2026-09-09. This board only; no other board's pin or label set is asserted in this comment.