re: F5 -- A snaps the plate, and does NOT advance the artwork's clock

Three captures, aligned by the sweep's position rather than by frame number.
The plate's alpha goes 23,46,69,92,115,139 over ~11 frames with no input,
and 255 in a single frame when A is pressed: zero intermediate values
against eleven. A cuts, it does not accelerate -- the human's prior holds.

The control is what makes it readable. Four elements ramp out right around
the press and I could have reported that as the effect; at sweep x=-1.42 all
three runs agree quad for quad, so those exits are the ordinary build-in.

Refutes clock:"shared" on F4's own discriminator: the artwork keeps
animating across the press, frame for frame identical to the control. Reach
stated -- that half rests on a 5-frame window, since everything else on
screen is already at 255 and cannot discriminate.

Also records the first attempt's miss: blind wall-clock timing put the press
after the settle, where A is accepted instead. The probe now gates on the
sweep appearing, which is the parent's declared t=70..100 gate.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

docs/re/f5-a-press-snaps-the-plate.md

@@ -0,0 +1,82 @@
+# F5 — Ⓐ **snaps**, and it snaps only the plate
+
+**Question:** when you press Ⓐ during the title's build-in, does the animation
+jump straight to finished, or does it speed up?
+
+**What the human looks at:** press Ⓐ while the title is still building. Pass for
+*snap* = the `PRESS Ⓐ` plate is simply there, with no fade. The artwork behind it
+keeps animating either way.
+
+**What this does NOT cover:** what Ⓐ does once the title has settled (it is
+accepted — see the miss below), and the sting question in F3.
+
+**Instrument:** ⟨capture⟩ ×3 — one press run (`f5`), two no-press controls
+(`f6`, `f6b`) captured earlier for F6.
+
+## ✅ Measured — it is a CUT, not an acceleration
+
+The brief's discriminator: an acceleration shows intermediate alphas, a cut shows
+none. Aligning all three runs **by the sweep's own position** (a phase-free clock
+readout, not a frame number):
+
+| plate's alpha, frame by frame, from its first draw | |
+|---|---|
+| no-press control `f6b` | 23 · 46 · 69 · 92 · 115 · 139 · … ~11 frames of ramp |
+| **press run `f5`** | **255** — one frame, nothing before it |
+
+**Zero intermediate values against eleven.** The human's *"looks more like a
+snap"* was a prior, and the measurement agrees with it.
+
+## ✅ The control is what makes this readable, and it nearly went the other way
+
+My first look at `f5` found four elements ramping *out* right around the press
+and I could have called that the effect. The controls say otherwise: at sweep
+`x = -1.42` all three runs agree quad for quad —
+
+```
+f5  f445 | 8ECA:-1.00 a54  8ECA:-0.90 a15  EAC3:-0.82 a29  8154:-0.74 a6
+f6  f781 | 8ECA:-1.00 a54  8ECA:-0.90 a15  EAC3:-0.82 a29  8154:-0.74 a6
+```
+
+— identical. Those exits are the ordinary build-in and the press did not cause
+them. Only the plate differs.
+
+## 🔴 This refutes `clock: "shared"` — on F4's own stated discriminator
+
+F4 set the test: press Ⓐ early and **watch the artwork, not the plate**. Snapping
+the artwork means one shared clock; leaving it animating means Ⓐ only forces the
+plate visible.
+
+**The artwork keeps animating.** Across the press, the sweep's position and alpha
+and the artwork's exit ramps continue frame-for-frame identically to the control
+(step −10 alpha/frame in both `f5` and `f6b`; `f6` runs −5 because that capture
+paced at half rate, which the ratio removes).
+
+So the title is **not one clock**. Ⓐ forces the plate and leaves the artwork's
+timeline alone.
+
+⚠️ **Reach.** The artwork half rests on a **5-frame window** — frames 446–450,
+the only stretch where the press had landed and artwork was still animating.
+Everything else on screen was already at α255 and cannot discriminate. Pressing
+Ⓐ right at the sweep's gate (`t≈70–100`) would widen that window and is the
+experiment that would harden it.
+
+## 🔴 The first attempt missed, and the probe said so
+
+Wall-clock timing put press 2 at log frame ~1217 when the title had settled at
+~653: Ⓐ was **accepted** instead, and UI draws stopped. The build-in is only
+~180 log frames wide and pacing varies 2×, so blind delays cannot hit it.
+
+The fix is the one the brief prescribes for F1: **gate the press on an
+observable.** `f5_snap_or_accelerate.sh` now waits for the sweep's texture page
+to appear — which *is* the parent's declared gate at `t=70…100` — then counts a
+fixed number of frames. It hit the window first try.
+
+## Not settled
+
+* The element called "the plate" is still identified by **screen position only**.
+  Its behaviour matches the plate (appears on Ⓐ, pulses after), but it is not
+  named. The 1.7× clock conflict against `t≈236` is unresolved.
+* Whether Ⓐ snaps a *third* clock, or reveals the plate by a route with no clock
+  at all — a cut is consistent with both.
+* The 5-frame reach above.

tools/re-capture/f5_snap_or_accelerate.sh

@@ -42,15 +42,27 @@ echo "logging confirmed at ${SECONDS}s (${sz} bytes)"
 
 # --- F5: a SECOND A during the title build-in ---------------------------
 # Discriminator (brief): a snap shows no intermediate alphas, an acceleration
-# does. Press 2 must land while the build-in is still running -- after the
-# sweep is up (title t>=100) and before the settle (~t=236). Blind timing is
-# the weak point, so the press instant is RECORDED and checked post hoc; a
-# press that lands late is reported as such, not silently reinterpreted.
-PRESS2="${PRESS2_DELAY:-16}"
-sleep "$PRESS2"
-echo "PRESS2 at ${SECONDS}s  (log frame marker below)"
-grep -c '^--- frame' "$OUT"/xenia_re_ui_draws_*.log | tail -1 | sed 's/^/frames at press2: /'
+# does. Press 2 must land while the build-in is still running.
+#
+# ⚠️ BLIND WALL-CLOCK TIMING DOES NOT WORK HERE and the first run proved it:
+# +16 s put the press at log frame ~1217 when the title had already settled at
+# ~653, so A was accepted instead of accelerating anything. The build-in is
+# only ~180 log frames wide and run pacing varies 2x. So GATE ON AN OBSERVABLE:
+# wait for the sweep's texture page to appear (that IS title t=70..100, the
+# parent's declared gate opening), then let a fixed number of frames pass.
+LOG=$(ls "$OUT"/xenia_re_ui_draws_*.log 2>/dev/null | head -1)
+SWEEP=8154424FFC48FE61
+for _ in $(seq 1 900); do
+  grep -q "$SWEEP" "$LOG" 2>/dev/null && break
+  sleep 0.2
+done
+grep -q "$SWEEP" "$LOG" 2>/dev/null || { echo "FATAL: sweep never appeared -- title build-in not seen"; pkill -x xenia_canary; exit 1; }
+n0=$(grep -c '^--- frame' "$LOG")
+echo "sweep up at log frame ${n0} (title t~70..100) at ${SECONDS}s"
+target=$((n0 + ${PRESS2_FRAMES:-40}))
+until [ "$(grep -c '^--- frame' "$LOG")" -ge "$target" ]; do sleep 0.2; done
+echo "PRESS2 at log frame ~${target}, ${SECONDS}s"
 pad "press=A"; sleep 0.4; pad ""
-sleep 90
+sleep 60
 pkill -x xenia_canary
 echo "done at ${SECONDS}s"; ls -la "$OUT"/*.log 2>/dev/null