Evidence-survival check FIRST: HEAD == origin/main == 7efb7a5, and every artefact
confirmed present in origin/main with git cat-file, including all 27 evidence
files. Nothing died with the rig.
1. VM 311 destroyed by exact VMID. qm list now shows only drill-r50; 311.conf does
not exist; images/311 gone. 126 GB returned - nvme 133G used / 758G avail ->
6.7G / 884G. A first attempt stopped the VM but its destroy never ran, killed by
an unescaped paren in my own echo; caught by checking qm list rather than the
exit code.
2. c10-scratch removed by name. storage.cfg 5 -> 4 entries. felhom-backup shares
the same path and is intact, config unchanged.
3. PBS on DooPlex (Tier 2). Identity confirmed first - the target carried the
comment this campaign set at creation. Datastore felhom-c10, user c10@pbs,
token !box, both ACLs and the on-disk chunkstore all gone; felhom-spike,
felhom@pbs, felhom@pbs!n100 and /mnt/5_hdd/backup/demo-felhom all intact. Only
the campaign's entries disappeared. "user delete" is not a PBS subcommand - it
printed usage and the user survived rc=0; caught by re-reading the user list.
4. Restic subaccount 281530 deleted after asserting home==felhom-campaign10 and
the description names Campaign 10 - the script aborts otherwise. 4 -> 3
subaccounts; demo-felhom, peti-felhom and demo-hp all present.
5. Hub customer c10-soak. The ONLINE gate REFUSED with HTTP 409 for 18 consecutive
attempts, exactly as anticipated (customer_delete.go:98-102, :146). Predicted
deletable at last-report 09:38:19 + 30 min = 10:08:19; measured 303 at 10:08:23.
Verified positively: 0 customer rows, 0 host/appliance rows, GET
/customers/c10-soak -> 404, and the hub logged the DELETE cascade COMPLETE with
residue purged. No /appliances/discard was needed - the appliance record was
bound and went with the cascade. drill-r50 verified INTACT (200, VM 300 present).
All 12 credential files shredded and the directory removed.
Register rows NOT written: app-catalog-felhom.eu has an uncommitted working tree
including scripts/check-volume-persistence.py, so the parallel catalog session is
still open and owns the register. R-156/R-157/R-158 rows and rankings remain owed,
itemised in the doc - and that session's volume-persistence checker looks like
R-156's fix shape, so the two should be reconciled before filing.
admin
482af37b7d
