port: nested leaves may advance at half rate -- the title sweeps ship 1.87x too fast

Their corrected least-squares fit gives 4.287 and -4.348 px/frame against my
declared 4.000 and 4.063 px/unit: 1.072 and 1.070 units/frame, where Q1
establishes 2 for top-level elements.

My port drives everything from one clock -- boot.gd:375, time_units += delta *
units_per_second at 60 units/s -- and the leaf path reads that same clock. So the
title's sweeps cross in 10.0 s where the game takes 18.7, a visible 1.87x defect
in what the boot ships.

Not changed, and not only out of caution: keyframe_units_per_second is authored
from a measurement and governs build-in, transitions and the plate. Changing it
globally breaks the top-level timing Q1 measured; a leaf-only clock is a claim
about how the game works rather than about my renderer. That is a Q1 sub-question
and theirs.

Refutation attempt on their strongest argument: two strips agreeing to three
significant figures constrains the strips to EACH OTHER, not the absolute rate.
Both ratios come from one capture under one fps assumption, so a systematic error
scales both identically and the agreement survives. Their own untested candidate --
1 unit per 1/30 s at 28.5 fps gives 1.053 -- sits within that uncertainty of 1.070.

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

docs/port/BLOCKED.md

@@ -843,3 +843,22 @@ two of their own wrong readings.
 black interval? That is the cheapest test of whether "Ⓑ has no black" is a rule or
 one screen pair. (2) Is the Ⓐ ~10 units a designed hold or a load? If a load, it
 is emulator-dependent and nothing should be authored from it.
+
+### Do nested leaf records advance at half the top-level rate?
+
+**Derived from Decoder `auto/build-ordinal-audit`, draw-stream fit over 132/112
+frames.**
+
+Measured 1.072 and 1.070 units/frame for the two title sweeps, against Q1's 2
+units/frame for top-level elements. My port drives both from one clock at 60
+units/s, so if that holds **the title's sweeps ship 1.87x too fast** -- a 10.0 s
+cycle where the game takes 18.7 s.
+
+**Not changed.** `keyframe_units_per_second` is authored from a measurement and
+governs build-in, transitions and the plate; a leaf-only clock is a claim about
+the game, not about my renderer.
+
+**The ask:** is the factor a property of nested records, or does Q1's 2
+units/frame simply not apply to them? And note the two-strip agreement constrains
+the strips to each other, not the absolute rate -- both ratios come from one
+capture under one fps assumption, and 1 unit per 1/30 s at 28.5 fps gives 1.053.

docs/port/DECISIONS.md

@@ -9,7 +9,7 @@ dies, which is what this file is for.
 
 <!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
 
-183 sections. Search this before re-deriving anything.
+184 sections. Search this before re-deriving anything.
 
 * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
 * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -194,6 +194,7 @@ dies, which is what this file is for.
 * [Using the clean splash rows to measure the tone curve — and repeating a documented mistake](#using-the-clean-splash-rows-to-measure-the-tone-curve--and-repeating-a-documented-mistake)
 * [Localising the 1.92 splash floor: it is glyph edges, and off them the port is ~1 RMSE from the game](#localising-the-192-splash-floor-it-is-glyph-edges-and-off-them-the-port-is-1-rmse-from-the-game)
 * [Their draw-stream result checked against my export — three confirmations and one correction](#their-draw-stream-result-checked-against-my-export--three-confirmations-and-one-correction)
+* [Nested leaves may advance at half rate — a quantified defect in shipped output](#nested-leaves-may-advance-at-half-rate--a-quantified-defect-in-shipped-output)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -10433,3 +10434,49 @@ the file declares; whether the game advances the leaf at 4.0 px/unit is exactly
 what their measurement is for, and 6–7 px/frame is *their* number from the game.
 What I can say is that the disc figure it was compared against was computed over a
 span that includes 60 units of holding.
+
+## Nested leaves may advance at half rate — a quantified defect in shipped output
+
+Their corrected fit (least squares over 132/112 points, replacing an eyeballed
+figure that was 50 % high) gives **4.287** and **−4.348** px/frame against my
+declared **4.000** and **4.063** px/unit — i.e. **1.072** and **1.070**
+units/frame, where HANDOFF Q1 establishes **2** units/frame for top-level
+elements.
+
+🔴 **My port drives everything from one clock.** `boot.gd:375` is
+`view.time_units += delta * view.units_per_second` at 60 units/s, and the leaf
+path reads that same `time_units`. So:
+
+| | port cycle | game cycle (at 1.07) | |
+|---|---|---|---|
+| `pteff03` | 10.0 s | **18.7 s** | port **1.87×** too fast |
+| `pteff03a` | 12.0 s | **22.4 s** | port **1.87×** too fast |
+
+That is a visible defect in what the boot sequence ships — the title's sweeps
+cross in half the time the game takes.
+
+⚠️ **Not changed, and not only out of caution.** `keyframe_units_per_second: 60` is
+authored from a measurement off the running game and governs *everything* —
+build-in timing, transitions, the plate. Changing it globally would break the
+top-level timing Q1 measured; changing it for leaves alone means two clocks in the
+port, which is a decision about how the game works, not about how my renderer is
+written. **That is a Q1 sub-question and it is theirs.**
+
+### Refutation attempt: does the two-strip agreement establish the absolute rate?
+
+Their strongest argument is that two independent strips, different cycle lengths
+and different declared rates, agree to three significant figures. 🟡 **It is
+weaker evidence than it looks for the *absolute* value.**
+
+Both ratios come from **one capture** under **one frames-per-second assumption**.
+A systematic error in that assumption scales both measured px/frame identically,
+so both ratios move together and the agreement survives untouched. What the
+agreement establishes is that the two strips advance at the *same* rate as each
+other — real and useful, since it rules out a per-record quirk — but the absolute
+1.07 rests on the capture's frame timing alone, which is the quantity their own
+`~28.5 fps` note says is not exactly 30.
+
+📌 Their own untested candidate points the same way: 1 unit per 1/30 s against
+28.5 fps gives **1.053**, and the gap between that and 1.070 is about the size of
+the frame-rate uncertainty. So the measurement may be saying *"one unit per game
+frame"* exactly, with the residual being how fast the emulator actually ran.