heavy-duty/box

Fork 1

feat: a minted box records how it was minted, and box info reads it back #129

Merged

dan-claude-bot merged 3 commits from feat/mint-stamp into main

2026-07-21 11:24:40 +00:00

dan-claude-bot commented

2026-07-20 10:14:00 +00:00

(Migrated from github.com)

Closes #103.

cmd_new knows a great deal at the moment it launches, and wrote three keys:

--config user.box=1 --config user.box.template="$t" --config user.box.user="$T_USER"

Everything else in scope on that line was dropped on the floor. There is no host-side per-box store — the Incus instance config is the database — so a fact not written there is not "hard to find later", it is gone the moment the mint returns.

What the mint knew and dropped

dropped	why it is unrecoverable
the box version that minted it	`$root/VERSION` was read in exactly one place, `version()`, and never in the mint path. `box --version` is a fact about the binary in front of you, never about the box you are looking at
the base image	`$T_IMAGE` is `images:debian/13/cloud` — an unpinned alias on a moving remote. Two boxes minted a month apart from "the same template" are not the same box, and nothing on either said so
the rig role	`$T_BOOTSTRAP_ROLE` was handed to `rig bootstrap` and forgotten
rig repo and ref	`RIG_REPO`/`RIG_REF` were substituted into the seed. Which rig converged this box was unrecoverable
mint time	box wrote no timestamp anywhere except a snapshot label and an export filename
the mode demand	the instance type says VM or CT afterwards. Only the mint knew whether a container was asked for or fallen back into for want of `/dev/kvm`

The stamp extends user.box.* at that same single write point. The three existing keys are untouched — box_user() and the login hint read two of them, and the suite now pins that they still ride the same line.

`user.box.schema` — what it promises, and what it does not

An integer naming the stamp's shape, not the box version. It moves when a key is removed or repurposed, never when one is added: a reader that meets a key it does not know simply does not print it, so adding fields is not a breaking change and does not need a bump.

The forward-compatibility contract runs in both directions, and the backward one is the load-bearing half:

Absent schema means pre-stamp. Every box minted before this PR has no schema key, and there are real ones — a box outlives the release that minted it, which is exactly what the legacy user.claudebox tag already says out loud at resolve_box. Reads tolerate absence by construction: incus config get on an unset key prints empty and exits 0 (drill audit item B4), so "no stamp" and "the daemon said no" arrive identically and both must render as a box with blanks. A legacy box under box info prints MINTED (not recorded — this box predates the mint stamp), skips every line whose key it lacks, and exits 0. A pre-rename user.claudebox box still reads as the claude template, the same mapping box_user() makes. Three tests pin exactly this, including an absence assertion that no half-empty IMAGE/ORIGIN/RIG/MODE line is printed for a key that does not exist.
A schema from the future is not a broken box. An older box will one day read a newer box's stamp. It shows what it understands and adds a NOTE saying there is more — refusing to describe a box a later release minted perfectly well is the wrong answer. A non-integer lands on that same side rather than failing arithmetic under set -e.

The clone decision, argued

This was the sharpest question in the issue and I did not want it to default.

incus copy preserves every user.* key (audit item B2, drill/RUNS.md:26, drill/drill.sh:454-464) — which is precisely what makes a clone know its template and user for free, with no code. It is also exactly why the stamp cannot ride along untouched. An inherited stamp does not go stale, it goes false: the clone would carry a mint time it was not present for, a box version that never saw it, and origin=mint for a mint that happened to a different instance.

So the clone re-stamps, and the split is deliberate. Updated after review (@claude-bot-andresmgsl): the split was originally two columns and one key fell between them — see Cleared below.

Re-stamped — the keys that describe this instance's coming into being: schema, version, created, origin=clone, origin.from=<srcref>. The clone was made here, now, by this box.

Left alone — the lineage keys: template, user, image, image.fingerprint, role, rig.repo, rig.ref, mode. The clone's disk genuinely did come from that image, converged by that role, from that rig. Re-deriving them from the cloning process's own template lookup would be the actual lie — and would break the login hint, which reads user.box.template off the instance precisely so a clone of a claude box still gets it. (incus copy preserves the instance type too, so mode stays true without help.)

Cleared — mode.asked, the one key that belongs to neither column. It is a mint-event fact by this PR's own criterion (only the mint knew whether a container was asked for or fallen back into), but the asker was the source's operator — and a clone refuses --vm/--container outright, so nobody was asked anything about this instance. Inheriting it made box info on a clone print MODE vm (asked: auto), a demand never made of it, with nothing marking it ancestral. There is no true value to re-stamp it with, so the clone incus config unsets it (cleared, not set-to-empty — an empty value is still a key), alongside the re-stamp and before the start. The read side needs no special case: the MODE line is already gated on asked, so absence renders as silence, and TYPE still reports VM or CT off the preserved instance type.

Two consequences I am stating rather than leaving implicit:

Ancestry is one hop. origin.from names the immediate source. A clone of a clone names its parent and forgets its grandparent. The alternative is an unbounded chain inside a config value, and the parent is the box an operator can actually go look at.
It lands before the start. The incus config set runs on the copied instance before incus start, so a clone is never observable — not for a second, not by a concurrent box info — wearing its source's provenance. Line-order-asserted, fail-closed.

The issue also notes limits.* carry over stale on a clone (--cpu/--memory/--disk are refused for clones). That is the same class of problem and I did not fix it here: it is a real resources question, not a provenance one, and folding it in would smuggle a behaviour change into a stamp PR.

The image: alias and fingerprint

Recording the alias is what #103 asks for, and the alias alone is not a reproducible fact. Incus resolves it during the launch and records the result in volatile.base_image, so box reads it back and pins it in a second incus config set — IMAGE images:debian/13/cloud @ 8a2f1c9d4e5b… answers "was this box built on the image that broke?" where a template name cannot.

The issue's open question was whether that second call is worth one more failure point in the mint path's hottest section. It is not one, by construction: the call runs only after a launch that already succeeded, and every failure in it is silent. A box that exists and boots must never be failed over a provenance field — with no fingerprint to be had, the mint still succeeds and the alias stands alone as the honest partial answer, which is exactly how cmd_info renders it. Both halves are tested: the pin lands, and an unknowable fingerprint neither fails the mint nor stamps an empty key.

Mint time: a timestamp, said out loud

A timestamp in a convergent config file is churn — the same run writing a different byte every time. A mint is not convergent: it happens once, to one instance, and is never re-run against it. created is UTC ISO 8601 so it sorts as a string and means the same thing on every host that reads it back; the test pins the shape, so a local-time or epoch-seconds spelling fails here rather than on a host.

Deliberately not stamped

cpu / memory — limits.cpu and limits.memory already hold them. A duplicate drifts the first time someone edits a limit by hand.
disk — the issue offered "stamp it or accept the gap knowingly". I claim there is no gap to accept: a VM's disk is the root device size, and a container's does not exist at all (--disk is explicitly dropped with a note — the container root rides the pool). A stamped container disk would be fiction, which is worse than a missing key.
tier — box_tier() derives admin/restricted/none from live id -nG. It describes whoever is asking, not the box, and stamping it records who happened to mint and then rots.

All four are absence assertions in the suite, so a well-meant later addition has to argue here first.

What I deliberately left alone

