diff --git a/REPORT.md b/REPORT.md
index 5469a57..87decc2 100644
--- a/REPORT.md
+++ b/REPORT.md
@@ -275,7 +275,13 @@ do **not** prove a live disk reaching Hiba. The fixture tests must not be read a
 
 Tracked as **R-332 (WATCHING)**. Closing condition: a live disk reaching Hiba from counters, or a
 deliberate injection through the real pipeline (agent `/disks` → controller check → hub event) — not
-a hand-set verdict. The drive that produced the fixture lives in DooPlex, which is Tier 2 and never a
+a hand-set verdict.
+
+**One item originally listed here has since been proven live** and is no longer part of this gap: the
+**persisted state surviving a controller restart**. The v0.215.0 → v0.216.0 redeploy destroyed and
+rebuilt the container, and the new one read back a `changed_at` written by the previous version rather
+than re-baselining — see §14. What remains unproven is the stronger half: an already-**alerted** disk
+not re-alerting after a restart, which needs a disk that has actually alerted. The drive that produced the fixture lives in DooPlex, which is Tier 2 and never a
 drill target; the demo boxes are all-flash and healthy.
 
 ---
@@ -396,11 +402,38 @@ rows — the dedup is about state and alerts, not display. Pinned by
 
 **Deployed:** `gitea.dooplex.hu/admin/felhom-controller:0.216.0 Up 6 seconds (healthy)`.
 
-**Honest note on the confirming cycle.** The two clean cycles in §8 ran on **v0.215.0**. A confirming
-cycle on v0.216.0 — where the evaluated count must now read **2** and match the record count — was
-still pending when this report was written; the check is hourly and the container had just restarted.
-Nothing about the fix depends on that observation (it is pinned by a red-proofed unit test), but the
-live count has not yet been re-read, and this report does not claim otherwise.
+**Confirming cycle on v0.216.0 — CONFIRMED LIVE, 09:31:35Z:**
+
+```
+live image: gitea.dooplex.hu/admin/felhom-controller:0.216.0 Up About an hour (healthy)
+2026/08/14 09:31:35 [INFO] [web] disk-health check complete: 2 disk(s) evaluated, 0 alert(s)
+grep -c disk_health_degraded: 0
+```
+
+**`2 disk(s) evaluated` now matches the 2 persisted records.** The count and the artefact agree, which
+is the disagreement that exposed R-335 in the first place. Still zero alerts, still both card rows.
+
+### The redeploy also proved persistence live — a gap §9 had listed as unproven
+
+The 0.215.0 → 0.216.0 redeploy **replaced the container**, and the state file came back intact:
+
+```json
+"path:/var/lib/vz":  {"verdict": 1, "changed_at": "2026-08-14T07:23:14.640216851Z", ...}
+"uuid:91d2dc2d-…":   {"verdict": 1, "changed_at": "2026-08-14T07:23:14.640216851Z", ...}
+```
+
+That `changed_at` was written by **v0.215.0's first cycle at 07:23Z**, before the container was
+destroyed and rebuilt. The v0.216.0 container read it back and preserved it rather than stamping a
+fresh time — so the new container **loaded the pre-restart record instead of silently re-baselining**.
+That is Scenario L observed on real hardware, not just through the production-path unit test, and it
+is exactly the behaviour that was impossible before v0.215.0 (the baseline was in-memory).
+
+It also incidentally confirms the unchanged-verdict path: `changed_at` is preserved across four checks
+and two controller versions because the verdict never changed, rather than being churned every cycle.
+
+**What this still does NOT prove:** these disks are healthy and were never alerted, so the stronger
+half — *an already-ALERTED disk not re-alerting after a restart* — remains unit-tested only. R-332
+stands.
 
 **Process note, recorded because it nearly cost the fix.** The red-proof harness reverts with
 `git checkout --`, which restores to `HEAD`. Running a red-proof against an **uncommitted** fix