Night brief part 2 (run by day 2026-10-20): register 160 -> 156 (closed R-1001, R-1011, R-1167, R-1070, R-1010, R-893, R-1169; opened R-1171..R-1173; R-1019/R-462 narrowed, R-49 READY -> D21, R-1083 re-stated); 07 §6.3 option A as the design; STATUS morning list; report part 2; P4 Immich plan, P7 release evidence

documentation/architecture/07-backup-architecture.md

@@ -736,6 +736,19 @@ stayed (37 tables, the live app had 36); the definition did not move (same versi
 answered 409. The restore page's „the database is back as it was" is false for it. Design note with the two options and
 the pick (A: a copy of the app's live volumes, put back on failure — one copy's disk for the restore's length, a fit
 check before the stop): `audits/night-2026-10-19/P3/design-R-893.md`; the decision is on `STATUS.md`.
+**`[DESIGN]` 2026-10-20 — „put back exactly as it was" (R-893 option A, operator decision D20 = A, `09` §3 decision 192
+second half; controller 0.336.0 is the floor).** Before the stop, every named volume the snapshot will replace is measured
+and its copy is added to the restore's own free-space need (R-357's exact rule); too little room or an unmeasurable volume
+refuses with nothing stopped. Right after the stop the volumes are tarred into `<namespace>/backups/restore-undo/<app>/`
+(outside every capture set). On ANY failure after a volume or the definition moved, the copies are poured back, a volume
+the snapshot added is removed, the live definition is written back and the app is STARTED; the household reads that the
+restore failed and nothing changed (with placed files: its database and volumes are back, the copied files stay); the
+operator gets `backup_run_failures` leg `restore-put-back`. The hold (`restore_mixed`) remains only for a put-back that
+fails — then the copy is kept for support — and the double failure (replay AND rollback) holds as before. On success the
+copy is removed. **`[FACT]` 2026-10-20 (9202, controller 0.336.0-rc.1, `audits/night2-2026-10-20/P2/live/`):** the same
+forced failure as on 2026-10-19 → 36 tables, the backup-only table absent, schema/data/row-count md5 equal to before,
+the app running, no hold, the copy (69 MB, 0.9 s) gone; a normal restore of the same snapshot then worked. The R-893
+known limit above is closed for named volumes; placed FILES are still not taken back (the plain-files mix, as ruled).
 
 **[DESIGN] 2026-08-22 — the failure ladder of a database restore: replay → rollback → hold.**
 Recorded here rather than only in a closed register row, because a decision that survives only inside