cmd_import — an imported box keeps the artifact's mint stamp verbatim. cmd_import's own comment already draws the line: what incus import restores is the artifact's truth, what box re-stamps is this host's. Mint facts are the originating host's truth and should survive the trip; an origin=import overlay would overwrite origin and destroy whether the thing was a mint or a clone before it was exported. That is a real decision with a real trade-off, and I did not want to smuggle it into this PR. Filing it as follow-up if reviewers want the import event recorded — it wants its own key, not a repurposed one.
host/migrate-host.sh — it backfills user.box.template/user.box.user for pre-tag boxes and now backfills nothing new. Fabricating a created or a version for a box whose mint nobody witnessed is precisely the invented-fact failure this PR exists to avoid; leaving the keys absent is what makes box info say "not recorded", which is true.
box list columns — the issue floats a TEMPLATE/AGE column. list is width-constrained and the per-box answer is info's job.
user.box.disk, per above.

Surfacing it

A stamp nothing can read is not done. cmd_info printed NAME / STATE / TYPE / IPV4, exposures and snapshots, and surfaced none of the user.box.* keys — including the two that already existed. It now prints a provenance block in the existing printf '%-11s%s\n' style, above the snapshots:

NAME       work
STATE      RUNNING
TYPE       VM
IPV4       10.1.2.3

MINTED     2026-07-19T14:22:07Z by box 0.8.1
TEMPLATE   claude (user claude, role claude)
IMAGE      images:debian/13/cloud @ 8a2f1c9d4e5b…
MODE       vm (asked: auto)
RIG        heavy-duty/rig@main
ORIGIN     clone of work/authed

box info --json needed no code at all: it passes incus list --format json through, and the keys ride along in config.

One refactor, and why it is not optional

RIG_REPO/RIG_REF defaults now live in rig_repo()/rig_ref(), read by both render_userdata (which substitutes them into the seed) and the stamp (which records them). Two spellings of the same default would eventually disagree, and a stamp that disagrees with the seed it shipped alongside is worse than no stamp. The suite drives the override end to end — RIG_REF=probe-ref must appear in both the stamped key and the rendered seed on the same launch — and the extraction that drives render_userdata in isolation now fails loudly if the helpers move, rather than silently rendering an empty repo and passing against nothing.

VERSION likewise has one reader, box_version(), pinned by a test: box --version and the mint stamp must never disagree about what minted a box.

Also: a template whose seed carries no @RIG_REPO@ token (blank) is stamped no rig pin and no role. Naming a rig that was never installed would be fiction.

Tests

New section in test/cli.sh, driven against a fake incus that logs the arguments box builds — the only proof available with no daemon, since the argument list is the write. Both halves: write (mint, clone) and read (info). Every key gets its own check, because a single grep for the whole block goes green on a partial stamp and "which fact was dropped" is the useful failure.

Each new assertion was proven to bite by breaking the thing it pins and observing RED, then reverting:

broke	went red
dropped `--config user.box.schema=`	`mint: stamps the schema`
dropped `--config user.box.mode.asked=`	`mint: stamps the mode that was ASKED`
deleted the clone re-stamp entirely	5 clone checks, including the ordering one
added `user.box.template=` to the clone re-stamp	`clone: does NOT re-stamp the template` (the absence assertion)
removed the clone's `config unset user.box.mode.asked`	`clone: clears the inherited mode.asked` and the clear-precedes-start ordering check
made the clear a `config set …mode.asked=` instead	all 4 write-side `mode.asked` checks, incl. `clears it rather than setting it empty`
left `mode.asked` in the clone's canned config	`info: a clone prints no MODE line` (exit 0, wanted 1 — the exact `MODE vm (asked: auto)` bug)
made the legacy `MINTED` line `die` instead of degrade	3 legacy/pre-rename `info` checks
inverted the `RIG` line's emptiness guard	`info: surfaces which rig converged it` and the no-half-empty-lines absence check

Checks

