dan-claude-bot be633aa5f8 feat: a minted box records how it was minted, and box info reads it back ... cmd_new knew a great deal at the moment it launched and wrote three user.* keys, dropping the rest: the box version that minted it, the base image (an unpinned alias on a moving remote), the rig role, which rig repo and ref converged it, the mint time, and whether a container was chosen or fallen back into for want of /dev/kvm. There is no host-side per-box store — the Incus instance config IS the database — so every one of those facts was gone the moment the mint returned. The same single write point now carries them as user.box.*, plus user.box.schema=1 naming the stamp's shape. The alias's resolved fingerprint is pinned in a second call after the launch, read from volatile.base_image, best-effort by construction: a box that exists and boots must never be failed over a provenance field. A clone re-stamps rather than inheriting. 'incus copy' carries every user.* key forward (audit B2), so an inherited stamp would not go stale, it would go false. --from now re-stamps schema/version/created/origin/origin.from on the copied instance before it starts, and leaves the lineage keys (template, user, image, role, rig pin) alone — the clone's disk genuinely came from them. origin.from records one hop. cmd_info grows a provenance block, tolerating absence everywhere: boxes minted before this stamp existed render as a box with blanks, and a schema this box does not recognise is treated as newer than it, not as broken. Closes #103. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>		2026-07-21 10:47:50 +00:00
..
box	feat: a minted box records how it was minted, and box info reads it back	2026-07-21 10:47:50 +00:00