docs: record D53, D54 and R-1297 (B) (09 §3 decisions 265-267); STATUS moves the two picks to history

documentation/backlog/STATUS-HISTORY.md

@@ -5,6 +5,15 @@ Moved here byte for byte on 2026-10-14 (night session), newest first, so that `S
 
 **Updated 2026-10-13 (night): demo-hp, demo-felhom and Tester 1 run agent 0.155.0; demo-felhom runs controller 0.310.0, the other two 0.309.0 until the floor is raised. The open-items list is at 127. Reports: `REPORT-poweroff.md`, `REPORT-plugmeter.md`, `REPORT-usenet-2026-10-12.md`, `REPORT-newapps-2026-10-12.md`, `REPORT-disk-evening-2026-10-12.md`, `REPORT-answers-2026-10-12.md`, `REPORT-m3-2026-10-11.md`, `REPORT-redesign-2026-10-10.md`, `REPORT-testers-2026-10-10.md`, `REPORT-register-shrink-2026-10-10.md`, `REPORT-new-apps-2026-10-10.md`, `REPORT-release-2026-10-10.md`, `REPORT-break-the-circle-2026-10-09.md`, `REPORT-dooplex-survival-2026-10-09.md`, `REPORT-day4-2026-10-09.md`.**
 
+## Moved from STATUS on 2026-10-26 (evening run)
+
+**Updated 2026-10-26 (afternoon).** A fresh install's whole-box off-site copy no longer fails silently: the cause (PBS's 5-second permission cache) is fixed on ep0, and the hub retries and mails you if it still fails (hub 0.172.0). Every box runs controller 0.345.0: the torrent rule leaves the household's alternative speed alone. Two picks wait for you (D53, D54).
+
+| D54 | R-1294 | demo-hp's weekly off-site clean-up is stuck: its plan (209 old copies, all from a test day and normal ageing) is above the safety cap (179), and it cannot catch up by itself. Prune it once by hand, or change the cap? | **Prune once** — on your yes, demo-hp gets one clean-up window with a raised cap of 220 through the hub's existing one-shot grant (the plan is honest: every removal is 7–30 days old, every app keeps ≥ 9 copies) | change the cap rule: code in hub + controller, and a weaker guard against a mass deletion | it is refused every Sunday, mails an error each week, and the store grows ~100 copies a week | — |
+| D53 | R-1291 | A stopped-and-held app (like Kimai for 11 days) should reach you. Operator-only reminders, or also mail the household for the two holds it can clear itself? | **Operator only first** (the design in `08` §10: a „Held apps" list and a reminder after a grace per reason; ~1.5 days of work) | also the household: two more customer mails to write and translate, and a mail about a stop they may not understand | held apps stay invisible until someone opens the app's page | — |
+
+**Ruled:** D53 = operator-only reminders first (`09` §3 decision 265); D54 = prune once, cap 220, the one-shot grant (decision 266) — both by starting the evening brief, 2026-10-26. Done by the operator 2026-10-26: a second CI runner on DooPlex, both runners 2 CPUs (R-1297 B, decision 267).
+
 ## Moved from STATUS on 2026-10-26 (afternoon run)
 
 **Updated 2026-10-26 (release day).** Every box runs hub 0.171.0, agent 0.166.0 and controller 0.344.0, and new installs start on golden 0.344.0 — all vouched: the torrent line hold, FileBrowser off the app network, a set-aside mails „nothing failed", a signed job lasts at most 24 h. One leftover: on a BYO host the SSH clean-up still comes one release late (R-1285).