rebuild-vm: run verify-vm after a development VM's switch #74

Merged

vnprc merged 2 commits from agent/rebuild-verify into master

2026-10-01 21:00:08 +01:00

allod-agent commented

2026-10-01 17:31:34 +01:00

Member

rebuild-vm now runs verify-vm after a development VM's switch, so a rebuild that advertises a repo the machine never cloned reports it missing instead of leaving a dangling memory link to be found at the next agent session. For a running machine nothing else changes: the switch itself is identical, a privacy VM (no forge key) is not verified, and a healthy dev VM prints the verifier's one passing line. Repair stays the explicit verify-vm --repair <vm>, which the failure line names, with the target override carried through when one was given. What proves it: the mocked rebuild-vm suite (17 cases, 5 new) in the provisioning-contract check. If it is wrong, revert; the verifier is additive and nothing on a machine is written by it.

Closes allod/nexus#71
Refs allod/strategy#62

Risk

R2: a localized behavior change in one host-side script, additive after the switch, with the verifier itself unchanged. The worst credible failure after validation is a false failure line after a successful switch, which the operator resolves by reading the verifier's own output. Rollback is a straight revert.

Validation

bash tests/rebuild-vm.sh: 17 passed, including call order (nixos-rebuild then verify-vm), target override reaching the verifier and its repair hint, a privacy VM never verified, and a failing verifier failing the rebuild after the switch ran.
nix build .#checks.x86_64-linux.provisioning-contract: green.
Sabotage: disabling the verifier call failed the order case; dropping the override from the hint failed the override case; both restored.
One cold cross-family review (codex gpt-5.6-sol): its repair-hint finding and two excess items were fixed in the second commit; its finding that the verifier reads the inventory checkout rather than the deploy pin describes the contract provision-vm already uses and was not acted on.

`rebuild-vm` now runs `verify-vm` after a development VM's switch, so a rebuild that advertises a repo the machine never cloned reports it missing instead of leaving a dangling memory link to be found at the next agent session. For a running machine nothing else changes: the switch itself is identical, a privacy VM (no forge key) is not verified, and a healthy dev VM prints the verifier's one passing line. Repair stays the explicit `verify-vm --repair <vm>`, which the failure line names, with the target override carried through when one was given. What proves it: the mocked `rebuild-vm` suite (17 cases, 5 new) in the `provisioning-contract` check. If it is wrong, revert; the verifier is additive and nothing on a machine is written by it. Closes allod/nexus#71 Refs allod/strategy#62 ## Risk R2: a localized behavior change in one host-side script, additive after the switch, with the verifier itself unchanged. The worst credible failure after validation is a false failure line after a successful switch, which the operator resolves by reading the verifier's own output. Rollback is a straight revert. ## Validation - `bash tests/rebuild-vm.sh`: 17 passed, including call order (nixos-rebuild then verify-vm), target override reaching the verifier and its repair hint, a privacy VM never verified, and a failing verifier failing the rebuild after the switch ran. - `nix build .#checks.x86_64-linux.provisioning-contract`: green. - Sabotage: disabling the verifier call failed the order case; dropping the override from the hint failed the override case; both restored. - One cold cross-family review (codex gpt-5.6-sol): its repair-hint finding and two excess items were fixed in the second commit; its finding that the verifier reads the inventory checkout rather than the deploy pin describes the contract `provision-vm` already uses and was not acted on.

allod-agent added 2 commits

2026-10-01 17:31:34 +01:00

rebuild-vm: verify after the switch on development VMs 6f9af3849a

A rebuild that advertises a new repo never ran the guest bootstrap, so
the repo could stay uncloned with nothing reporting it. Running the
clone calls here would pull into trees other agents are working in,
so rebuild-vm instead runs verify-vm on the target after a successful
switch; repair stays the explicit verify-vm --repair.

Refs allod/nexus#71

rebuild-vm: carry the target override into the repair hint 183af760ec

Fix round from cold review: with an explicit target IP, 'verify-vm
--repair' needs the same IP to reach the host, so the die message now
includes it when one was given. Also drops a comment restating the
condition under it and a test assertion over the stub's own text
rather than rebuild-vm's behavior.

Refs allod/nexus#71

allod-agent referenced this pull request from allod/strategy

2026-10-01 18:14:21 +01:00

Host-provided repos: inject and refresh a checkout from the hypervisor when the guest may not read its remote #62

allod-agent added 1 commit

2026-10-01 20:51:02 +01:00

Merge remote-tracking branch 'origin/master' into agent/rebuild-verify 5b63f13bef