R-212 CLOSED: the three orphaned stores deleted after a corrected list (~1.45 GB)

The register said 'two set-aside stores, ~1.2 GB'. Measured before touching
anything: THREE set-aside stores totalling ~1.45 GB, and the thing that was
exactly 1.2 GB was demo-felhom's LIVE felhom-repo. Matching on the size would
have deleted a working repository. The operator was shown the corrected list
and confirmed 'delete all three'.

Deleted: demo-felhom orphaned-20260717 (1.4 G) + orphaned-20260718 (3.0 M);
demo-hp orphaned-20260804 (43 M). Both LIVE repos untouched, confirmed by full
listings before and after on each account.

Proof nothing live was caught: a real off-site run on demo-hp immediately
afterwards returned status ok, orphaned false, no error, 6 snapshots.

Method note recorded for the next session: the storage box has a RESTRICTED
shell. 'test -d X && rm -rf -- X' returns 'Command not found' and does nothing
(it failed CLOSED, verified by an unchanged listing); 'rm -r <path>' as one
simple command is the working form.

REPORT-r204-item4.md

@@ -125,7 +125,7 @@ initially seeded `Status: "blocked"` through `SaveCustomerConfig`, whose INSERT
 column — so the customer was never actually blocked and the assertion would have been vacuous. It now
 goes through `SetCustomerConfigStatus` **and asserts `IsCustomerBlocked` before proceeding**.
 
-## 8. Part 4 — HALTED AT ITS STOP. Nothing was deleted.
+## 8. Part 4 — STOPPED, corrected, then COMPLETED with the operator's confirmation
 
 §8.7: *"If the paths do not match R-193's record exactly, STOP. A near-match on a protected endpoint
 is not a match."* **They do not match.**
@@ -143,7 +143,29 @@ Measured read-only over SFTP, using each box's own credential, from inside its g
 The ruling says *"~1.2 GB across the two demo boxes, in set-aside stores"*. Reality: **three** set-aside
 stores totalling **~1.45 GB** — and **the figure that matches ~1.2 GB is demo-felhom's LIVE
 `felhom-repo`**. Had the size been used to identify the target, the live repository would have been
-deleted. **Filed as R-212, WAITING-ON-OPERATOR.**
+deleted. Filed as **R-212**, and the operator was asked with the corrected list.
+
+**The operator confirmed *delete all three*, and all three were deleted.**
+
+| Account | Deleted | Freed |
+|---|---|---|
+| `u629488-sub1` | `felhom-repo.orphaned-20260718` | 3.0 M |
+| `u629488-sub1` | `felhom-repo.orphaned-20260717` | 1.4 G |
+| `u629488-sub3` | `felhom-repo.orphaned-20260804` | 43 M |
+
+**AFTER, on each account, a full listing:** `u629488-sub1` holds `.ssh` + `felhom-repo` (**1.2 G**,
+live); `u629488-sub3` holds `.ssh` + `felhom-repo` (**582 K**, live). **Nothing outside the three named
+paths was touched**, and no prune job, datastore or live repository was involved.
+
+**Proof nothing live was caught:** a REAL off-site run triggered on demo-hp immediately afterwards
+(`POST /backup/offbox/run`, authenticated + CSRF) returned `status: "ok"`, `orphaned: false`,
+`last_error: ""`, `last_run: 2026-08-05T09:14:02Z`, `last_duration: 1m24s`, 6 snapshots.
+
+**METHOD NOTE, worth carrying forward.** The Hetzner storage box runs a **restricted shell**: no shell
+operators, no `test`, no GNU long flags. The first attempt used `test -d X && rm -rf -- X` and got
+*"Command not found. Use 'help' to get a list of available commands."* — **it failed CLOSED, verified
+by a byte-identical before/after listing.** `rm -r <path>` issued as ONE simple command is the working
+form, and the smallest store was deleted first to confirm the syntax before the 1.4 GB one.
 
 ## 9. Live validation
 
