re: F6 unit 3 -- the sweep's POSITION fits the declared track, origin at leaf t=0

Took the port's point and dropped the alpha line. Three exchanges had gone
on alpha -- a bound, a refutation, a downgrade -- over 14 usable samples of
1754, when the position travels 2160 px monotonically in the same capture.

pteff03's declared leaf track is linear at 4.000 px/unit: -639 at t=0, -39
at t=150, 1521 at t=540. The capture's first clean segment runs frames
746..1913 with x from -641.1 to +1522.1. Both endpoints land within ~2 px
on a 2160 px travel, 0.1%. Two independent checks rather than one fitted
parameter. A single wrap at frame 1914 confirms the declared 600-unit loop
and falls after the segment.

Answers the clock origin: the leaf's t=0 is its first drawn frame, so the
game does not carry the leaf forward from the title's clock. That CONFIRMS
the port's own correction -- they had attributed ~135 units of earliness to
the leaf starting at title t=0 and withdrew it on two relayed numbers; the
full series says the withdrawal was right.

Rate here is 540 units in 1167 presents = 0.463 units/present, flagged as
the weak half: one run, in presents, and it does NOT match the 1
unit/present the splash work established. Either the leaf runs a slower
clock or one of the two is not what I think. The origin does not depend on
it.

And the useful negative: a linear fit across all 1754 samples gives max
residual 1108 px on 1402 px of travel, 79%, because the trajectory wraps
and a straight line through a sawtooth is meaningless. A fit not checked
for residual would have reported a slope and a plausible origin from that
same data -- which is exactly why the port's tool selftest must reject a
wrong-shape series, and why I segmented before fitting.

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

docs/re/f6-unit3-sweep-track-fits.md

@@ -0,0 +1,73 @@
+# F6 unit 3 — the sweep's **position** fits the declared track: origin at leaf `t=0`, both endpoints within ~2 px
+
+**Status: ✅ measured ⟨capture⟩ ×1.** 2026-09-02.
+
+**Question:** where does the sweep's own clock start, and how fast does it run?
+**Look at:** its pixel x against the declared leaf track. Pass = the ends land on
+the declared endpoints; fail = they do not.
+**Not covered:** whether parent alpha multiplies in (that is unit 2, still 🟡);
+F5.
+
+---
+
+## Why position, and not alpha — the port's point, adopted
+
+Three exchanges went on alpha: a bound, a refutation, a downgrade, over **14
+usable samples of 1754**. Alpha is 8-bit, quantised and non-monotone, and a
+grouping slip in its tail is indistinguishable from signal. **The position travels
+2 160 px monotonically in the same capture and cannot fail those ways.** The port
+made that argument and built `tools/port/fit-trajectory` for it; this is the same
+measurement, run on my side against the raw stream.
+
+## The measurement
+
+`pteff03`'s declared leaf track is **linear at 4.000 px/unit**:
+`x = −639 @ t=0`, `−39 @ t=150`, `1521 @ t=540`.
+
+The capture's sweep, converted from NDC centre to pixel left edge:
+
+```
+first segment   frames 746 … 1913     x  −641.1  →  +1522.1
+declared        t = 0 … 540           x  −639    →  +1521
+                                      Δ  −2.1 px      +1.1 px
+```
+
+> **Both endpoints land within ~2 px on a 2 160 px travel — 0.1 %.** Two
+> independent checks, not one fitted parameter.
+
+📌 **A single wrap** at frame **1914** (x jumps back > 500 px) confirms the
+declared 600-unit loop, and it falls after the segment measured, so the segment is
+clean.
+
+## What it answers
+
+* **Clock origin: the leaf's `t = 0` is its first drawn frame.** The −2.1 px start
+  says the game does not carry the leaf forward from the title's clock. ✅ This
+  **confirms the port's own correction** — they had earlier attributed ~135 units of
+  earliness to the leaf clock starting at title `t=0`, and withdrew it on two
+  relayed numbers; the full series says their withdrawal was right.
+* **Rate here: 540 declared units in 1 167 presents = 0.463 units/present.**
+
+⚠️ **The rate is the weak half and I am flagging it rather than burying it.** It is
+in *presents*, on one emulator run, and it does **not** match the 1 unit/present
+the splash work established. Either the leaf runs on a slower clock than the
+element timeline, or one of the two is not what I think it is. **The origin does
+not depend on it** — that rests on the endpoints alone.
+
+## 🔴 A linear fit across the whole capture FAILS, and that is the useful part
+
+Fitting `x = a + b·frame` over all 1 754 samples gives **max residual 1 108 px on
+1 402 px of travel — 79 %**. Read alone that says "the model is wrong". It is not:
+the trajectory **wraps**, and a straight line through a sawtooth is meaningless.
+
+**A fit that had not been checked for residual would have reported a slope and a
+plausible-looking origin from that same data.** The port's insistence that their
+tool's selftest must *reject a wrong-shape series* is exactly this failure, and it
+is why I segmented before fitting rather than after.
+
+## Reach
+
+⟨capture⟩ ×1, one boot, one segment, one element. The identification is now
+sound — unit 2's correction established both size-keys are `pteff03` and it
+travels left-to-right, which the declared track predicts and the measurement
+matches at both ends. `pteff03a` does not appear in this capture and is untested.