night 2026-09-25 (in progress): part 7 shipped as controller v0.271.0 — decisions 31-33, evidence A/B/C/F, register (R-685..R-687; closed R-672 R-673 R-684 R-680 R-678)

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

documentation/architecture/07-backup-architecture.md

@@ -347,6 +347,19 @@ never moved by an update or an undo, and the unit restore accepts it.
 offsets — db-dump at W, Tier-2 at W+60m, offsite at W+105m — so they can never be misordered
 (`cmd/controller/main.go:604-607`). Both boxes run W = `02:30`.
 
+**[FACT, controller v0.271.0, 2026-09-25] A fourth leg: automatic app updates, CHAINED after the off-site
+leg** (`09` §3 decisions 11 and 20, §6.4 part 7). The `offbox-backup` job runs the update leg when its off-site
+half ends, on every path (no target, ok, failed, panicked); a box without an off-site tier runs it at W+105m. The
+leg starts no step at or after **W+5h**, and the whole-guest gate — open [W+2h, W+6h) — **defers while the leg
+runs until W+5h**, then only for a step already in flight, never past W+5h30m (decision 31). So on an update
+night the whole-guest backup starts later inside its own window; it is never skipped for an update. Live
+numbers: `audits/DRILL-night-2026-09-25.md` Part D.
+
+**[FACT, 2026-09-25] demo-hp's local whole-guest target is its host ROOT disk; retention there is now
+keep-last=1** (operator ruling 2026-09-24, option A; R-684). PVE prunes AFTER a successful backup, so the target
+must hold keep-last + 1 archives during the run — measured: a 9201 archive is 8.18 GB, the root disk 39 GB. The
+warning that should precede such a failure is R-685.
+
 **[FACT] What the whole-guest tiers do NOT carry.** `mp8 /mnt/felhom-drives` and
 `mp9 /etc/felhom-bootstrap` are **host bind mounts** and are out of `vzdump` scope entirely (LIVE
 `pct config 9201`, both hosts). So the whole-guest tiers carry the guest and **none of the customer's