# TEARDOWN LAYER 2 - the host (demo-hp). Before at 00:30:34Z, after at 00:36:07Z.

## pvesm status, side by side
  storage        BEFORE used            AFTER used             change
  felhom-pbs     0                      0                      -
  local          29,325,896 KiB 72.49%  29,325,928 KiB 72.49%  unchanged (not the drill's storage)
  local-lvm      25,278,351 KiB 44.75%  25,278,351 KiB 44.75%  UNCHANGED - the fence held, the
                                                               drill never used local-lvm
  nvme-scratch   66,624,884 KiB  6.78%  15,850,280 KiB  1.61%  ~48.5 GB RELEASED

## /mnt/hdd_1, the storage the brief named
  images/        59 G  ->  9.4 G        and images/336 is GONE ("No such file or directory")
                                        the only directory left there is 9202 - the SCRATCH GUEST's
                                        own disk, which must stay
  dump           4.8 G -> 4.8 G         untouched
  felhom-data    994 M -> 996 M         untouched (grew by its own accord, not by the drill)
  free space     827 G -> 875 G

## guests
  BEFORE   VM 336 tester1-chaos-night running   +  CT 9201 demo-hp   +  CT 9202 demo-hp-scratch
  AFTER    no VMs at all                        +  CT 9201 running   +  CT 9202 running
Both standing guests survived, which is the fence that mattered most on this host.

## the loop, the hog, and the rules
  household unit   stopped AND disabled on the box before the box was destroyed
  diskguard unit   stopped AND disabled; its log was 0 bytes - it never fired once all night
  leftover files   none: no *chaos* or *hog* file under /root or /tmp on demo-hp
  firewall         -P FORWARD ACCEPT, physdev rules: 0, bridge-nf sysctl: 0
                   i.e. exactly the baseline, so none of the three network accidents left a rule
                   behind on a host that also carries two standing guests

## WHAT IS NOT PROVEN HERE
"No leftover drill files" rests on looking at /root and /tmp at depth 1 on demo-hp. It is not an
exhaustive sweep of the host, and it is not claimed to be. The drill's work happened inside VM 336,
which no longer exists, and the accidents that touched the HOST were iptables rules and a `qm set`
disk detach - both verified reverted above.

## LAYER 3 BEGINS - and the first delete attempt was REFUSED, deliberately and correctly
The brief asks for the host record to be deleted "through the acknowledged flow". The flow was read
from the hub's own source rather than guessed (hosts.go:866 onward), which gives the route and the
gates in order:
    POST /hosts/{id}/delete
    gate 1  host ONLINE            -> refused
    gate 2  confirm_host_id mismatch -> 400 (type-to-confirm)
    gate 3  escrow present, delete_escrow != 1 -> 409, moves NOTHING

Attempt 1, made on purpose WITHOUT the escrow acknowledgement, 00:38:37Z:
    POST /hosts/tester-1-022354/delete   confirm_host_id=tester-1-022354
    -> HTTP 409
    -> "Host is ONLINE - deletion is refused (a live agent would receive 401s permanently)."
So gate ONE fired, not gate three. The hub still believed the box was alive: its last report was
~00:23:43Z and the box was destroyed at 00:35:25Z, inside the 30-minute liveness window.

The impact probe the UI calls before offering a delete agrees, and explains itself:
    {"deletable":false,"escrow_present":true,"guests":1,"log_bundles":0,
     "pbs_secret_present":true,"recovery_present":true,"reports":20,"status":"ok","wg_peer_bound":true}

THE RECORD SURVIVED THE REFUSAL, checked properly: GET /hosts/tester-1-022354 -> HTTP 200.
(My first check counted the id on the /hosts page and read "3" then "2", which looked like something
had been removed. It had not: `grep -c` counts LINES CONTAINING a match, not occurrences, and the
page wraps differently between renders. The record's own URL answering 200 is the real test.)

THE WAIT IS THE PRODUCT'S, NOT MINE TO SHORTCUT. The hub should mark the host stale around
00:53:43Z. The acknowledged delete is armed for 00:55Z with a guard that refuses to post while the
host still reads ONLINE. The fence says the hub is never blocked, stopped or changed - so the
correct response to a liveness gate is to wait for it, not to reach into the hub and move it.

## BEFORE-PICTURE OF THE RECORDS THE FENCE SAYS MUST SURVIVE (2026-09-17T00:47:30Z)
Taken while the delete was still pending, because it cannot be taken afterwards. The same reason
ep0 was listed twice: a fence is only proven by a comparison.

  GET /hosts/drill-r50-0a4f9a   -> 200, 26471 bytes     (fence: "drill-r50 stays")
  GET /customers/tester-1       -> 200, 188121 bytes    (fence: "never RESET tester-1")
  hosts the customer page lists -> tester-1-022354      (exactly one: tonight's box)
  all host records right now    -> demo-felhom-8363b5
                                   demo-hp-bb76ea
                                   drill-r50-0a4f9a
                                   tester-1-022354

WHAT MUST BE TRUE AFTERWARDS, written down BEFORE the act so it cannot be adjusted to fit:
  * three host records remain; tester-1-022354 is gone
  * demo-felhom-8363b5, demo-hp-bb76ea and drill-r50-0a4f9a are all still 200
  * /customers/tester-1 still answers 200 - the CUSTOMER is never reset, only its host record goes
  * the customer page then lists ZERO hosts
  * ep0's six snapshots across three namespaces are untouched
