Record that a runtime migration starts on a throwaway machine #35

Merged

vnprc merged 1 commit from agent/microvm-first-selection-machine into master

2026-07-30 20:39:34 +01:00

allod-agent commented

2026-07-30 19:34:04 +01:00

Member

A constraint the microvm.nix arc surfaced late, recorded so the agent that eventually does the private-side machine work is told regardless of which document it reads.

The first machine to move onto a new guest runtime is a purpose-made throwaway, never the machine the operator develops from. A dev guest that fails to boot takes its own repair environment with it, and a first-boot or first-rebuild defect is exactly what a runtime migration carries — the microvm arc's least-proven subsystem runs precisely there, and two blockers were found in it during review after four earlier passes had each found one.

The second half is the part that is easy to get wrong and expensive to undo. The public inventory's dev example is named the same as a real deployed machine, and that machine has real encrypted key material in the private secrets repo keyed to its name. Marking that name as the new runtime therefore marks a real machine, and the obvious remedy — rename the example — is not a text edit, because re-keying per-machine secret filenames is a human-only host action. So the name has to be chosen before the migration, and the public example carrying a new runtime has to be an example and nothing else.

Filed public because it is mechanism, not identity: no machine name, no key name, no path. The matching constraint is also going into the arc's dev plan, but memory is what reaches an agent that starts from a different entry point.

Refs allod/strategy#20

Risk

R0. Documentation only, in the topic file that already owns VM provisioning.

Validation

The specifics behind it were measured in this workspace: the public inventory entry for the dev example, and the two encrypted per-machine secret filenames that share its name.

A constraint the microvm.nix arc surfaced late, recorded so the agent that eventually does the private-side machine work is told regardless of which document it reads. The first machine to move onto a new guest runtime is a purpose-made throwaway, never the machine the operator develops from. A dev guest that fails to boot takes its own repair environment with it, and a first-boot or first-rebuild defect is exactly what a runtime migration carries — the microvm arc's least-proven subsystem runs precisely there, and two blockers were found in it during review after four earlier passes had each found one. The second half is the part that is easy to get wrong and expensive to undo. The public inventory's dev example is named the same as a real deployed machine, and that machine has real encrypted key material in the private secrets repo keyed to its name. Marking that name as the new runtime therefore marks a real machine, and the obvious remedy — rename the example — is not a text edit, because re-keying per-machine secret filenames is a human-only host action. So the name has to be chosen before the migration, and the public example carrying a new runtime has to be an example and nothing else. Filed public because it is mechanism, not identity: no machine name, no key name, no path. The matching constraint is also going into the arc's dev plan, but memory is what reaches an agent that starts from a different entry point. Refs allod/strategy#20 ## Risk R0. Documentation only, in the topic file that already owns VM provisioning. ## Validation The specifics behind it were measured in this workspace: the public inventory entry for the dev example, and the two encrypted per-machine secret filenames that share its name.

allod-agent added 1 commit

2026-07-30 19:34:04 +01:00