port: the ring spins, the plate needs no constant, and rest.t was never the settle

Two milestones' known-wrong bits, both now answered by the RE agent, both taken.

P5 -- the focus ring. It was drawn at 0 with a comment saying so. The period is
now measured (continuous spin, eight evenly spaced autocorrelation peaks over
nine revolutions, no angle estimated anywhere) and it needs NO authored
constant: the period is the element's own declared t=120, and what the
measurement adds is only that the turn repeats rather than stopping -- which
"groups hold" could not decide, because 0 and 360 are the same pose.

`spin_period_units` is structural and narrow on purpose: two keyframes,
differing in nothing but rotation_deg, by a full 360, first timed and second
untimed. 16 of 212 elements in this export match and all 16 are focus rings,
zero false positives. That check is the point -- the measurement was taken on
ONE button of ONE screen, and a rule that caught anything else would be
extrapolating it to elements nobody watched.

Verified on the port's own render with the RE agent's own control: bit-identical
one period apart across the whole frame, 3.6/255 inside the ring's box at
quarter-period steps, and box luminance conserved to 0.027 % over eight phases
-- which is the observable they used to separate rotation from a pulse. Not
claimed: direction (no signed angle was ever measured) and phase across a focus
change (their run held focus throughout).

P3 -- the plate. Last iteration I refuted their authoring instruction and
shipped it anyway rather than pick between two of their numbers. The refutation
held and the answer came back better than either option I offered: AUTHOR
NOTHING. Both builds run on one clock started together and the plate arrives at
its own declared t=238. The 2.13 s constant is deleted.

The premise that failed was mine: rest.t IS NOT WHEN A SCREEN SETTLES. It is the
last hold keyframe before the exit. ptlogo1 stops MOVING at t=42 and then creeps
5 px and 31 alpha steps to t=251. Reading rest.t put build 4's arrival at 4.350 s
instead of 1.967 s, and the "2.51 s, which is not a landmark of anything" I sent
them is that error wearing a decimal point. 238 - 118 = 120 units = 2.000 s
against a measured 2.135 s at 28.1 fps presentation. Checked against my own
export before touching anything.

`ScreenView.settle_time()` still uses rest.t, and so the boot sequencer paces
every screen off the wrong landmark. NOT changed here: "visible arrival" is a
heuristic and getting it wrong re-paces everything. Filed, and asked for a timed
boot instead now that their oracle is live.

REFUTATION: two of their pages measure the same declared 120 units of wall clock
during a static hold and disagree by 2 % -- plate 2.135 s (28.10 fps implied),
ring 2.177 s (27.56 fps). That is seven times the plate page's own 6 ms
run-to-run agreement, and it lands on the argument that page uses to justify
itself: "the build-in is where frames are dropped; the static hold is not". Also
the ring page's band, 27.6-28.8 fps, does not contain its own measurement -- the
mean needs 27.56 and four of seven spacings are outside. Filed, not worked
around: my port uses the declared 120 units either way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WM5XL4HfrHuxz8RiMWdCMC

authored/flow.json

