Operator-confirmed. Stopped under a name guard (demo-hp carries its own 9201),
aged past the hub's stale_threshold read from the DEPLOYED ConfigMap (30m), and
polled delete-impact until deletable:true — treating an empty response as retry,
never as success. Cascade + qm destroy --purge, guarded a second time.
Every layer verified absent against a positive control that must survive and does:
VM 300 drill-r50 and demo-hp's own guest 9201 still there; ep0 namespaces
demo-felhom + demo-hp still there; wg peers .2 .3 .4 .250 still on the live wg0;
hub rows for demo-felhom, demo-hp, peti-felhom untouched. 16.64 GiB returned
against 17 G measured.
RECORDED FOR THE NEXT TEARDOWN: the WG peer is removed on a ~5-minute SCHEDULE,
not by the cascade. Immediately after the delete the hub row was gone while
10.77.0.5 was still on ep0's live wg0; wgsync had last run 37 seconds before the
cascade, and the next push (4 peers) removed it, verified on the live interface at
16:57:07Z. The previous ledger checked this after it had already converged, so it
read as instantaneous — a teardown that checks too soon would file a false finding.
R-244 grew by 30 rows (app_log_issues), PREDICTED in the pre-run enumeration
rather than discovered afterwards. Running total across torn-down venues ~101.
Nothing here claims a clean teardown.
Storage Box layer evidenced from the hub's own deprovision log: the HETZNER_API
token in ~/.config/credentials cannot see box 611421 (subaccounts -> 404,
storage_boxes -> 200 with 0 entries) — it is scoped to another project.
Capability map: the unaided-recovery row turns FAILED -> PROVEN-LIVE, scoped, with
what it still does not claim stated in the row itself: shape (c) did not fire
positively (with the mint guard holding there is no local key, so the offer comes
from shape (a)); and 'unaided' here means possible-without-a-shell, not obvious,
because two obstacles are unsignposted.
OPEN-ITEMS: R-201 closed with its evidence. Five new rows R-249..R-253 (the
retrieval passphrase in page HTML; the host-key scan ladder vs AAAA settle; the
listing's per-tag rows; the two unsignposted restore steps). R-243 annotated
rather than re-filed: on a REBUILD offsite_delivery_stuck does not skip, so the
row's gap is narrower than it reads.
STATUS.md: headline changed, and trimmed 97 -> 92 lines rather than extended, per
its own header.
Teardown recorded as OWED with its before-measurements, the stop-and-age gate, and
the positive controls that must survive.
THE DATA: PASS. All three sentinels byte-identical out of snapshot 5b0f20f7,
including the accented filename's bytes, read back as bytes from the live path.
THE JOURNEY: PASS — the first time in five walks. Zero guest command lines were
needed to progress; the previous walk needed three. The reset-code hatch was used
once, in Phase A only.
§5's observation, which stands on its own whatever the verdict: at 14:58:52Z the
rebuilt box collected its re-staged credential, configured the transport, and
REFUSED TO MINT a repository password over the sealed package the hub holds. At
the equivalent moment the previous walk minted a fresh key and lost the journey
silently at 03:18. Sampled every 20s from T0: no key at any moment.
Honest about which shape fired: with the mint guard holding there is no local key,
so the offer comes from shape (a), not shape (c). Shape (c) was measured in Phase A
in its NEGATIVE half (equal hashes, correctly silent). This proves the mint guard
positively and the discriminator negatively.
RTO 71.7s login to open store, of which 12.44s was the unseal and ~22s my own
CSRF harness retry.
Two new customer-facing obstacles, neither needing a shell but neither signposted:
the restore refuses on unattached drives, and refuses because the app is not
installed on a page that says the restore reinstalls it.
Written before the destruction, per §9.9. A fresh install landed on the VOUCHED
set with no hand upgrade (controller 0.206.0, agent 0.127.0) — R-239's delivery
gap is closed for this run, which is the first of the five walks where the box
under test is the box a customer receives.
Both §4.6 pre-destruction checks pass, neither previously exercised on a clean
box: the recovery offer is correctly SILENT (shape (c) compares equal — the two
key hashes are byte-identical on box and hub), and the restore page lists the app
with the future-backup toggle OFF (R-237's fix, which the last walk measured
failing).
Also recorded: the §4.5 gate caught a harness fault (a toggle sent as enabled=1
rather than enabled=on) that had produced a green 'ok' over a zero-snapshot
repository — the exact shape the gate exists for.
admin