Measured by the Decoder: the plate reaches alpha 255 in a single frame against
~11 frames of ramp with no input, and the sweep enters at 255 with no ramp where
an untouched run obeys its parent's declared t=70..100 gate. A cut, not an
acceleration.
It advances the ONE SHARED CLOCK, so authored/flow.json's clock: 'shared' stands.
🔴 I IMPLEMENTED THE OPPOSITE FIRST AND REVERTED IT. Their initial report had the
artwork animating across the press, which would mean two clocks and an
overlay-only jump; I built that (_plate_offset). It rested on a 5-frame window
that sat entirely inside the 11-12 frame lag between a scripted press and its
effect -- it compared frames where the input had not been acted on yet. A wider
pre-registered test refuted it: three elements mid-fade vanish in one frame.
🔴 AND MY FIRST VERSION NEVER FIRED, SILENTLY. It gated on overlay.settle_instant,
which is -1 for press_start: that screen declares a 22-unit settle window against
SETTLE_WINDOW_MIN=30. The boot has always printed 'settles at t=236' from
settle_time(), a DIFFERENT quantity, and I took the printed number as evidence
for the field I was testing. Caught only by filming and seeing overlay-view stay
flat at 0.0 across the press.
⚠️ The target is BOUNDED, not pinned: the capture puts it inside [100,238] -- past
the sweep's gate at 100, not past 250 or ptloop01's exit ramp would return the
sweep to alpha 0. settle_time()=236 sits inside that and is where the plate
reaches full alpha.
New diagnostic --press-at=S[,S...] presses (A) at wall-clock moments anywhere in
a boot; --skip-at lives inside the movie branch and fires once, so it cannot
reach the title. Marked fragile by construction.
VERIFIED on a filmed boot: shared clock jumps 109.4 -> 236.0 and view_units and
overlay_units move together across the press.
2b802e06b6