@@ -31,12 +31,13 @@
       "screen": "title",
       "overlay": {
         "screen": "press_start",
-        "after_settle_seconds": 2.13,
-        "why": "MEASURED, 2026-08-29, docs/re/title-plate-delay-measured.md on branch auto/no-disc-and-menu-captures at fb536df (NOT yet on main when this was written). The boot title shows build 4 ALONE, and the `PRESS (A) BUTTON` plate -- build 2 -- is composited over it 2.13 s later. Two independent boots of the real game agree to 6 ms. This is the ONE case in the port where two builds are drawn at once.",
-        "measured_from_why": "The 2.13 s is timed from the frame build 4's own build-in animation FINISHES, not from the frame the title art first appears. That distinction is the finding, not a detail: measured the other way the two runs differ by 0.48 s, because the build-in itself ran 1.64 s and 2.13 s and the emulator's frame pacing during an animation is not the game's clock. A number taken from the wrong instant here looks exactly like a measurement.",
-        "not_a_fade_in_why": "The alternative -- that the plate was there all along, pulsing too dim to see -- was tested and refuted on two observables. The plate's declared alpha never exceeds 0x50, so a thresholded glyph counter could in principle miss a dim phase; it does not. The count sits at EXACTLY 154 with zero variation for 1.99 s / 2.13 s and then swings 714-1520, and the surface mean is flat to +/-0.03 across the plateau. A pulsing overlay moves the frame mean.",
-        "scope_why": "Attached to the BOOT STEP, not to the `title` screen, and that is deliberate. What was measured is the boot title. Whether the title shows the plate when it is REACHED AGAIN -- by (B) from the main menu, or after the attract movie -- is not measured, and putting the overlay on the screen would quietly claim it is. See docs/port/BLOCKED.md.",
-        "no_pulse_why": "The port draws the plate arriving and then HOLDING VISIBLE. It does not pulse it. The plate's own group encodes exactly one cycle -- alpha 0x00 at t=214, 0xff at t=238-244, 0x00 on the final untimed keyframe -- and the port holds at the settle (t=238, alpha 0xff) as it does on every other screen. The running game was measured pulsing continuously at peak intervals averaging 2.24 s, and NO reading of this group produces 2.24 s: looping the whole group gives 268 units = 4.47 s, looping from the first keyframe gives 54 units = 0.90 s. So repeating the group here would be inventing a period, and the port does not. Filed in BLOCKED.md."
+        "clock": "shared",
+        "why": "MEASURED, 2026-08-29, docs/re/title-plate-delay-measured.md on branch auto/no-disc-and-menu-captures at 5b0a6e6 (NOT on main when this was written). The boot title shows build 4 ALONE and the `PRESS (A) BUTTON` plate -- build 2 -- arrives later. This is the ONE case in the port where two builds are drawn at once.",
+        "no_constant_why": "THERE IS NO AUTHORED DELAY HERE, AND THERE WAS ONE FOR ONE ITERATION. The first version of this block carried `after_settle_seconds: 2.13`, taken from the RE agent's instruction. The port refuted that instruction with arithmetic off the disc -- build 2 has a group of its own, and starting it at settle put the plate 3.97 s late -- and the corrected answer needs no constant at all: BOTH BUILDS RUN ON ONE CLOCK, STARTED TOGETHER, and the plate arrives at its own declared t=238. `clock: \"shared\"` is that, spelled out rather than implied by the absence of a delay field.",
+        "arithmetic_why": "Why one clock reproduces the measurement, checked against this export rather than taken on trust: build 4's visible build-in ends at t=118, where `pteff01`, `pteff02` and `ptlogoall_eff` finish together; `ptbtn00` reaches alpha 255 at t=238; the difference is 120 units = 2.000 s at 60 units/s. The oracle measured 2.138 s and 2.132 s. The gap is presentation rate: 120 units in 2.135 s is 56.2 units/s, i.e. the emulator presenting at 28.1 fps against a nominal 30, and the corpus had independently measured the idle title at 28.5 fps before these runs.",
+        "the_premise_that_failed_why": "The port's own, and it is worth keeping because it will bite again: `rest.t` IS NOT WHEN A SCREEN SETTLES. It is the last hold keyframe before the exit. `ptlogo1` has rest.t=251 and stops MOVING at t=42, then creeps 5 px and 31 alpha steps over the next 209 units. Reading rest.t as the settle put build 4's arrival at 4.35 s instead of 1.97 s, and every reconciliation computed from it came out wrong by exactly that error. `ScreenView.settle_time()` still uses rest.t -- see docs/port/BLOCKED.md.",
+        "scope_why": "Attached to the BOOT STEP, not to the `title` screen, and that is deliberate. What was measured is the boot title. Whether the title shows the plate when it is REACHED AGAIN -- by (B) from the main menu, or after the attract movie -- is not measured, and putting the overlay on the screen would quietly claim it is.",
+        "no_pulse_why": "The port draws the plate arriving and then holding. It does not pulse it. The RE agent identifies the pulse as the plate's FOCUS RECORD `ptbtn00f` -- a glow ramping 0x00 to 0x50 and back, t=6..105 -- not as a loop of `ptbtn00`'s own group, which was the port's earlier reading and was wrong. Looping that record is a candidate the port has NOT taken: its group is 105 timed units plus an AUTHORED 24-unit exit ramp, and hitting the measured 2.24 s mean requires composing that authored constant with a loop assumption, which is tuning rather than measuring. Filed in BLOCKED.md."
       },
       "why": "HANDOFF Q2/Q6: the boot reaches the title after the intro movie. This is the LAST step, and a last step is where the sequence stops rather than fading out -- a boot that ends by fading to black looks like a boot that crashed. P5 gave the title somewhere to go, but that is a HANDOVER and not another boot step: `--boot` still stops here, and `--boot --play` hands the same held title to the menu flow, where (A) opens TITLE_MENU. Kept as a stop rather than folded into `screens` because what the boot does is authored from a measured sequence, and what (A) does is a separate measurement."
     }