From 2441c86a89690486d4e5d2cc1f2805015bc16a75 Mon Sep 17 00:00:00 2001
From: kisfenyo <nagyfenyvesi.viktor@gmail.com>
Date: Tue, 6 Oct 2026 16:11:28 +0200
Subject: [PATCH] Design build done: R-469, R-638 closed; R-518/R-717/R-762
 narrowed, R-528 stopped by its measurement; delivery + teardown evidence;
 STATUS, CONTEXT, REPORT (137 -> 137; 2 opened, 2 closed); section counts
 recomputed

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
---
 CONTEXT.md                                    |  12 +
 REPORT.md                                     | 207 ++++++++----------
 STATUS.md                                     |  24 +-
 .../delivery/T1-9202-repoint-live.txt         |  27 +++
 .../delivery/T2-drill-reset.txt               |   1 +
 .../delivery/controller-delivery.txt          |   1 +
 documentation/backlog/CLOSED-ITEMS.md         |   9 +
 documentation/backlog/OPEN-ITEMS.md           |  20 +-
 8 files changed, 171 insertions(+), 130 deletions(-)
 create mode 100644 documentation/audits/design-build-2026-10-06/delivery/T1-9202-repoint-live.txt
 create mode 100644 documentation/audits/design-build-2026-10-06/delivery/T2-drill-reset.txt
 create mode 100644 documentation/audits/design-build-2026-10-06/delivery/controller-delivery.txt

diff --git a/CONTEXT.md b/CONTEXT.md
index 2dcb210b..6dbb9e7f 100644
--- a/CONTEXT.md
+++ b/CONTEXT.md
@@ -16,6 +16,18 @@
 > and holds nothing of its own; this file does hold its own content, namely the standing rulings below.
 
 
