box import records nothing about the import event — and `origin=import` is the wrong fix #131

New issue

Closed

opened 2026-07-20 10:29:52 +00:00 by dan-claude-bot · 1 comment

dan-claude-bot commented

2026-07-20 10:29:52 +00:00

(Migrated from github.com)

Follow-up carved out of #103's PR (#129), which deliberately left cmd_import
alone and flagged the decision rather than smuggling it in.

The gap

#129 stamps user.box.* provenance at mint, including origin=mint|clone.
An imported box keeps the artifact's stamp verbatim — the mint time,
version, image and role of the box as it existed on the originating host.

That is the right default, and #129 argues it: cmd_import's own comment
already draws the line between what incus import restores (the artifact's
truth) and what box re-stamps (this host's). Mint facts belong to the
originating host and should survive the trip.

What is missing is any record that the trip happened. An imported box is
today indistinguishable from a box minted on this host at the artifact's
mint time.

Why this is not a one-line addition

The obvious move — set origin=import — is the wrong one, and naming why is
most of this issue's value:

origin records how this instance came into being: mint or clone.
Overwriting it with import destroys that distinction. A clone that was
exported and imported would come back claiming to be an import, with no
record it was ever a clone, and the lineage origin.from points at becomes
unreadable. The import event is a third fact, orthogonal to the first two —
it wants its own key, not a repurposed one.

So the decision this issue owes:

Which key(s). user.box.imported/user.box.imported.at alongside an
untouched origin, or a more general "events" shape? The stamp is
deliberately flat key=value today.
Does re-import overwrite or append? A box can make the trip more than
once. First-wins, last-wins, and a count are all defensible; the manifest
work in heavy-duty/rig#61 hit the same question and settled on a birth
pair plus a latest pair, which may be the precedent to follow.
Does box info surface it, and under what line? #129's provenance
block prints MINTED … by box X.Y.Z; an import line has to read clearly
next to a mint time that is deliberately not this host's.
Schema. #129's user.box.schema moves only on removal or repurposing.
Adding a key is not breaking, so this should not need a bump — worth
confirming against whatever shape is chosen.

Explicitly not in scope

host/migrate-host.sh, for the same reason #129 left it alone: it backfills
template/user for pre-tag boxes, and fabricating a created or version
for a mint nobody witnessed is precisely the invented-fact failure the stamp
exists to avoid. Absent keys are what make box info say "not recorded",
which is true.

Blocked

On #129. There is no user.box.schema, no origin, and no provenance block
to extend until it lands, and all three can still change in review.

Refs

#103 (the parent), #129 (where it was left alone, with the reasoning),
heavy-duty/rig#61 (the birth-pair/latest-pair precedent for repeated events)

Follow-up carved out of #103's PR (#129), which deliberately left `cmd_import` alone and flagged the decision rather than smuggling it in. ## The gap #129 stamps `user.box.*` provenance at mint, including `origin=mint|clone`. An **imported** box keeps the artifact's stamp verbatim — the mint time, version, image and role of the box as it existed on the originating host. That is the right default, and #129 argues it: `cmd_import`'s own comment already draws the line between what `incus import` restores (the *artifact's* truth) and what box re-stamps (*this host's*). Mint facts belong to the originating host and should survive the trip. What is missing is any record that the trip happened. An imported box is today indistinguishable from a box minted on this host at the artifact's mint time. ## Why this is not a one-line addition The obvious move — set `origin=import` — is the wrong one, and naming why is most of this issue's value: `origin` records **how this instance came into being**: `mint` or `clone`. Overwriting it with `import` destroys that distinction. A clone that was exported and imported would come back claiming to be an import, with no record it was ever a clone, and the lineage `origin.from` points at becomes unreadable. The import event is a *third* fact, orthogonal to the first two — it wants its own key, not a repurposed one. So the decision this issue owes: - **Which key(s).** `user.box.imported`/`user.box.imported.at` alongside an untouched `origin`, or a more general "events" shape? The stamp is deliberately flat `key=value` today. - **Does re-import overwrite or append?** A box can make the trip more than once. First-wins, last-wins, and a count are all defensible; the manifest work in heavy-duty/rig#61 hit the same question and settled on a birth pair plus a latest pair, which may be the precedent to follow. - **Does `box info` surface it**, and under what line? #129's provenance block prints `MINTED … by box X.Y.Z`; an import line has to read clearly next to a mint time that is deliberately *not* this host's. - **Schema.** #129's `user.box.schema` moves only on removal or repurposing. Adding a key is not breaking, so this should not need a bump — worth confirming against whatever shape is chosen. ## Explicitly not in scope `host/migrate-host.sh`, for the same reason #129 left it alone: it backfills `template`/`user` for pre-tag boxes, and fabricating a `created` or `version` for a mint nobody witnessed is precisely the invented-fact failure the stamp exists to avoid. Absent keys are what make `box info` say "not recorded", which is true. ## Blocked On #129. There is no `user.box.schema`, no `origin`, and no provenance block to extend until it lands, and all three can still change in review. ## Refs #103 (the parent), #129 (where it was left alone, with the reasoning), heavy-duty/rig#61 (the birth-pair/latest-pair precedent for repeated events)