re: WITHDRAW the (A)-press finding -- three emulators were live at once

While chasing the draw-stream question I found THREE xenia instances running
simultaneously (started 15:39, 15:44, 16:12), which violates the "one emulator at
a time" hard rule and confounds the finding I recorded last iteration.

All three read the same /tmp/xenia_pad.txt and share display :98. A press written
to that file is delivered to EVERY instance, while `screenshot` grabs whichever
window is topmost -- not necessarily the one that acted on it. So "(A) was
delivered and the screen did not change" may simply be two different emulators,
and the keystroke-level confirmation proves only that SOME instance received it.
The navigation.md entry claiming the boot title's "2 of 2" is no longer 2 of 2 is
withdrawn as unsupported, pending a clean re-run.

The cause was mine. run-canary's lockfile is the IMPLEMENTATION of the one-at-a-
time rule; a kill -9 orphans it, and the obvious unblock -- rm -f the lock --
also disables the guard for every later launch. I did that more than once today.

METHOD gains two entries. A lockfile is the rule, not an obstacle to it: clear a
stale lock only after confirming zero live instances, and COUNT them rather than
trusting a kill landed, because a plain kill is asynchronous and a -9 on a stuck
process can take seconds. When a guard blocks you, the question is whether the
condition it guards against is present, not how to remove the guard.

And a third instance of pgrep -f matching the shell that runs it -- this time it
killed a cleanup command halfway through, leaving the emulators alive and the
lock in place. Already recorded for wait-loops; promoted to "reach for -C first".

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

docs/re/METHOD.md

@@ -355,6 +355,27 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   element animates, confirm the element **draws there** — from a leaf sweep, a draw
   capture, or the rendered quad's own coordinates. A pivot is not a bounding box.
 
+* **A lockfile IS the rule, not an obstacle to it.** `run-canary` holds
+  `/tmp/xenia-canary.lock` to enforce "one emulator at a time". A `kill -9` orphans
+  it, and the obvious unblock — `rm -f` the lock — **also disables the guard for
+  every later launch**. Doing that repeatedly left **three emulators live at once**
+  on 2026-08-30, all reading the same `/tmp/xenia_pad.txt` and sharing display
+  `:98`. A scripted press then reaches *every* instance while `screenshot` grabs
+  whichever window is topmost, so "the input was delivered and nothing happened"
+  became unfalsifiable — and a finding built on it had to be withdrawn. ⚠️ **Clear
+  a stale lock only after confirming zero live instances**, and count them
+  (`ps -C xenia_canary --no-headers | wc -l`) rather than trusting that a kill
+  landed: a plain `kill` is asynchronous and a `-9` on a stuck process can take
+  seconds. **When a guard blocks you, the question is whether the condition it
+  guards against is present — not how to remove the guard.**
+
+* ⚠️ **`pgrep -f` / `pkill -f` match the shell that runs them.** Already recorded
+  here for wait-loops; it has now also killed a cleanup command mid-way and, in a
+  third instance, a launcher. Any `-f` pattern that appears in your own command
+  line matches your own process. Kill by process **name** (`ps -o pid= -C name`),
+  or exclude `$$`. Three instances in one session is not a footnote — reach for
+  `-C` first and use `-f` only when the name genuinely is not enough.
+
 ## Runtime / emulator
 
 * **Look at the PNG** — and check its dimensions.