diff --git a/docs/re/mission-freeze-resume-spin.md b/docs/re/mission-freeze-resume-spin.md
index bf084df..a43cf3f 100644
--- a/docs/re/mission-freeze-resume-spin.md
+++ b/docs/re/mission-freeze-resume-spin.md
@@ -510,3 +510,23 @@ run (342 MB resident here) and `run-canary` only clears it at *launch*; and
 `vm.drop_caches` is not writable in the container (read-only `/proc/sys`), so
 page cache can only be left to the kernel to reclaim. Clearing the stale shm
 files between runs is the one lever available.
+
+
+### The v2 baseline holds on a second healthy run (run 7)
+
+`NO FREEZE within 1100s`, and the same shape as run 5 — so the control is
+measured twice:
+
+| thread | run 5 windows / peak / objects | run 7 windows / peak / objects |
+|---|---|---|
+| `F8000008` (main) | 224 / 1 235 / 13 | 167 / 947 / 13 |
+| `F8000234` | 47 / 919 / 10 | 35 / 830 / 8 |
+| `F800025C` | 41 / 819 / 7 | 28 / 737 / 7 |
+| result | SUCCESS ×314 | SUCCESS ×230 |
+
+Same three threads, same ceiling of **13 distinct objects**, and **not one
+non-SUCCESS window in 544** across both runs. The v1 stuck-wait side reported its
+usual single pair (`BE56BB5C`) and nothing else.
+
+**Run tally since v2: three runs, no frozen sample** — GAME OVER at ~22 min
+(run 5), `EMULATOR GONE` at 810 s (run 6), and no freeze in 1 100 s (run 7).