@@ -153,7 +175,7 @@ deleted. **Filed as R-212, WAITING-ON-OPERATOR.**
 | 2 | **The declared state, produced live without wiping a box** | demo-felhom 9201 arranged **reversibly** into the stranded shape (settings + `offbox/` backed up first; the `offbox` key removed and `repo_password` moved aside). Report **id=16743** reached the hub carrying `{enabled:false, state:"needs_credential", quota_gb:0, repo_size_bytes:0}`. Restored the same minute; report **id=16744** is healthy again. **The single declaration was absorbed by the debounce — no self-heal event fired** — which is Scenario F demonstrated on live infrastructure rather than in a fake. |
 | 2b | **The ACK field is no longer discarded** | Both demo boxes' `settings.json` now carry `hub_escrow_identity_present = true` — the recorder working on a HEALTHY box, which is the case that used to return early. |
 | 3 | **A push from outside the workspace is refused** | A scratch clone at `/tmp/.../outside-clone`: `pre-push: PUSH REFUSED - this clone is OUTSIDE the felhom workspace`, naming `/mnt/5_hdd/felhom.eu`, **before the gates run**. **Red-proof:** with the assertion removed the same push **succeeded** (`rc=0`, new branch on a throwaway bare remote). In-workspace pushes ran normally all session. |
-| 4 | **Part 4** | **Not performed — halted at the STOP.** Listings above. |
+| 4 | **Part 4** | **Completed after the STOP and a corrected list.** Full listings before and after on both accounts; both LIVE repos intact; a real off-site run on demo-hp succeeded immediately afterwards (`status: ok`, `last_run 09:14:02Z`). |
 
 **Not fired live: the hub actually re-staging a credential.** Doing so would have re-applied
 demo-felhom's off-site target mid-session and changed the very state Part 4's listing describes. It is

STATUS.md

@@ -47,6 +47,14 @@ over; and the file was restored **byte for byte identical**. *(R-201)*
 
 ## What shipped recently
 
+- **2026-08-05** — **The orphaned backups are deleted — and the list you were given was wrong, which
+  is why you were asked again.** You had approved "about 1.2 GB in two set-aside stores". Measured
+  before touching anything: there were **three** set-aside stores totalling **~1.45 GB** — and the
+  thing that was exactly 1.2 GB was demo-felhom's **live** store. Matching on the size would have
+  deleted a working backup. With the corrected list confirmed, all three were removed and both live
+  stores left alone; a real off-site backup ran successfully straight afterwards to prove nothing
+  working had been caught. *(R-212)*
+
 - **2026-08-05** — **A rebuilt machine now asks for its storage credential, and the hub gives it back.**
   The machine says plainly what it needs — it can tell it has been rebuilt, because its data area is
   empty *and* the hub is holding a sealed recovery package for it — instead of leaving the hub to guess
@@ -107,13 +115,7 @@ over; and the file was restored **byte for byte identical**. *(R-201)*
   (controller up to 0.135.0, hub up to 0.57.0; everything newer is safely in the registry). **Nothing
   was deleted.** Worth knowing before you spend time on it: they only account for about 27 GB against
   199 GB now free, so this is about clutter, not space. *(R-210)*
-- **The orphaned-backup deletion is STOPPED and needs your ruling — the list does not match.** You
-  asked for about 1.2 GB in two set-aside stores to be deleted. Measured today, read-only: demo-felhom
-  holds a **live** store of 1.2 GB plus set-aside stores of **1.4 GB** and **3 MB**; demo-hp holds a
-  live store of 582 KB plus a set-aside store of **43 MB**. So there are **three** set-aside stores
-  totalling ~1.45 GB, not two — **and the thing that is exactly 1.2 GB is demo-felhom's LIVE store**,
-  which must not be deleted. **Nothing was deleted.** Tell me which of the three `orphaned` stores to
-  remove. *(R-212)*
+- **Nothing.**
 - **The recovery screen you described has been priced, and it can be built.** A freshly installed
   machine that finds a sealed package waiting should say so, offer a box for the recovery code, and
   show what would come back before doing anything. One thing to weigh, deliberately not decided: that