Day 2026-10-19: agent 0.160.0 (released, not vouched), controller 0.332.0 floor (one sign-in R-1100, escrow confirm R-1151), hub 0.159.0 deployed (R-1150, R-1154), R-1153 not a defect, old-restic check passed; register 168 -> 166 (closed 10, opened R-1155..R-1162)

documentation/backlog/CLOSED-ITEMS.md

@@ -26,11 +26,20 @@
 
 ---
 
-## 2026-10-19 (day) — agent 0.160.0, one sign-in for the file manager, hub small fixes (full text of each row: `git show e4f022a0:documentation/backlog/OPEN-ITEMS.md`)
+## 2026-10-19 (day) — agent 0.160.0, one sign-in for the file manager (controller 0.332.0), hub 0.159.0 (full text of each row: `git show e4f022a0:documentation/backlog/OPEN-ITEMS.md`)
 
 | Row | What | Closed | Evidence |
 |---|---|---|---|
 | **R-887** | **Some CI jobs are never run, and Gitea fails them ~10–13 minutes later with no log** (Gitea's zombie-task stop after the runner abandoned its fetch; S21 on 2026-10-12: runner `fetch_timeout` 5 s → 30 s, crawler rate limit). (P3) | CLOSED 2026-10-19 — **the dated check is met:** since 2026-10-12 12:00Z the four repos ran **381 jobs, 0 lost**. 25 ended `failure`, every one with a readable log (the runner ran them); 3 jobs had a second attempt (controller 1944, 1959, 1991), and each first attempt (tasks 1962, 1978, 2011) failed in 47–49 s — a run that did work, not the lost shape (one cause on record: the register not pushed yet, `REPORT-burndown2-2026-10-16.md`). **Control:** the known lost attempt of controller job 1639 (task 1653, 2026-10-10) ran 11 min 48 s, and the attempt count finds it. **Reasoning kept:** the jobs endpoint shows only the LAST attempt (R-1137), so „a failed job with no log" alone cannot find a lost attempt that was re-run — count `run_attempt > 1` and read the first attempt in `actions/tasks`. | `audits/day-2026-10-19/R-887/` |
+| **R-978** | **Starting the escrow ceremony again can make the customer's written-down recovery code useless: the new package replaces the old one before the new code is confirmed.** (P3) | CLOSED 2026-10-19 — **agent 0.160.0 released** (the operator's yes, given in advance in the day brief) and running on demo-hp, Tester 1 and demo-felhom by the signed-job path. Live on demo-hp 9201: an abandoned second ceremony left the first code opening the hub's package (with R-1151's confirm on top, below). | `audits/day-2026-10-19/P1/escrow-*.txt` |
+| **R-973** | **A compromised controller can make the whole-guest backup run again and again, and each run prunes older restore points: the local tier directly, and the off-site tier through the store's own nightly keep-last-2.** (P3) | CLOSED 2026-10-19 — **agent 0.160.0 on all three test hosts**; a normal „Mentés most" whole-guest backup of demo-hp 9201 ran green (6.9 GB, 443 s) and the cap counted it (two successes in the rolling 24 h on disk). The numbers (3 a day, 1 per 6 days off-site) were *decided by CC unattended*; the operator said yes to the release. The local half's remaining flood within a day is closed by R-1149 (keep-daily). **The off-site half (ep0's keep-last 2 is a count) moves to R-1162.** | `audits/day-2026-10-19/P1/backup-press.txt`, `demo-hp-after-backup.txt` |
+| **R-1093** | **An EMPTY partition asks for the typed „data will be erased" confirmation.** (P3) | CLOSED 2026-10-19 — **agent 0.160.0, proven on the real route** on demo-hp: a 64 MB RAM disk from the kernel's `scsi_debug` module (`/dev/sdb`, the route accepts only sd/nvme/vd/hd names — a loop device is refused before any probe, by design), one empty GPT partition → `POST /disks/format` with no confirmation → 200 `formatted`, `data_bearing: false`. **Control:** the same call on the now-ext4 partition → 403 `needs_confirmation` („device has a ext4 filesystem"). The RAM disk removed (`rmmod`). | `audits/day-2026-10-19/P1/r1093-format-route.txt` |
+| **R-1149** | **The local whole-guest tier prunes keep-last 3, so even with the R-973 cadence cap a compromised controller can replace all three restore points within one day.** (P3) | CLOSED 2026-10-19 — **operator decision D17 = „one per day, 3 days"; agent 0.160.0**: the local tier prunes `keep-daily=N` (the „backup tier armed" line names it on all three hosts). Before/after: demo-hp (retention 1) kept the same single newest copy as keep-last would; Tester 1 and demo-felhom hold one copy per day, so their next night prunes the same copy under either rule. Test: a day-long flood with the cap leaves the two earlier days' copies (red-proved). | `audits/day-2026-10-19/P1/demo-hp-*.txt`, `others-before.txt` |
+| **R-1151** | **The new escrow package now uploads when its code is claimed (R-978), but the wizard's typed-back check is the browser's alone:** (P3) | CLOSED 2026-10-19 — **agent 0.160.0 + controller 0.332.0 (the floor)**: the new package reaches the hub only after `POST /escrow/ceremony/confirm` brings two words of the code back (the agent draws the positions, keeps only those two words, 30-minute window); an old controller keeps the R-978 order. Live on demo-hp 9201 through the wizard's own calls: ceremony 1 — one wrong word 422, the right words 200, then code 1 opens the hub's package and code 0 is an earlier kept package (422, superseded at the confirm second); ceremony 2 shown and abandoned — code 1 still opens it, code 2 opens nothing. demo-hp's stored code was replaced with code 1 (CC's secret store). | `audits/day-2026-10-19/P1/escrow-*.txt` |
+| **R-1100** | **One sign-in for the dashboard and FileBrowser (proxy auth) — spike first.** (P3) | CLOSED 2026-10-19 — **built (operator decision D16 = yes) and shipped in controller 0.332.0, the floor for every box**: a dashboard pass (60 s, one use, host- and session-bound, none for a cross-site request) → a host-only files cookie → traefik forwardAuth sets the box's SECRET header naming `felhom-household`; the dashboard cookie is not widened. Live: on 9201 in the headless browser „Fájlok ↗" opened the app's folder with no login, a dashboard sign-out asked again; on demo-hp and Tester 1 the same path through the public internet; forged headers (the old public name, a random name, the real name with no cookie through traefik) all 401, and only the real name from an app container straight to `filebrowser:80` (the control) got in. A live bug was fixed before release: traefik made the pass answer's relative redirect point at `felhom-controller:8080`. | `audits/day-2026-10-19/P2/`, `P4/05-files-one-sign-in.txt`, `P4/06-demo-felhom-checks.txt` |
+| **R-1153** | **FileBrowser's preview of a .docx answered 500 while the OnlyOffice link was on** (P4) | CLOSED 2026-10-19 — **not a product defect.** FileBrowser 1.5.6 previews a .docx with its own MuPDF before it ever asks OnlyOffice (`preview.go` `determinePreviewType`: document conversion first). On 9202 (controller 0.331.0) a real .docx (OnlyOffice's own `sample.docx`) previews **200, a 256×256 JPEG in 0.3 s** with the link on AND off; the 500 is the 912-byte hand-made test file, which MuPDF cannot open („fitz: cannot open document"), with the link on or off. OnlyOffice removed through the product after. | `audits/day-2026-10-19/P3/` |
+| **R-1150** | **A refused whole-guest backup (the R-973 cap) reaches the operator as `agent_capability_degraded`, whose text reads „agent privileged capability degraded”.** (P4) | CLOSED 2026-10-19 — **hub 0.159.0 deployed** (the operator's yes, given in advance): the cadence cap alone raises the operator-only, hub-origin `whole_guest_backup_refused` with plain text (its clearing: `whole_guest_backup_refusal_cleared`); other critical capabilities keep `agent_capability_degraded`, which is now operator-only by register too. Not in `allowedEventTypes` on purpose (the suspected controller must not post or pre-empt it, the R-895 shape). Deploy: ArgoCD synced the hub Deployment only, Synced/Healthy, the floor read back, reports from all three hosts and controllers after the restart. | `audits/day-2026-10-19/P5/` |
+| **R-1154** | **A reinstall while the customer's OLD host record still exists skips both clean-slate re-issues (the claim code and the off-site credential) in silence.** (P3) | CLOSED 2026-10-19 — **hub 0.159.0 deployed: the reuse path never re-issues; it makes the reinstall LOUD.** A first draft re-issued automatically when the old host was stale or switched off; a security review found that would let anyone with the household's retrieval passphrase trigger the operator's re-issues (claim code, off-site provider password) while the box is off. Now: old box gone (no wait connection, and switched off on purpose or both reports older than the stale threshold) → the operator-only warning `host_reinstall_over_old_host`, mailed: „… delete the old host and run the installer again, or re-issue …"; a live box → the info record `host_reenroll_while_live`. The mint after the operator's delete re-issues as before. Not walked live (no reinstall today). Residual: R-1156. | `hub/internal/api/reenroll.go`, `05` §8 |
 
 ## 2026-10-18 (evening) — a fresh install from scratch, OnlyOffice saves, Redis without a volume, CI mail link (controller v0.331.0, catalog `30eea97`)