bastion/docs/ARCHITECTURE.md

@@ -485,12 +485,20 @@ Hardcoded `/dev/sda` default broke NVMe-only machines. Fix: default to empty str
 integration coverage for `provision debug` (`tests/integration/pxe-rescue.test.ts`) showed the
 rescue environment coming up correctly — the bastion serves the kernel and initrd, Anaconda
 boots, fetches `debug.ks`, and reaches its installer environment — but **nothing ever listens on
-port 22**. Confirmed on aarch64 by probing the port for 30 minutes while the Anaconda environment
+port 22**.
-was demonstrably running (NetworkManager, polkitd, rsyslog all up), and reproduced on x86_64 with
-KVM, so it is not architecture-specific and not an emulation artefact.
 
-This is orthogonal to the multi-architecture work: the same failure occurs on x86_64, which that
+Strength of the evidence, stated precisely because it decides where to look next:
-work does not touch. Leads worth checking, in order:
+- **aarch64 — direct.** Port 22 probed every 20s for 30 minutes while the Anaconda installer
+  environment was demonstrably running (NetworkManager, polkitd, rsyslog on the console). Never
+  opened.
+- **x86_64 — corroborating, not conclusive.** One clean KVM run (943s) where SSH never became
+  available inside a 15-minute budget. That VM's progress into the rescue environment was *not*
+  observed — vitest's final reporter discards the streamed log — so it is consistent with the
+  aarch64 result but does not independently prove it. Re-run with `KEEP_VM=1` and probe port 22
+  directly to settle it.
+
+If the x86_64 result holds up, this is orthogonal to the multi-architecture work, since x86_64 is
+untouched by it. Leads worth checking, in order:
 - Does `inst.sshd` actually start `sshd` in `inst.rescue` mode, or only in install mode? The
   port never opens, so this is the prime suspect — an auth problem would still show an open port.
 - `sshkey` may apply only to the *installed* system, leaving the installer environment