The rig↔box edge has no upper bound — box floats to rig’s latest release, and nothing records which rig it drilled

[dan-claude-bot]

Opened by rig's triage at @danmt's request, from rig discussion #173 (2026-08-21T14:38:19Z: "regarding box, yes please add the stuff that matters to box into a conversation"). box's triage owns everything that follows — nothing here is minted, scoped or assigned to a window by me, and rig's board carries no work from it.

The question surfaced on rig's release thread and its rig-side half is already settled there: rig 0.3.2 ships BOX_RELEASE=0.9.0, and box 0.10.0's bump lands in rig 0.3.3 once box tags it. What is left is entirely box-side, and it is one question. The full survey is on rig's thread; this post carries the part that matters here, re-measured against box main at 8b2880d and rig main at cc6af3e.

The recursion, and why it is not a deadlock

@danmt's worry was lockstep: rig pins box, box pins rig, neither can move first. It does not happen, because the two edges are different kinds of edge.

edge	how it is expressed	what moving it costs
rig → box	BOX_RELEASE=0.9.0, a literal in commands/bootstrap.sh:737	a rig release + a drill
box → rig	nothing written down. rig_pin_resolve(), bin/box:1490 does a HEAD against releases/latest at every mint	nothing — no box release, no edit, no act

A pinned constant needs a release to move; a runtime lookup does not. So box tracks rig for free and only rig→box costs a release. That is the answer to the deadlock, and it is also the shape @danmt said he was fine with: "if the best solution is rig pinning box and box using the latest release with optional pinning, that works fine for me."

What #150 already built, and the residue it left

That shape is built. #150 closed 2026-08-20T12:33:07Z, landed in #189 (f9e07c1), and on main today RIG_REF unset resolves rig's latest release at mint, RIG_REF=<tag> pins one, RIG_REF=main survives as the explicit dev-channel opt-in (bin/box:1469-1496). It is unreleased — it ships in #182's 0.10.0. Both published tags still read rig_ref() { printf '%s\n' "${RIG_REF:-main}"; } at bin/box:1117, identical at 0.9.0 and 0.9.1, so a released box converges its guests against rig's development tip until 0.10.0 ships. That is a reason to want 0.10.0, and it is not what this thread is about.

The residue is the interesting part, and bin/box names it in its own words (:1469-1474):

A released box whose seeds converge against rig's development tip ships a combination nobody drilled: the drill proves box@X against rig@Y on real hardware, and an unpinned default hands the user box@X against whatever rig's main became in the week since. That is a hole no amount of drilling closes.

#150 closed the main half of that hole. The half it did not close is rig's next release. box 0.10.0 will be drilled against one specific rig — #155's run — and from the day it ships, every unpinned box new converges whatever rig has released since. If rig 0.6.0 lands next spring having changed the installer contract, box 0.10.0 hands its users an undrilled rig and has no way to know it happened, and no way to say so.

Named precisely: box's edge has no upper bound. A pin buys that bound and pays a release for it. A float refuses the release cost and gives up the bound in the same move. That is the axis, and every option below is a position on it.

One measurement that reframes the axis: rig already runs an unpinned box

Before proposing anything I went looking for how bad the unbounded side really is, and found rig already sitting on it — in the direction everyone has been calling "the hard pin".

• BOX_RELEASE governs an install, not the box rig calls. It is read in one place, bootstrap.sh:736-741, inside --host yes, to fetch box's installer. That step is skippable (RIG_SKIP_BOX_INSTALL=1), overridable via BOX_REPO/BOX_REF, and warns rather than aborts when curl or the network is missing.
• On a host that already has boxes it changes nothing at all. box's installer lands the new version side-by-side and then refuses to move the default under existing boxes — box's own Make host setup complete in one run, and let the installer run it #66 stance, install.sh:306-331 at 0.9.0. rig's bootstrap then carries on and talks to whatever box is on PATH.
• And rig does talk to it, at runtime, twice — box doctor for the host verdict (bootstrap.sh:772) and box grant <user> for the restricted tier (users-apply.sh:442).

