R-442 CLOSED (controller v0.236.0): "delete my data too" deletes it or refuses; R-465..467 opened

- OPEN-ITEMS: R-442 row removed; R-465 (six remaining Paths.HDDPath readers — audit),
  R-466 (recovery-unit residue after "delete backups"), R-467 (v0.236.0 owes a golden).
- CLOSED-ITEMS: R-442 compressed, reasoning kept, fleet shape now established.
- 00-capability-map: lifecycle row narrowed (Campaign 3 proved remove removes the APP,
  not the data) and re-proven from audits/R442-2026-09-13/.
- STATUS: item 13 in plain language; item 7 closed (ruled 2026-09-02, 09 §3).
- audits/R442-2026-09-13/: live evidence (A, C, D bodies, controls, log window, teardown).

Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

STATUS.md

@@ -1,5 +1,7 @@
 # STATUS — what works, what's broken, what's next
 
+**Updated 2026-09-13 — "delete my data too" now deletes the data, or tells you it could not. Until today the box said it worked and left everything on the drive. Live on both machines (0.236.0), proven on the HP with a throwaway Nextcloud. Nothing needs you. Item 7 is closed: you decided it on 2026-09-02 and the page still listed it open.**
+
 **Updated 2026-09-06 (third pass) — I chased down the BookStack database problem I found this
 morning. Good news: it does not get worse, and fixing it costs seven seconds and loses us nothing.
 The catch I expected — that fixing it would stop us being able to go back — turned out not to be
@@ -41,7 +43,7 @@ not an evening's work.**
 *This section is allowed to be longer than one screen, and each item says what happens if you do
 nothing.*
 
-1. **Two things are waiting on you: item 11 (how wide to take the upgrade testing) and item 12 (a small yes/no about the database setting — I have measured both costs).** Item 4 (the Hetzner e-mails) is answered and is being handled in a separate session. Item 7 — the safety-copy decision — is the one open question, and it is **not urgent any more**: the thing that made it urgent was that a restart could upgrade an app behind your back, and as of today it cannot. Item 10 is new and needs nothing from you. Item 5's alarm mail can now be ignored for good. Otherwise: Both problems the overnight test found are fixed and proven on
+1. **Two things are waiting on you: item 11 (how wide to take the upgrade testing) and item 12 (a small yes/no about the database setting — I have measured both costs).** Item 4 (the Hetzner e-mails) is answered and is being handled in a separate session. Item 7 — the safety-copy decision — was ruled on 2026-09-02 and is now marked closed below (it was **not urgent any more**: the thing that made it urgent was that a restart could upgrade an app behind your back, and as of today it cannot. Item 10 is new and needs nothing from you. Item 5's alarm mail can now be ignored for good. Otherwise: Both problems the overnight test found are fixed and proven on
    the real machines:
    - the background job that could delete a live restore's lock now waits its turn — and the check
      that finds the next one like it is a test, not a comment, so it cannot come back quietly;
@@ -93,7 +95,9 @@ nothing.*
    Not in git, not in any saved file — in the log on this machine. **If you do nothing:** it stays as
    it is, at the risk you accept by leaving it. I can change it without ever showing you the new one.
 
-7. **Where should the safety go before an app updates? This is the one decision from today's
+7. **CLOSED 2026-09-13 — you decided this on 2026-09-02, and the page kept listing it open.** The ruling is recorded in `documentation/architecture/09-update-architecture.md` §3: the safety copy is a *verified recent backup as a precondition*, not a new copy made for the update; the guest-snapshot idea is to be spiked before anything is built on it. The text below is kept as the record of what was asked.
+
+   *Original question:* **Where should the safety go before an app updates? This is the one decision from today's
    measurement, and it is a design choice, not a bug report.**
 
    **What I measured.** The box downloads new app versions by itself every 15 minutes and writes them
@@ -269,6 +273,8 @@ nothing.*
     actually moved a major version so far; the other three will land in the same place when their
     turn comes. I have not changed any template — this is your call, not a quiet edit.
 
+13. **"Delete my data too" now deletes the data — or tells you it could not.** Until today, when a customer removed an app and ticked the box, the box said it worked and left everything on the drive (128 MB of a Nextcloud on 2026-09-01). The cause: the removal asked one global setting for the drive, and no machine fills that setting in. Every other part of the box already asks the app itself where its data is. Now the removal does too. If the box cannot work out where the data is, it refuses and keeps the app, so you can try again — it never again reports success over data left behind. Proven on the HP with a throwaway Nextcloud: 63 MB the app wrote itself was gone after removal, and the answer listed it; the refusal was shown with the app still in place; an app with no drive data gets a plain "nothing to delete" note. Live on both machines (0.236.0). No standing app was touched. **If you do nothing:** nothing to do.
+
 8. **`demo-hp`'s network setup does not match our own notes** (R-338) — the machine works, the page is
    wrong, or the other way round. **If you do nothing:** the page keeps misleading the next session,
    as it misled one by an hour.