re: the plate pulses via ptbtn00f on a declared 120-unit loop, not ptbtn00 at 244

The port asked whether the PRESS (A) plate pulses and with what period,
framing it as "does the timeline loop at 244 or does something else drive
it". Both halves of that disjunction are wrong about ptbtn00.

ptbtn00 ramps, holds, extinguishes at t=244 and stays out. The pulse is
ptbtn00f -- the plate's focus/glow variant, reached through focus_link and
carrying no top-level element of its own -- which declares a 120-unit loop
from the disc. A reader looking only at ptbtn00 sees a one-shot because the
looping element is the one a declaration-order walk never reaches. Same
element that needed the by-name accessor in ui_layout, for the same reason.

Cross-check that makes it more than a stopwatch reading: 120 declared units
at the rate law is 2.000 s at 60 Hz, against a measured mean of 2.24 s over
four intervals -- 12% long, the direction and roughly the size Canary's
pacing produces.

Stated plainly as what it is not: the port asked for a per-frame series and
this is not one. The four intervals come from the screenshot probe, the
weaker instrument, carrying a wall-clock duration off an emulator with
load-dependent pacing -- the class that has cost this corpus four withdrawn
timing claims. The strong instrument has never reached this screen: five
attempts, blocked by wall-clock timeout, frame cap, a self-matching pkill,
and the title sitting past the 137.7 s attract movie.

So the fact and the period are answerable now; the trajectory within a
cycle is not, and I am not inferring its shape from declared keyframes when
the whole point of the splash exercise was that only a capture confirms
shape.

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

docs/re/plate-pulses-via-ptbtn00f.md

@@ -0,0 +1,82 @@
+# ✅ The plate **does** pulse — but `ptbtn00` is not what loops. `ptbtn00f` is, on a declared **120-unit** cycle
+
+**Status: ✅ measured for the pulse; ✅ decoded for the period's source; ❔ the
+per-frame series does not exist.** 2026-09-02. Instruments: ⟨disc⟩ for the loop
+length, ⟨capture⟩ for the pulse itself.
+
+Answers the port's question — *does the `PRESS Ⓐ` plate pulse in the running game,
+and with what period?* — and **corrects the premise it was asked under**.
+
+---
+
+## The correction first, because it changes where to look
+
+The port asks whether `ptbtn00`'s declared `0:0 214:0 236:255 238:255 244:0`
+loops at `t = 244`. **It does not.** `ptbtn00` ramps up, holds, extinguishes, and
+stays out.
+
+> **The pulse is a different element.** `ptbtn00f` — the plate's focus/glow variant,
+> reached through `focus_link` and carrying **no top-level element of its own** —
+> declares a **120-unit loop** ⟨disc⟩.
+
+That is why a reader looking only at `ptbtn00` sees a one-shot: the looping
+element is the one that a declaration-order walk never reaches.
+📌 It is also the same element that needed the by-name accessor in
+`ui_layout` — `ptbtn00f.t32` is in `build.sprites` with nothing pointing at it —
+so this is the second time that element has been invisible to a walk that only
+follows declared elements.
+
+## The measurement that exists
+
+[`title-plate-delay-measured.md`](title-plate-delay-measured.md), from two boots
+on 2026-08-29:
+
+> *"its pulse is the focus record `ptbtn00f`, measured here at **2.12 / 2.19 /
+> 2.34 / 2.31 s** over four intervals, mean **2.24 s**"*
+
+**Cross-check against the disc, which is the part that makes it more than a
+stopwatch reading:** 120 declared units at the rate law
+([`clock-rate-follows-the-vblank.md`](clock-rate-follows-the-vblank.md):
+`units/s` = display refresh rate) is **2.000 s** at 60 Hz. Measured mean **2.24 s**
+— **12 % long**, in the direction and roughly the size Canary's slower-than-real
+pacing produces. Declared period and measured period agree.
+
+**So: yes, it pulses, and the period is 120 units.**
+
+## ⚠️ What this is NOT, stated plainly
+
+The port asked for a **per-frame series**, and **this is not one.**
+
+* Those four intervals come from a **screenshot probe** — the weaker of the two
+  instruments, and one carrying a wall-clock duration off an emulator whose pacing
+  is load-dependent. It is the instrument class that has cost this corpus four
+  withdrawn timing claims.
+* The strong instrument — per-frame vertex alpha off the guest's own buffer, the
+  one that settled the splash — **has never reached this screen.** Five capture
+  attempts, each blocked differently: wall-clock timeout, frame cap, a
+  self-matching `pkill`, and the fact that the title sits past the **137.7 s**
+  attract movie at ~1.3–1.8 presents per decoded movie frame.
+
+**For the port:** the *fact* and the *period* are answerable now — a 120-unit
+cycle, not a 244-unit one, driven by `ptbtn00f` and not `ptbtn00`. The
+**trajectory within a cycle** is not, and I will not infer its shape from the
+declared keyframes when the whole point of the splash exercise was that only a
+capture could confirm the shape.
+
+## Refutation attempt, recorded per the adversarial duty
+
+**Target:** the port's framing that the question is *"whether the timeline loops
+at 244 or something else drives it."*
+
+**Result: the disjunction is REFUTED — both halves are wrong about `ptbtn00`.** It
+does not loop at 244, and nothing else drives *it*; a **different element** loops,
+on 120. The port's instinct not to infer from "PRESS START prompts usually blink"
+was right, and the answer turned out to be one element sideways rather than one
+timing constant away.
+
+## Reach
+
+⟨disc⟩ for the 120-unit loop, so it generalises to every screen carrying that
+element. ⟨capture⟩ ×2 boots for the pulse, at four intervals, via the screenshot
+probe. **No per-frame series, on any instrument, for this element** — that gap is
+real and is what the next title-reaching capture should spend itself on.