Send the reader between the two halves, in the order that works

The node runbook never told anyone to install an operating system. It created a VM in section 2, configured a firewall in section 3, and ended section 3 by testing that firewall from inside the VM - a VM with no OS on it, because installing one is the guest runbook's section 1 and this page never pointed there.

The two documents interleave and neither said so. The guest runbook claimed the node page should be done through the end of its section 3 first, which cannot happen for the same reason.

There is now an order section near the top, an explicit handoff to install the OS at the end of section 2, and a handoff back to the guest runbook at the end of section 3. The guest runbook defers to that order rather than stating its own.

It also names the trap in the ordering, which is why the sequence is what it is rather than a preference. The Debian installer takes its address by DHCP whatever you intend to pin it to afterwards, and the lease reply needs the inbound rule from section 3. Apply the group before installing, without the DHCP pair, and the installer has no network - which presents as a broken mirror or a dead link, not as a firewall switched on ten minutes earlier. Ticking the Firewall checkbox in section 2 is safe on its own; the group and the policies are what start dropping things.

The link guard caught a wrong anchor while I was writing it, which is the second time it has paid for itself.

docs/building-a-devbox.md

@@ -4,11 +4,18 @@ The guest-side half. Everything here happens inside the VM and is the same on
 any hypervisor.
 
 The node-side half is [proxmox/README.md](../proxmox/README.md): creating the
-VM and applying the firewall to it. **Do that page first, through the end of
-its §3, then come back here.** The two halves are separate documents so that
-another hypervisor can be added later without touching a single guest-side
+VM and applying the firewall to it. The two halves are separate documents so
+that another hypervisor can be added later without touching a single guest-side
 step.
 
+**They interleave rather than running one after the other**, and that page's
+[order section](../proxmox/README.md#what-order-to-do-this-in) is the
+authoritative version. In short: do its §1 and §2, come here for §1 below and
+install the OS, go back for its §3, then return here and carry on from §2.
+
+The reason is that the node firewall's rules are checked from inside the VM,
+and there is nothing to check from until an OS is running.
+
 ---
 
 ## 1. Install Debian

proxmox/README.md

@@ -56,6 +56,33 @@ each layer actually grants.
 
 ---
 
+## What order to do this in
+
+This page and the guest runbook interleave. Doing them strictly in sequence
+does not work, and the reason is worth knowing before you hit it.
+
+1. **§1 and §2 here.** Datacenter firewall on, VM created.
+2. **[Install the OS](../docs/building-a-devbox.md#1-install-debian)**, then
+   come back. That is the guest runbook's §1 and it is the only part of it you
+   need before returning.
+3. **§3 here.** Build the rules and apply them. Both halves of its verification
+   work at this point, including the ones run from inside the VM.
+4. **[The rest of the guest runbook](../docs/building-a-devbox.md#2-addressing-leave-it-on-dhcp-for-now)**,
+   from its §2 onward.
+5. **§4 here** whenever you want a snapshot.
+
+**The rules go on after the OS is installed, not before**, and that ordering is
+load-bearing rather than a matter of taste. The Debian installer takes its
+address by DHCP whatever you intend to pin it to afterwards, and a lease needs
+a reply back in. Apply the group first without the DHCP pair from §3 and the
+installer simply has no network, which presents as a broken mirror or a dead
+link and not as a firewall you switched on ten minutes earlier.
+
+Ticking the Firewall checkbox in §2 is safe on its own. It is the group and the
+policies in §3 that start dropping things.
+
+---
+
 ## 1. Check the datacenter firewall is on
 
 **Do this first.** A per-VM firewall with the datacenter switch off is read
@@ -114,6 +141,19 @@ later visit. That is reason enough to pin it.
 
 ---
 
+## Now install the OS, then come back
+
+The VM exists and has no operating system. Go to
+**[docs/building-a-devbox.md §1](../docs/building-a-devbox.md#1-install-debian)**,
+install Debian, and return here for §3.
+
+Nothing else from the guest runbook is needed yet. Coming back with a booted VM
+is what makes the rest of this page checkable rather than assumed: §3 ends by
+testing the rules from inside, and there is nothing to test from until an OS is
+running.
+
+---
+
 ## 3. The firewall rules
 
 Ten rules, built once as a **security group** and applied to each devbox. Even
@@ -424,6 +464,20 @@ edited, and a rule widened by accident has no symptom on this VM at all.
 
 ---
 
+## The node side is done. Go back to the guest.
+
+Everything above is what a hypervisor does and a guest cannot. The rest is
+inside the VM: pinning the addressing, installing the audit and its timer,
+keeping credentials off the box, and patching.
+
+**Continue at [docs/building-a-devbox.md §2](../docs/building-a-devbox.md#2-addressing-leave-it-on-dhcp-for-now).**
+
+Come back here only for §4, when you want a snapshot. If you added the DHCP
+rules and later pin the address in the guest, you can drop them then - that is
+the one thing on this page the guest runbook can change.
+
+---
+
 ## 4. Snapshots, and why there is no cadence
 
 Take a snapshot before anything you would not want to undo by hand: a kernel