## 2026-09-16T17:50:47Z TEARDOWN, LAYER 1 — the machine
purging VM 335 from related configurations..
--- qm list after:
--- any 335 disk left:
ls: cannot access '/mnt/hdd_1/images/335': No such file or directory
--- FENCE CHECK, demo-hp own containers:
VMID       Status     Lock         Name                
9201       running                 demo-hp             
9202       running                 demo-hp-scratch     
##  LAYER 1 DONE: VM 335 stopped and destroyed with --purge --destroy-unreferenced-disks.
##    `qm list` empty · /mnt/hdd_1/images/335 absent · no file matching *335* on the drive.
##    FENCE CHECK: demo-hp's own containers 9201 („demo-hp") and 9202 („demo-hp-scratch") both still
##    running and untouched, as required.
##  EVIDENCE WENT FIRST (R-320): controller debug log (26 288 B), stacks, disks, the backup page and
##    the hub host page were pulled BEFORE the destroy. Not collected: the agent journal from the box
##    itself — root SSH is refused on the appliance (the agent hardens sshd; operator access is a
##    separate tunnel-only port) — stated rather than quietly omitted.
##  SECRET-LEAK CHECK, done properly this time: six real secret VALUES (dashboard password, app admin
##    password, claim code, recovery code, install root password, owner passphrase) used as needles
##    against all 41 evidence files. Planted positive control matched 6/6, so the grep works; the
##    committed evidence matched 0 files. The earlier count of „22" was the WORD „password" in labels
##    like „Password set" — a word count, not a leak check.
## 2026-09-16T18:16:43Z TEARDOWN, LAYER 3 — delete the HOST record, keep the customer (never RESET)
  pre-state: {"deletable":true,"escrow_present":true,"guests":1,"log_bundles":0,"pbs_secret_present":true,"recovery_present":true,"reports":9,"status":"stale","wg_peer_bound":true}
  delete POST at 2026-09-16T18:16:43Z
  http=409
  host record after: 200  (404 = gone)
  customer record after: 200  (200 = KEPT)
  hub log right after the delete:
    2026/09/16 20:16:30 [INFO] Host staleness: tester-1-33b6a9 ok → stale (host_stale)
    2026/09/16 20:16:31 [INFO] Operator email sent for tester-1/host_stale
    2026/09/16 20:16:43 [WARN] host delete refused: tester-1-33b6a9 has key escrow (acknowledgement missing)
## 2026-09-16T18:17:45Z delete retried WITH the escrow acknowledgement (retained custody)
  delete POST at 2026-09-16T18:17:45Z
  http=303
  host record after: 404  (404 = gone)
  customer record after: 200  (200 = KEPT)
  hub log right after:
    2026/09/16 20:16:31 [INFO] Operator email sent for tester-1/host_stale
    2026/09/16 20:16:43 [WARN] host delete refused: tester-1-33b6a9 has key escrow (acknowledgement missing)
    2026/09/16 20:17:30 [INFO] Staleness: tester-1 ok → stale (node_stale)
    2026/09/16 20:17:31 [INFO] Operator email sent for tester-1/node_stale
    2026/09/16 20:17:46 [INFO] host deleted: tester-1-33b6a9 (escrow deleted: true)
    2026/09/16 20:17:46 [INFO] self-bind link emailed to the registered address of tester-1
    2026/09/16 20:17:46 [INFO] self-bind link (hash 69b8422e…, valid 7 days) emailed to the registered address of tester-1
    2026/09/16 20:17:46 [INFO] self-bind link auto-minted for tester-1 on host delete (the console banner's promised email now exists)
##  THE FIRST DELETE WAS REFUSED, and it was right to refuse (18:16:43Z):
##    „host delete refused: tester-1-33b6a9 has key escrow (acknowledgement missing)" -> HTTP 409,
##    host record still 200, customer still 200 — nothing was dropped.
##    This box carries a REAL key escrow because the household performed the ceremony an hour ago, and
##    the hub will not discard a customer's sealed package on an unacknowledged delete. The documented
##    action is to acknowledge it, which moves the escrow to RETAINED custody rather than destroying it.
##  AND THE STALENESS ALARM FIRED TRUTHFULLY: „Host staleness: tester-1-33b6a9 ok → stale (host_stale)"
##    at 20:16:30 CEST with an operator mail one second later — the box really was gone by then.
##  LAYER 3 DONE (18:17:45Z), with the acknowledgement given:
##    POST /hosts/tester-1-33b6a9/delete (confirm_host_id + delete_escrow=1) -> 303
##    host record  -> 404 (gone)      customer record -> 200 (KEPT; RESET was never used)
##    hub log, same second:
##      „host deleted: tester-1-33b6a9 (escrow deleted: true)"
##      „self-bind link emailed to the registered address of tester-1"
##      „self-bind link (hash 69b8422e…, valid 7 days) emailed to the registered address of tester-1"
##      „self-bind link auto-minted for tester-1 on host delete (the console banner's promised email
##       now exists)"
##    So R-509's automatic e-mail fired again, on a second box, at the second of the delete.
##  A WORDING MISMATCH WORTH CHECKING RATHER THAN REPEATING: the refusal text says the acknowledgement
##    moves the escrow „to retained custody", while the log line says „escrow deleted: true". Those are
##    two different statements about a household's last key, so the customer record is read below
##    instead of trusting either sentence.
##  THE AUTOMATIC CONNECT E-MAIL — PROVEN AGAIN, on a second box in the same session:
##    host delete at 2026-09-16T18:17:45Z  ->  mail in the customer's inbox at 18:17:46Z (ONE second),
##    „[Felhom] Kösd össze a Felhom dobozodat", to tester1@felhom.eu, body „Elkészült a Felhom dobozod,
##    és készen áll az összekötésre… https://hub.felhom.eu/bind/…", link valid 7 days.
##    Requirement was two minutes. R-509 now has two independent live proofs today (12:23:00Z and
##    18:17:46Z), on two different boxes.
##  THE ESCROW'S FATE, answered from the hub's own text rather than from either log line:
##    „host deletion only demotes custody, never destroys it"
##    „1. The host(s) will be deleted — recovery-key custody is demoted to RETAINED custody, not
##     destroyed." …and the customer delete is named as „the one true purge point".
##    So the acknowledgement demoted the custody; it did not destroy the household's sealed package.
##    The log line „escrow deleted: true" is the FLAG's name, not the effect — recorded as a row.
##  CUSTOMER RECORD AFTER EVERYTHING: present (200), with e-mail, domain, tunnel and DR tier intact,
##    and „waiting — no host enrolled yet — the Day-0 install enrolls…" — exactly the state a customer
##    is in between boxes. RESET was never used.
