Night 2026-10-19 Part 10: ep0's first weekly prune matched the dry runs (only tester-1's 10-04 copy removed; every household has a rule) -> R-1162 closed, register 161 -> 160; R-895 and R-435 due dates moved 10-20 -> 10-21 with the reason; P10 evidence

documentation/architecture/07-backup-architecture.md

@@ -488,7 +488,8 @@ data drives** — 916 GB on demo-felhom, 938 GB on demo-hp.
 > (today, floodable); a per-tier count per rolling window (chosen: no ordinary day is refused); a time-bucketed prune
 > instead (the durable shape, but a retention change — R-1149 for the local tier, R-973's design line for ep0). Limits:
 > ep0's prune is time-bucketed since 2026-10-19: **[FACT] `prune-demo-hp` and `prune-demo-felhom` keep `keep-weekly 2`**
-> (R-1162, operator decision STATUS D18, 2026-10-19 08:24; read back 07:49 UTC) — the newest copy of each of the two newest
+> (R-1162, operator decision STATUS D18, 2026-10-19 08:24; read back 07:49 UTC; the first scheduled run, 2026-10-20
+> 03:30 UTC, removed only tester-1's 2026-10-04 copy, as the dry runs said — `audits/night-2026-10-19/P10/`) — the newest copy of each of the two newest
 > ISO weeks, so a flood inside a week replaces only that week's copy and the previous week's survives, however many runs
 > get through. Before the change, PBS's own dry run and an offline model of its selection both showed the new rule
 > removing nothing on either box (`audits/day-2026-10-19b/P1/`). DooPlex's copy of ep0 already prunes by time