re: ask #2 -- t=357.7 came from a GPU draw capture, and a sweep cannot date a frame

The port asked whether the refined sweep fit t=357.7 was measured against
live-title-build4-no-plate.png, because if so one of us is 42 units out.

It was not. 357.7 was solved against title-draw-capture-vertex-colours.log, a
GPU per-draw capture of the submitted vertex buffer -- four observables at once,
two quad centres and two vertex alphas. No framebuffer, no PNG.

The gap is not a fitting error either. Posing the leaves directly, t=400 misses
the captured quads by +169.0 and -172.2 px. Probe control: it reproduces the
page's published t=355 centres, 981 and 478, exactly.

Refutation attempted and FAILED: I expected the port's fit to be minimised by
the quad leaving the screen -- 'best fit' meaning 'draws least', the same shape
as the .tbm control that could not fail. At t=400 quad B is fully on screen and
quad A is 319 of 400 px. Their number is fitting something present and it
survives.

The real reason the two must differ is better than 'different frames'. The
sweeps are nested records on a free-running loop and their cycles differ -- 600
and 720, read from the record header +0x08 -- while the top-level clock stops at
settle. So two captures of the same settled title share a screen time and not a
sweep phase, by construction.

Consequence for the port: a sweep position does not date a frame; it gives a
phase on a 600- or 720-unit loop. And 357.7 is a joint fit over both leaves
while the port's ~400 poses one, so the two are not comparable in kind -- the
phases coincide only every LCM 3 600 units.

Discriminator handed to the port rather than taken: if its ~400 is pteff03 and
the frame is in the first cycle, pteff03a must be at centre 295 in that same
frame. The fit is against its renderer, so it owns the check.

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

docs/re/structures/ui-leaf-vs-parent-alpha.md

@@ -158,6 +158,84 @@ slow one, never the reverse.
 
 ---
 
+## ✅ 2026-08-30 — the port's ask: **no**, t=357.7 was never fitted against a PNG
+
+The port agent best-fits the same leaf against
+[`live-title-build4-no-plate.png`](../captures/title-builds/live-title-build4-no-plate.png)
+and gets **~400 units**, and asked whether that is the capture behind the
+**357.7** above — because if it is, one of us is ~42 units out.
+
+**It is not, and the two numbers are not measuring the same thing.**
+
+### What 357.7 was actually measured against
+
+[`title-draw-capture-vertex-colours.log`](../captures/title-builds/title-draw-capture-vertex-colours.log)
+— a **GPU per-draw capture**, recording the vertex buffer the game submitted:
+quad corner positions and per-vertex colours, for draw 2 of the title. No
+framebuffer, no PNG, and nothing rendered by us. The 357.7 is a joint solve over
+**four** observables from that one submission — two quad centres and two vertex
+alphas.
+
+### The gap is 170 px, which no fitting error reaches
+
+Posing the leaves directly
+([`../data/ptloop-leaf-sweep-positions.txt`](../data/ptloop-leaf-sweep-positions.txt);
+the probe reproduces this page's published t=355 centres of 981 and 478 exactly,
+which is its control):
+
+| | at t = 357.7 | at t = 400 | measured in the draw capture |
+|---|---|---|---|
+| quad A centre x | **991.8** | 1161 | **992.0** |
+| quad B centre x | **467.2** | 295 | **467.2** |
+
+At t=400 the prediction misses the captured quads by **+169.0** and **−172.2 px**.
+The draw-captured frame is not at t≈400 by any reading.
+
+### 🔴 The refutation I tried, and it failed
+
+**Hypothesis: the port's fit is minimised by the quad leaving the screen** — the
+same shape as a control that cannot fail, where "best fit" is really "draws least".
+It is **wrong here.** At t=400 quad B is fully on screen (400 of 400 px) and quad A
+is 319 of 400. Neither is anywhere near absent, so a pixel fit at 400 is fitting
+something present. **Their number survives the attempt.**
+
+### ✅ Why the two captures *must* differ — and why a sweep cannot date a frame
+
+The sweeps are **nested records on a free-running loop**, and their cycle lengths
+are read straight from the record header's `+0x08`
+([`ui-record-loop-length.md`](ui-record-loop-length.md)):
+
+| leaf | cycle |
+|---|---|
+| `ptloop01.rat` → `pteff03.t32` | **600** |
+| `ptloop02.rat` → `pteff03a.t32` | **720** |
+
+**They are different**, and `ui-clock-freezes-at-settle.md` establishes that the
+**top-level clock stops** inside the settle window while nested records keep
+cycling. So two captures of the "same" settled title are at the same top-level
+time and at *different* sweep phases, by construction.
+
+⚠️ **The consequence worth carrying: a sweep position does not date a frame.** It
+gives a phase on a 600- or 720-unit loop, not a screen time.
+
+⚠️ **And the two numbers are not comparable in kind.** 357.7 is a **joint** fit
+where both leaves agree; the port's ~400 is described as posing *"the `ptloop`
+leaf"* — one of them. Because the cycles differ, one leaf's phase does not pin the
+other except inside a common cycle (they coincide only every LCM = **3 600** units
+= 60 s). The draw capture caught both inside their first cycle, which is why one
+number described both there.
+
+### The discriminator, if anyone wants to close it
+
+If the port's ~400 is `pteff03` and its frame is inside the first cycle, then
+`pteff03a` in that **same** frame must sit at centre **295**. Checking the second
+leaf with the same instrument separates *"a different frame"* from *"one of us is
+wrong"*, and it needs no emulator. Handing it over rather than doing it here: the
+fit is against the port's renderer, and a claim resting on a renderer belongs to
+whoever owns it.
+
+---
+
 ## 🔴 Refutation — "125 % is the only non-whole-multiple scale" is WRONG, and by a lot
 
 `DECISIONS.md` records `title_jp`'s `ptlogo_eff2` at 125 % as *"the single drawn