# TEARDOWN LAYER 3 - the hub. Completed 2026-09-17T07:25:13Z.

## THE ACT
  GET  /hosts/tester-1-022354/delete-impact  (07:24:58Z)
       {"deletable":true,"escrow_present":true,"guests":1,"log_bundles":0,"pbs_secret_present":true,
        "recovery_present":true,"reports":20,"status":"down","wg_peer_bound":true}
  POST /hosts/tester-1-022354/delete   confirm_host_id=tester-1-022354   delete_escrow=1
       -> HTTP 303, Location: /hosts
The escrow acknowledgement moves the escrow to RETAINED CUSTODY; it does not destroy it
(the handler's own refusal text, and R-544).

## THE AFTER-PICTURE, against the expectation written down at 00:47:30Z BEFORE the act
  expected                                         measured
  tester-1-022354 gone                             GET /hosts/tester-1-022354      -> 404
  drill-r50 survives                               GET /hosts/drill-r50-0a4f9a     -> 200
  demo boxes survive                               GET /hosts/demo-hp-bb76ea       -> 200
                                                   GET /hosts/demo-felhom-8363b5   -> 200
  the CUSTOMER is never reset                      GET /customers/tester-1         -> 200
  three host records left                          demo-felhom-8363b5, demo-hp-bb76ea, drill-r50-0a4f9a
  customer page lists zero hosts                   0 links to the deleted host; its 4 remaining
                                                   mentions are EVENT HISTORY rows (host_stale,
                                                   host_down), which correctly stay
  ep0 untouched                                    3 namespaces, 6 snapshots, 16G used - identical to
                                                   the readings of 00:17:15Z and 00:36:52Z
Every line matched. Nothing had to be re-interpreted after the fact.

## THE AUTOMATIC CONNECT MAIL, quoted (arrived 07:25:15Z - TWO SECONDS after the delete)
  From: monitoring@felhom.eu   To: tester1@felhom.eu
  Subject: [Felhom] Kösd össze a Felhom dobozodat

  Kedves Ügyfél!

  Elkészült a Felhom dobozod, és készen áll az összekötésre. Az alábbi hivatkozáson
  tudod te magad összekötni a fiókoddal — nincs szükség bejelentkezésre:

  https://hub.felhom.eu/bind/<one-time token REDACTED>

  A hivatkozás megnyitása után két adatot kell megadnod:

    1. A párosító kódot, amely a doboz képernyőjén (a monitoron) látható.
    2. A tulajdonosi jelmondatodat (az 5 szóból álló kifejezést), amelyet a
       Felhom üzemeltetőjétől kaptál — személyesen vagy telefonon, e-mailben
       soha. Ez igazolja, hogy a fiók a tiéd.

  A hivatkozás 7 napig érvényes. Biztonsági okból 5 sikertelen próbálkozás után
  zárolódik — ilyenkor vedd fel a kapcsolatot az ügyfélszolgálattal.

  Ha nem te kérted ezt, hagyd figyelmen kívül ezt az e-mailt.

  Üdvözlettel,
  Felhom.eu

WHY THIS QUOTE IS PROVABLY TONIGHT'S: the mailbox baseline at 00:38Z held NO self-bind mail newer
than 18:17:46Z. This one is 07:25:15Z. The brief's warning - that an earlier claim about this mail had
been read from yesterday's delete - cannot apply to it.
Also true and delivered while the box was dead: host_down for tester-1-022354 at 01:27:31Z
("no report for 1h"), and host_stale before it (shown "sent" on the customer page). Both TRUE.

## THE ELEVENTH INSTRUMENT FAULT - and the one that cost the most time
The first delete (00:38:37Z) was correctly refused: the host was still inside its liveness window.
I armed a retry for 00:55Z behind a guard: "do not post while the host page contains ONLINE".
That guard COULD NEVER PASS. The word is inside a JavaScript string that is always on the page:
    ... (d.deletable ? '' : ' Host is ONLINE — deletion will be refused.')
So the guard refused six times, 00:55Z to 01:20Z, while the hub's own structured answer would have
said "status":"down" from about 00:54Z. Then the retry loop ran out and exited 0.
The session did not resume until 07:24Z (after a login), so the hub layer finished ~6 hours after the
rest of the teardown. The fix was the obvious one and should have been the first one: ask the
endpoint that returns a STATUS FIELD, not grep a page for a word. Same class as every other fault
tonight - a probe that cannot fail in the way I needed it to is not a measurement.