+> **2026-10-06 (evening) — the design build (`09` §3 151–156).** Register 137 → 137 (2 opened: R-892 Tester 1 walk
+> route, R-893 off-site rollback reverse direction; 2 closed: R-469 by ruling, R-638). Controller **v0.301.0**
+> (`0b1b8d3`, MinAgent 0.131.0) + golden 0.301.0 (`96e94fed…`, Docker pinned to the approved set), vouched with agent
+> 0.149.0; floors 0.301.0 / MinAgent 0.131.0 for demo-hp, demo-felhom, tester-1 — all three run it. **R-518** one stop per
+> tier, the button makes the local copy only (reverses R-82's one window; first night read-back owed). **R-638** main
+> restore paths measured safe on 9202 (docmost, romm), two side paths fixed by order. **R-717** `after_setup`
+> `open_command`; wishlist uses it (catalog `a5a5b51`, live-proven); opengist cannot (no tool in its container).
+> **R-528 STOPPED by its measurement:** Docker 29.8.2 sets `OOMKilled` correctly in all four shapes tried (operator to
+> confirm or drop decision 155). **R-762** wger serves `/static` + `/media` through a `wger-files` nginx (catalog
+> `cf1ed43`, a definition step — new bench option `--move-to` / writer `--to-definition`); wger stays hidden, its
+> `runserver` question remains. Agent repo gained the shared rule file. Evidence `audits/design-build-2026-10-06/`.
+
 > **2026-10-06 (afternoon) — instruction files kept true; vaultwarden on the ladder (`09` §3 149–150).** Decision 150:
 > a session corrects a stale fact in `CLAUDE.md` / `.claude/rules/*` itself and names the edit (file, before, after, why);
 > it never loosens a rule, fence or „never" without the operator — rule text in `.claude/rules/unprompted-work.md` §5
diff --git a/REPORT.md b/REPORT.md
index 1e5b5ddf..a4fd7543 100644
--- a/REPORT.md
+++ b/REPORT.md
@@ -1,147 +1,122 @@
-# REPORT — instruction files kept true; vaultwarden on the ladder; the burn-down continued (2026-10-06 afternoon)
+# REPORT — the design build: restore order, out-of-memory alarm, one stop per tier, the family window, wger's files (2026-10-06 evening)
 
 | Part | Result |
 |---|---|
-| **A** — the instruction-file rule (R-891, R-469, sweep) | **done** — rule in all four copies of `unprompted-work.md` §5 and `PROMPT-TEMPLATE.md` §9 rule 9; R-891 fixed and closed; R-469 re-read: NOT removable, narrowed (an operator question); sweep: 26 factual edits in four repos (list below). No permission prompt or refusal came up. |
-| **B** — vaultwarden on the update ladder (R-890) | **done** — the test-box admin seed built (catalog `6b4877d`, red-proved); 1.36.0-alpine → 1.37.4-alpine proven on bench 9401 and on 9202; written by `--write-ladder` (catalog `ecb8552`); R-890 closed |
-| **C** — the burn-down | **3 closed** (R-644, R-763, R-764), **2 stopped with the reason written** (R-762 medium, R-717 needs a design) |
+| **A** — housekeeping | **done** — decisions 151–156 recorded first; R-469 closed by ruling; the agent repo has the shared rule file (identical: `diff` against the controller's copy empty, one md5 across five copies); the Tester 1 walk route is NOT a 30-minute fix → R-892 |
+| **B** — restore order (R-638) | **done** — measured first on 9202: both main paths SAFE (docmost, romm); two side paths fixed by order, red-proved; exposure 3 not fixable by order → known limit in `07` §6.3 + R-893; R-638 closed |
+| **C** — out-of-memory alarm (R-528) | **STOPPED by its measurement** — Docker 29.8.2 set `OOMKilled` correctly in all four shapes; nothing built; a decision for you |
+| **D** — one stop per backup tier (R-518) | **built and delivered, not shown live** — measured first (read-only): the off-site part of a stop is ~2 s; red-proved; the live button test was not possible on 9202 (no agent connection) and the demo boxes take deliveries only → R-518 open for the first night read-back |
+| **E** — reopen a sign-up for the family window (R-717) | **done for wishlist, proven live; opengist stopped** (no tool in its container) → R-717 narrowed |
+| **F** — wger's file server (R-762) | **done and proven on both venues; wger stays hidden** — R-762 narrowed to the `runserver` half it carries from R-755 |
 
 | Rows before | Rows after | Opened | Closed |
 |---|---|---|---|
-| **142** | **137** | **0** | **5** (R-890, R-891, R-644, R-763, R-764) |
+| **137** | **137** | **2** (R-892, R-893) | **2** (R-469, R-638) |
 
 ## Baselines and rulings
 
-Verified at the start: felhom.eu `7d0dffcf34`, controller `36088fd82e` (v0.300.0), agent `cefdc731a4` (v0.149.0),
-catalog `65130c6c03`; register 142. Read: every repo's `CLAUDE.md` and `.claude/rules/`, `REPORT.md`, R-890, R-891,
-R-469. The two rulings were recorded first as `09` §3 decisions 149 and 150, with the reviewer's error recorded in 150.
-Architecture read: `09-update-architecture.md` §3 (decisions 16, 35, 42, 146), §6.4 part 4 (the ladder writer), §6.5
-(the drill catalog).
+Verified at the start: felhom.eu `01d5dbd3e0`, controller `31242786af` (v0.300.0), agent `3e8ebeb96c` (v0.149.0), catalog
+`ecb8552ee9`, register 137. Read: the three designs in `audits/night-burndown-2026-10-05/`, rows R-638, R-528, R-518, R-717,
+R-762, R-469, `07` §6, `08` (the OOM rung), `09` §3 decisions 47/49. Rulings recorded first as `09` §3 151–156 (ruling 6 is
+carried as A by the brief; the operator's chat answer was not visible to this session).
 
-## Part A
+## Part B — R-638
 
-**The rule** — `.claude/rules/unprompted-work.md` §5 „Instruction files", the operator's text verbatim plus the
-permission-check sentence; identical in felhom.eu, felhom-controller, app-catalog-felhom.eu and the workspace root's
-unversioned copy (md5 `c1e6c881…` for all four). `documentation/PROMPT-TEMPLATE.md` §9, rule 9. felhom-agent has no copy
-of the shared rule file (it never had one); adding one is a rule change, left for the operator.
+**Slice 0, measurement only** (scratch 9202, controller 0.299.0, drill catalog; `audits/design-build-2026-10-06/B/`).
+Install the OLD definition → seed → the guarded Update migrates (its backing-up phase makes the copy at the old version) →
+the household's restore of that copy (`POST /backup/restore`, the only copy offered: "helyi").
 
-**R-469 — not met.** R-463 closed (8 of 11 PostgreSQL apps converted by the box; zipline, adventurelog, immich stay on 16
-by decision 42), but the engine gate now enforces decision 35: a PostgreSQL major passes only with a two-venue ladder
-entry carrying `engine_conversion`. Removing it would let an unproven major ship, and the image refuses to start on the
-old datadir. That is a loosened fence. Nothing is left for CC to build; the row asks the operator to close it (CC's pick)
-or keep it.
+| app | migration | after restore | `Imported DB dump` | seed | the copy's own dump (control) |
+|---|---|---|---|---|---|
+| docmost 0.95.0 → 0.96.0 (pg16) | 42 → 48 tables (+6 `oauth_*`, `public_spaces`, `siem_destinations`) | 42, none of the 6 | yes | read back | 42, equal |
+| romm 5.0.0 → 5.3.0 (mariadb 11.4) | 27 → 39 (+12) | 27, none of the 12 | yes | read back | 27, equal (views counted) |
 
-**Every instruction-file edit** (before → after, why). All factual; none loosens a rule.
+Both went back to the old pinned version and ran. **Said plainly:** romm needed four runs — run 1 refused the install
+(its data path must be a drive), run 2 hit an empty drill commit, run 3 measured correctly but my control read the wrong
+file (a `pre-restore-*` dump) and missed three VIEWS; run 4 fixed both. docmost's run 1 installed the live version
+because the box had not read the drill yet (the script then waited for the old reference).
 
-felhom.eu
-1. `CLAUDE.md` „Gates — ONE entry point": a list of ten gates + „`--fast` … today that is all of them" → the `GATES`
-   table is the list (nineteen gates); `--fast` skips the full-run-only gates and names them (today `iso-bootstrap`). Why:
-   `repo_gates.py` imported: 19 gates, `iso-bootstrap` not fast. **R-891.**
-2. `CLAUDE.md` design pointer `architecture/01..05-*.md` → `01..11-*.md` (00 = the capability map). Why: 06–11 exist.
-3. `.claude/rules/docs.md` „the locked design" `01..05` → `01..11`. Same reason.
-4. `.claude/rules/website.md`: the list of what `site_gates.py` asserts gains „no embedded `<style>` blocks". Why: its
-   gate 7 (`site_gates.py` docstring).
-5. `.claude/rules/unprompted-work.md`: §5 added; „Same wording lives in all three repos'" → names the three repos and the
-   workspace root. Why: four copies exist.
-6. `documentation/runbooks/workspace-CLAUDE.md` (the workspace root `CLAUDE.md` links to it): standing rule 3 carried the
-   R-286 sentence group twice in a row; the second copy removed.
+**Slices 1 and 2** (controller `9c94568`): `RestoreApp` starts only the database services, replays, then the app; a dump
+with no identifiable database service is refused before anything is touched; a failed volume step skips the replay
+(fallback and unit restore). Red: `B/red-slice1-fallback-order.txt` ("the FULL stack was already up when the replay fired
+(calls before the replay: stop,start)"), `B/red-slice2-no-replay-after-volume-failure.txt`. **Exposure 3** (the off-site
+rollback loads the newer pre-restore dump over the older volume; the older definition is not put back) cannot be fixed by
+order — known limit in `07` §6.3, row R-893.
 
-felhom-agent
-7. `CLAUDE.md` gates: „`reuse_refs_check` and `instructions_gate` … today that is all of them" → every gate in `GATES`
-   (five: three shared, `published`, `release-complete`); `--fast` skips `published`. Why: `agent_gates.py:52-60`.
-8. `CLAUDE.md` decoy paragraph: `scripts/decoy_coverage_gate.py`, `documentation/audits/AUDIT-gate-decoys-…` → with
-   `felhom.eu/`. Why: neither exists in this repo.
-9. `.claude/rules/health-checks.md` (comment): „The single source is now felhom.eu/CLAUDE.md 'Code quality rules'" → the
-   copies are felhom.eu `hub.md` and the controller's `gates.md`. Why: that section holds no health-check rule.
+## Part C — R-528, stopped
 
-felhom-controller
-10. `.claude/rules/gates.md`: `python3 controller/scripts/controller_gates.py` (from `controller/`) →
-    `python3 scripts/controller_gates.py` from `controller/` (or the long path from the repo root). Why: the old path does
-    not exist from `controller/`; the runner's usage line and CI use the new one.
-11. `.claude/rules/gates.md`: the list of ten local gates → a pointer to `GATES` (fourteen local + three shared; the
-    advisory `golden-notice`). Why: `controller_gates.py:71-101`.
-12. `.claude/rules/gates.md`: the shared list gains `observations_gate.py`. Why: `controller_gates.py:87`.
-13. `.claude/rules/gates.md` (two lines): decoy gate and audit paths with `felhom.eu/`.
-14. `CLAUDE.md` Commands table: the same command fix as 10.
-15. `CLAUDE.md`: „Protected stacks (traefik, cloudflared, felhom-controller)" → „…, and always samba". Why:
-    `internal/config/config.go` `alwaysProtectedStacks`.
-16. `CLAUDE.md` design pointer `architecture/01/02/03-*.md` → `architecture/NN-*.md` (01–03; 07, 09, 10).
-17. `.claude/rules/unprompted-work.md`: as 5.
+`C/C0-oom-signal-measure-9202.txt`: four runs in a throwaway alpine container under a cap. Runs 1–3: the kernel killed the
+hog AND the main process (the box cannot protect it: `--oom-score-adj -1000` left pid 1 at 0) — exit 137,
+`OOMKilled=true`. Run 4 (256 MB, `sleep infinity`, one 400 MB block): the container kept running, `oom_kill` 0 → 3,
+`OOMKilled=true`, three `oom` events. The design's premise — the flag stays false while the counter rises — did not
+reproduce on Docker 29.8.2 (the false flags of 2026-09-15 were on 29.8.0). By the brief's measure-first rule, nothing was
+built. Cost read for the record: one exec read of demo-hp's 21 containers 1.6 s wall (`C/C1-…`). `08` records it.
 
-app-catalog-felhom.eu
-18. `CLAUDE.md`: „each holding exactly `docker-compose.yml` + `.felhom.yml`" → without „exactly", plus `steps/<StepKey>.yml`
-    for a superseded ladder step. Why: 20 templates have `steps/`.
-19. „Only the two template files sync" → „Only the template files sync".
-20. „60 checks in 10 groups" → 61. Why: `NEW-APP-CHECKLIST.md` row-count table.
-21. „runs all four gates … scopes the two gates that accept scoping" → every gate in `GATES` (fourteen); scopes every gate
-    that accepts an app scope (eight). Why: `catalog_gates.py:88-131`.
-22. „CI was rejected for now … R-161 stays open at reduced scope" → CI exists and re-runs `--fast`; R-161 closed 2026-10-05.
-23. „`--fast` … is gate 1 and the engine-major gate … the other two" → every gate except image-resolvable and
-    volume-persistence.
-24. The paragraph „There is no gate for this yet and that is a known gap" removed. Why: `check-catalog-since.py` is a
-    registered gate (R-452, closed); the same section already names it.
-25. „The four MariaDB services (…)" → the five (grimmory added), noting the gate judges by glob; „The eleven PostgreSQL
-    services" → twelve, postgis and immich's image counted. Why: `templates/*/docker-compose.yml`.
-26. Decoy gate and audit paths with `felhom.eu/`; `.claude/rules/unprompted-work.md` as 5.
+## Part D — R-518
 
-Sweep notes not acted on: word-for-word repeated paragraphs (R-421 in three CLAUDE.md files; „Presence is not success" in
-the controller's `backup-paths.md`) — repetition, not a wrong fact.
+**Measured first, read-only:** demo-felhom's night off-site job (2026-10-06): started 06:21:08, `snapshotted` 06:21:10,
+its one app running at 06:21:18. demo-hp had no successful off-site run in 10 days. A new off-site run from 9202 was not
+possible (it would write to ep0). **Built** (helper, then corrected by me): one window per tier, resume at that tier's
+`snapshotted`, the next tier in a later cycle; the button makes the LOCAL copy only. **My correction:** the helper let the
+button back up the off-site tier when the local storage is absent; the ruling says local only, so it now backs up
+nothing and stops nothing (red: `D/red-press-no-local-backs-up-nothing.txt`); an agent that flags no tier primary keeps
+the old first tier (the breaker test's fake agent showed that case). Red: `D/red-first-tier-resume.txt` (restarts
+sampled at each poll `[0 0 0 0]`), `D/red-manual-local-only.txt`. Page text, hu + en: about 1–1.5 minutes — an estimate
+from measured parts, not a measured press. **Not shown live** (see the Part table).
 
-## Part B — R-890
+## Part E — R-717
 
-**Built** (catalog `6b4877d`): `box_admin_seed_allowed(w, app)` allows the admin seed on a box walk only when all five
-hold — not the bench venue; `FELHOM_BOX_ADMIN_SEED=1`; the walk targets demo-hp guest 9202 (never 9201, a demo box's
-household-shaped guest); THIS run installed the app (`box_walk.DEPLOYED_THIS_RUN`, set on the deploy's 202); the box's
-`controller.yaml` names the drill catalog. The invite runs inside the box: the token is read from the container's
-environment into a shell variable and handed to curl on stdin; the admin cookie is in a 0600 file that is shredded
-(vaultwarden marks it Secure, so it is sent by hand over the container's plain-http address); only HTTP codes come back.
-**The Tester 1 box is allowed by the ruling, but the walk has no route to it** (`box_walk.py` drives demo-hp guests
-only) — written in the code, not built. Tests `BoxAdminSeedGuard` (6); **red-proof:** a guard returning `(True, "")`
-fails three tests (`test_each_condition_alone_refuses`, `test_a_household_shaped_box_is_never_seeded`, and the bench's
-`test_the_box_walk_never_signs_in_as_admin`).
+Controller (`5b86569`): `after_setup` `open_command` / `open_success`; the window marks `opening` on disk first; a failed
+open closes again and the page says so; the close runs at the window's end, at every start and after a successful
+update; a failed close retries every 2 min. Six red-proofs in `E/`. Catalog (`a5a5b51`, pushed AFTER the controller
+reached the three boxes): wishlist closes/opens `system_config.enableSignup` (group `global`) with Node's own sqlite
+module, `min_controller: "0.301.0"`. **Live on 9202** (the 0.301.0 test image, `E/live.txt`): after setup `false`, a
+stranger straight at the app 401 "invite only", users 1; window `true`, a family member 200, users 2; window end 13:47:34Z,
+close 13:47:44Z, `false`, a stranger 401, users 2. **Opengist:** no sqlite tool, no script runtime, and its CLI has only
+`create-user`, `reset-password`, `toggle-admin` — not doable with this mechanism.
 
-**Proven:**
-- Bench LXC 9401 (harness v5, 600 s memory watch): verdict `proven`; seed read back before and after; healthy in 30.9 s;
-  anon peak 16.3 % (cgroup 22.3 %); 0 kills, 0 restarts; no file changed.
-- Box 9202 (drill catalog): self-registration 400; the in-box admin sign-in and invite → (200, session yes, 200);
-  invited registration 200; seed read back; guarded Update backing-up → pulling → copying → verifying → done in 12.3 s;
-  seed read back; badge „Frissítés elérhető — 80 napja" → „Naprakész"; removed through the product.
-- `upgrade-test.py --write-ladder` from both verdicts → `vaultwarden/server:1.37.4-alpine`, `catalog_since` 2026-10-06,
-  the first ladder entry (catalog `ecb8552`); `check-image-resolvable.py vaultwarden` OK.
-- **Who gets it:** no box reports vaultwarden today (hub DB copy with its WAL: last vaultwarden telemetry 2026-09-18,
-  demo-hp; control: the latest telemetry row of any app 13:51 today; the copy shredded). Read directly: demo-hp 9201 and
-  demo-felhom 9201 run no vaultwarden container.
+## Part F — R-762
 
-## Part C
+Upstream's production compose read first (its `nginx` serves `/static/` and `/media/` from the shared volumes;
+`prod.env` sets `DJANGO_DEBUG=False`). Here traefik sends only those two paths to a `wger-files` nginx
+(`nginx:1.30.5-alpine`, 32 MB, stock config, volumes read-only) — every box gate wraps every router, so it is gated
+like wger. The bench tool could not express a step that adds a service, so I added `--move-to` and
+`--write-ladder --to-definition` (catalog `c48a0db`, red-proved). **Bench:** proven, wger anon peak 50.3 %, wger-files
+15.9 %, the page's hashed CSS 200 from wger-files and 404 straight at wger. **9202:** the guarded Update done in 59.4 s,
+the seed read back, a photo posted before the step 404 → 200 / 178 B / image/png after, CSS 404 → 200, wger-files
+7.6 MiB. **Said plainly:** my box script crashed after the step when it decoded the PNG as text; the after-checks were
+re-read binary-safe and the box verdict was written by hand from them (it says so). **Ready to show?** Files and sign-up
+yes; it still runs Django's `runserver` (upstream's gunicorn runs 3 workers, which do not fit 384 MB) — not ready. Cost:
+283 MB of collected static files in a named volume, in every wger backup (the checks refuse an unnamed volume).
 
-- **R-644 closed:** no gokapi on 9202 (no container, no volume; control: the six running containers are listed).
-- **R-763 closed** (fix from 2026-10-05, proven now): wger installed fresh on 9202; its own process reads
-  `ALLOW_REGISTRATION False`, `ALLOW_GUEST_USERS False`; straight at the app, a stranger's sign-up GET and a CSRF-valid
-  POST both redirect to the features page (control: the same CSRF token passes on the login form, 200); three anonymous
-  dashboard visits → login; users 1 before and after (2 → 4 before the fix).
-- **R-764 closed** (proven now): mail off → healthy, 0 restarts, console backend; mail on (the toggle's injection) →
-  settings load, smtp backend, port 2526, TLS off. Not measured: a real reset mail (9202 has no app-mail).
-- **R-762 stopped:** still 404 on wger 2.7; the image has no whitenoise and runs Django's `runserver`, so it needs a
-  second container for `/static` and `/media` — medium. Note added to the row.
-- **R-717 stopped — needs a design:** the controller's `after_setup` command form runs only when the lock is set; the
-  household's 15-minute window cannot reopen a database switch. Note added to the row.
+## Release and delivery
 
-## Said plainly
+Controller **v0.301.0** (`0b1b8d3`, image `sha256:0e80f6af…`), MinAgent 0.131.0. Golden **0.301.0**
+(`GOLDEN_SHA256=96e94fed…`, Docker pinned to the approved set, registry round trip equal, token grep 0 with a working
+control). Hub: vouched agent 0.149.0 / golden 0.301.0 / min_agent 0.131.0; floors 0.301.0 for demo-hp, demo-felhom,
+tester-1 — first saved without a declared MinAgent (allowed: floor = golden), then re-saved with 0.131.0. demo-hp and
+demo-felhom run 0.301.0 (healthy); tester-1's hub page "Controller elindult (0.301.0)". Global floor and Tester 2 not
+touched. No agent release.
 
-- **A merge conflict was committed into the DRILL catalog** (vaultwarden's `.felhom.yml`, by a `commit -am` after a
-  failed merge). Found at once by its conflict markers and fixed in the next drill commit; the drill was then reset to
-  live. The live catalog was never touched by it.
-- My first wger user-count command had a quoting bug (it printed a Python NameError); the reads were repeated through a
-  file. The stranger checks were not affected.
+## Instruction-file edits (decision 150)
+
+- `.claude/rules/unprompted-work.md`, all five copies, line 8–9: before „…in `felhom.eu`, `felhom-controller` and
+  `app-catalog-felhom.eu` `.claude/rules/`, and in the workspace root's unversioned `.claude/rules/`; change all four or
+  none." → after: names `felhom-agent` too, „change all five or none". Why: decision 152 added the agent's copy.
+- `felhom-agent/.claude/rules/unprompted-work.md`: new file (decision 152), identical to the other copies.
+
+## Fixed without a row
+
+- `OPEN-ITEMS.md` section headings: every count was stale (e.g. „Install & onboarding — 11 rows" over 5); recomputed.
 
 ## CI, last commit of every repo
 
-catalog `ecb8552` → 1433 success (and `6b4877d` → 1430 success); agent `3e8ebeb` → 1431 success; controller `3124278`
-→ 1432 success; felhom.eu `a29ee9dd` → 1434 (checked before the next push), and this commit (checked after the push).
+controller `0b1b8d3` → 1439 success; catalog `cf1ed43` → 1438 success (`a5a5b51` checked after its push); agent
+`de812bc` (checked after its push); felhom.eu `8db4425` → 1440 (checked), and this commit (checked after the push).
 
 ## Teardown
 
-Machine: 9202 back on the live catalog (`controller.yaml` restored byte-identical), vaultwarden and wger removed through
-the product (no container, no volume), the same six containers as at the start. Bench 9401: 0 containers, `.env` gone,
-stopped. Drill: reset to live (`ecb8552` = `ecb8552`). Host: nothing else. Hub: nothing changed (one read-only DB copy,
-shredded). Scratch secrets shredded at the end.
+Machine: 9202 back on the live catalog (`controller.yaml` byte-identical), on the released 0.301.0 (was 0.299.0), every
+test app removed through the product (no volume left), the test images removed by name, the same six containers as at
+the start. Bench 9401 stopped. Drill VM: build guest destroyed, files shredded, off, `virgin`. Drill catalog = live.
+Host: nothing else. Hub: the vouch and three floors; two read-only DB copies, deleted.
diff --git a/STATUS.md b/STATUS.md
index d2779f03..222a7116 100644
--- a/STATUS.md
+++ b/STATUS.md
@@ -2,8 +2,26 @@
 
 **Ready for the first real tester (Tester-2): yes. Tester 2 (a laptop) is off; nothing was sent to it.**
 
-**Updated 2026-10-06 14:15: every box of ours healthy on hub 0.139.0, agent 0.149.0, controller 0.300.0. The open-items
-list is at 137. Report: `REPORT.md`.**
+**Updated 2026-10-06 16:30: demo-hp, demo-felhom and Tester 1 run controller 0.301.0 (hub 0.139.0, agent 0.149.0).
+The open-items list is at 137. Report: `REPORT.md`.**
+
+## Evening (2026-10-06): the designs built; the list at 137
+
+- **Safer restores:** measured first — restoring a copy after an app update brings back exactly the old database (docmost
+  and romm). Two rarer restore paths now load the database before the app starts.
+- **Shorter backup stop:** each backup copy now gets its own short stop, and the button makes the local copy only; the
+  off-site copy follows at night. **Not yet seen live** — the first night run on the demo boxes is the proof.
+- **Family sign-up window:** wishlist's own sign-up now closes after setup and opens for the 15-minute window (proven
+  live). Opengist cannot do this yet.
+- **wger** shows its styles and photos now (proven). It stays hidden: it still runs a development web server.
+- **Out-of-memory alarm: not built.** Today's Docker reports the memory kills correctly, so the design's reason was
+  gone. Your choice below.
+
+**Needs you (none urgent):**
+1. **R-528** — build the memory-kill alarm anyway? (A) No: keep watching for a box where Docker misses a kill (my pick).
+   (B) Yes, as insurance (about 1.6 s of work every 5 minutes on a full box). If nothing: nothing is built.
+2. **R-892** — where does the Tester 1 box run, and may CC reach it by SSH? Then the update test can run there too. If
+   nothing: the update test stays on the scratch box only.
 
 ## Afternoon (2026-10-06): your two answers built; the list at 137
 
@@ -17,7 +35,7 @@ list is at 137. Report: `REPORT.md`.**
 - **wger's two fixes are proven** on the scratch box: a stranger cannot sign up, visits make no guest accounts, and mail
   works when switched on. wger stays hidden: it still shows no styles or photos.
 
-**Needs you (none urgent):**
+**Needs you (none urgent):** *(answered 2026-10-06 14:24 and done)*
 1. **R-469** — the catalog's database-version check cannot be removed any more: it is now how decision 35's per-app
    proof is enforced. (A) close the row and keep the check (my pick), or (B) keep the row open. If nothing: the row
    stays open; the check works either way.
diff --git a/documentation/audits/design-build-2026-10-06/delivery/T1-9202-repoint-live.txt b/documentation/audits/design-build-2026-10-06/delivery/T1-9202-repoint-live.txt
new file mode 100644
index 00000000..7c2a03f3
--- /dev/null
+++ b/documentation/audits/design-build-2026-10-06/delivery/T1-9202-repoint-live.txt
@@ -0,0 +1,27 @@
+26:    repo_url: https://gitea.dooplex.hu/admin/app-catalog-felhom.eu.git
+3
+RESTORED-IDENTICAL
+
+gitea.dooplex.hu/admin/felhom-controller:0.301.0
+gitea.dooplex.hu/admin/felhom-controller:0.301.0 sha256:03b7f7b6293bd004b928a4fc991d9aa02cb3902ed2ef13aad81071ecfdd8538d
+felhom-controller Up 25 seconds (healthy)
+filebrowser Up 7 hours (healthy)
+paperless-webserver Up 14 hours (healthy)
+paperless-postgres Up 14 hours (healthy)
+paperless-redis Up 14 hours (healthy)
+traefik Up 30 hours
+0
+removed ghcr.io/thomiceli/opengist:1.15
+kept-or-absent ghcr.io/cmintey/wishlist:v0.67.1
+kept-or-absent wger/server:2.7
+kept-or-absent nginx:1.30.5-alpine
+kept-or-absent docmost/docmost:0.95.0
+kept-or-absent docmost/docmost:0.96.0
+kept-or-absent rommapp/romm:5.0.0
+kept-or-absent rommapp/romm:5.3.0
+kept-or-absent mariadb:11.4
+kept-or-absent postgres:16-alpine
+kept-or-absent vaultwarden/server:1.36.0-alpine
+kept-or-absent vaultwarden/server:1.37.4-alpine
+kept-or-absent sha256:8f31d56f2d56cac3456080b3146624cf62e64e3f6952f6fae03fda946511a3f0
+/dev/loop0       32G  1.3G   29G   5% /
diff --git a/documentation/audits/design-build-2026-10-06/delivery/T2-drill-reset.txt b/documentation/audits/design-build-2026-10-06/delivery/T2-drill-reset.txt
new file mode 100644
index 00000000..4853fffe
--- /dev/null
+++ b/documentation/audits/design-build-2026-10-06/delivery/T2-drill-reset.txt
@@ -0,0 +1 @@
+drill=a5a5b51 live=a5a5b51
diff --git a/documentation/audits/design-build-2026-10-06/delivery/controller-delivery.txt b/documentation/audits/design-build-2026-10-06/delivery/controller-delivery.txt
new file mode 100644
index 00000000..d921415c
--- /dev/null
+++ b/documentation/audits/design-build-2026-10-06/delivery/controller-delivery.txt
@@ -0,0 +1 @@
+2026-10-06T14:07:25Z demo-hp + demo-felhom felhom-controller:0.301.0 (healthy, docker ps on each guest 9201); tester-1 hub page 'Controller elindult (0.301.0)'; Tester 2 not touched
diff --git a/documentation/backlog/CLOSED-ITEMS.md b/documentation/backlog/CLOSED-ITEMS.md
index 5906bd05..9c7b7d07 100644
--- a/documentation/backlog/CLOSED-ITEMS.md
+++ b/documentation/backlog/CLOSED-ITEMS.md
@@ -26,6 +26,15 @@
 
 ---
 
+## 2026-10-06 (evening) — the design build
+
+The full text of every row below: `git show 8db4425d98:documentation/backlog/OPEN-ITEMS.md`.
+
+| Row | What | Closed | Evidence |
+|---|---|---|---|
+| **R-469** | **[P3-LOW] REMOVE THE ENGINE-MAJOR RULE when Slice 4 (R-448) ships — a tracked act, not a lapse.** (P3) | CLOSED 2026-10-06 — BY OPERATOR RULING (`09` §3 decision 151, option A) | The engine-major gate stays as decision 35's permanent per-app check; nothing is removed. Re-read and narrowed 2026-10-06 (afternoon): R-463 closed, the gate enforces decision 35 (a PostgreSQL major passes only with a two-venue ladder entry carrying engine_conversion). |
+| **R-638** | **[P2-MEDIUM] The product's database loader cannot replay a copy over a NEWER schema: on PostgreSQL it FAILS, on MariaDB it leaves the newer version's tables behind.** (P2) | CLOSED 2026-10-06 — MEASURED SAFE ON THE MAIN PATHS + SIDE PATHS FIXED BY ORDER (`09` §3 decision 154, option A alone; option B kept as a note) | Slice 0 on 9202 (controller 0.299.0): docmost 0.95.0 -> 0.96.0 migrated 42 -> 48 tables, the household's restore of the pre-update copy put back exactly the copy's 42 (6 new gone), `Imported DB dump` logged, data read back; romm 5.0.0 -> 5.3.0, 27 -> 39, back to exactly 27 (views counted). Controller v0.301.0 (delivered to demo-hp, demo-felhom, tester-1): RestoreApp starts only the DB services, replays, then the app; a failed volume leg skips the replay (fallback and unit restore); TestR638_* 7 tests, red-proved — `audits/design-build-2026-10-06/B/`. Option B (a loader that rebuilds) stays a note: R-893 (the off-site rollback's reverse direction, not fixable by order) carries it. |
+
 ## 2026-10-06 (afternoon) — wger's two fixes proven on 9202
 
 The full text of every row below: `git show a29ee9dd33:documentation/backlog/OPEN-ITEMS.md`.
diff --git a/documentation/backlog/OPEN-ITEMS.md b/documentation/backlog/OPEN-ITEMS.md
index 8e9c4190..fe9239b8 100644
--- a/documentation/backlog/OPEN-ITEMS.md
+++ b/documentation/backlog/OPEN-ITEMS.md
@@ -112,7 +112,7 @@ match what the reader sees is how an instrument stops being believed (R-421). It
 **nothing was proven on the day this line was drawn** and a stopping line that moves a status is a
 stopping line that lies.
 
-## Install & onboarding — 11 rows (P3 7, P4 4)
+## Install & onboarding — 5 rows (P3 3, P4 2)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -122,7 +122,7 @@ stopping line that lies.
 | **R-494** | Install & onboarding | P4 | **NARROWED 2026-09-14 by operator ruling → [P3-LOW] the hub COULD create the tunnel at customer creation, for a domain already on Cloudflare. Not blocking: every customer has their own domain and the operator creates the tunnel per day-0 A.1 (`architecture/01-topology-and-trust.md`).** *Original finding, kept:* **[P1-HIGH] A new customer's dashboard has NO reachable address unless the operator hand-makes a Cloudflare tunnel — the link in the setup-code mail is dead.** MEASURED 2026-09-14 on a fresh install from the public ISO (drill intervention **I1**): the claim mail points at `https://felhom.drill0242.felhom.eu`; that name has **no A and no AAAA** record (`dig @1.1.1.1`, control `felhom.enkisfelhom.hu` resolves); the hub has **no tunnel- or DNS-creation code** (`hub/internal/cloudflare/` holds only geo-rule removal; `cf_tunnel_token` is a pasted, optional form field, `configs.go:1478`) — day-0 runbook A.1 makes it a manual Cloudflare-dashboard step that nothing on the customer-create page asks for; the box's own split-horizon resolver on the appliance LAN IP answered `google.com` but not the dashboard name at 13:27:39Z; the agent applied the record at **13:27:44Z** (`lanresolver: applied split-horizon record … ip=192.168.0.158`, 3 m 46 s after the controller started), so the box CAN answer the name — **but only to a device that uses the box as its DNS server, and no document, screen or mail tells a household to do that**; the router and the installer-offered DNS answer nothing. The page was reachable only at the guest's LAN address with the name forced (`curl --resolve …:443:192.168.0.158`). **A volunteer could not have done that.** **What it needs:** an operator ruling — the hub creates the tunnel and DNS at customer creation, or the product gives a household a LAN address that works with no DNS change. | **READY — rank P3-LOW; owner: CC** **Re-ranked 2026-10-03: P3→P4: operator-side automation; the operator creates the tunnel by hand per the day-0 runbook.** | — | — | CC |
 | **R-504** | Install & onboarding | P4 | **[P3-LOW] `iso.felhom.eu` cannot show an index page on its own — its root returns 404, and the download page lives on the website instead.** MEASURED 2026-09-14: `https://iso.felhom.eu/` and `/index.html` → 404; only named objects answer. The host is an R2 bucket behind a custom domain; whether R2 would serve an uploaded `index.html` at `/` was **not measured** (uploading anything to the public bucket is a publication). The ISO v1.27.0 task puts the Hungarian download page at `felhom.eu/letoltes` (published with the ISO, after the operator's yes). **Remaining:** a redirect from `iso.felhom.eu/` to that page needs a Cloudflare rule the session has no credential for. | **WAITING-ON-OPERATOR — rank P3-LOW; owner: operator (Cloudflare rule)** **Re-ranked 2026-10-03: P3→P4: households are sent to the website's download page; the bare address is cosmetic.** | — | — | operator |
 
-## Apps & catalog — 14 rows (P3 6, P4 8)
+## Apps & catalog — 10 rows (P3 4, P4 6)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -137,17 +137,16 @@ stopping line that lies.
 | **R-770** | Apps & catalog | P4 | **[P3-LOW] Invidious — fit check only; the recommendation is not to build it.** READ 2026-10-01: playback needs `invidious-companion` (rolling `latest`, no version tags); PostgreSQL 14 (EOL 2026-11); `registration_enabled: true` by default; upstream: a bot check means „your IP is blocked from YouTube”, a 429 can last 24 h, triggered by „someone on your network” — on our boxes that IP is the household's. One bad period in 2026 (March, ~2 weeks). No report found of a family's other devices being bot-checked (inference). **Needs:** the operator's go / no-go. `audits/new-apps-2026-10-01/FIT.md` | **WAITING-ON-OPERATOR — rank P3-LOW; owner: operator** **Re-ranked 2026-10-03: P3→P4: a new-app idea waiting on a decision.** | — | — | operator |
 | **R-771** | Apps & catalog | P4 | **[P3-LOW] moonlight-web — fit check only; not buildable through an HTTP-only tunnel at usable latency.** READ 2026-10-01: two unrelated projects (MrCreativ3001/moonlight-web-stream, the original; linckosz/moonlight-web); both need Sunshine/Apollo/Wolf on a gaming PC on the LAN and WebRTC over UDP (40000-40100/udp; linckosz recommends host networking and sends telemetry by default); both have a WebSocket fallback (high latency, all video through the tunnel); a logged-in user controls the PC's desktop. **Needs:** the operator's go / no-go (LAN-only use would need a different publishing model). `audits/new-apps-2026-10-01/FIT.md` | **WAITING-ON-OPERATOR — rank P3-LOW; owner: operator** **Re-ranked 2026-10-03: P3→P4: a new-app idea waiting on a decision.** | — | — | operator |
 
-## App updates — 8 rows (P3 5, P4 3)
+## App updates — 4 rows (P3 4)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
 | **R-440** | App updates | P3 | **[P2-MEDIUM] 23 catalog image pins float, so an update is not reproducible.** `compose pull` on a moving tag fetches whatever upstream published that day. **MEASURED 2026-09-01 over `app-catalog-felhom.eu` @ `29edad9c5bf4`: 79 `image:` lines across 53 apps, 66 distinct; 23 of those lines carry a tag with no patch version.** `postgres:16-alpine` (8 apps), `redis:7-alpine` (6), `mariadb:11.6` (2), plus one each of `postgres:15-alpine`, `postgis/postgis:16-3.5-alpine`, `mariadb:11.4`, `mariadb:12.3`, `ghcr.io/claperco/claper:2.5`, `ghcr.io/thomiceli/opengist:1.13`, `wger/server:2.6`. **A 24th is arguable and is recorded rather than rounded away:** `ghcr.io/immich-app/postgres:16-vectorchord0.4.3-pgvectors0.2.0` pins both extensions exactly but leaves the PostgreSQL patch floating. A customer pressing Frissites can therefore swap their DATABASE ENGINE build with no catalog change and no record; two boxes updated on two days end up different. **Severity MEDIUM on its own; it becomes BLOCKING the moment a pre-update copy exists**, because "what did we upgrade from and to" must be recordable and today it is not — which is also why R-440 must be read next to the digest discipline in Rule 10 of the spike. **MEASURED LIVE 2026-09-01 — the floating pins have ALREADY moved, with a passing control.** Running digests on demo-hp compared against what the registry serves for the same tag today: **`mariadb:11.4` MOVED** (`sha256:4f1d8d20...` -> `sha256:611a2fcc...`) and **`mariadb:12.3` MOVED** (`sha256:a02fe89c...` -> `sha256:dd9b303a...`), while `postgres:16-alpine`, `redis:7-alpine`, `mariadb:11.6` and `opengist:1.13` were SAME — **and both fully-pinned CONTROLS (`rommapp/romm:5.0.0`, `privatebin/pdo:2.0.5`) were SAME.** So on a box with ZERO visible drift by tag, pressing Frissites today silently swaps the DATABASE ENGINE build under `romm` and `bookstack`, with no catalog change and no record. **Compounding fact found while reading:** the recovery unit records `ImagePins` but the manifest comment says *"image NOT stored - re-pulled on restore"*, so a RESTORE of a floating-pinned app also re-pulls whatever is current — the same non-reproducibility on the recovery path. **HALF OF THE ANSWER SHIPPED 2026-09-02 (controller v0.233.0, slice 1): `app.yaml.installed_images` now records, per compose SERVICE, the reference AND the repo digest each container was actually created from — so "what did we upgrade FROM" is answerable on any box that has taken one lifecycle action since the upgrade.** What is still missing is the other half: comparing that digest against what the registry serves for the same tag TODAY, which needs a network call the render path deliberately does not make (see R-446). **The row therefore stays OPEN and its rank is unchanged** — recording a digest does not make a floating pin reproducible; it makes the drift measurable after the fact. `audits/SPIKE-app-update-2026-09-01.md` **— NIGHT 2026-09-23:** every image moved tonight (and the 21 backfilled moves) carries its resolved digest in the catalog's test record; the floating pins themselves still float until the box pulls by digest (`09` §6.4 part 6). **-- MEASURED 2026-09-30 on demo-hp 9201: a fresh install or a guarded Update renders `name:tag@sha256` from the ladder (`digest.go` `RenderWithLadderDigests`) — 9 of 20 services there run such a definition (adventurelog, docmost, paperless-ngx). The other 11 run TAG-ONLY definitions: bookstack, kimai, opengist, privatebin, romm were installed before v0.269.0 and not updated since, and `CarryDigests` (`digest.go:141`) keeps only a digest the running definition already has; bentopdf and calibre-web have no ladder at all. So a re-pull of those (a restore) takes whatever the tag serves that day. `audits/pg-last-six-2026-09-30/E/E2-digests-demo-hp.txt`.** **-- 2026-09-30 (evening):** calibre-web now has a ladder entry (`53a4a1d`), so a new install or a guarded Update renders its tested digest; bentopdf still has none. `audits/more-night-apps-2026-09-30/` **Merged 2026-10-05 from R-446 (duplicate):** the household-visible consequence — for these apps the „Naprakész" badge can never turn „behind" (`felhom-controller controller/internal/stacks/updateorder.go:96` returns false with no catalog digests / no test date); R-740 (same-tag re-test) is closed, so floating-tag drift for laddered apps is handled. | **NARROWED 2026-09-30 — floating only for (1) apps with no ladder entry and (2) apps installed before v0.269.0 until their next guarded Update; owner: CC.** **Re-ranked 2026-10-03: P2→P3: narrowed to apps with no ladder entry and pre-v0.269 installs; each guarded update fixes the latter.** | — | — | CC |
 | **R-462** | App updates | P3 | **[P2-MEDIUM] Widen the upgrade harness beyond three apps — and the cost is dominated by FIXTURES, not by machine time.** The R-449 harness works and is proven by a red negative control (`audits/SPIKE-upgrade-test-2026-09-06.md` §1). **Costed with this run's REAL numbers rather than an estimate:** a successful edge takes **6.4 s – 305.1 s, median 71.8 s**; a FAILING edge takes **556 s**, roughly **8×**, because a negative is only honest if it waits out the full settle window; 3 apps / 11 images cost **5.07 GB**, so 53 apps naively extrapolate to **~90 GB** and, at the median, about an hour of harness time for one edge each. **THAT EXTRAPOLATION UNDERSTATES THE REAL COST BY AN ORDER OF MAGNITUDE, and that is the point of this row.** Two of the three apps needed a bespoke non-browser seed route; one needed two attempts and a discarded approach; one (bookstack) can only ever be half-proven (R-460). **Fixture time scales with apps and does not amortise.** **The decision this row is really asking for is scope, not schedule:** all 53, or only the apps a customer would lose data from, or only apps whose catalog transition is a MAJOR. **Recommended shape, NOT a design — the operator picks:** start with the apps that carry a database, because §3 measured that the abort question only ever bites there. Owner: **VIKTOR rules on scope, CC implements.** `audits/SPIKE-upgrade-test-2026-09-06.md` §5 **ROW CORRECTED 2026-09-21: the scope is NOT open and this row said it was.** It read *"VIKTOR rules on scope"*; the operator ruled on 2026-09-13 (`09` §3 decision 6) that the upgrade test goes to **ALL** apps through the nightly rotation, explicitly *not* "database apps first". What is open is the WORK, not the scope. An ORDER inside that ruling — the 15 database services first, because that is where a wrong answer costs data rather than uptime — is costed as a drill brief in `09` §6.4: legs A–E ≈ **21–34 CC-hours** plus ~25–30 GB on a scratch host, with legs C (a PostgreSQL `pg_upgrade` rehearsal) and E (one automatic night on a throwaway) the two that unblock a decision. **-- UPDATE NIGHT 2026-09-21:** **The count moved from 3 apps to 21 EDGES ACROSS 19 APPS.** The update night walked real within-a-major upstream edges on scratch guest 9202 through the product's own guarded Update, each app seeded and read back through its OWN front door with a negative control on every readback: **14 proven, 3 failed, 4 inconclusive**. Proven: actualbudget, audiobookshelf, bookstack, docmost, grafana, home-assistant, mealie, n8n, navidrome, papra, privatebin, romm, vikunja, and nextcloud's MariaDB engine major. **Ten of the fourteen printed a verbatim migration line**, so the database really was rewritten and the data still read back. Box-side fixtures for 20 apps now exist at `audits/update-night-2026-09-21/fixtures.py`, and four (actualbudget, navidrome, audiobookshelf, vikunja) are ported into `app-catalog-felhom.eu/scripts/upgrade_fixtures.py` with seven new EDGES (U1-U7) so the same edges can be run on the harness venue **with their ABORT step**, which the box deliberately does not offer. **OWED, stated so it is not mistaken for done:** the U1-U7 harness RUNS (the code is in, the runs are not), and fixtures for the four inconclusive apps, of which two (vaultwarden, zipline) cannot be seeded at all while the catalog rightly closes their sign-up (see R-624). **-- 2026-09-23, the RomM lesson is IN THE HARNESS:** `upgrade-test.py` v2 runs every edge that read back under light load for `--soak` seconds (default 600) and reads the kernel's `oom_kill` counter host-side; a kill or restart turns `proven` into `failed`, a peak over 80 % of the limit adds `memory_tight`. **Red-proof:** romm 5.0.0 → 5.3.0 on the template AS PROMOTED (512M, four workers) — seeded, migrated, read back, and then **OOM-killed at +76 s** under four light callers, verdict `failed` (Docker's own OOMKilled read true here; restarts stayed 0, which is why the walk never saw it). Ten minutes is ample for this failure; demo-hp's first kill came at two hours only because nothing was loading it. Evidence `audits/update-rulings-2026-09-23/harness/`. **— NIGHT 2026-09-23:** the bench and the box now share ONE fixture set — the box walk's fixtures run on the bench through `upgrade_boxport.py` (ported verbatim into the catalog), plus a new wishlist fixture and fixes for opengist 1.15, komga (`/api/v2/users/me`) and nextcloud (wait for `occ status`). 14 apps / 15 edges tried; 12 proven on both venues and published with their test records (`audits/DRILL-night-2026-09-23.md` Part C). **-- 2026-09-30 (day brief): three new front-door fixtures (sparkyfitness, rallly, outline; catalog `e6f3ec2`) and five apps moved on both venues — the three PostgreSQL conversions (R-463) plus bookstack 26.05.5 → 26.09.1 and kimai apache-2.57.0 → 2.67.0 (upstream dropped the `apache-` prefix; the plain tag's digest equals `apache`'s, measured). The catalog currency and the next-apps ranking: `audits/catalog-currency-2026-09-30.md` — 25 of 53 apps behind upstream inside a major, 19 across one (morning); after the session **31 apps can update themselves at night (+ nextcloud with a whole copy)**, 32 carry a proven step, 21 have no ladder.** **-- 2026-09-30 (evening, more-night-apps brief): ten more steps published on both venues** — first ladders for calibre-web, gitea, wger, crafty-controller, uptime-kuma, zipline (new front-door fixtures; gitea's installer form), within-major steps for emby, ghost, home-assistant, outline, rallly. **Night-updatable by the audit's method (a): 30 + 2 conditional at the session's start → 35 + 3 conditional** (calibre-web conditional: `files_may_change`). zipline got a two-step ladder 4.6.1 → 4.7.0 → 4.8.0 (the direct jump fails, R-742). Stopped: wanderer (the bench cannot run it, R-739). Fixture/harness defects fixed on the way: R-735, gitea's installer, the HTTPS backend on the bench, per-file names for `files_may_change`. `audits/more-night-apps-2026-09-30/` | **READY — rank P2-MEDIUM; owner: CC (scope already ruled, `09` §3 decision 6)** **Re-ranked 2026-10-03: P2→P3: 35+ apps already update by proven steps; an app without a ladder simply does not move, which is safe.** | — | — | CC |
-| **R-469** | App updates | P3 | **[P3-LOW] REMOVE THE ENGINE-MAJOR RULE when Slice 4 (R-448) ships — a tracked act, not a lapse.** Since 2026-09-13 `app-catalog-felhom.eu` `CLAUDE.md` rules that *until the Update button takes a verified backup as its precondition, no template may move a database-engine image across a major version* (four MariaDB, eleven PostgreSQL services), and `scripts/check-engine-major.py` (fourth row of `catalog_gates.py`, run by `.githooks/pre-push` with the push range) refuses one, naming the rule and this expiry. **Why the rule:** every `mariadb:` sidecar now carries `MARIADB_AUTO_UPGRADE=1` (R-459), so a MariaDB major move CONVERTS the customer's datadir on the next Update; PostgreSQL converts nothing and refuses to start (R-463). Either way a customer-data event with no backup in front of it. **Honest limit, not re-filed:** the gate needs a parent commit and CI fetches at `--depth 1` — the R-452 gap — so on a shallow clone the runner skips it out loud and only the hook bites. **When R-448 ships:** delete the CLAUDE.md rule, the gate's row and the gate, in one commit that cites this row; then close this. **2026-09-13 — UNBLOCKED, NOT LIFTED.** R-448 shipped in controller v0.237.0/v0.238.0 (slice 4): an update now refuses without a restorable, proven Tier-2 copy, backs up first when it is stale, takes a safety dump, and holds an app that does not come up — the precondition this rule was waiting for. **The rule stays in force until someone deliberately removes it**, which is a separate act (and is worth weighing against R-475: an app with no Tier-2 copy cannot be updated at all, so the guard does not yet cover every app a major engine move would touch). **HALF-LIFTED 2026-09-21, catalog `5ff36d098cbc`.** Slice 4 shipped 2026-09-13, so the rule's own expiry condition is met — **for MariaDB**: the four `mariadb:` sidecars have both halves they need, a verified backup in front of the Update (any tier since v0.239.0) and `MARIADB_AUTO_UPGRADE=1` whose conversion the harness WATCHED run on E3/E3b with the seeded data read back after. **PostgreSQL and MySQL stay refused** — postgres performs no `pg_upgrade` and REFUSES to start on an older major's datadir across eleven templates (R-463); a backup is a route BACK, not a conversion. The refusal text now cites R-463 instead of the shipped R-448. **R-450's second half is enforced in its place:** a MariaDB major must be the ONLY image move in its template in that commit (the bookstack `0b73e5e` shape — two migrations behind one edge). The gate now PRINTS what it allowed, by name — a lifted rule that goes quiet is a lifted rule nobody can audit. Two new decoy cases; two red-proofs, each seen to fail; 40 cases green. **What remains of this row:** the PostgreSQL half, which is R-463's to clear — see `09` §3b **Q5**. **-- NARROWED 2026-09-25 (evening), catalog `6a4a5f0`, `09` §3 decision 35:** the PostgreSQL half now passes ONE app at a time — only a template whose ladder entry for the step is proven on BOTH venues and carries `engine_conversion` (the box converts it, controller v0.273.0), as the only image move in its commit. Every other PostgreSQL app stays refused; the postgis family is judged now (it was not). CLAUDE.md rule text updated the same commit. Decoys + red-proof: `audits/night-2026-09-26/C/`. **-- RE-READ 2026-10-06 (afternoon, `09` §3 decision 150): the removal condition is NOT met, and the rule has stopped being one that expires.** R-463 closed 2026-09-30 (8 of 11 PostgreSQL apps converted by the box; zipline, adventurelog and immich stay on 16 by decision 42), but the gate is now how decision 35 is enforced: a PostgreSQL major passes only with a two-venue ladder entry carrying `engine_conversion`. Removing it would let an unproven PostgreSQL major ship (the image refuses to start on the old datadir, R-463) — a loosened fence, which needs the operator. What is still missing for removal: nothing CC can build; only a decision that decision 35's check is no longer wanted. Same edit: the catalog `CLAUDE.md` rule's stale counts corrected (five MariaDB services with grimmory; twelve PostgreSQL-family, postgis and immich counted). | **NARROWED 2026-10-06** — PARTLY CLOSED 2026-09-21 (MariaDB lifted); the PostgreSQL half is now decision 35's permanent per-app check | — | Operator: (A) close this row — the gate stays as decision 35's permanent check (CC's pick); (B) keep it open as a reminder. If nothing: the row stays open; the gate keeps working either way | operator |
 | **R-683** | App updates | P3 | **[P3-LOW] Watch: after a power cut during an update's health check, the hold named an HOUR-OLD second-drive copy, not the one the update's own backup should have just made.** 2026-09-24 chaos round 3 (nextcloud, `backup_max_age: 1m`): no `backing-up` phase was seen and the hold named Tier 2 at 13:04 for an update pressed at 14:04; the pre-cut controller log was lost with the container (the runner now saves it at arm time — R-320). Round 11, the same action without a power cut, named a fresh 14:34 copy and logged the Tier-2 copy. The sentence was TRUE (it named the copy it offered); the question is why the update did not back up first. Not reproduced; watch the next power-cut drill. `audits/night-2026-09-24/E/round-03*.json`, `E/round-11-controller-pre.log` | **OPEN — P3; owner: CC (watch)** | — | — | CC |
 | **R-785** | App updates | P3 | **[P3-LOW] SparkyFitness is pinned 11 releases and a major behind upstream (v0.17.3; upstream v1.7.3, v1.6.0 dated 2026-07-24).** READ 2026-10-01 (`audits/visitors-2026-10-01/C/bench/C1-previous-tag.txt`). **Needs:** an update walk 0.17 → 1.x through the ladder (bench + box), after R-784 is decided. | **OPEN — rank P3-LOW; owner: CC (after R-784)** | — | — | CC |
 
-## Backup & restore — 34 rows (P2 8, P3 11, P4 15)
+## Backup & restore — 32 rows (P2 7, P3 11, P4 14)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -157,7 +156,6 @@ stopping line that lies.
 | **R-304** | Backup & restore | P2 | **The retained escrow key works, and the customer is told their correct code is wrong.** DRILL 2026-08-12 answered the three questions separately, on `demo-felhom`, with planted data. **(a) retention: WORKS** — the first retained row in fleet history to carry material (`host_escrow_superseded` id 11, `identity_blob` 572 B), byte-identical (`sha256 a10032341c8584ed…`) to the pre-supersession `host_escrow` row. **(b) the material opens the old store: YES** — unsealed with the OLD recovery code it yielded a password byte-identical to the pre-change one (`sha c60c8bc737a6b7c6…`), and restored three planted files **byte-identical** from a store the box itself could no longer open (negative control first: `Fatal: wrong password or no key found`), **including a Hungarian accented filename verified as raw bytes**. **(c) the customer's route: DOES NOT EXIST, and misinforms.** `ListSupersededEscrow` (`store.go:2841`) is the only reader of a retained `identity_blob` and has **zero production callers** — five call sites, all `_test.go`; the product path (`POST /escrow/recover-offsite-password` → `FetchIdentityEscrow` → `GetHostDRBundle`, `store.go:3152`) selects `FROM host_escrow` — the CURRENT row only. Asked for the old password with the code that demonstrably opens the retained row, the product answered **"the recovery code did not open the sealed bundle — nothing was written"**. **This is the R-224 class again**: there an unreachable hub was reported as a bad code; here a VALID code for retained history is reported as a bad code, and the customer's attempt ends there. **Consequence:** the census answer stands (it was about retention); the countdown banner's promise is true in substance and false in practice; **any capability-map claim that the customer can recover the old history with their recovery code is false today and must move** | **READY (L) — NEW 2026-08-12, RANK 1** | R-198, R-199, R-224, R-241 | Decide the shape: serve retained rows on the recovery path (needs a "which package?" choice — a customer may have several), or stop promising retrieval anywhere the customer cannot perform it. **Until one of those, the honest position is that retention is an operator-only capability.** At minimum, the refusal must stop asserting the code is wrong when the hub simply never looked | operator + CC |
 | **R-366** | Backup & restore | P2 | **The 21 August reinstall orphaned `demo-hp`'s PBS whole-guest archives as well as its off-site repo — the box can no longer read its own pre-reinstall backups, and this surfaces only as a restore-test failure.** Hub event 3016, 2026-08-21 21:59:28Z, unprompted: `Restore-test FAILED on the pbs tier: archive felhom-pbs:backup/ct/9201/2026-08-18T03:58:43Z could not be restored+booted … proxmox-backup-client failed: Error: wrong key - unable to verify signature since manifest's key 3f:4f:65:c0:d8:f3:9f:3c does not match provided key dd:d1:d8:53:44:62:5e:0b`. The archive predates the reinstall by three days. **This is the PBS-tier analogue of R-193** (a guest rebuild mints a fresh secret and orphans the history), and the two together mean a rebuilt box loses BOTH off-premises tiers at once: the restic repo needed a self-heal + re-toggle (see the drill report), and the PBS archives are simply unreadable to it. **Credit: the restore-test caught it and said so precisely** — the mechanism works. **The gap is what it is called:** it is reported as *a restore test that failed*, which reads as a flaky verification, not as *every whole-guest backup you took before the reinstall is unreadable on this machine*. **Found incidentally by the 2026-08-21 backup-truth drill; nobody was looking for it.** | **OPEN — HIGH** | related: R-193 | Establish whether the pre-reinstall PBS archives are recoverable at all (the old key's whereabouts), and separate the two verdicts: a tier whose ARCHIVES ARE ORPHANED is a different alarm from a tier whose restore test failed. Do not close on the strength of the restore-test wording alone. | CC |
 | **R-518** | Backup & restore | P2 | **[P2-MEDIUM] „Mentés most" on the whole-system backup stops every app for about eight minutes while the page promises „csak néhány másodpercre".** MEASURED 2026-09-14 (BIGNIGHT, VM 333, 12 apps): the button's call quiesced all 12 stacks at 19:03:23Z (first stopped 19:03:27Z); the local vzdump ran 19:03:49 → 19:09:59Z; the controller then kept the apps stopped for the second (PBS) tier and restarted them at 19:10:09Z after it failed, the last started 19:11:12Z (`phase4/guest-backup-quiesce-log.txt`) — **≈ 7 m 45 s** with every app answering 404. The page under the button: „Pillanatkép-mód: az alkalmazások csak néhány másodpercre állnak le." A household pressing it at dinner loses every app for the length of the dump, and longer on a bigger box. **Fix shape:** state the real expected downtime (it scales with data), or quiesce per tier and not across a second tier's attempt; do not start a tier whose storage is absent (see R-517). **NARROWED 2026-09-15 (controller v0.243.0 + agent v0.131.0):** a tier whose storage the agent reports absent is skipped before anything stops (`backup_tier_skipped`, once per absence; unknown never skipped), and the button copy now says „általában néhány perc, nagyobb adatnál több". Unit-proven with red-proofs. **Still open:** quiesce per tier, so a slow second tier does not keep every app down. **— NIGHT 2026-09-23 (controller v0.267.0):** the copy half is DONE: the page and the confirm now state the measured stop (≈ 8 minutes on a 12-app box), both languages, red-proofed (`audits/night-2026-09-23/A5-*`). The brief's „csak néhány másodpercre" had already gone in v0.243.0. **Still open:** quiesce per tier, so a slow second tier does not keep every app down. | **READY — P2, narrowed to per-tier quiesce; owner: CC (controller). 2026-10-05: the copy now states today's measurement too (demo-hp, 9 apps, local tier only: 5 min 47 s) — controller v0.296.0, `audits/hub-safety-2026-10-05/partE/`.** **2026-10-05 (burn-down night): a one-page design proposal (no code) is in `audits/night-burndown-2026-10-05/design-R-518.md`** — for the operator. **2026-10-06: BUILT — controller v0.301.0, `09` §3 decision 156 (reverses R-82's one window).** One stop per tier; the button makes the local copy only. Measured first, read-only: demo-felhom's night off-site job reached `snapshotted` 2 s after it started, the app back 8 s later (the off-site part of a stop is seconds). **Not shown live:** a press under the new rule — scratch 9202 has no agent connection and the demo boxes take deliveries only. Red tests and the build: `audits/design-build-2026-10-06/`D/. **Risk noted, unmeasured:** after a local copy the agent runs its OS step, and the off-site tier then answered BUSY (2026-10-05) — under the new rule that costs one short stop with no copy before the 15-min backoff. | — | Read back the first night runs on demo-hp and demo-felhom under v0.301.0 (the agent's `snapshotted` line, the apps' StartedAt, the controller's window lines); close with that evidence. If nothing: the row stays open | CC |
-| **R-638** | Backup & restore | P2 | **[P2-MEDIUM] The product's database loader cannot replay a copy over a NEWER schema: on PostgreSQL it FAILS, on MariaDB it leaves the newer version's tables behind.** MEASURED 2026-09-23 on 9202. `ImportDump` (`appbackup/dbdump.go:719`, `psql -v ON_ERROR_STOP=1 --single-transaction`) replays a `pg_dump --clean --if-exists` file over the live database. After docmost 0.95.0 → 0.96.0 migrated, the replay of the pre-update copy was refused in 0.40 s, rc 3: *cannot drop constraint workspaces_pkey on table public.workspaces because other objects depend on it / DETAIL: constraint oauth_clients_workspace_id_fkey …* — the new version created six tables whose foreign keys point at old ones, and `--clean` only drops what the dump knows. Database unchanged (the transaction rolled back). On MariaDB (`mariadb-dump`, `FOREIGN_KEY_CHECKS=0`) the same replay after romm 5.0.0 → 5.3.0 returned rc 0 in 1.25 s and left **12 base tables** of the new version behind; RomM 5.0.0 happened to ignore them. **What worked:** `DROP SCHEMA public CASCADE; CREATE SCHEMA public;` + the dump in ONE transaction — rc 0 in 1.38 s, every table, index and extension back. **Why this is a row of its own and not only part of R-637:** the SAME loader backs shipped paths — `rollbackSafetyDump` (off-site restore's undo) and the dump replay of the restores — so **any restore of a copy taken BEFORE an update that migrated, replayed over the migrated database, may fail the same way. NOT MEASURED:** whether the unit restore the hold sentence names does this (it also carries the data VOLUME tar, which may make the replay moot). That is the measurement owed, on 9202, before anyone relies on it. Evidence: `audits/update-rulings-2026-09-23/README.md` Part 1, `docmost-45`, `romm-44`. **-- NARROWED 2026-09-23:** the undo no longer touches this loader — it copies folders (decision 19, controller v0.263.0). **What stays open is the part about SHIPPED paths:** `rollbackSafetyDump` and the restores' dump replay still replay over whatever schema is live, and whether the unit restore the hold sentence names works after a real schema migration is STILL UNMEASURED. | **OPEN — P2, narrowed to the restore paths; owner: CC; measure the named restore after a real schema migration first** **2026-10-05 (burn-down night): a one-page design proposal (no code) is in `audits/night-burndown-2026-10-05/design-R-638.md`** — for the operator. | — | — | CC |
 | **R-893** | Backup & restore | P3 | **After a failed OFF-SITE replay, the rollback pours the NEWER pre-restore copy over the OLDER volume just put back.** Read in source 2026-10-06 (R-638 option A, not measured): `internal/backup/offbox_reconstitute.go` writes the undo copy from the live (newer) database, replaces the volumes with the snapshot's older tars, then — when the replay fails — `rollbackSafetyDump` loads that newer dump over the older database volume. The loader only drops what the dump knows, so tables the newer migration removed stay; and when the snapshot's older definition was written, the rollback branch does not put the newer definition back, so the older app starts on rolled-back data; non-database volumes stay at the snapshot's state. An order change cannot fix it (the only undo is a logical dump, and its volume was replaced). Known limit in `07` §6.3. | **OPEN — filed 2026-10-06** | a design: R-638 option B (a loader that rebuilds instead of overlays) or a pre-restore volume copy | Measure it once on 9202 (a forced replay failure after an off-site restore over a migrated app); then a design for the operator | CC |
 | **R-822** | Backup & restore | P2 | **An add-only key does not make retention safe: an attacker who can only ADD snapshots can make the honest pruner erase every real one.** MEASURED 2026-10-03 (lab, restic 0.14.0 from the controller image, rclone `--append-only`): 13 empty snapshots dated in the future with the same host and tag, added through the add-only key (all allowed), make the box's exact policy `forget --group-by host,tags --keep-daily 7 --keep-weekly 4 --keep-monthly 6` keep only the fakes and select **all 3 real snapshots** for removal (`--dry-run`). **Whoever prunes an append-only repo — the box in a window, or a Felhom-side worker — inherits this.** Not a defect today (today the box can simply delete, R-95); a PRECONDITION on the R-95 build, like R-430 was. `audits/offsite-append-only-2026-10-03/lab/C3-retention-poisoning.txt` | **NARROWED 2026-10-03 — the guard ships in controller v0.289.0 (future-dated / newer-than-hub / recent-removal refusals, oldest-first cap, the lab's 13-fake shape refused in a test). RESIDUAL, not closable by a guard: an add-only attacker can plant PAST-dated snapshots interleaved with real ones and so steer weekly/monthly keeps; bounded per window by `MaxRemove` and the hub's count check, not prevented.** | — | Before any `forget`: refuse when a snapshot is dated in the future or newer than the newest the hub has seen reported; dry-run first and abort above the count the policy can remove in a week; hub compares the count before/after (DESIGN.md §3) | CC |
 | **R-49** | Backup & restore | P3 | **[P2] The offsite capture set is ~90% cache and duplication — 1.1 GB of a 1.2 GB immich "photo backup".** Measured 2026-07-19: `immich_ml_cache.tar` **823 660 032 B (~60%)** — re-downloadable ML model weights; `immich_postgres_data.tar` **308 251 136 B (~23%)** — a raw tar of the postgres data dir that DUPLICATES the logical `.sql` dump captured beside it; `upload/backups/` **18 MB** — immich's own nightly dump, a backup inside the backup, growing daily; plus the stranded pre-v3 `dccc13fe…` tree (~36 MB) no DB has ever referenced. Actual irreplaceable content: **72 MB of originals**. **MIGRATED FROM `ROADMAP.md` 2026-08-22 (R-369) — originally filed 2026-07-19, size S–M, roadmap state `idea`.** Moved verbatim; nothing added or reinterpreted. The roadmap keeps its copy as history, marked moved. | **OPEN — migrated from ROADMAP 2026-08-22, rank unchanged** **Re-ranked 2026-10-03: P2→P3: wasted space and transfer, no data risk; needs a capture-set ruling, not a sale blocker.** | — | **Evidence: `audits/DIAG-immich-restore-round2-2026-07-19.md` §4 (full byte breakdown).** This is the customer's offsite quota and transfer cost, and it lands on the Hetzner sub-account they are billed for. **Recorded, deliberately not changed** — a capture-set exclusion is a data-loss-shaped decision and gets its own ruling, not a drive-by edit. Candidates in priority order: (a) `immich_ml_cache` — pure cache, strongest case; (b) the `postgres_data` volume tar where a logical dump of the same DB is already captured (the dump is what the restore path actually replays); (c) `upload/backups/`. Likely generalises past immich into a template-classification rule about cache volumes and self-backup directories, so it should be specified against the catalog, not one app | CC |
@@ -185,7 +183,7 @@ stopping line that lies.
 | **R-832** | Backup & restore | P4 | **ep0's copy in a place outside both Hetzner and the operator's home (roadmap).** Today DooPlex (the operator's home) holds it (decision 71). A Hetzner Storage Box would share a provider with ep0 and with every household's file backups, and cannot run PBS, so the copy could not be verified or restored from directly. | **DEFERRED — later, if the product grows** | — | — | operator |
 | **R-878** | Backup & restore | P4 | **A catch-up (R-871) runs the database-dump leg in the DAY, and that leg stops an app with a volume for its copy — the household may notice the stop, and a large volume makes it longer.** MEASURED 2026-10-05 on demo-felhom: the catch-up at 08:25:02 stopped opengist, copied 182.5 KB, started it again — about 1 s, then a few seconds of `health: starting`; the night does exactly the same, unseen. Nothing measured for a large volume. Fix direction (if it matters): skip the volume copy of a running app in a DAYTIME catch-up and leave it to the next night, or warn. `audits/catchup-2026-10-05/partA/live-demo-felhom.txt` | **READY — owner: CC** **2026-10-05 (burn-down night): NEEDS A LIVE MEASUREMENT** — a timed catch-up on 9202 for an app with a multi-GB volume, then the skip-or-warn choice. | — | measure a large volume first | CC |
 
-## Storage & devices — 8 rows (P3 6, P4 2)
+## Storage & devices — 7 rows (P3 5, P4 2)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -197,7 +195,7 @@ stopping line that lies.
 | **R-331** | Storage & devices | P4 | **Disk health Phase 3 — growth-rate detection, and retiring the static 64.** The v0.215.0 count backstop (64 unreadable sectors → Hiba) is **a judgement from ONE drive**: the observed benign excursion peaked at 16 and cleared inside an hour, and the terminal run passed 64 at 13 Aug 11:28 and never came back. It is deliberately a backstop BEHIND the sustain rule, not the primary signal, but it is still a magic number tuned on a single sample and it will be wrong for some drive. With Phase 2's history the box can ask the question that actually matters — *is this count climbing, and how fast* — which distinguishes a drive with eight stable aging sectors from one adding forty a day, something no static threshold can do. Revisit 64 when that exists | **READY (M) — NEW 2026-08-14** | R-330 | Growth-rate rule over persisted samples; re-derive or delete the static 64 | CC |
 | **R-352** | Storage & devices | P4 | **Four screens state something untrue about where an app's data goes, and the configured default is consulted by nothing that places data.** Measured on `demo-hp` 2026-08-21. **(1)** **40 of 53** catalogue templates declare no data path (`grep -rl 'env_var: HDD_PATH' --include='.felhom.yml'` → 13; total 53); those apps get **no storage field and no default** — their data lands in a named Docker volume on the system drive. **(2)** `GetDefaultStoragePath()` has exactly **three** non-test callers — the metrics collector (`cmd/controller/main.go:410`), the dashboard SystemInfo panel (`web/server.go:733`) and `.fab` import landing (`handler_export_upload.go:154`). **The deploy route never reads it.** Its field comment `// new apps use this by default` (`internal/settings/settings.go:453`) has never been true — an invariant with no test pinning it. **(3)** The first-tier backup follows the data onto the same disk (`backup/backup.go:324-334` → `systemDataPath`), so data and nearest copy share one device for a customer doing nothing wrong — the posture Tier 2 refuses outright at `tier2.go:329`. **(4)** „1 alkalmazás használja" on the Drives page counts only `Env["HDD_PATH"] == path` (`web/handlers.go:2118`), so it can never include the 40-class; it truthfully means *„1 of the apps that CAN use a drive does"*. | **NARROWED** — **PARTLY CLOSED 2026-08-21** — visibility shipped; **placement OPEN** | — | **Shipped tonight (visibility only, no placement change, nothing migrated):** the deploy page now states where the app's data will live before the button is pressed, naming the system drive for the 40-class and the selected drive for the 13. **⚠ RE-FRAMED 2026-08-22 — THE FOUR MEASUREMENTS STAND; TWO OF THE CONCLUSIONS DRAWN FROM THEM DO NOT.** (1) is a measurement and is correct, but "those apps get no storage field and no default" is not a deprivation: the architecture places **hot** data (DB/config/cache) on fast storage inside the guest and states that placement is **ENFORCED** (`documentation/architecture/01-topology-and-trust.md:150-152`). The 40 are all-hot apps; the 13 are the ones with **bulk** content, which belongs on an attached drive. There is no choice being denied. (3) **overstated one risk and understated a distinction.** Since R-165 the guest carries a small OS rootfs plus **ONE** data volume at `/var/lib/felhom`; `/var/lib/docker` and `/mnt/sys_drive` are two **binds of that same volume** (`felhom-agent/configs/build-golden.sh:29-40, 99`) — the `mp0`/`mp1` split assumed here was retired 2026-08-03. **Real risk:** a physical-disk failure loses the data and its first-tier copy together — which is what the off-site and whole-machine tiers exist for, and which is equally true of a drive-resident app whose unit sits beside its data by design. **Overstated risk:** a full data volume stopping the operating system — the OS rootfs is a separate volume and the capture floor refuses per app before exhaustion (`00-capability-map.md:94`), watched working 2026-08-21 with the volume at 99% and all 15 containers healthy. **The comparison to Tier 2's same-disk refusal (`tier2.go:329`) is withdrawn:** Tier 2 refuses a SECOND copy on the same disk; Tier 1's unit is meant to sit beside the data. **(2) and (4) are untouched and remain correct** — (2) is now filed on its own as **R-368** with its scope measured, and (4) needs no ruling: the count is honest and only easy to misread. **The specification for the rest is filed at `documentation/backlog/SPEC-app-data-placement-2026-08-21.md`** (corrected 2026-08-22, framing marked inline, measurements kept) and lists the five points a ruling must settle (compose-template vs controller, existing deployments, when the SSD is legitimately right, `IsDefault` must become true or go away *with a test*, and the Drives-page count). **An earlier recommendation to refuse deployment until a drive is registered was WITHDRAWN** — it assumed the customer had failed to choose; they had no choice to make. | **Viktor rules**, CC executes |
 
-## Security & access — 20 rows (P2 2, P3 16, P4 2)
+## Security & access — 15 rows (P2 2, P3 11, P4 2)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -217,7 +215,7 @@ stopping line that lies.
 | **R-525** | Security & access | P4 | **[P3-LOW] FileBrowser has its own login; putting it behind the dashboard session (traefik forwardAuth or Quantum proxy auth) is a new mechanism nobody has measured.** Filed 2026-09-15 by the P1-fixes task (B.5). R-513 closed the default-password hole with a generated password; a household still has two logins. **What it needs:** a spike on a scratch guest — forwardAuth to the controller session, and what FileBrowser Quantum does with a trusted header. | **READY — rank P3-LOW; owner: CC (spike)** **Re-ranked 2026-10-03: P3->P4: comfort feature needing a new unmeasured mechanism; the default password hole is closed.** | — | — | CC |
 | **R-779** | Security & access | P4 | **[P3-LOW] Part A's "two outside addresses seen as two" is proven through the simulated tunnel only; on the REAL tunnel the second outside address (ep0, one request allowed) was refused by Cloudflare's edge with 403 and never reached the box.** Measured 2026-10-01 19:51 UTC (`audits/visitors-2026-10-01/A/L2-demo-hp-real-tunnel.txt`): no log line on demo-hp; demo-hp's box has no geo restriction in its settings, so a Cloudflare ZONE rule (country or bot, not read) refused a German datacenter address. DooPlex's own address on the real tunnel was seen as itself. **Needs:** one sign-in from a second Hungarian address (the operator's phone off wifi) while DooPlex is locked out — 2 minutes; and say which Cloudflare rule refused ep0. | **WAITING-ON-OPERATOR — rank P3-LOW; owner: operator (a phone), CC reads the logs** **Re-ranked 2026-10-03: P3→P4: a proof gap on the real tunnel; operator-only follow-up.** | — | — | CC + operator |
 
-## Box system & updates — 9 rows (P2 1, P3 8)
+## Box system & updates — 7 rows (P2 1, P3 6)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -229,7 +227,7 @@ stopping line that lies.
 | **R-468** | Box system & updates | P3 | **[P3-LOW] THE GOLDEN WAIVER — goldens on a cadence, not per release (operator ruling 2026-09-13).** 25 goldens in 26 days in August, almost one per release, because `golden_currency_gate.py` trips on every release by design and the only honest ways past it were a bake or a declared `--no-verify` (thirteen by 2026-09-01, R-404/R-417). **The ruling: bake WEEKLY, and always before any drill or fresh install.** Every release still raises the FLOOR, so both demo boxes keep getting each release in ~20 s; only the golden — which protects a fresh install and nothing else — moves to a cadence. **The mechanism (built 2026-09-13):** `documentation/tests/golden-waiver. **⚠ CORRECTED THE SAME DAY (R-472): between bakes the floor does NOT carry a release — the hub holds any floor above the vouched golden (publish-train rule 1), so releases between bakes reach the demo boxes only by hand-deploy.**yml`, four lines (`issued`, `expires`, `reason`, `register_row: R-468`), read by the gate. While valid, a golden BEHIND the record makes the gate print a loud ADVISORY and exit 0; when it expires the gate is red again until someone bakes or renews. **The 14-day cap is enforced by the gate, not the runbook** — a longer, undated, unparseable, reason-less or row-less waiver is INCONCLUSIVE (exit 2), never 0 and never silently ignored. **It never covers a golden that is UNRECORDED (R-385)** — that is not a cadence choice. **A dated waiver cannot be forgotten; it just expires** — the difference from R-242's original rule, which recurred the day after it was written. Tests: `scripts/test_golden_currency_gate.py` cases 5–15 (E/F/G/H, a 15-day, absent, unparseable, bad-row and empty-reason waiver each 2; the R-421 decoy — a file saying only `expires` — 2). **This is a PRE-CUSTOMER arrangement: the first external install retires it** (delete the file in that commit). Cadence written into `RUNBOOK-manual-build.md` §4.2 and the `felhom.eu` end-of-session checklist. **Does NOT touch R-242's open half (nothing gates the VOUCH).** | **WATCHING — rank P3-LOW; owner: CC (renew ≤ 14 days or bake); retire at the first external install** | — | — | CC |
 | **R-836** | Box system & updates | P3 | **A new host kernel that hangs before userspace stays the GRUB default: `--next-boot` is not a one-shot on these hosts.** MEASURED 2026-10-04 on demo-hp (operator's word, 2 reboots): both demo hosts boot UEFI + GRUB without proxmox-boot-tool ESPs; installing a kernel makes it the default at once; `kernel pin <new> --next-boot` writes an ordinary `GRUB_DEFAULT`, and `proxmox-boot-cleanup.service` clears it only after a boot reaches userspace. With the old kernel pinned FIRST, the fallback after a good boot worked (new 60 s, old 76 s). READ FROM THE CODE, not measured: a hang leaves the new kernel default on every power cycle. Only `softdog` runs (useless before userspace); demo-hp's `sp5100_tco` ships unloaded, untested. Fix direction for the slow lane: GRUB's own one-shot (`GRUB_DEFAULT=saved` + `grub-reboot`) with the old kernel saved — to be measured, including Secure Boot (ON on demo-hp). `audits/os-updates-spike-2026-10-04/partH/` | **NARROWED 2026-10-04 (os-host-lane Part E, operator's word before each of 2 reboots) — GRUB's own one-shot is NOT a one-shot here either.** `GRUB_DEFAULT=saved` (old kernel saved) + `grub-reboot <new>`: boot 1 → new kernel, **Secure Boot ON and fine**; but GRUB could not clear `next_entry` (`grub-reboot` itself warns: *environment block on lvm device … will remain the default until manually cleared*; `/boot` is ext4 on LVM `pve-root`), so boot 2 (no command) → **the new kernel again**. `kernel.panic = 0`: a panic leaves the host stopped (R-851). `sp5100_tco` LOADS and answers (`SP5100 TCO timer`, 60 s, inactive, nowayout 0; read from sysfs, never opened, unloaded) — a hardware watchdog exists on demo-hp, but nothing arms it before userspace. demo-hp left on 7.0.14-20 with that as the saved default. **LEFT (fix direction):** a GRUB env block GRUB can write (on the ESP, vfat) or a userspace "boot good" step that rewrites the default, plus arming `sp5100_tco`; to be measured before the kernel slow lane. `audits/os-host-lane-2026-10-04/partE/` **READY — owner: CC + operator (reboots).** | — | — | CC |
 
-## Monitoring & notifications — 18 rows (P2 3, P3 10, P4 5)
+## Monitoring & notifications — 16 rows (P2 3, P3 9, P4 4)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -278,7 +276,7 @@ stopping line that lies.
 | **R-89** | Business & legal | P4 | Retention as a per-customer **commercial** policy on the hub | READY (increment 2) | — | Policy object + reconciler → ep0 prune job; keep box tokens write-only | CC |
 | **R-794** | Business & legal | P4 | **[P3-LOW] redis 7.4 (RSALv2 / SSPL, not OSI) runs as a private cache in seven apps: dawarich, docmost, immich, nextcloud, outline, paperless-ngx, romm.** READ 2026-10-02 (`audits/licences-2026-10-02/TABLE.md`). Read as permitted (a private cache only its app uses is not Redis offered as a service — inferred). Valkey (BSD-3) or redis 8 (AGPL option) removes the question. **Needs:** a ladder step per app to valkey or redis 8, through the harness — no hurry. | **READY — rank P3-LOW; owner: CC** **Re-ranked 2026-10-03: P3→P4: the row itself says no hurry; usage read as permitted.** | — | — | CC |
 
-## Process & tooling — 25 rows (P3 2, P4 23)
+## Process & tooling — 23 rows (P3 2, P4 21)
 
 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|