# TEARDOWN LAYER 1 - the machine. 2026-09-17T00:35:25Z

## A GUARD BEFORE AN IRREVERSIBLE ACT
The destroy was gated on the VM's NAME, not just its number:
    NAME=$(qm config 336 | awk '/^name:/{print $2}')
    [ "$NAME" != "tester1-chaos-night" ] && REFUSE
A VMID is a number that can be mistyped, and 9201 and 9202 - a standing demo box and the scratch
guest - live on the same host. The guard passed: name was `tester1-chaos-night`.

## WHAT WAS DONE
  qm stop 336            -> status: stopped
  qm destroy 336 --purge 1 --destroy-unreferenced-disks 1
                         -> "purging VM 336 from related configurations.."

## WHAT IS TRUE AFTERWARDS (each one checked, not assumed)
  qm list                -> NO VMs at all on demo-hp
  pct list               -> 9201 demo-hp (running), 9202 demo-hp-scratch (running)   <- both SURVIVE
  /mnt/hdd_1/images/336  -> "No such file or directory"

So all three disks went with it - the 32 G system disk, the 100 G data disk pulled in round 11, and
the 64 G disk I added in Phase 0 to extend the thin pool I had filled. The fixture deviation
recorded in teardown-baseline.txt is therefore gone from the host, but preserved in the record.

## THE FENCES, RE-STATED AGAINST WHAT ACTUALLY HAPPENED
  DooPlex            never a target; only builds and this repo ran here
  Peti's box         untouched
  ep0                read only, all night; the final listing is taken separately
  drill-r50          its hub record still exists (seen in /hosts) - not touched
  demo boxes         9201 and 9202 still running, their standing apps and bentopdf untouched
  local-lvm          never used for the drill box: its disks were on nvme-scratch (/mnt/hdd_1)
  prune              never run anywhere
  tester-1           the CUSTOMER record is never RESET; only tonight's HOST record is deleted,
                     and that is layer 3, done through the acknowledged flow