bash test/cli.sh — 529 passed, 0 failed (was 493 before this PR's additions)
bash test/labels-reconcile.sh — 19 passed, 0 failed
bash test/release.sh — 90 passed, 0 failed
shellcheck -x over CI's exact globstar list (bin/* **/*.sh, 15 files) — clean
.github/scripts/changelog-armed.sh — passes
CHANGELOG.md was edited by insertion only — git diff -- CHANGELOG.md is 58 insertions(+), 0 deletions, and zero lines beginning -## (checked explicitly, per #122)

On real-Incus proof — what CI's rehearsal does and does not settle. I could not run a mint locally (the box this was written in has no daemon), so every assertion in test/cli.sh is against a fake incus and proves only the arguments box builds. CI's rehearsal job, however, runs drill/multiuser.sh on a real Incus, and it is green on this head. That job really does box new --name mine --template blank, box new --name c1 --from mine/s1, and box info mine — so the real daemon accepted every new --config user.box.* key on the launch line (schema, version, image, mode, mode.asked, created, origin), accepted the clone's multi-key incus config set, and box info rendered without erroring against live config.

What that still does not prove, stated plainly:

No assertion on the stamp's contents. The rehearsal checks that mint/clone/info succeed, not what they wrote. A key stamped with a wrong value would pass it.
The fingerprint pin-back is unproven end to end. If volatile.base_image were empty at the moment box reads it, the mint succeeds silently and identically — that is the design, and it is also why a green rehearsal cannot distinguish the two.
blank only. The rehearsal mints the one template with no rig seed, so the role and rig.repo/rig.ref stamps — and the "no rig token, no rig pin" branch's counterpart — have never run against a real daemon.

Those three want a release-drill run with a claude mint and an eyeball on box info.

Merge-order note: #104 touches the adjacent region

heavy-duty/box#104 (a pristine snapshot at mint) is in flight on feat/pristine-snapshot and lands in cmd_new near the rig bootstrap hook — the same function, a few lines from this PR's launch block and post-launch fingerprint pin. Both branch from origin/main and neither knows about the other, so whichever merges second should expect a textual conflict in cmd_new. No semantic interaction that I can see: this PR writes instance config, #104 takes a snapshot, and the two do not read each other's state.

Closes #103. `cmd_new` knows a great deal at the moment it launches, and wrote three keys: ```sh --config user.box=1 --config user.box.template="$t" --config user.box.user="$T_USER" ``` Everything else in scope on that line was dropped on the floor. There is no host-side per-box store — the Incus instance config **is** the database — so a fact not written there is not "hard to find later", it is gone the moment the mint returns. ## What the mint knew and dropped | dropped | why it is unrecoverable | |---|---| | the box version that minted it | `$root/VERSION` was read in exactly one place, `version()`, and never in the mint path. `box --version` is a fact about the binary in front of you, never about the box you are looking at | | the base image | `$T_IMAGE` is `images:debian/13/cloud` — an **unpinned alias on a moving remote**. Two boxes minted a month apart from "the same template" are not the same box, and nothing on either said so | | the rig role | `$T_BOOTSTRAP_ROLE` was handed to `rig bootstrap` and forgotten | | rig repo and ref | `RIG_REPO`/`RIG_REF` were substituted into the seed. Which rig converged this box was unrecoverable | | mint time | box wrote no timestamp anywhere except a snapshot label and an export filename | | the mode *demand* | the instance type says VM or CT afterwards. Only the mint knew whether a container was **asked for** or **fallen back into** for want of `/dev/kvm` | The stamp extends `user.box.*` at that same single write point. The three existing keys are untouched — `box_user()` and the login hint read two of them, and the suite now pins that they still ride the same line. ## `user.box.schema` — what it promises, and what it does not An integer naming the stamp's **shape**, not the box version. It moves when a key is **removed or repurposed**, never when one is added: a reader that meets a key it does not know simply does not print it, so adding fields is not a breaking change and does not need a bump. The forward-compatibility contract runs in both directions, and the backward one is the load-bearing half: - **Absent schema means pre-stamp.** Every box minted before this PR has no schema key, and there are real ones — a box outlives the release that minted it, which is exactly what the legacy `user.claudebox` tag already says out loud at `resolve_box`. Reads tolerate absence *by construction*: `incus config get` on an unset key prints empty and exits 0 (drill audit item B4), so "no stamp" and "the daemon said no" arrive identically and both must render as a box with blanks. A legacy box under `box info` prints `MINTED (not recorded — this box predates the mint stamp)`, skips every line whose key it lacks, and exits 0. A pre-rename `user.claudebox` box still reads as the claude template, the same mapping `box_user()` makes. Three tests pin exactly this, including an absence assertion that no half-empty `IMAGE`/`ORIGIN`/`RIG`/`MODE` line is printed for a key that does not exist. - **A schema from the future is not a broken box.** An older box will one day read a newer box's stamp. It shows what it understands and adds a `NOTE` saying there is more — refusing to describe a box a later release minted perfectly well is the wrong answer. A non-integer lands on that same side rather than failing arithmetic under `set -e`. ## The clone decision, argued This was the sharpest question in the issue and I did not want it to default. `incus copy` preserves every `user.*` key (audit item B2, `drill/RUNS.md:26`, `drill/drill.sh:454-464`) — which is precisely what makes a clone know its template and user for free, with no code. It is also exactly why the stamp **cannot** ride along untouched. An inherited stamp does not go *stale*, it goes **false**: the clone would carry a mint time it was not present for, a box version that never saw it, and `origin=mint` for a mint that happened to a different instance. So the clone re-stamps, and the split is deliberate. **Updated after review (@claude-bot-andresmgsl):** the split was originally two columns and one key fell between them — see **Cleared** below. **Re-stamped** — the keys that describe *this instance's coming into being*: `schema`, `version`, `created`, `origin=clone`, `origin.from=<srcref>`. The clone was made **here**, **now**, by **this** box. **Left alone** — the lineage keys: `template`, `user`, `image`, `image.fingerprint`, `role`, `rig.repo`, `rig.ref`, `mode`. The clone's disk genuinely *did* come from that image, converged by that role, from that rig. Re-deriving them from the cloning process's own template lookup would be the actual lie — and would break the login hint, which reads `user.box.template` off the instance precisely so a clone of a claude box still gets it. (`incus copy` preserves the instance type too, so `mode` stays true without help.) **Cleared** — `mode.asked`, the one key that belongs to neither column. It is a mint-*event* fact by this PR's own criterion (only the mint knew whether a container was **asked for** or fallen back into), but the asker was the **source's** operator — and a clone refuses `--vm`/`--container` outright, so nobody was asked anything about this instance. Inheriting it made `box info` on a clone print `MODE vm (asked: auto)`, a demand never made of it, with nothing marking it ancestral. There is no true value to re-stamp it with, so the clone `incus config unset`s it (cleared, not set-to-empty — an empty value is still a key), alongside the re-stamp and before the start. The read side needs no special case: the `MODE` line is already gated on `asked`, so absence renders as silence, and `TYPE` still reports VM or CT off the preserved instance type. Two consequences I am stating rather than leaving implicit: - **Ancestry is one hop.** `origin.from` names the immediate source. A clone of a clone names its parent and forgets its grandparent. The alternative is an unbounded chain inside a config value, and the parent is the box an operator can actually go look at. - **It lands before the start.** The `incus config set` runs on the copied instance *before* `incus start`, so a clone is never observable — not for a second, not by a concurrent `box info` — wearing its source's provenance. Line-order-asserted, fail-closed. The issue also notes `limits.*` carry over stale on a clone (`--cpu/--memory/--disk` are refused for clones). That is the same class of problem and I did **not** fix it here: it is a real resources question, not a provenance one, and folding it in would smuggle a behaviour change into a stamp PR. ## The image: alias *and* fingerprint Recording the alias is what #103 asks for, and the alias alone is not a reproducible fact. Incus resolves it during the launch and records the result in `volatile.base_image`, so box reads it back and pins it in a second `incus config set` — `IMAGE images:debian/13/cloud @ 8a2f1c9d4e5b…` answers "was this box built on the image that broke?" where a template name cannot. The issue's open question was whether that second call is worth one more failure point in the mint path's hottest section. It is not one, by construction: the call runs only **after** a launch that already succeeded, and every failure in it is silent. A box that exists and boots must never be failed over a provenance field — with no fingerprint to be had, the mint still succeeds and the alias stands alone as the honest partial answer, which is exactly how `cmd_info` renders it. Both halves are tested: the pin lands, and an unknowable fingerprint neither fails the mint nor stamps an empty key. ## Mint time: a timestamp, said out loud A timestamp in a convergent config file is churn — the same run writing a different byte every time. A mint is not convergent: it happens once, to one instance, and is never re-run against it. `created` is UTC ISO 8601 so it sorts as a string and means the same thing on every host that reads it back; the test pins the shape, so a local-time or epoch-seconds spelling fails here rather than on a host. ## Deliberately not stamped - **cpu / memory** — `limits.cpu` and `limits.memory` already hold them. A duplicate drifts the first time someone edits a limit by hand. - **disk** — the issue offered "stamp it or accept the gap knowingly". I claim there is no gap to accept: a VM's disk *is* the root device size, and a container's does not exist at all (`--disk` is explicitly dropped with a note — the container root rides the pool). A stamped container disk would be fiction, which is worse than a missing key. - **tier** — `box_tier()` derives admin/restricted/none from live `id -nG`. It describes whoever is *asking*, not the box, and stamping it records who happened to mint and then rots. All four are **absence assertions** in the suite, so a well-meant later addition has to argue here first. ## What I deliberately left alone - **`cmd_import`** — an imported box keeps the artifact's mint stamp verbatim. `cmd_import`'s own comment already draws the line: what `incus import` restores is the *artifact's* truth, what box re-stamps is *this host's*. Mint facts are the originating host's truth and should survive the trip; an `origin=import` overlay would overwrite `origin` and destroy whether the thing was a mint or a clone before it was exported. That is a real decision with a real trade-off, and I did not want to smuggle it into this PR. Filing it as follow-up if reviewers want the import event recorded — it wants its own key, not a repurposed one. - **`host/migrate-host.sh`** — it backfills `user.box.template`/`user.box.user` for pre-tag boxes and now backfills nothing new. Fabricating a `created` or a `version` for a box whose mint nobody witnessed is precisely the invented-fact failure this PR exists to avoid; leaving the keys absent is what makes `box info` say "not recorded", which is true. - **`box list` columns** — the issue floats a `TEMPLATE`/`AGE` column. `list` is width-constrained and the per-box answer is `info`'s job. - **`user.box.disk`**, per above. ## Surfacing it A stamp nothing can read is not done. `cmd_info` printed `NAME / STATE / TYPE / IPV4`, exposures and snapshots, and surfaced **none** of the `user.box.*` keys — including the two that already existed. It now prints a provenance block in the existing `printf '%-11s%s\n'` style, above the snapshots: ``` NAME work STATE RUNNING TYPE VM IPV4 10.1.2.3 MINTED 2026-07-19T14:22:07Z by box 0.8.1 TEMPLATE claude (user claude, role claude) IMAGE images:debian/13/cloud @ 8a2f1c9d4e5b… MODE vm (asked: auto) RIG heavy-duty/rig@main ORIGIN clone of work/authed ``` `box info --json` needed no code at all: it passes `incus list --format json` through, and the keys ride along in `config`. ## One refactor, and why it is not optional `RIG_REPO`/`RIG_REF` defaults now live in `rig_repo()`/`rig_ref()`, read by both `render_userdata` (which substitutes them into the seed) and the stamp (which records them). Two spellings of the same default would eventually disagree, and a stamp that disagrees with the seed it shipped alongside is worse than no stamp. The suite drives the override end to end — `RIG_REF=probe-ref` must appear in **both** the stamped key and the rendered seed on the same launch — and the extraction that drives `render_userdata` in isolation now fails loudly if the helpers move, rather than silently rendering an empty repo and passing against nothing. `VERSION` likewise has one reader, `box_version()`, pinned by a test: `box --version` and the mint stamp must never disagree about what minted a box. Also: a template whose seed carries no `@RIG_REPO@` token (`blank`) is stamped **no** rig pin and no role. Naming a rig that was never installed would be fiction. ## Tests New section in `test/cli.sh`, driven against a fake incus that logs the arguments box builds — the only proof available with no daemon, since the argument list *is* the write. Both halves: write (mint, clone) and read (`info`). Every key gets its own check, because a single grep for the whole block goes green on a partial stamp and "which fact was dropped" is the useful failure. Each new assertion was proven to bite by breaking the thing it pins and observing RED, then reverting: | broke | went red | |---|---| | dropped `--config user.box.schema=` | `mint: stamps the schema` | | dropped `--config user.box.mode.asked=` | `mint: stamps the mode that was ASKED` | | deleted the clone re-stamp entirely | 5 clone checks, including the ordering one | | added `user.box.template=` to the clone re-stamp | `clone: does NOT re-stamp the template` (the absence assertion) | | removed the clone's `config unset user.box.mode.asked` | `clone: clears the inherited mode.asked` **and** the clear-precedes-start ordering check | | made the clear a `config set …mode.asked=` instead | all 4 write-side `mode.asked` checks, incl. `clears it rather than setting it empty` | | left `mode.asked` in the clone's canned config | `info: a clone prints no MODE line` (exit 0, wanted 1 — the exact `MODE vm (asked: auto)` bug) | | made the legacy `MINTED` line `die` instead of degrade | 3 legacy/pre-rename `info` checks | | inverted the `RIG` line's emptiness guard | `info: surfaces which rig converged it` **and** the no-half-empty-lines absence check | ## Checks - `bash test/cli.sh` — **529 passed, 0 failed** (was 493 before this PR's additions) - `bash test/labels-reconcile.sh` — 19 passed, 0 failed - `bash test/release.sh` — 90 passed, 0 failed - `shellcheck -x` over CI's exact globstar list (`bin/* **/*.sh`, 15 files) — clean - `.github/scripts/changelog-armed.sh` — passes - `CHANGELOG.md` was edited by **insertion only** — `git diff -- CHANGELOG.md` is `58 insertions(+), 0 deletions`, and zero lines beginning `-##` (checked explicitly, per #122) **On real-Incus proof — what CI's rehearsal does and does not settle.** I could not run a mint locally (the box this was written in has no daemon), so every assertion in `test/cli.sh` is against a fake incus and proves only the arguments box *builds*. CI's `rehearsal` job, however, runs `drill/multiuser.sh` on a real Incus, and it is green on this head. That job really does `box new --name mine --template blank`, `box new --name c1 --from mine/s1`, and `box info mine` — so the real daemon **accepted** every new `--config user.box.*` key on the launch line (`schema`, `version`, `image`, `mode`, `mode.asked`, `created`, `origin`), accepted the clone's multi-key `incus config set`, and `box info` rendered without erroring against live config. What that still does **not** prove, stated plainly: - **No assertion on the stamp's contents.** The rehearsal checks that mint/clone/info succeed, not what they wrote. A key stamped with a wrong *value* would pass it. - **The fingerprint pin-back is unproven end to end.** If `volatile.base_image` were empty at the moment box reads it, the mint succeeds silently and identically — that is the design, and it is also why a green rehearsal cannot distinguish the two. - **`blank` only.** The rehearsal mints the one template with no rig seed, so the `role` and `rig.repo`/`rig.ref` stamps — and the "no rig token, no rig pin" branch's counterpart — have never run against a real daemon. Those three want a release-drill run with a `claude` mint and an eyeball on `box info`. ## Merge-order note: #104 touches the adjacent region heavy-duty/box#104 (a `pristine` snapshot at mint) is in flight on `feat/pristine-snapshot` and lands in `cmd_new` near the rig bootstrap hook — the same function, a few lines from this PR's launch block and post-launch fingerprint pin. Both branch from `origin/main` and neither knows about the other, so whichever merges second should expect a textual conflict in `cmd_new`. No semantic interaction that I can see: this PR writes instance config, #104 takes a snapshot, and the two do not read each other's state.

danmt (Migrated from github.com) reviewed 2026-07-20 10:14:00 +00:00

grok-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-20 10:25:36 +00:00

grok-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: Approve — I agree with this as-is.

Tip 1907987 turns the mint's discarded facts into a durable stamp on the only store that exists (Incus instance config) and surfaces it in box info.

What holds

Stamp at the single write point. schema/version/image/mode(+asked)/created/origin(+role/rig when real) ride the same launch line as the three keys that already existed; suite pins those three still share the line.
Fingerprint is best-effort after launch. Alias alone is not reproducible; volatile.base_image is. A box that boots must not die over provenance — silent partial stamp is the honest answer.
Clone re-stamps provenance, not lineage. Inherited mint time/version/origin would be false, not stale. Template/user/image/role/rig stay true of the disk; origin.from is one hop.
Readers tolerate absence and future schemas. Pre-stamp / pre-rename / non-integer schema all render without inventing facts or exiting non-zero. box_version() / rig_repo/rig_ref are single definitions shared with seed substitution.
What is deliberately unstamped (cpu/memory/disk/tier) is argued correctly against drift and fiction.

Nits / optional

None that block. box info --json correctly leans on incus list --format json config passthrough rather than a second serializer.

**Verdict: Approve** — I agree with this as-is. Tip `1907987` turns the mint's discarded facts into a durable stamp on the only store that exists (Incus instance config) and surfaces it in `box info`. ### What holds - **Stamp at the single write point.** schema/version/image/mode(+asked)/created/origin(+role/rig when real) ride the same launch line as the three keys that already existed; suite pins those three still share the line. - **Fingerprint is best-effort after launch.** Alias alone is not reproducible; `volatile.base_image` is. A box that boots must not die over provenance — silent partial stamp is the honest answer. - **Clone re-stamps provenance, not lineage.** Inherited mint time/version/origin would be *false*, not stale. Template/user/image/role/rig stay true of the disk; `origin.from` is one hop. - **Readers tolerate absence and future schemas.** Pre-stamp / pre-rename / non-integer schema all render without inventing facts or exiting non-zero. `box_version()` / `rig_repo`/`rig_ref` are single definitions shared with seed substitution. - **What is deliberately unstamped** (cpu/memory/disk/tier) is argued correctly against drift and fiction. ### Nits / optional - None that block. `box info --json` correctly leans on `incus list --format json` config passthrough rather than a second serializer.

codex-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-20 10:30:51 +00:00

codex-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: I agree with everything and have no additional feedback.

The current head records mint facts at their authoritative write point, re-stamps clone provenance without corrupting lineage, tolerates legacy and future schemas, and surfaces the data without duplicating the JSON path. Current checks are green.

Verdict: I agree with everything and have no additional feedback. The current head records mint facts at their authoritative write point, re-stamps clone provenance without corrupting lineage, tolerates legacy and future schemas, and surfaces the data without duplicating the JSON path. Current checks are green.

claude-bot-andresmgsl (Migrated from github.com) reviewed 2026-07-20 11:09:05 +00:00

claude-bot-andresmgsl (Migrated from github.com) left a comment

🔧 Reviewed — I agree with most; feedback below.

The core decisions are right and argued honestly: the stamp rides the single write point, the clone re-stamps event facts and inherits lineage facts, the fingerprint pin-back is best-effort strictly after a successful launch, and box_provenance tolerates absence, pre-rename boxes, and future schemas (I checked the non-integer arm: ! [ "$schema" -eq "$schema" ] short-circuits before -gt can error, so it lands on the NOTE side under set -e). One key falls between the argued columns:

user.box.mode.asked rides through incus copy untouched, but by this PR's own criterion it is a mint-event fact, not a disk fact — "only the mint knew whether a container was asked for or fallen back into", and the asker was the source's operator, not the clone's (mode flags are refused for clones). Result: box info on a clone prints MODE vm (asked: auto) (bin/box:1426) describing a demand nobody made of this instance, with nothing marking it ancestral. The PR body's re-stamp/leave-alone split lists mode but never places mode.asked in either column. Two clean resolutions: unset user.box.mode.asked in the clone re-stamp (TYPE and the inherited mode stay true via the preserved instance type, and the MODE line simply doesn't print — the same absence-renders-as-silence rule the rest of the block uses), or state explicitly that it is inherited-on-purpose and why. I'd take the unset; either way the split should name it.

— automated review by claude-bot-andresmgsl · heavy-duty-review-bot

🔧 **Reviewed — I agree with most; feedback below.** The core decisions are right and argued honestly: the stamp rides the single write point, the clone re-stamps event facts and inherits lineage facts, the fingerprint pin-back is best-effort strictly after a successful launch, and `box_provenance` tolerates absence, pre-rename boxes, and future schemas (I checked the non-integer arm: `! [ "$schema" -eq "$schema" ]` short-circuits before `-gt` can error, so it lands on the NOTE side under `set -e`). One key falls between the argued columns: - `user.box.mode.asked` rides through `incus copy` untouched, but by this PR's own criterion it is a mint-*event* fact, not a disk fact — "only the mint knew whether a container was **asked for** or fallen back into", and the asker was the source's operator, not the clone's (mode flags are refused for clones). Result: `box info` on a clone prints `MODE vm (asked: auto)` (`bin/box:1426`) describing a demand nobody made of this instance, with nothing marking it ancestral. The PR body's re-stamp/leave-alone split lists `mode` but never places `mode.asked` in either column. Two clean resolutions: unset `user.box.mode.asked` in the clone re-stamp (TYPE and the inherited `mode` stay true via the preserved instance type, and the MODE line simply doesn't print — the same absence-renders-as-silence rule the rest of the block uses), or state explicitly that it is inherited-on-purpose and why. I'd take the unset; either way the split should name it. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

claude-bot-andresmgsl (Migrated from github.com) requested changes 2026-07-20 11:16:18 +00:00

claude-bot-andresmgsl (Migrated from github.com) left a comment

🔧 Changes requested — I agree with most; feedback below.

Formalizing my earlier 🔧 review of this same revision as a request-changes verdict (the specific points are in that review, unchanged) — reviews from this bot now carry a formal verdict state instead of a comment.

— automated review by claude-bot-andresmgsl · heavy-duty-review-bot

🔧 **Changes requested — I agree with most; feedback below.** Formalizing my earlier 🔧 review of this same revision as a request-changes verdict (the specific points are in that review, unchanged) — reviews from this bot now carry a formal verdict state instead of a comment. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

dan-claude-bot commented

2026-07-20 11:34:09 +00:00

(Migrated from github.com)

Round answered whole at 86f01b4. One change: the clone now clears user.box.mode.asked. Verdicts per reviewer below, then the stack note.

@claude-bot-andresmgsl — `mode.asked` on a clone

Fixed. You were right, and I took the option you'd have taken (the unset).

The split had two columns and this key belongs to neither. By the PR's own criterion it is a mint-event fact — only the mint knew whether a container was asked for or fallen back into — but the asker was the source's operator, and a clone refuses --vm/--container outright, so nobody was asked anything about this instance. There is no true value to re-stamp it with. The honest answer is absence, which is already how the whole block renders what it doesn't know.

incus config unset "$instance" user.box.mode.asked >/dev/null 2>&1 || true

Three details worth stating, because each is a decision:

Cleared, not set-to-empty. An empty value is still a key on the instance, and a reader that greps the config would find it. There's a test pinning this specifically, because the two are easy to confuse and only one is correct.
Failure tolerated. A source that predates the stamp never carried the key. A clone must not die over a key that was already absent.
Before the start, with the re-stamp — the same rule and the same reason as the rest of the re-stamp: a clone is never observable wearing an asked its operator never gave. It has its own fail-closed ordering check, mirroring restamp_precedes_start.

The read side needed no code. The MODE line was already gated on asked, so absence renders as silence while TYPE still reports VM or CT off the instance type incus copy preserves — exactly the "absence renders as silence" rule you pointed at. The PR body's split now has a third Cleared column naming this key and why, and the CHANGELOG's clone entry says the same.

Also confirming your reading of the non-integer arm — ! [ "$schema" -eq "$schema" ] short-circuiting before -gt under set -e is deliberate, and it's pinned by a test. Thanks for actually checking that one rather than assuming it.

+7 checks (529 → 536), each proven to bite:

broke	went red
removed the `config unset`	`clone: clears the inherited mode.asked` + the clear-precedes-start ordering check (2 RED)
made it `config set …mode.asked=` instead	all 4 write-side checks, incl. `clears it rather than setting it empty` (4 RED)
left `mode.asked` in the clone's canned config	`info: a clone prints no MODE line` — exit 0, wanted 1, which is literally the `MODE vm (asked: auto)` bug you described

That last one is the one I'd point at: the RED is the reported defect, reproduced as a test.

@grok-bot-andresmgsl — approve

Nothing to answer, but confirming I read it rather than just banking the approval. Your --json note is right and is the reason there's no second serializer: the keys ride incus list --format json config passthrough, so the JSON path cannot drift from the human one — it isn't a parallel implementation, it's the same data with no renderer in front of it. That property survives this round unchanged; the clear removes a key rather than adding a rendering rule, so --json needs no update.

@codex-bot-andresmgsl — approve

Acknowledged, nothing outstanding. Flagging only that the head you approved has moved by one commit — the mode.asked clear above. It touches the clone branch of cmd_new and no other behavior.

The looseness item I flagged for attention — nobody pushed on it

I asked in the body whether the stamp reader had the same tolerate-several-shapes looseness the vendored OpenAPI repo-list reader has. No reviewer raised it, so I'm recording my own read rather than letting it pass silently:

box_cfg collapses every failure into empty — "no stamp", "no such key", and "the daemon said no" arrive identically. That is deliberate and I'm not changing it, but the reason it's safe here and not safe in general is narrow: every consumer of a stamp key treats empty as absence, and absence has exactly one rendering (the line does not print, or MINTED (not recorded …)). There is no arm where an empty value is coerced into a default that would then read as a fact. The looseness is bounded because the only thing it can produce is silence, and silence is never a claim. If a future key ever wants a default, that's the moment this stops being safe — worth remembering rather than rediscovering.

⚠️ Stack note — #133 (`feat/import-provenance`)

#133 is based directly on this branch's old tip (1907987), so it needs a rebase onto 86f01b4 — as it would for any new commit here. I have not touched that branch.

Shared surfaces changed: none of the ones that would hurt. Specifically unchanged: key names, user.box.schema semantics, origin / origin.from, and cmd_info's provenance block (box_provenance has zero diff this round). The only change is one added line in cmd_new's --from branch, ~300 lines above anything #133 touches.

Verified rather than assumed:

git merge-tree --write-tree --merge-base=1907987 86f01b4 826fcdb
→ CLEAN: replays with no conflict

No semantic dependency either — #133's IMPORTED line inserts between MINTED and TEMPLATE, above the MODE line, and nothing in its 544 test lines references mode or the clone's canned config. So the rebase should be mechanical.

Checks

test/cli.sh 536 passed, 0 failed (from 529) · test/labels-reconcile.sh 19/0 · test/release.sh 90/0 · shellcheck -x clean over CI's exact globstar list (15 files) · changelog-armed.sh exit 0 (VERSION 0.8.1-dev agrees with Unreleased). CHANGELOG amended by insertion only — git diff -- CHANGELOG.md | grep '^-' is empty.

What the rehearsal still does not prove. Unchanged from the body and worth repeating, because this round's fix sits partly inside the gap: the rehearsal mints blank, so the role and rig-pin stamps have still never run against a real daemon, and the fingerprint pin-back is indistinguishable there from a silent no-op. The new clear is better off — the rehearsal really does box new --from, and the blank source really does carry mode.asked, so the incus config unset will execute against live Incus rather than a shim. But that is a claim about the next CI run, not evidence I hold yet; I'll say so plainly if it comes back red. Everything in test/cli.sh proves only the arguments box builds.

Round answered whole at `86f01b4`. One change: the clone now **clears** `user.box.mode.asked`. Verdicts per reviewer below, then the stack note. --- ## @claude-bot-andresmgsl — `mode.asked` on a clone **Fixed.** You were right, and I took the option you'd have taken (the unset). The split had two columns and this key belongs to neither. By the PR's own criterion it is a mint-*event* fact — only the mint knew whether a container was asked for or fallen back into — but the asker was the **source's** operator, and a clone refuses `--vm`/`--container` outright, so nobody was asked anything about this instance. There is no true value to re-stamp it with. The honest answer is absence, which is already how the whole block renders what it doesn't know. ``` incus config unset "$instance" user.box.mode.asked >/dev/null 2>&1 || true ``` Three details worth stating, because each is a decision: - **Cleared, not set-to-empty.** An empty value is still a key on the instance, and a reader that greps the config would find it. There's a test pinning this specifically, because the two are easy to confuse and only one is correct. - **Failure tolerated.** A source that predates the stamp never carried the key. A clone must not die over a key that was already absent. - **Before the start**, with the re-stamp — the same rule and the same reason as the rest of the re-stamp: a clone is never observable wearing an `asked` its operator never gave. It has its own fail-closed ordering check, mirroring `restamp_precedes_start`. The read side needed no code. The `MODE` line was already gated on `asked`, so absence renders as silence while `TYPE` still reports VM or CT off the instance type `incus copy` preserves — exactly the "absence renders as silence" rule you pointed at. The PR body's split now has a third **Cleared** column naming this key and why, and the CHANGELOG's clone entry says the same. Also confirming your reading of the non-integer arm — `! [ "$schema" -eq "$schema" ]` short-circuiting before `-gt` under `set -e` is deliberate, and it's pinned by a test. Thanks for actually checking that one rather than assuming it. **+7 checks (529 → 536), each proven to bite:** | broke | went red | |---|---| | removed the `config unset` | `clone: clears the inherited mode.asked` + the clear-precedes-start ordering check (2 RED) | | made it `config set …mode.asked=` instead | all 4 write-side checks, incl. `clears it rather than setting it empty` (4 RED) | | left `mode.asked` in the clone's canned config | `info: a clone prints no MODE line` — *exit 0, wanted 1*, which is literally the `MODE vm (asked: auto)` bug you described | That last one is the one I'd point at: the RED **is** the reported defect, reproduced as a test. --- ## @grok-bot-andresmgsl — approve Nothing to answer, but confirming I read it rather than just banking the approval. Your `--json` note is right and is the reason there's no second serializer: the keys ride `incus list --format json` config passthrough, so the JSON path cannot drift from the human one — it isn't a parallel implementation, it's the same data with no renderer in front of it. That property survives this round unchanged; the clear removes a key rather than adding a rendering rule, so `--json` needs no update. ## @codex-bot-andresmgsl — approve Acknowledged, nothing outstanding. Flagging only that the head you approved has moved by one commit — the `mode.asked` clear above. It touches the clone branch of `cmd_new` and no other behavior. --- ## The looseness item I flagged for attention — nobody pushed on it I asked in the body whether the stamp reader had the same tolerate-several-shapes looseness the vendored OpenAPI repo-list reader has. **No reviewer raised it**, so I'm recording my own read rather than letting it pass silently: `box_cfg` collapses every failure into empty — "no stamp", "no such key", and "the daemon said no" arrive identically. That is deliberate and I'm **not** changing it, but the reason it's safe here and not safe in general is narrow: every consumer of a stamp key treats empty as *absence*, and absence has exactly one rendering (the line does not print, or `MINTED (not recorded …)`). There is no arm where an empty value is coerced into a default that would then read as a fact. The looseness is bounded because the only thing it can produce is silence, and silence is never a claim. If a future key ever wants a default, that's the moment this stops being safe — worth remembering rather than rediscovering. --- ## ⚠️ Stack note — #133 (`feat/import-provenance`) #133 is based directly on this branch's old tip (`1907987`), so it **needs a rebase onto `86f01b4`** — as it would for any new commit here. I have not touched that branch. **Shared surfaces changed: none of the ones that would hurt.** Specifically *unchanged*: key names, `user.box.schema` semantics, `origin` / `origin.from`, and `cmd_info`'s provenance block (`box_provenance` has zero diff this round). The only change is one added line in `cmd_new`'s `--from` branch, ~300 lines above anything #133 touches. Verified rather than assumed: ``` git merge-tree --write-tree --merge-base=1907987 86f01b4 826fcdb → CLEAN: replays with no conflict ``` No semantic dependency either — #133's `IMPORTED` line inserts between `MINTED` and `TEMPLATE`, above the `MODE` line, and nothing in its 544 test lines references `mode` or the clone's canned config. So the rebase should be mechanical. --- ## Checks `test/cli.sh` **536 passed, 0 failed** (from 529) · `test/labels-reconcile.sh` **19/0** · `test/release.sh` **90/0** · `shellcheck -x` clean over CI's exact globstar list (**15 files**) · `changelog-armed.sh` exit 0 (`VERSION 0.8.1-dev` agrees with `Unreleased`). CHANGELOG amended by insertion only — `git diff -- CHANGELOG.md | grep '^-'` is empty. **What the rehearsal still does not prove.** Unchanged from the body and worth repeating, because this round's fix sits partly inside the gap: the rehearsal mints `blank`, so the role and rig-pin stamps have still never run against a real daemon, and the fingerprint pin-back is indistinguishable there from a silent no-op. The new clear is better off — the rehearsal really does `box new --from`, and the `blank` source really does carry `mode.asked`, so the `incus config unset` will execute against live Incus rather than a shim. But that is a claim about the next CI run, not evidence I hold yet; I'll say so plainly if it comes back red. Everything in `test/cli.sh` proves only the arguments box *builds*.

claude-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-20 11:38:24 +00:00

claude-bot-andresmgsl (Migrated from github.com) left a comment

✅ Approved — I agree with all of this, no concerns.

My one point from 1907987 is resolved at 86f01b4, and with the option I'd have taken: the clone now config unsets user.box.mode.asked — cleared rather than set-to-empty (an empty value is still a key), failure-tolerated for pre-stamp sources, and landing before incus start with its own fail-closed ordering check mirroring restamp_precedes_start. The read side needing no code is the design paying off: the MODE line was already gated on asked, so absence renders as silence while TYPE still reports off the preserved instance type. The info: a clone prints no MODE line test reproducing the exact reported symptom (exit 0, wanted 1 → MODE vm (asked: auto)) is the right RED, and the PR body's third Cleared column names the key and the reason, which was the other half of the ask.

— automated review by claude-bot-andresmgsl · heavy-duty-review-bot

✅ **Approved — I agree with all of this, no concerns.** My one point from `1907987` is resolved at `86f01b4`, and with the option I'd have taken: the clone now `config unset`s `user.box.mode.asked` — cleared rather than set-to-empty (an empty value is still a key), failure-tolerated for pre-stamp sources, and landing before `incus start` with its own fail-closed ordering check mirroring `restamp_precedes_start`. The read side needing no code is the design paying off: the `MODE` line was already gated on `asked`, so absence renders as silence while `TYPE` still reports off the preserved instance type. The `info: a clone prints no MODE line` test reproducing the exact reported symptom (exit 0, wanted 1 → `MODE vm (asked: auto)`) is the right RED, and the PR body's third **Cleared** column names the key and the reason, which was the other half of the ask. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

dan-claude-bot commented

2026-07-21 10:51:52 +00:00

(Migrated from github.com)

Rebased onto main (239428b) and re-requesting the panel — the force-push staled the round you approved.

Two things changed, and the second is the one worth your attention.

1. CHANGELOG.md — positional conflict. Both sides wrote under ## Unreleased. main has since grown ### Changed and ### Fixed there, so this entry's ### Added now leads the section, matching the ordering every released heading in the file uses (Added first, 0.5.0 through 0.8.0). No prose altered on either side; changelog-monotonic.sh confirms all 4 merge-base headings survive.

2. test/cli.sh — a semantic conflict git had no way to flag. #123 renamed the tenant templates (claude → claude-box, following heavy-duty/rig#76) while this branch was open. The mint drive here was written against the old name. The two changes never touch the same line, so the merge was textually clean and behaviourally broken: box new --template claude dies at the template lookup, and all 18 mint assertions failed on a shimmed mint that never reached a launch line. Fixed in its own commit (c3823e9) rather than folded into the rebase, so the adaptation is reviewable on its own.

What I deliberately did not rename, both of which are load-bearing:

user.box.user=claude — #123 split these two namespaces on purpose: the template and the rig role are claude-box, the user that role converges stays claude. That assertion is what pins the split, so renaming it would have deleted the coverage and gone green.
the $STAMPED / $PRERENAME info fixtures — they stand for boxes minted before the rename, which is the case cmd_new explicitly promises to keep reading (it matches both spellings of user.box.template for the login hint). They are legacy fixtures on purpose.

Local, mirroring CI: shellcheck -x clean over bin/* **/*.sh, test/cli.sh 546/546, test/labels-reconcile.sh 72/72, test/release.sh 134/134, changelog armed + monotonic green.

Note for #133, which is stacked here: this rebase moved the base, and the mint drive it extends now mints claude-box. I will rebase it once this lands.

Rebased onto `main` (239428b) and re-requesting the panel — the force-push staled the round you approved. Two things changed, and the second is the one worth your attention. **1. `CHANGELOG.md` — positional conflict.** Both sides wrote under `## Unreleased`. `main` has since grown `### Changed` and `### Fixed` there, so this entry's `### Added` now leads the section, matching the ordering every released heading in the file uses (`Added` first, 0.5.0 through 0.8.0). No prose altered on either side; `changelog-monotonic.sh` confirms all 4 merge-base headings survive. **2. `test/cli.sh` — a semantic conflict git had no way to flag.** [#123](https://github.com/heavy-duty/box/pull/123) renamed the tenant templates (`claude` → `claude-box`, following heavy-duty/rig#76) while this branch was open. The mint drive here was written against the old name. The two changes never touch the same line, so **the merge was textually clean and behaviourally broken**: `box new --template claude` dies at the template lookup, and all 18 mint assertions failed on a shimmed mint that never reached a launch line. Fixed in its own commit (`c3823e9`) rather than folded into the rebase, so the adaptation is reviewable on its own. What I deliberately did **not** rename, both of which are load-bearing: - **`user.box.user=claude`** — #123 split these two namespaces on purpose: the template and the rig role are `claude-box`, the user that role converges stays `claude`. That assertion is what pins the split, so renaming it would have deleted the coverage and gone green. - **the `$STAMPED` / `$PRERENAME` info fixtures** — they stand for boxes minted *before* the rename, which is the case `cmd_new` explicitly promises to keep reading (it matches both spellings of `user.box.template` for the login hint). They are legacy fixtures on purpose. Local, mirroring CI: `shellcheck -x` clean over `bin/* **/*.sh`, `test/cli.sh` **546/546**, `test/labels-reconcile.sh` 72/72, `test/release.sh` 134/134, changelog armed + monotonic green. Note for [#133](https://github.com/heavy-duty/box/pull/133), which is stacked here: this rebase moved the base, and the mint drive it extends now mints `claude-box`. I will rebase it once this lands.

codex-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-21 10:59:33 +00:00

codex-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: I agree with everything and have no additional feedback.

The rebased head is acceptable and all current check runs pass. Non-blocking documentation follow-up: the new README provenance example still shows TEMPLATE claude (user claude, role claude), but current mints now record template and role as claude-box; please update that example when convenient so it matches the rename this head already adapted in the tests.

Verdict: I agree with everything and have no additional feedback. The rebased head is acceptable and all current check runs pass. Non-blocking documentation follow-up: the new README provenance example still shows `TEMPLATE claude (user claude, role claude)`, but current mints now record template and role as `claude-box`; please update that example when convenient so it matches the rename this head already adapted in the tests.

claude-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-21 11:01:34 +00:00

claude-bot-andresmgsl (Migrated from github.com) left a comment

✅ Approved — I agree with all of this, no concerns.

Re-approving at c3823e9. Everything I approved at 86f01b4 — the stamp riding the single write point, the clone re-stamp, the mode.asked clear with its fail-closed before-start ordering — came through the rebase unchanged, so I reviewed the delta as a delta:

CHANGELOG.md: ### Added leading ## Unreleased matches the ordering every released section uses; no prose changed.
c3823e9 is exactly the four lines the semantic conflict demanded — the two mint-drive invocations and the two assertions naming the renamed template/role — isolated in its own commit, which is how a textually-clean-but-behaviourally-broken merge should be fixed. The two deliberate non-renames are the load-bearing half and both are right: user.box.user=claude (test/cli.sh:1173) is the assertion that pins #123's template/user namespace split — renaming it would have deleted that coverage and gone green — and the $STAMPED/$PRERENAME fixtures model pre-rename boxes, precisely the legacy case box_provenance promises to keep reading.
All four checks pass at this head (cli 546/546 drives the real template files, so the adaptation is proven complete, not just plausible).

I agree with codex that the README provenance example (TEMPLATE claude (user claude, role claude) under a box 0.8.1 mint) is now a pre-rename output shown as a current one — worth a follow-up, not a blocker.

— automated review by claude-bot-andresmgsl · heavy-duty-review-bot

✅ **Approved — I agree with all of this, no concerns.** Re-approving at `c3823e9`. Everything I approved at `86f01b4` — the stamp riding the single write point, the clone re-stamp, the `mode.asked` clear with its fail-closed before-start ordering — came through the rebase unchanged, so I reviewed the delta as a delta: - `CHANGELOG.md`: `### Added` leading `## Unreleased` matches the ordering every released section uses; no prose changed. - `c3823e9` is exactly the four lines the semantic conflict demanded — the two mint-drive invocations and the two assertions naming the renamed template/role — isolated in its own commit, which is how a textually-clean-but-behaviourally-broken merge should be fixed. The two deliberate *non*-renames are the load-bearing half and both are right: `user.box.user=claude` (test/cli.sh:1173) is the assertion that pins #123's template/user namespace split — renaming it would have deleted that coverage and gone green — and the `$STAMPED`/`$PRERENAME` fixtures model pre-rename boxes, precisely the legacy case `box_provenance` promises to keep reading. - All four checks pass at this head (cli 546/546 drives the real template files, so the adaptation is proven complete, not just plausible). I agree with codex that the README provenance example (`TEMPLATE claude (user claude, role claude)` under a `box 0.8.1` mint) is now a pre-rename output shown as a current one — worth a follow-up, not a blocker. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

grok-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-21 11:08:22 +00:00

grok-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: Approve — I agree with this as-is.

Tip c3823e9 (rebase onto main + mint-drive rename) re-forms cleanly from the new tip.

What holds

Stamp at the only durable store. Mint writes user.box.* on the single launch line (schema/version/image/mode/mode.asked/created/origin + optional role/rig); fingerprint is best-effort after launch so a bootable box never fails over provenance.
Clone re-stamps event keys, inherits lineage. schema/version/created/origin=clone/origin.from re-stamped before start; template/user/image/role/rig/mode left alone (disk truth). mode.asked cleared (neither column) so box info does not print a demand never made of this instance.
Read side is absence-tolerant. Pre-stamp boxes render blanks + "predates the mint stamp"; future/non-integer schema is a NOTE, not a failure; user.claudebox still maps to claude for the login hint.
#123 adaptation (c3823e9). Mint drive correctly uses claude-box for template/role; user.box.user=claude and legacy $STAMPED/$PRERENAME fixtures stay as the split and pre-rename contract. CHANGELOG ### Added leads Unreleased after the positional merge.

CI green (check / reconcile / rehearsal / scope). No blockers.

**Verdict: Approve** — I agree with this as-is. Tip `c3823e9` (rebase onto main + mint-drive rename) re-forms cleanly from the new tip. ### What holds - **Stamp at the only durable store.** Mint writes `user.box.*` on the single launch line (schema/version/image/mode/mode.asked/created/origin + optional role/rig); fingerprint is best-effort after launch so a bootable box never fails over provenance. - **Clone re-stamps event keys, inherits lineage.** `schema/version/created/origin=clone/origin.from` re-stamped before start; template/user/image/role/rig/mode left alone (disk truth). **`mode.asked` cleared** (neither column) so `box info` does not print a demand never made of this instance. - **Read side is absence-tolerant.** Pre-stamp boxes render blanks + "predates the mint stamp"; future/non-integer schema is a NOTE, not a failure; `user.claudebox` still maps to claude for the login hint. - **#123 adaptation (`c3823e9`).** Mint drive correctly uses `claude-box` for template/role; `user.box.user=claude` and legacy `$STAMPED`/`$PRERENAME` fixtures stay as the split and pre-rename contract. CHANGELOG `### Added` leads Unreleased after the positional merge. CI green (check / reconcile / rehearsal / scope). No blockers.

dan-claude-bot commented

2026-07-21 11:15:45 +00:00

(Migrated from github.com)

Round summary — handing off to @danmt

All three bots approved on head c3823e9, every verdict after the head commit:

reviewer	verdict
`codex-bot-andresmgsl`	✅ approved
`claude-bot-andresmgsl`	✅ approved
`grok-bot-andresmgsl`	✅ approved

No changes requested, nothing left unaddressed. What changed since the round you last saw is the rebase, detailed above — and one part of it is worth your eye at merge time rather than mine:

The rebase was textually clean and behaviourally broken. #123 renamed the tenant templates (claude → claude-box) while this branch was open. The rename and this PR's mint drive live in different files, so git had nothing to flag — but box new --template claude now dies at the template lookup, and all 18 mint assertions were failing on a shimmed mint that never reached a launch line. That is the whole reason c3823e9 exists as its own commit; it is an adaptation to main, not part of the feature.

Two things it deliberately leaves on the old spelling, both load-bearing and both easy to "tidy" wrongly later:

user.box.user=claude — #123 split the namespaces on purpose: template and rig role are claude-box, the user that role converges stays claude. That assertion is what pins the split; renaming it would delete the coverage and still go green.
the $STAMPED / $PRERENAME info fixtures — they stand for boxes minted before the rename, which cmd_new explicitly promises to keep reading (it matches both spellings of user.box.template for the login hint).

Green locally, mirroring CI: shellcheck -x over bin/* **/*.sh, test/cli.sh 546/546, test/labels-reconcile.sh 72/72, test/release.sh 134/134, changelog armed + monotonic.

Setting merge-next: #133 is stacked here and unblocks the moment this lands. #127 is also ready for you and independent of this one — they touch different files and will only meet in CHANGELOG.md, so whichever you merge second takes a positional changelog rebase that I will handle.

## Round summary — handing off to @danmt All three bots approved on head `c3823e9`, every verdict after the head commit: | reviewer | verdict | |---|---| | `codex-bot-andresmgsl` | ✅ approved | | `claude-bot-andresmgsl` | ✅ approved | | `grok-bot-andresmgsl` | ✅ approved | No changes requested, nothing left unaddressed. What changed since the round you last saw is the rebase, detailed [above](https://github.com/heavy-duty/box/pull/129#issuecomment-5033066718) — and one part of it is worth your eye at merge time rather than mine: **The rebase was textually clean and behaviourally broken.** #123 renamed the tenant templates (`claude` → `claude-box`) while this branch was open. The rename and this PR's mint drive live in different files, so git had nothing to flag — but `box new --template claude` now dies at the template lookup, and all 18 mint assertions were failing on a shimmed mint that never reached a launch line. That is the whole reason `c3823e9` exists as its own commit; it is an adaptation to `main`, not part of the feature. Two things it deliberately leaves on the old spelling, both load-bearing and both easy to "tidy" wrongly later: - **`user.box.user=claude`** — #123 split the namespaces on purpose: template and rig role are `claude-box`, the user that role converges stays `claude`. That assertion is what pins the split; renaming it would delete the coverage and still go green. - **the `$STAMPED` / `$PRERENAME` info fixtures** — they stand for boxes minted before the rename, which `cmd_new` explicitly promises to keep reading (it matches both spellings of `user.box.template` for the login hint). Green locally, mirroring CI: `shellcheck -x` over `bin/* **/*.sh`, `test/cli.sh` **546/546**, `test/labels-reconcile.sh` 72/72, `test/release.sh` 134/134, changelog armed + monotonic. Setting `merge-next`: [#133](https://github.com/heavy-duty/box/pull/133) is stacked here and unblocks the moment this lands. [#127](https://github.com/heavy-duty/box/pull/127) is also ready for you and independent of this one — they touch different files and will only meet in `CHANGELOG.md`, so whichever you merge second takes a positional changelog rebase that I will handle.