diff --git a/docs/re/canary-scripted-input-traps.md b/docs/re/canary-scripted-input-traps.md
index ed0603f..7b85f5a 100644
--- a/docs/re/canary-scripted-input-traps.md
+++ b/docs/re/canary-scripted-input-traps.md
@@ -577,12 +577,31 @@ On the first clean boot afterwards, the same loader thread is the **caller** on
 boot before the fix had exactly **zero** of both. That is the predicted change,
 and it is the strongest evidence available short of a reliability run.
 
+### Measured: 5 of 5 after, against 1 of 5 before
+
+`tools/re-capture/resume_reliability.sh` boots repeatedly and records, per boot,
+whether the loader thread was created and whether it ever became the **caller**
+of a kernel call. Counting only boots where the press actually reached the title:
+
+| | boots | loader ran | reached the main menu |
+|---|---|---|---|
+| **before** the fix | 5 | **1** | 1 |
+| **after** | 5 | **5** | 3 (the others were not driven that far) |
+
+The three post-fix boots that were driven on all show the same shape: title
+detected at 216–252 s, loader thread created, **40** kernel calls by it, **6**
+`ResolvePath` asset reads, screen classified `menu`. Before the fix the failing
+boots had **zero** of both, every time.
+
+⚠️ One caveat worth keeping: the pre-fix runs were interleaved with compiles and
+other load, and a race is load-sensitive. The post-fix runs were not. The
+mechanism is read directly from the code, which is what carries the conclusion;
+the counts corroborate it.
+
 ### What is honestly not shown
 
-* 🟡 **That boots now reach the menu reliably.** The post-fix boot drifted into
-  the attract loop because `skip_intro.sh` fired its single press at 145 s, and
-  the run before it pressed on the **SQUARE ENIX publisher logo** — see below. A
-  clean before/after reliability count still needs several boots.
+* 🟡 A larger sample. Five boots each way is enough to act on, not enough to
+  quote a rate.
 * ⚠️ **`host resume was refused` is not by itself a defect.** Resuming a thread
   that is not suspended legitimately returns false, and the log fires ~7 times in
   a normal boot. It is a breadcrumb, not an alarm.
@@ -601,3 +620,26 @@ and it is the strongest evidence available short of a reliability run.
 Now `tools/re-capture/is_title.py` **counts** the green glyph over the whole
 frame — geometry-independent and specific. Measured: **0** pixels on the SQUARE
 ENIX logo, **1 520** on a real title, threshold 400.
+
+
+## ⚠️ One emulator at a time has to mean one *driver* at a time (2026-08-19)
+
+The first reliability batch reported `title_at_s=none` on two runs, with the
+emulator log ending in `Killed`. That was read at first as the title detector
+having been tightened too far. **It was not.**
+
+An earlier copy of `resume_reliability.sh` was still running: the `pkill -f
+resume_reliability.sh` meant to stop it had matched the *shell running the
+command* instead (exit 144) and killed that, leaving the script alive. Each of
+its iterations begins by killing the emulator **by name** — which is outside
+`run-canary`'s lockfile — so it kept shooting the newer batch's boots.
+
+Two lessons, both cheap:
+
+* `pkill -f <script>` matches your own shell. Use `pkill -x <script>`.
+* The lockfile protects the emulator, not the harness. `resume_reliability.sh`
+  now takes `/tmp/resume-reliability.lock` and refuses to start a second copy.
+
+The evidence recovered cleanly once the interference stopped — the interrupted
+batch's own run 3 had already reached the menu with the same 40 calls / 6
+`ResolvePath` signature.
diff --git a/docs/re/captures/resume-fix-reliability.csv b/docs/re/captures/resume-fix-reliability.csv
new file mode 100644
index 0000000..57a874f
--- /dev/null
+++ b/docs/re/captures/resume-fix-reliability.csv
@@ -0,0 +1,5 @@
+run,title_at_s,thread_created,thread_ran_calls,resolvepath_after,screen
+1,none,0,0,0,other
+2,none,0,0,0,other
+3,216,1,40,6,menu
+4,252,1,40,6,menu
diff --git a/tools/re-capture/resume_reliability.sh b/tools/re-capture/resume_reliability.sh
index 3707328..13919f7 100755
--- a/tools/re-capture/resume_reliability.sh
+++ b/tools/re-capture/resume_reliability.sh
@@ -21,6 +21,18 @@ mkdir -p "$OUT"
 CSV="$OUT/$TAG.csv"
 echo "run,title_at_s,thread_created,thread_ran_calls,resolvepath_after,screen" > "$CSV"
 
+# Refuse to run two of these at once. Each iteration below kills the emulator by
+# name, which is outside run-canary's lockfile — so a second copy of this script
+# silently killed the first copy's boots mid-run and they were recorded as
+# failures ("title_at_s=none", the emulator log ending in "Killed"). One
+# emulator at a time has to mean one DRIVER at a time too.
+exec 8>/tmp/resume-reliability.lock
+if ! flock -n 8; then
+  echo "resume_reliability.sh: another run is in progress (lock /tmp/resume-reliability.lock)" >&2
+  echo "  kill it with:  pkill -x resume_reliability.sh   # -x, NOT -f: -f matches your own shell" >&2
+  exit 1
+fi
+
 for i in $(seq 1 "$RUNS"); do
   pkill -9 -x xenia_canary 2>/dev/null; sleep 3
   rm -f /tmp/xenia-canary.lock