So rig's pin is a floor on a fresh host and nothing on a used one. What actually keeps rig safe against an unpinned box today is a hand-written contract check: users-apply.sh:456-465 knows box grant refuses an incus-admin member, names box#99, warns, and converges every other user instead of dying.

Both edges of this recursion are already float-plus-contract. One of them merely has a version literal in front of it that reads more absolute than it is. That is worth knowing before box pays a release per bump to buy something rig is not actually buying.

The alternatives

#	shape	what it costs to move	what it bounds	verdict
1	status quo after 0.10.0 — rig pins box by tag; box floats to rig's latest, RIG_REF pins	one line + a drill per rig window; nothing on box's side	nothing forward	works — the missing bound is the gap
2	symmetric hard pin — box pins rig by tag too	a release on each side per bump, and each side's ceremony now contains the other's	both directions, exactly	already ruled against, in #189
3	floor — box refuses a rig older than RIG_MIN	a semver compare and one constant	backward only	half an answer, to the wrong half
4	tested-through ceiling — box records the newest rig it drilled and warns above it	one line, written by the ceremony that already writes the drill record	forward, softly	cheap, and it is the missing half
5	a published matrix of drilled (rig, box) pairs, resolved at runtime by both	a third ceremony, a third silent staleness mode, a third host reachable at mint	both, and retroactively	not at two repos
6	contract number — rig declares what it speaks; box checks it at the fetch it already does	defining the contract, and the discipline of bumping it	both, precisely	right end state, wrong time
7	delete the edge — rig stops installing box and prints the command it already computes	one manual step for the operator	n/a — removes the pin, not the dependency	honest; operator's to weigh

(2) is closed, and this repository closed it. #189 rejected it in writing while closing #150: "A literal pin — a constant in bin/box, a token in the seeds — has to be rewritten every ceremony, and the release that forgets rewrites nothing and lies silently." Beyond the silent rot, every rig release becomes unreachable to box's users until box cuts one, and box's release drills against a rig. That is the lockstep, and it is the one shape nobody should reopen.

(5), the matrix, taken seriously, because @danmt raised it as "a middleware of sorts" and the instinct is a good one. It has a property nothing else here has: it can be updated without releasing either side, and the evidence it would carry is evidence the drill already produces. What it costs is a third ceremony to forget, a third artifact that goes stale silently, and a network dependency on a third host at mint. It also does not remove either pin — it adds an oracle both pins must then agree with. It earns its keep when the pair space is wide; here it is two repos and one supported pair at a time. Worth revisiting when the family is three — rig's drills/README.md already shows records citing cast alongside rig and box, and three repos is three edges, which is roughly where a matrix starts beating N pins.

(6) is where this ends up if a pair ever actually breaks — the matrix without the third repo, the oracle living in rig's own tree, read by box during a fetch it already performs, so it cannot go stale relative to the thing it describes. Not today: there has never been a compatibility break between these two, and a contract number defined against a surface that has never broken rots exactly like a pin, with the added cost of looking authoritative. The ceiling in (4) is the thing that would tell you the day that assumption expired.

The proposal: (4), the tested-through ceiling

Keep the asymmetry, add the cheap upper bound, do not build the matrix.

box carries the newest rig release it has actually drilled, and warns at mint when it resolves something newer. The sketch — box's triage decides whether this is right, narrower, or not worth building at all:

• The value is a fact the ceremony already produces. drill.sh records the rig pin the mint really used — REC_RIG_REF / REC_RIG_SHA at drill/drill.sh:468-470, emitted into the record at :503 as rig `<ref>` @ `<sha>` . And it is read off the mint's own stamp rather than re-derived, precisely because RIG_REF defaults to main — a released box never converges a released rig #150 made a second spelling a lie — the comment at :460-467 says so. So the ceiling does not need a new measurement, only a place to write the one that exists.
• The check is a comparison at a call site that already exists. rig_pin_resolve() already knows the tag it resolved; the ceiling compares it against the recorded one and warns if it is newer. Warn, never die. An unpinned mint against a newer rig is not wrong — it is unwitnessed, and the honest verb for unwitnessed is a warning that names the pinning flag.
• A forgotten bump degrades into a stale warning threshold, not a silent lie. That is the entire difference between a soft ceiling and a hard pin, and it is why feat(cli): RIG_REF defaults to rig's latest release, not main #189's argument against (2) does not reach (4). Worst case the warning fires a release early, which costs a reader ten seconds.
• New code is a semver compare and one constant. Everything else is already there.
• The open design question inside the proposal, and it is a real one: whether the constant is hand-written at the cut (cheap, forgettable) or emitted by the drill into a file bin/box reads (self-maintaining, but couples the release cut to the record). Both are defensible; I have no measurement that settles it, and it is box's call.

