# Milestone 9 diagnostics

Current execution state and acceptance are in [PLANS.md](../../PLANS.md). This
file records bounded host preparation failures, not systemd acceptance evidence.
All timestamps are UTC; the VM is disposable and contains synthetic data only.

## 2026-10-25T18:28:55Z — M9.1-R8, initial create parse

`python3 tests/vm/create.py` registered only
`wga-m9-debian137-20261025` (UUID
`b14c850b-a21e-4a56-acca-785590f0c4ac`) and stopped before VM configuration.
Cause: actual VirtualBox 7.2.8 machine-readable output contains an indented
`rec_screen0` recording section marker. The strict parser rejected it. Read-only
inventory showed the target powered off with only its `.vbox` file; the existing
Windows VMs were unchanged. A narrow marker parser repair and synthetic test
passed independent re-review. Creation cannot be rerun because the target path
is occupied; a UUID-pinned resume procedure was reviewed instead.

## 2026-10-25T18:35:00Z — M9.1-R5/R8, resume final guard

`python3 tests/vm/resume.py` verified the exact partial target, then configured
the VDI, pinned installer ISO, NAT-only NICs, and private host marker/manifest.
Its final read-only guard refused actual quoted SATA attachment keys and
per-port metadata. `python3 tests/vm/guard.py check` first reported an
unrecognized machine-readable key; after quoted-key parsing it reported an
unrecognized attachment-shaped metadata key. Read-only `showvminfo` identified
`SATA-IsEjected-1-0` among the actual metadata. Focused repairs accepted only
the observed key forms, required the exact SATA controller, and rejected
unrecognized/extra media and a symlinked target folder. Independent re-review
closed the findings; the integrated synthetic VM suite passed 26/26 and the
actual read-only `guard.py check` exited 0. No second resume or VM start occurred.

## 2026-10-25T18:47:20Z — M9.1 unattended prerequisite (recorded)

The first no-change `VBoxManage unattended install ... --dry-run --start-vm=none`
refused a single-label hostname. Repeating with the fully qualified synthetic
hostname `wga-m9-debian137.invalid` exited 0, including a separate dry run with
the local Guest Additions ISO. Both used current-user mode-`0600` private
synthetic password files. VirtualBox prints password values in dry-run output;
the wrapper redacted them before display. These runs created no files or VM
configuration changes. Actual installer preparation, boot, Guest Additions,
and guest systemd remain unverified.

## 2026-10-25T18:53:05Z — M9.1 installer preparation (recorded)

Independent review found that the first prepare-only script omitted the
required `--iso` and used an unsupported root-password option; its media
comparison also rejected VirtualBox's empty SATA ports. M9.1-R9/R10 repairs
passed re-review and 33/33 synthetic VM tests. The corrected
`python3 tests/vm/install_prepare.py` exited 0 outside the sandbox with
password-bearing VirtualBox output suppressed. Read-only `showvminfo` showed the
same pinned VM powered off, NAT-only, with its one VDI at SATA 0 and the private
generated `Unattended-<UUID>-aux-iso.viso` at SATA 1. Generated installer files
were mode `0600` in the mode-`0700` target folder. The normal guard intentionally
refuses `.viso`; first start awaits a separately reviewed installer-state guard.

## 2026-10-26T20:30:15Z — User stopped M9.1

The installer-state guard and start code passed independent review after a
hard-link isolation repair; the full synthetic VM suite passed 44/44. Actual
`python3 tests/vm/install_boot.py check` and `start` exited 0 against only the
pinned target. Read-only `list runningvms` listed only that VM; a private
console screenshot showed Debian base-system installation at 6%. Completion
was not observed. After the user explicitly stopped Milestone 9, the exact VM
was powered off; a subsequent read-only running-VM inventory was empty. Guest
installation, Guest Additions, systemd, WireGuard, and M9 acceptance remain
unverified. No existing Windows VM, production resource, Git commit, or
deployment was touched.