Ruling needed: create heavy-duty/rig-templates and accept a main-tracked repo that runs as root at every mint — or don't split? (#110, blocked since 2026-07-22)

[dan-claude-bot]

Escalated from #110 by triage, which stays blocked. Everything on rig's side of that issue is specified and needs no further decisions — the tasks, the acceptance criteria and the sequencing were re-verified on 2026-07-23. It is blocked on one thing only: a decision plus an action that belong to @danmt, and triage will not soften that into a partial issue to get something moving.

This is being raised here rather than left in a comment because rig's Discussions were enabled on 2026-07-23 — the day after #110 was normalized. The escalation has been sitting on a blocked issue with no door to a human since 2026-07-22. That is the gap this thread closes.

The decision

Does heavy-duty/rig-templates get created — and if so, is it main-tracked, knowing that every merged PR in it then executes as root inside every future mint?

Verified 2026-07-24: heavy-duty/rig-templates does not exist. Task one of #110 is "Operator: create it, ceremony-governed", and every other task and acceptance criterion reads from that repo. A builder who claimed #110 today would get as far as the parser and stop.

What is actually waiting

The per-tenant knowledge that would move lives in one file at commands/bootstrap-tenant.sh (456 lines): four CLI-install arms — claude, codex, grok, kimi — plus their matching rc-PATH arms. Nothing is broken today: kimi-box shipped through exactly this shape (#109 / heavy-duty/box#158, both merged 2026-07-22). The interim path works. This is a cadence and posture decision, not a defect, which is why it can wait for a human and why it should not wait indefinitely.

The premise that moves — and why this is ripe now

#110 argues the main-tracked default is acceptable because of three facts together, the first being that it narrows today's surface, where all of rig is already main-tracked-as-root. That premise is true right now and has an expiry date on it: heavy-duty/box#150 (open) proposes defaulting RIG_REF to the latest released rig tag instead of main.

Both halves of #110's reasoning turn on that one issue, in opposite directions:

• box#150 landing is what makes the split necessary rather than merely tidy — once mints converge a released rig, a new agent tenant cannot reach a box without a rig release. Two cadences conflated, which is Role templates move out of rig's tree (heavy-duty/rig-templates) — pinned to the rig version by default, overridable per mint #110's whole thesis.
• box#150 landing is also what invalidates the security argument's first fact — rig stops being main-tracked-as-root, and rig-templates becomes the only main-tracked-as-root surface in the org. A widening, not a narrowing.

#110's own escape clause is written for exactly this: "If any of those three weakens, the default flips to a pinned RIG_TEMPLATES_REF" — and its triage block says that flip "should be decided before the migration, not after." Condition one is what box#150 weakens. So the ruling is ripe now, ahead of the migration, as designed.

Options

	Root-exec surface	Cadence after box#150	Migration cost
A — create it, main-tracked (as #110 specs)	one small, single-purpose, human-merged repo, main-tracked	decoupled — a tenant change ships without a rig release	paid once
B — create it, pinned by default	narrow — only a reviewed pin bump executes	not decoupled — the default lives in rig's tree, so bumping the pin needs a rig PR, and under box#150 a rig release to reach mints	paid once, buys tidiness only
C — don't split; close #110	unchanged	unchanged — adding a tenant is a rig release	none

B is the trap. It looks like the safe middle and it is not: it pays the whole migration cost and, once box#150 lands, delivers none of the cadence benefit the migration exists for — unless the pin becomes a mint-time knob box passes through, which is a cross-repo dependency #110 does not carry and would need its own design.

Note that A already pins where evidence is owed: drills record the rig-templates SHA they converged alongside BOX_REF/RIG_REF. The question is only what the default at mint is.

Recommendation

A, or C — and the honest version of A states the trade as an acceptance, not a narrowing.

Take A if you are willing to hold, standing: one main-tracked repo whose merged PRs execute as root at every mint is acceptable because it is small, single-purpose, ceremony-governed with a human merge as the gate, and its install.sh-class diffs are treated as the highest-trust review surface in the org. Post-box#150 that is a deliberate acceptance of a new root-exec surface, not a reduction of an existing one — #110's bold paragraph should be amended to say so before anyone builds against it.

If that standing acceptance is not something you want to give, take C and close #110 with the reason. Adding an agent tenant then costs a rig release, which is a real but bounded price, and it is more honest than paying a migration for tidiness.

What triage does with each answer

• A → amend Role templates move out of rig's tree (heavy-duty/rig-templates) — pinned to the rig version by default, overridable per mint #110's security paragraph to the post-box#150 framing, flip it to ready once the repo exists and is seeded, and mint nothing else.
• B → Role templates move out of rig's tree (heavy-duty/rig-templates) — pinned to the rig version by default, overridable per mint #110 goes back to outcome 2: the mint-time pin knob is an open design question and needs box's side settled before an issue can carry it.
• C → close Role templates move out of rig's tree (heavy-duty/rig-templates) — pinned to the rig version by default, overridable per mint #110 with the reasoning, and record the cadence cost on box#150 so the trade is visible from the issue that creates it.

Decider: @danmt. Whichever way it goes, the answer belongs in #110's body — this is the second design in three days whose blocker was a posture question rather than a technical one, and the next reader should not have to re-derive it.

Refs: #110 (origin, blocked), heavy-duty/box#150 (open — the pin that moves both premises), #109 / heavy-duty/box#158 (the interim path, merged), heavy-duty/box#159 (roles at runtime; independent, not a blocker), #76 (the -box/-server family suffixes the flat layout assumes).

[dan-claude-bot]

The canonical block, which the escalation above was missing. The analysis
stands as written; these five lines are the contract
(heavy-duty/ceremony@main BUILDER.md → “The ruling ask”'s
five fixed field labels), and the Default: line is the part that matters most here — it
says out loud that nothing will happen without you.

🧭 needs-ruling — create heavy-duty/rig-templates, and if so, is it main-tracked at every mint?
Options:  A — create it, main-tracked (as #110 specs)   B — create it, pinned by default   C — don't split; close #110
Recommend: A or C. A only with the trade stated as an acceptance — post-box#150 it is a NEW main-tracked root-exec surface, not a narrowing of one. C if that standing acceptance is not one you want to give; adding a tenant then costs a rig release, which is bounded and honest. B is the trap: it pays the whole migration and, once box#150 lands, buys none of the cadence benefit the migration exists for.
Blocked:  #110, entirely — every task and acceptance criterion reads from a repo that does not exist. Nothing else stops: #109 / box#158 already shipped the interim path, kimi-box was minted through it, and adding a tenant works today by editing commands/bootstrap-tenant.sh.
Default:  none — hard block. Creating an org repo is an operator act and an org-policy decision, both hard blocks by construction; a bot holding `triage` cannot create a repository, and no partial issue will be minted to look busy.

Ripeness, restated in one line so the block is self-contained:
heavy-duty/box#150 is open and
moves both halves of #110's reasoning in opposite directions, and #110's own
escape clause says the flip "should be decided before the migration, not
after". So this is due now, ahead of the work, by that issue's own rule.

Ladder note: the clock runs from this comment, not from a labeled event —
rig has no needs-ruling label to anchor one. The row post-dates the
0.1.0 pin every consumer runs, so it exists only in ceremony; that gap is
ceremony#102, with the
machinery fix minted at ceremony#105.
It changes nothing here in practice: a hard block does not fire on any rung, so
#110 stays blocked until you rule.

---

Correction, 2026-07-24: this comment first cited rig's vendored .ceremony/BUILDER.md for the block. It is not there. The five-line ruling ask lives in ceremony@main BUILDER.md, and ceremony's only tag is 0.1.0 — which is what rig vendors, and which predates it. So the template is the same pin gap this comment already names for the needs-ruling label, not a separate one: rig has neither the label nor the doctrine that defines it, and both arrive together at the next pin bump (ceremony#102 / ceremony#105). The block above is unchanged and still binds triage — only the citation was wrong. Fixed in place rather than in a third comment, so a decider reads two comments and not four.

[dan-claude-bot]

12-hour re-read of the ladder — and not a routine one: the repo now exists.

heavy-duty/rig-templates was created 2026-07-24T12:15:06Z by Daniel Marin, eleven and a half hours after the block above said it did not. That is task one's operator act, and it moves the question rather than answering it. Read live at 12:45Z, not cited:

fact	value
created / pushed	2026-07-24T12:15:06Z / 12:15:08Z
visibility	private
default branch	main
contents	one README.md, one commit (Initial commit), no description

What it discharges: half of one checkbox

The repo exists. It is not ceremony-governed — no .ceremony/ mirror, no labels workflow, no review panel, no CONTRIBUTING.md — and it is not seeded with claude-box / codex-box / grok-box / kimi-box. Neither is a triage act. Neither is a builder act either, while the posture below is unsettled: a builder seeding it would be choosing the answer.

And creating a repo is not the same as accepting the trade #110 states in bold. I am not reading it as one.

What it opens, and this is what has to be settled before #110 can be built

It is private, and #110's design cannot fetch a private repo.

• Role templates move out of rig's tree (heavy-duty/rig-templates) — pinned to the rig version by default, overridable per mint #110 resolves the registry by tarball fetch at bootstrap time, the same shape as the rig preinstall — RIG_TEMPLATES_REPO/RIG_TEMPLATES_REF, defaulting to heavy-duty/rig-templates@main.
• That path is unauthenticated by construction. install.sh L101 says so in as many words — "no API, no token" — and L218 is a bare curl -fsSL "$URL". One layer up, bootstrap-tenant.sh L11-15 is creds-free by contract: box auto-runs it at mint, non-interactive, holding nothing.
• heavy-duty/rig and heavy-duty/box are public. heavy-duty/rig-templates is not. An unauthenticated tarball fetch of a private repo is a 404 at every mint.

So acceptance criterion 1 — "a template added to rig-templates main is mintable by an already-installed rig with zero changes in rig or box" — is unreachable as specified while the repo is private. That criterion is not decoration; it is the one that says whether the split bought anything.

I am deliberately not offering "keep it private, pass a credential at mint" as a fourth option. It retracts a contract that box's entire unattended mint path stands on, to save a visibility toggle. If you want it anyway, say so and I will spec it — but it does not go on the menu as a peer of the other three.

The ruling, re-cut

The block below supersedes the one above. The creation half is answered by your act; the posture half was never answered and now has visibility attached to it.

🧭 needs-ruling — rig-templates exists and is private; #110 fetches it unauthenticated at every mint
Options:  A — make it public, main-tracked (exactly what #110 specs, trade and all)   B — make it public, pinned by default (RIG_TEMPLATES_REF defaults to a tag, not main)   C — it stays private; #110 is retracted and closed, and adding a tenant keeps costing a rig release
Recommend: A, and only with the trade accepted out loud: post-box#150 this is a NEW main-tracked root-exec surface, not a narrowing of one — every merged PR in that repo runs as root inside every future mint, gated by the review panel and your merge. C is the honest alternative if that standing acceptance is not one you want to give; it is bounded and it costs a release per tenant. B remains the trap it was: it pays the whole migration and, once box#150 lands, buys none of the cadence benefit the migration exists for.
Blocked:  #110, still entirely — every task and acceptance criterion reads from that repo, and now the fetch path reads from its visibility too. Nothing else stops: #109 / box#158 shipped the interim path, kimi-box was minted through it, and adding a tenant works today by editing commands/bootstrap-tenant.sh.
Default:  none — hard block. Flipping an org repo's visibility is an operator act and an org-policy decision, both hard blocks by construction. dan-claude-bot holds `triage` on rig and nothing at all on rig-templates. No default can fire here, on this rung or any later one.

Two things unchanged by any of it

Ripeness still holds. heavy-duty/box#150 is open, untouched since 2026-07-21. It still moves both halves of #110's reasoning in opposite directions, and #110's own escape clause still says the pinned-vs-main flip "should be decided before the migration, not after". Due now, ahead of the work, by that issue's own rule.

#110 stays blocked, and rig still has no needs-ruling label to show it on the board — ceremony#102, where the same act is waiting on you from the other end.

[dan-claude-bot]

Ruled — closing the loop on this ask. @danmt answered on #110 directly (2026-07-24 21:54Z); recorded here because this discussion is where the ask lived and where a future reader will look for the answer.

The ruling, verbatim:

• heavy-duty/rig-templates already exists.
• im fine with the security posture but i would not use main by default but pin it based on the rig version, so newer rig version matches newer rig-templates by default but you can change it.
• the builder behind this should be seeding the templates from what we have already

Mapped against the block above: the B shape — proceed with the split (not C), default pinned rather than main-tracked (not A) — with a better pin than the B this ask offered: coupled to the rig version via an in-tree pin (the BOX_RELEASE discipline, rig#103 / PR #122), not a static tag, so the cadence objection to B ("buys none of the benefit") is answered — a pin bump is a one-line rig PR, and RIG_TEMPLATES_REF stays the immediate per-mint path. Seeding is builder-owed, reversing the earlier hold that was only there because seeding would have pre-empted this ruling.

Triage has re-cut #110 to match (the re-cut comment lists every body edit): needs-ruling removed, spec re-cut in place, title no longer promises main-tracking.

@danmt — one act of yours remains before #110 is buildable: flip heavy-duty/rig-templates to public. Re-verified private just before this write. The pinned default changes when a merged template becomes the default, not how it is fetched — the mint-time fetch is an unauthenticated tarball by contract (box runs bootstrap-tenant.sh non-interactive, holding nothing), so a private repo is a 404 at every mint and your third bullet (builder seeds) can't start. The moment it is public, triage flips #110 to ready — no further decisions are owed by anyone. (Ceremony governance for the repo — labels, review panel — is still worth doing per the accepted posture, but it does not gate the flip to ready.)

[dan-claude-bot]

The one remaining act landed — this ask is fully discharged.

@danmt flipped heavy-duty/rig-templates public at 2026-07-24T22:09:47Z (confirmed on #110). Verified live: an unauthenticated tarball fetch of main — the exact mint-time path whose 404 was the block — returns 200.

#110 is re-cut to ready (the flip comment lists every edit): ruling executed, visibility gate cleared, everything remaining builder-owed. Nothing further is asked of anyone here — this discussion answered its question end to end (ask 00:27Z → ruling 21:54Z → gate cleared 22:09Z) and can be closed whenever @danmt likes; the record it holds is linked from the issue body.

[dan-claude-bot]

Closing as resolved. The ask is discharged end to end — block posted 00:51Z, ruling from @danmt 21:54Z, repo public 22:09Z, #110 re-cut to ready 22:13Z. The record stays here and is linked from the issue body; nothing further is owed by anyone on this thread.