diff --git a/docs/re/f5-a-press-snaps-the-plate.md b/docs/re/f5-a-press-snaps-the-plate.md
index 9248f9f7..d2ac0b36 100644
--- a/docs/re/f5-a-press-snaps-the-plate.md
+++ b/docs/re/f5-a-press-snaps-the-plate.md
@@ -1,4 +1,11 @@
-# F5 — Ⓐ **snaps**, and it snaps only the plate
+# F5 — Ⓐ **snaps**, and it snaps the WHOLE title
+
+> 🔴 **CORRECTED 2026-09-02, same day.** This page first said Ⓐ snaps *only* the
+> plate and leaves the artwork animating, and used that to refute
+> `clock: "shared"`. **That was wrong.** A pre-registered wider test
+> ([`f5-artwork-window-prereg.md`](f5-artwork-window-prereg.md)) refuted it: the
+> artwork snaps too. The cut finding stands and is stronger; the artwork half is
+> reversed. See "What went wrong" at the bottom — the error is instructive.
 
 **Question:** when you press Ⓐ during the title's build-in, does the animation
 jump straight to finished, or does it speed up?
@@ -80,3 +87,52 @@ fixed number of frames. It hit the window first try.
 * 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.
+
+
+---
+
+# 🔴 The correction — the artwork snaps too
+
+Pressing Ⓐ at the sweep's **gate** (`t≈70`) instead of 40 frames later leaves ~40
+frames of artwork still animating. Pre-registered prediction: the artwork
+continues identically to the control. **It does not.**
+
+```
+f435 | 8ECA:-1.00,a55   EAC3:-0.83,a27   8154:-0.74,a27      artwork mid-ramp
+f436 | 8154:-1.54,a255  EAC3:-0.90,a255  8154:-0.54,a255     gone; settled set at full
+```
+
+Three elements mid-fade-in **vanish in one frame**, and the settled set appears at
+α255. Most telling: **the sweep enters at α255 with no ramp**, where the control
+ramps it 17→255 over ~15 frames as its parent's declared `t=70…100` requires. The
+title clock jumped past `t=100`.
+
+It did **not** jump past 250 — `ptloop01`'s exit ramp would then have taken the
+sweep back to α0, and the sweep is at 255. So Ⓐ advances the title clock into
+**`[100, 238]`**, consistent with the settle window `[160,236]` that
+[`ui-clock-freezes-at-settle.md`](structures/ui-clock-freezes-at-settle.md)
+already found the clock freezing in.
+
+**So `clock: "shared"` is NOT refuted. Ⓐ advances one clock and the artwork rides
+it.** F4's discriminator, run properly, goes the other way.
+
+## What went wrong, because it is a trap worth naming
+
+**The press takes ~11–12 frames to take effect, and I measured inside that gap.**
+
+| run | press sent | effect visible | gap |
+|---|---|---|---|
+| `f5` (late press) | f445 | f456 | 11 |
+| `f5-early` | f424 | f436 | 12 |
+
+My "5-frame window, frames 446–450, artwork identical to control" sat **entirely
+inside the latency gap**. Of course it matched the control — the input had not
+been acted on yet. And by the time it was, the artwork had finished its ramps on
+its own, so there was nothing left to snap and nothing to see.
+
+The window was not merely small. It was **positioned where the effect cannot
+appear**, which no amount of enlarging would have fixed — only moving the press
+earlier did. I stated the 5-frame reach honestly and still drew a conclusion the
+data could not carry.
+
+**A control matched at the wrong instant is not a control.**