branderson
58a6bc0632
v5's verification step said to run `dejima-guard check` and watch it succeed. A guard with no baseline now refuses to check rather than quietly recording whatever it finds, so following v5 verbatim on a fresh guard reports a failure that is not one, on the step whose only job is to confirm the upgrade worked. The note names the three commands in the order they have to run, and says why accept comes first: a baseline taken later records whatever is on the box by then as normal. The install-key line runs as the guard's own account now, since the host path gained one and that account owns the key it installs and has to read it afterwards. The guard's README stays authoritative for that machine, and this says so rather than growing a second copy of its setup. A test holds the ordering. Nothing here can see the other project's code, so what it can check is that the two commands are named in the order that works, which is the half that goes stale silently when that project changes.
docs
| building-a-devbox.md | The guest-side runbook: install, bootstrap, verify, and what to keep off the machine |
| threat-model.md | What each layer grants, why container escape is deprioritised, and which options were rejected |
| reference.md | The three verdicts, the three addressing modes, and the one config key |
| upgrading.md | Moving a devbox that already exists to a newer version, and why the two halves are counted separately. Start at Updating |
| ../upgrades/ | One note per version: what an operator does in the console and in the guest to reach it |
The node-side half is ../proxmox/README.md, kept separate so another hypervisor can be added without touching a guest-side step.