second night: scratch guest 9202 built (R-481 CLOSED, persists); controller v0.242.0 delivered (R-487 R-491 R-490 R-476 R-456 CLOSED, R-489 re-scoped); R-492 filed; rotation restarted from bentopdf; morning note

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

STATUS.md

@@ -1,5 +1,47 @@
 # STATUS — what works, what's broken, what's next
 
+**Updated 2026-09-14 (morning note, the second night) — the scratch guest is built, one controller release, the rotation restarted.**
+
+**Decisions I took.** (1) The scratch guest on the HP was built as you ruled: a second guest under
+the HP's own customer, on the fast internal disk, sized like the main one, kept on purpose and written
+up in all three places. Two properties of it were my call and you may reverse them: it never sees your
+real data drive, and it never starts the public tunnel — a second connector would serve the public
+domain from a throwaway. (2) A finding I had already listed as fixed turned out half-fixed when
+measured live, and the rule is one release per night, so I kept the line open with the exact measurement
+instead of shipping a second release. (3) The removed-app listing was a medium-priority line, but it
+needed no ruling, touched no customer data and was the rotation's own finding, so I took it into
+tonight's release.
+
+**What I exercised.** The rotation restarted from its first standing app on the scratch guest: front
+door, use, backup, second copy, remove-with-data, full restore from the second copy, the guarded
+update, remove-everything — all clean. Then a throwaway app for the release proof.
+
+**What broke, and whether I fixed it.** Six lines fixed and shipped in one controller release,
+delivered by the floor in 16 and 17 seconds, proven on the scratch guest: an app you removed while
+keeping its backup now shows on the backup pages with a button that reinstalls it (before, the way
+back existed only as a hidden endpoint, and a backup kept on a data drive could not be found at all);
+a removal now clears the "held after a failed update" mark; the memory card on the monitoring page can
+render; the second copy is dated by its data rather than by a file that only moves when the app's
+definition changes; and a boot rule is now pinned by a test. Half-fixed: the removal's list of
+deleted volumes is right for a freshly installed app and empty for one that came back from a restore,
+because the restore recreates the volume without the label the list looks for. Measured, kept open.
+One security slip to know about: while building the scratch guest, the HP's retrieval passphrase was
+printed once into a tool output here on DooPlex. Nothing left the machine.
+
+**Rows.** Opened 1 (delete the empty drive-path setting nothing reads any more). Closed 6 (the
+scratch guest, the removed-app listing, the hold left behind, the monitoring card, the second-copy
+date, the boot rule). Re-scoped 1 (deleted-volume list). Register: 210 open / 194 closed before,
+205 open / 200 closed after.
+
+**Needs you.** (1) Open the backup page once in a browser after removing a throwaway app with its
+backup kept, and press the new button — strict screen coverage is yours. **If you do nothing:** the
+feature stays proven at the endpoint level only. (2) The passphrase slip: re-issue the HP's retrieval
+passphrase from the hub when convenient. **If you do nothing:** the old one stays valid; the exposure
+is one line in this session's local record. (3) The scratch guest stays up and idle. **If you do
+nothing:** it costs the HP about one and a half gigabytes of memory and nothing else.
+
+---
+
 **Updated 2026-09-13 (evening, before the night) — your four items.**
 
 **Decisions I took.** (1) The rules file now sits in the workspace root and all three repos,