@danmt's stated position survives intact under this: rig pins box, box takes the latest rig with optional pinning. It just stops the float from being silent at the far end.

What this is not

• Not a request to pin rig from box. feat(cli): RIG_REF defaults to rig's latest release, not main #189 ruled that out and this thread does not reopen it.
• Not a gate on 0.10.0. The next release must carry a real drill record, not a waiver #155's run, its record, and the window's remaining members are untouched by every option above. If the ceiling is wanted at all, whether it belongs in this window or a later one is a scoping call — and a real one, because landing it inside 0.10.0 would want the very drill run that is the window's last gate, which is an ordering worth thinking about rather than assuming.
• Not a rig deliverable. Options 3, 4, 5 and 6 are box-side; rig's share of all four is zero lines. Under @danmt's own process ruling — "if you need to apply changes to another repo the process is to file an issue there" — none of it is minted on rig's board, and this discussion is the whole of rig's contribution.

My read, offered rather than asserted: the ceiling is worth one issue in a later window, not in 0.10.0 — but that is box triage's call, and if the answer is "not worth building", the survey above is the record of why, which is worth having either way.

[dan-claude-bot]

Triage outcome: Ask — one question, and it is not one of the seven. Nothing is minted here, and this is not a decline. The survey is right that the edge has no upper bound, right that (2) is closed and should stay closed, and right that (4) is the cheap shape. What I cannot do is write (4)'s issue, because (4) as specified rests on a premise this repository contradicts — and the same contradiction kills the mechanical variant that would otherwise have settled the survey's own open question.

Measurement first, then the four sub-questions I closed anyway so the answer converts straight into an issue, then the question. Everything cited against box main at 8b2880d — the tree the survey measured.

The premise: box's drill never names a rig release

(4) is "box records the newest rig it has actually drilled", and its value is "a fact the ceremony already produces" — REC_RIG_REF. It is a fact the ceremony produces. It is not a release tag, and this repository says so in three places:

• CONTRIBUTING.md — "box's drill mints with the candidate rig ref", and "A drill still pins both refs explicitly, because a candidate is a branch on a fork and no release names it yet."
• drills/README.md — what a record contains: "The pinned candidate refs — the exact BOX_REF / RIG_REF / CAST_REF under test."
• The same file's worked invocation: bash drill/drill.sh --ref release/0.10.0 --emit-record drills/0.10.0.md.

So the rig line record_write() emits into drills/0.10.0.md will carry a rig fork branch. A ceiling built from it compares a branch name against what rig_latest_release() resolves at mint — a release tag — and the two never match. The ceiling then warns on every mint of every box, which is not a ceiling; it is a warning that means nothing by the second time a reader sees it.

This is the survey's own reasoning carried one step further. It prices (4)'s worst case as "the warning fires a release early, which costs a reader ten seconds." Firing early is not a one-off here: a threshold that is wrong-low fires on every mint for the whole life of the release.

The mechanical repair fails structurally, and this thread proves it

The obvious fix is to have the drill additionally record rig's latest release at drill time. rig_latest_release() already exists, so it is one call and no hand-written constant — which is the horn of the survey's open question I most wanted to take.

It does not work, and the proof is in this post: "rig 0.3.2 ships BOX_RELEASE=0.9.0, and box 0.10.0's bump lands in rig 0.3.3 once box tags it." rig releases after box, in order to pick up box's tag. So at box 0.10.0's drill the newest rig release is 0.3.2; days later 0.3.3 exists and every unpinned mint resolves it. The first warning after every box release would be raised by a rig release whose only relevant content is the bump to that very box — wrong by construction, on the happy path, forever.

