night fixes 2026-10-26: live proofs (R-1220, R-1232, R-1187, R-1298), register states, design lines; R-1300 filed; R-528 design

Evidence audits/night-fixes-2026-10-26/ (scanned: 0 secret hits).

documentation/architecture/03-host-agent.md

@@ -510,7 +510,7 @@ per Part 1: **snapshot** (LVM-thin, transient, whole-guest rollback — not a ba
   backup is due (`GET /backup/due`, §6) → **quiesces** (stops its app stacks) → `POST /backup` →
   polls `GET /backup/status` to `done` → **unquiesces** (restarts exactly the stacks it stopped).
   Implemented in `felhom-controller` v0.36.0 (`internal/quiesce`) + `felhom-agent` v0.11.0 (the
-  `/backup/due` cadence policy + `/backup/status` phases). **An agent-initiated vzdump is
+  `/backup/due` cadence policy + `/backup/status` phases). *[DESIGN] R-1232 (2026-10-26 night, agent main `3911cc6`, next agent release): on an encrypted tier the due-check counts only archives written with THIS storage's key (the R-727 discriminator — an archive carries no host id), so a reinstalled box does not read the old box's archive as its own last backup.* **An agent-initiated vzdump is
   crash-consistent only** (there is no inbound-to-guest channel to trigger a quiesce — §3/§5); the
   controller stopping its stacks first is what makes the captured state **clean-shutdown-consistent**
   (validated live: a quiesced postgres restore comes up clean — "database system was shut down" — vs

documentation/architecture/05-hub-architecture.md

@@ -300,7 +300,7 @@ What remains:
   **`host_escrow.blob`** (and the identity blob beside it).
   **[DESIGN] 2026-10-24 (R-1254; committed felhom.eu `dcf4f84c`, hub next v0.170.0 — NOT deployed):** the escrow PUT
   stores the blob, its sealed-password hash and the identity blob in ONE transaction (`Store.SaveHostEscrowWithIdentity`;
-  the superseded copy is made inside it). A failure leaves all of the old package or all of the new — never the new hash
+  the superseded copy is made inside it). *[DESIGN] R-1218 (2026-10-26 night, hub main `09b5f02f`, next hub release): a package that seals the off-site repository password is never replaced by one that seals none — the PUT answers 409 and the good package stays current (it used to be demoted to operator-only custody, so the household's code no longer opened its off-site copy).* A failure leaves all of the old package or all of the new — never the new hash
   beside the old identity package, which a box would read as „escrowed" while the written code opened nothing. A
   malformed identity blob is refused before anything is stored. (The agent ceremony's „the previous code still works"
   after a lost answer, R-1254's other half, stays open.)

documentation/architecture/07-backup-architecture.md

@@ -403,6 +403,8 @@ never moved by an update or an undo, and the unit restore accepts it.
 > copy protected the app's files. Since v0.245.0 every dashboard page carries the reminder (the R-241
 > bar, second instance) and the Tier-1 sentence renders by state — „védené … szünetel" while paused.
 > Measured on a fresh box 2026-09-16: zero snapshots, and the page said the files were protected.
+>
+> *[DESIGN] R-1219 / R-1218 (2026-10-26 night, controller main `1170b48`, next release): during a recovery offer the bar does NOT urge the ceremony (a new code would replace the key that opens the old off-site copy) and the start answers 409; a ceremony stages the off-site password whenever its FILE is on the box, also with off-site switched off or cleared.*
 
 > **R-191 (2026-08-04) — this row was RIGHT and the configuration disagreed with it, weekly, for as long as R-89 has been in force.** The contract has not changed: offsite retention is ep0's, the box's token is write-only, and the box cannot delete its own history. What had not followed was the installer's `keep_last: 2` on the offsite tier, so every weekly run uploaded its snapshot successfully and then failed the whole JOB on a prune the token is refused — `whole_guest_backup_failed` in the operator's inbox about a backup that had already succeeded. Fixed in installer **1.25.0** (`keep_last: 0`) and on both live boxes; a gate now asserts it. **Verified before changing it:** ep0's two prune jobs have run every day since 2026-07-27, 18 tasks, all OK. A doc that states the contract does not enforce it — the gate does.
 
@@ -923,6 +925,8 @@ run makes it longer.
 
 *Second-drive copies that are KEPT (D25) and the rule that a rejected backup block never deletes one: §8.2a (R-1252, 2026-10-24).*
 
+*[DESIGN] R-1220 (2026-10-26 night, controller main `7e15a37`, ships with the next controller release): an app whose `app.yaml` EXISTS but does not parse counts as INSTALLED — every folder its compose binds, on every registered drive, is live and never listed as kept data (fail closed; one WARN names the app).*
+
 **What it is.** "Remove the app, keep my data" leaves the app's drive folder (`<drive>/appdata/<app>`, or the folder
 its definition binds through `${HDD_PATH}`) in place. A reinstall over it no longer runs silently into the old files
 (R-657): the install asks „A megőrzött adataimat használom" / "Use my kept data" (the database from the newest copy of
@@ -1080,6 +1084,8 @@ second drive's whole restore (its `CheckOnly` pass carries the pull, so its file
 load from a unit and from off-site, and a set-aside unit (D47) — the off-site restore, the second drive's file restore
 and the no-unit fallback. Not covered: the `.fab` import — it removes the running app's volumes before its definition is pulled (R-1279).
 
+*[DESIGN] The `.fab` route, R-1187 (2026-10-26 night, controller main, next release): the export carries a symlink AS A LINK and stops on a FIFO, socket or device naming its path; a drive folder that cannot be packed fails the export (never left out). The import writes only through `os.Root`, keeps owners and modes, restores a link only when it points DOWNWARD inside the folder (no absolute target, no „..”, no link on the way — others refused and listed), refuses while another operation holds the box and refuses an empty or relative `HDD_PATH`; its compose runs get the controller's own `USERDATA_PATH`/`IMPORT_PATH`; the database loads through the backup side (`appbackup.ImportDump`: mariadb / mariadb-admin, psql ON_ERROR_STOP) — the import's own `mysqladmin`/`mysql` calls failed on every MariaDB 11+ image. Live: `audits/night-fixes-2026-10-26/`.*
+
 ### 6.7 Why an off-site run failed — the failure classifier (R-571)
 
 **[FACT, read from source 2026-10-05, felhom-controller `114ff27`]** When an off-site (restic) run fails, the

documentation/architecture/08-alarm-ladder.md

@@ -660,3 +660,5 @@ a row the box stopped repeating for 50 h (the list still shows it, marked). `ale
 every grace — a test configuration only. Live proof: `audits/d53-held-apps-2026-10-26/` (a crash-looped throwaway app on
 9202 against a test hub with a 3-minute grace: listed on both pages, one operator mail, Start cleared it, the row went,
 every household leg `skipped operator_only`).
+
+*[DESIGN] R-1298 (2026-10-26 night, controller main `b156e45`): an install's hold (`unhealthy_stop`, `update_failed`, `putback_pending`) of an app that is NOT installed (no `app.yaml`) is not reported — it would remind weekly about an app that does not exist; a restore hold is always reported (R-379, a person clears it).*