# Teardown ledger — the campaign venues (2026-08-06)

Three throwaway appliances had accumulated, each with its own storage sub-account, hub record, tunnel
peer and off-site repository. **Two were destroyed here.** The third (`part4`, VM 323) was kept until
Parts 1 and 3 had banked their findings, and goes separately.

## What was matched, and how

Matched on **identity** — customer id → host id → off-site sub-account → wg peer — never on size. The
hub's own delete-preview (`GET /configs/<id>/delete`) was used as an independent enumeration and
agreed with the hand-built one in every field.

## The cascade is the hub's, not a hand-deletion

`POST /configs/<id>/delete` runs the designed teardown: leg 1 hosts (including
`DELETE FROM wg_peers WHERE host_id = ?`), leg 2 the committed reset with **external teardown FIRST**
(off-site store + PBS namespace destroyed), leg 3 residue, leg 4 the customer record and **all** escrow
ciphertext. Its own confirmation: „offsite tároló és PBS névtér megsemmisítve… Visszafordíthatatlan."

**Six gates, all of which had to be satisfied deliberately** — three acknowledgements
(`ack_hosts`/`ack_reset`/`ack_purge`), a type-to-confirm `confirm_id`, an `expect_hosts` race guard,
and — the one that shaped the whole operation — **the cascade refuses to delete a live host**:

> Delete refused: host c11-36d660 is ONLINE. Decommission the box first — the cascade never deletes a
> live host.

There is no hub decommission endpoint; the word appears only in that refusal. So both VMs were
**stopped** and the hub was allowed to age them past its `stale_threshold` (**30m**, from the deployed
`hub-config`) before the cascade would accept them. `rewalk` aged out at ~21 min of silence, `c11` at
~28 min — the two boxes' last reports had landed at different points in their cycles.

## Venue 1 — `c11` "Campaign 11"

| Layer | Item | After |
|---|---|---|
| Machine | `demo-hp` VM **321** `c11-appliance` (200 G + 50 G + 50 G + efidisk, **20 G on disk**) | `qm destroy 321 --purge` — absent from `qm list` |
| Hub host | `c11-36d660` | 0 occurrences |
| Hub customer | `c11` (residue 340 rows, 1 superseded blob) | 0 occurrences |
| Off-site | Storage Box sub-account **`u629488-sub4`** | 0 occurrences |
| Off-site | `ep0` PBS namespace **`c11`** | gone |
| Network | WireGuard peer **10.77.0.5** | 0 occurrences |

## Venue 2 — `rewalk` "Re-walk R-201"

| Layer | Item | After |
|---|---|---|
| Machine | `demo-hp` VM **322** `rewalk-appliance` (**17 G on disk**) | `qm destroy 322 --purge` — absent |
| Hub host | `rewalk-1ab77d` | 0 occurrences |
| Hub customer | `rewalk` (residue 93 rows) | 0 occurrences |
| Off-site | Storage Box sub-account **`u629488-sub5`** | 0 occurrences |
| Off-site | `ep0` PBS namespace **`rewalk`** | gone |
| Network | WireGuard peer **10.77.0.6** | 0 occurrences |

## Space returned, measured

`c11-scratch` used: **58,578,256 KiB → 21,228,640 KiB** = **37.3 GB reclaimed**, against 20 G + 17 G
measured before deletion. Free went 874.8 GB → 912.1 GB.

## The positive control

An absence proves nothing unless the instrument can still find something. After each cascade the same
greps were run for **`part4`**, which must survive: host `part4-905bdb` still present (2 rows), wg peer
**10.77.0.7** still present, `ep0` namespace `part4` still present. So the zero counts above are
measurements, not a broken query.

`ep0` namespaces after both teardowns: `demo-felhom`, `demo-hp`, `part4` — exactly the three that
should remain. Nothing on `ep0` outside the campaign's own namespaces was touched.

## Untouched, as scoped

`demo-hp` itself and its guest 9201, `demo-felhom`, `drill-r50` (VM 300), DooPlex, the tester's box,
and every `ep0` namespace that is not the campaign's own.


## Venue 3 — `part4` "Part 4 - no hand upgrade" (destroyed after the findings were written)

Kept deliberately while Parts 1 and 3 read it: it was standing in the exact failed half-B state, and
tearing it down first would have destroyed the evidence. Destroyed only after the diagnoses were
committed (`70b6260`).

| Layer | Item | After |
|---|---|---|
| Machine | `demo-hp` VM **323** `part4-appliance` (**16 G on disk**) | `qm destroy 323 --purge` — absent |
| Hub host | `part4-905bdb` | 0 occurrences |
| Hub customer | `part4` (residue 66 rows) | 0 occurrences |
| Off-site | Storage Box sub-account **`u629488-sub6`** | 0 occurrences |
| Off-site | `ep0` PBS namespace **`part4`** | gone |
| Network | WireGuard peer **10.77.0.7** | 0 occurrences |

Positive control for this one: **`demo-hp-bb76ea`** must survive the same greps, and does (2 rows).

## Final state

- `demo-hp` guests: **VM 300 `drill-r50`** and **CT 9201** (demo-hp's own customer guest). All three
  campaign appliances are gone.
- `ep0` namespaces: **`demo-felhom`, `demo-hp`** — only the two real demo boxes remain.
- `c11-scratch` used: **58,578,256 KiB → 5,184,912 KiB = 53.4 GB reclaimed** across the three venues
  (20 G + 17 G + 16 G measured beforehand). Free 874.8 GB → 928.2 GB.

## Secrets that died with the venues

Each cascade purged the customer record **and all escrow ciphertext** (leg 4). The recovery codes for
these venues therefore no longer open anything: `R_C11_REWALK` and `R_PART4` in the operator's
credentials file are now inert and can be removed at the operator's convenience. The working copies
under `~/.config/part4/` on DooPlex were shredded.

**One operational note carried over from the walk:** the `part4` retrieval passphrase was leaked into
a session transcript on 2026-08-06 and rotated at the time; the customer it belonged to no longer
exists.

---

## ⚠ CORRECTION, 2026-08-07 — the "0 occurrences" claims above are narrower than they read

Verifying the `finalwalk` teardown with a **full census** (every table, every column) rather than a
per-table query found rows this ledger's method could not see. `app_log_issues` is **not** covered by
the cascade's residue purge, and it still holds **`c11` 40 rows, `rewalk` 20, `part4` 24** — plus 29
for `finalwalk`.

The tables this ledger *did* check are genuinely at zero; the claim that is wrong is the implied
completeness of the sweep. **A per-table absence query is not a census.** Filed as **R-244**, with the
reason the leg is not trivial (the table is a fleet-wide aggregate whose rows are shared with live
customers, so the fix is a de-reference plus an orphan sweep, not a delete). No secret material is
involved. Full working: `teardown-finalwalk-2026-08-07.md`.