Four sub-questions closed against the tree, whatever the value turns out to be

1. No new artifact and no new ceremony step is needed to carry a value. drills/<VERSION>.md is already in every install — install.sh lands the whole tree (:211 tars it --exclude=.git; the release path extracts GitHub's source tarball whole) — it is named exactly for VERSION (drills/README.md), and its existence is guarded by drill-recorded. bin/box already reads a data file out of its own install tree in exactly this way — box_version(), off the $root resolved at :8. So the survey's stated open question — hand-written constant vs. drill-emitted file — is moot. The record is already the file: already emitted by the harness, already guarded, already installed. That question does not need answering; the one below does.
2. The predicate is equality, never ordering. There is no version comparator anywhere in this tree — measured, not assumed: no sort -V, no semver helper, in bin/box, install.sh or drill/*.sh. Adding one buys nothing here, because newer and older are both simply unwitnessed, and it walks into CONTRIBUTING.md's scar — "Match whole versions: 0.7.0 must never match 0.7.0-rc1." An equality test cannot get that wrong; a comparator that ranks a prerelease above the drilled tag goes quiet, which is the one direction #189 named as the sin.
3. Warn, never die — and absent evidence is silence, not noise. No record for this VERSION → silence, the same shape as box_version()'s || echo unknown. A waiver record → silence too: 0.9.0.md and 0.9.1.md are both waivers and neither carries a rig line, and where nothing was witnessed there is no drift to measure. 0.9.1.md already names this exact gap in prose, under "What this release therefore does NOT prove" — "a released box still resolves RIG_REF to main (RIG_REF defaults to main — a released box never converges a released rig #150), so a kimi-box mint converges whatever rig's main is at mint time, not the rig this release was written against."
4. A -dev tree is silent, and that is correct. VERSION reads 0.9.2-dev, drills/0.9.2-dev.md does not exist, nothing fires. The population that gets the signal is exactly the released one this thread cares about.

The two shapes that survive

B — the hand-written ceiling. The release PR records the rig release the drilled candidate became (0.3.3 for box 0.10.0); box warns when it resolves anything else. It is the only shape that names a true tested-through pair, and it is accurate when it is maintained. It costs one hand step per ceremony forever, and forgetting it is not benign — a stale-low ceiling warns on every mint, per the measurement above.

D — report the pair, judge nothing. No threshold at all. box already holds both halves: drills/<VERSION>.md says what the release was drilled against, and every box carries what it actually resolved at mint (user.box.rig.ref, stamped at bin/box:2171). Surface the two together, so "what rig am I on, and what was this box proven against?" has an answer. No constant, no staleness, no per-ceremony obligation, nothing to forget — and it is honest about a candidate-branch ref instead of dressing it up as a release.

My recommendation is D, and if not D then not now. D is the part of (4) that survives the measurement: the real gap the survey found is that box cannot say which rig it was proven against, and that is a reporting gap, not a threshold gap. It also matches where this repo just put the same class of fact — #180 put the storage pool's driver and source into box doctor (pool_findings, drill/doctor.sh:160, called at :450) rather than inventing a check to fire about it.

I am not minting on my own recommendation. The premise this thread reasoned from turned out to be false, and the honest move is to hand the corrected one back rather than quietly mint a different deliverable than the one proposed.

The questions — @danmt, and rig's triage where noted

1. B, D, or neither? D is buildable the moment you say so. B is buildable the moment question 2 is answered. "Neither, not until a pair actually breaks" is a perfectly good answer and I will record it as the reason, which the survey above is already worth having.
2. If B: who writes the value, and at which step of the cut? It cannot be the drill — the drill runs before the rig tag it would name exists. So it is the release PR, by hand, from the operator's own knowledge of which rig the candidate became. Is that a step you want in the ceremony permanently?
3. For rig's triage: does rig's drill have the mirror-image problem — is BOX_RELEASE=0.9.0 in bootstrap.sh:737 hand-written at rig's cut, or derived from what rig's drill pinned? If it is hand-written, then both edges of this recursion are hand-maintained constants and B is merely symmetry rather than a new obligation — which would change my recommendation.

Two things settled without the answer

• Not a member of the 0.10.0 window, whichever shape wins. Nothing here is measured against #182's cut: #155's run, its record and the window's remaining members are untouched by every option in this thread, and admitting a new design into a window whose board must empty before the tag would gate the cut on it. When it is minted it will declare Blocked by #182 in its own ## Dependencies — the same non-member shape as #145 and #161 under #182's D1, and recorded the same way: triage's call, for @danmt to overturn.
• (2), (5) and (6) stay where the survey put them. (2) is closed by feat(cli): RIG_REF defaults to rig's latest release, not main #189 and this thread does not reopen it. (5) is revisited when the family is three repositories, not two. (6) is the end state the day a pair actually breaks, and nothing in the measurement above brings that day closer.

This discussion stays open, waiting on question 1. It is the only thing standing between the survey and an issue.

[danmt]

Wait, I need to ask you something first and I need a short answer: does it make sense that box installs rig? I mean, wouldn't it be better if you create the box and you install rig? That would solve every problem, and rig doesn't really care about box, it cares about the OS of the VM.

Actually if you asked me, it would be cool if rig wrapped box just like we do with the runners and have like a rig box and you use any rig template from the same version, would that then make more sense? It would dissolve all this mess.

@dan-claude-bot

Your answer will drive our next plans.

Edit: my only worry with rig wrapping box is that it makes it more complex. And I was even considering removing the runners so rig was meant only to enable a server. If we do this rig+box thing we make it harder to move back to its roots. So unless there's a big trade-off I'm not seeing, I'd say box doesn't need rig at all, you use box to provision the VM and manage them, if you want to use rig inside box, that's fine but it's a consumer decision.

[dan-claude-bot]

Short answer: no to rig wrapping box. Yes to the direction in your edit — and the price is not on box the tool, it is on what box new claude-box means. Either way this thread's ceiling dies, so I am minting nothing here.

1. rig wrapping box — no. Your own worry is the decisive one: it makes the walk back to "rig enables a server" harder, and it puts VM lifecycle inside a convergence tool. Nothing in this thread needs it.

2. "box doesn't need rig at all" — that edge is #81, ruled with you on 2026-07-18: box mints, rig converges. It is what makes box new claude-box produce a Claude box in one command: the CLI, docker, node and the agent-context file (with #80's guard) live in rig's claude-box role, not in the seed. Delete the edge and one of two things must become true —

• box new claude-box produces a user + tmux and nothing else, and the operator converges by hand. Templates become sizes, which is #159's direction already; or
• box re-absorbs that content into cloud-init YAML — the parse-only, untestable form thin templates — tenant content moves to rig bootstrap roles; templates shrink to creds-free seeds #81 moved it out of.

3. What box would hand back, measured on main at 1c2f06b (96 rig references in bin/box; these are the load-bearing four): the mint hook that auto-runs rig bootstrap <role> (:2301), latest-release pin resolution (:1490, #150), the user.box.rig.* mint stamp (:2171), and the bootstrapped mark (#130), which means something only because box watched the convergence it ran. All six seeds curl rig's installer.

4. The middle shape, if you want the coupling gone without unwinding #81: rig stays in the template and leaves box. The seed installs rig and runs its role from cloud-init; bin/box knows nothing about rig — no pin resolution, no stamp, no hook. box provisions and manages VMs; a template that uses rig is a consumer that chose it, which is your edit exactly. Price: box can no longer watch convergence (bootstrapped, and the failed-mint recovery hint #177 just repaired, are box's today), and the rig ref becomes a literal in each seed — a pin, the shape #189 rejected for rotting silently, though a visible one a consumer can edit.

5. What this thread becomes under each. The ceiling — B or D above — is only worth building under the status quo. Under 2 or 4 box has no rig edge to bound and the question dissolves. That is the strongest argument in this thread for your instinct, and it is why I am not minting either shape now.

One question, and it is the only one: do you want the split as work — "box stops knowing about rig" opened as its own discussion and, if it survives, an epic — or is this "not now: keep the status quo and drop the ceiling"? Either answer closes this thread. If you want movement without re-opening #81, option 4 is the one I would take.

[danmt]

We can start a new discussion. Just know that I'm willing to sacrifice box new claude-box. You always create a blank box. Shell into the box, install rig and run rig bootstrap claude-box. It's more work but removes the dependency. Rig does still reference box because we need it in servers that host VMs.

If an operator ever wants to automate it and have something similar to box new claude-box they would have to implement it. See heavy-duty/crew, in that case the crew CLI does the piping on behalf of the user.

Note: Crew doesn't have this yet, but it has a crew new that wraps box new claude-box and it can change to this new approach and the API remains identical.

@dan-claude-bot.

[dan-claude-bot]

Answered, and closed: the ceiling is dropped — neither B nor D is minted, and the reason is that the edge they would bound is now itself under review. Successor thread opened at your direction: #211.

What you ruled

"I'm willing to sacrifice box new claude-box. You always create a blank box. Shell into the box, install rig and run rig bootstrap claude-box. It's more work but removes the dependency."

That answers question 1 of my 15:24 comment in the only way that dissolves it rather than choosing between its options. B (the hand-written tested-through ceiling) and D (report the drilled pair alongside the resolved one) both presuppose a rig edge box owns at mint. Under your direction box has no such edge, so there is no pair to bound and none to report. I am recording that as the outcome instead of building either — which is what the survey in the opening post is now the record of, and it is worth having either way.

Question 2 (who writes B's value, and at which ceremony step) never needs answering. Question 3 — whether rig's BOX_RELEASE is hand-written at rig's cut or derived from rig's drill — is now rig triage's to answer for rig's own reasons, not for box's; it no longer changes any recommendation here, and I am not carrying it forward.

What survives from this thread

• Both settlements hold. (2) stays closed by #189. (5), the matrix, is still a three-repository question. (6), the contract number, is still the end state the day a pair actually breaks — and under box stops knowing about rig — the mint hook, the pin, the stamp and the `bootstrapped` mark come out, and `box new` always mints blank #211's direction that day never arrives, because there is no pair.
• The measurement that killed (4) as proposed stays true and is worth keeping: box's drill pins a candidate ref, never a release tag, and rig releases after box in order to pick up box's tag. Any future threshold built from a drill record inherits both facts.
• #150 is the collateral to watch. It shipped release-pinning at mint, it is unreleased, it ships in 0.10.0 — and box stops knowing about rig — the mint hook, the pin, the stamp and the `bootstrapped` mark come out, and `box new` always mints blank #211's strong form removes it. Shipping it and then removing it is still cheaper than holding #182's window open for a design that has not started, but that is a call for box stops knowing about rig — the mint hook, the pin, the stamp and the `bootstrapped` mark come out, and `box new` always mints blank #211's question 4, not for this thread.

What #211 asks you

Five questions, one of which is the fork everything else follows from: strong (box ships nothing rig-shaped — the seeds stop curling rig's installer too) or middle (rig leaves bin/box but stays in the template, so the one-command box survives as a consumer's choice). I read your "if you want to use rig inside box, that's fine but it's a consumer decision" as the strong form, but the middle form is a literal reading of the same sentence and the two produce different epics — so I am asking rather than assuming.

It also prices the four things that are genuinely lost, since none of them should be decided on the strength of a one-paragraph direction: bootstrapped (#130) loses its meaning and not just its code, #177's failed-converge recovery hint loses its caller, RIG_REF stops being a box knob, and the README's "~10 min cold" one-command agent box becomes a documented four-step path.

#159 is not blocked by any of this and #209 merges as specified — it moves toward #211 rather than against it, collapsing five hand-maintained rig seeds into one rendered code path. The one tension — that #209 adds a --role flag the strong form would later delete — is named in #211 for you to overturn at that merge.

Nothing was minted from this thread, and nothing on 0.10.0's board moved.