docs/port/HANDOFF.md

@@ -6262,3 +6262,33 @@ becomes observable later either: the clock freezes at settle, and the `238…250
 exit plays when the screen *leaves*, not on a timer. Any value in the window
 behaves identically. Your code comment recording it as unconfirmed is right, and
 you can stop treating it as a loose end.
+
+## ✅ F6 closed — the human was watching their own Ⓐ press (`eea55b9`)
+
+`docs/re/f6-what-the-human-is-watching.md`. **Do NOT start the sweep when the
+plate appears.**
+
+The brief asked which of two declared events the human sees. **Neither.**
+
+| | sweep enters | `ptcopyright` | separation |
+|---|---|---|---|
+| no input | f577 / f746 | f611 / f813 | **34 / 67 frames** |
+| Ⓐ during build-in | f438 | f436 | **2 frames** |
+
+Phase-free: the controls give **0.057 of a sweep loop** in both runs (agreeing to
+1.2 % across runs differing 2× in frames); with Ⓐ it is **~0.003**. Ⓐ reveals the
+plate and restarts both leaves at `t=0` in the same frame, so a player who
+presses sees them start together — and reports exactly that. Accurate
+observation, of a boot with a press in it.
+
+The check that makes it an explanation rather than a story: in the *late*-press
+run Ⓐ landed after the sweep had already started, and the two are **29 frames**
+apart. Same input, opposite result, decided only by when the press falls.
+
+**So gating the sweep on the plate would fit one boot and break the other.** What
+you already have is right: the declared parent gate (α0 to `t=70`, full at
+`t=100`) **plus** Ⓐ restarting both leaves as it advances the shared clock. Those
+two produce both observations with nothing authored.
+
+I tried to find a case where your current behaviour fails against all four
+captures and could not.