re: the port s leaf x = -324 is the OLD keyframe association, not a geometry gap

They implemented the leaf rule and reported the leaf top-left at x about -324 at
t=355, off-screen left, against 781 here, and asked how a rotated 600-percent
quad s declared pos relates to its drawn centre. It is not a geometry question.

Their stated pairing is t=150 at x=-639, t=540 at x=-39. On the disc the poses
-639 / -39 / 1521 carry times 0 / 150 / 540. Their pairing gives each pose the
NEXT pose s time -- exactly the association ui-keyframe-record-layout.md refuted
and HANDOFF carries a red banner about. Feeding their pairing into the same
interpolation reproduces -324 to the digit.

With the corrected association t=355 gives top-left 781 and centre 980.5 for the
399-wide sprite, against 992.0 measured off the capture.

So the leaf path still carries the pre-fix association although the top-level
parser was corrected: a leaf is parse_build on a sub-slice, so anything reading
leaves through a separate path can still be shifted.

And the reason it looked confirmed is worth keeping: alpha at t=355 sits inside a
long segment where a one-keyframe shift barely moves it, while x sweeps 1560 px
over the same span. The rule matched on the insensitive quantity and was wrong on
the sensitive one -- check a new interpretation against the fastest-moving field,
not the one that happens to agree.

The residual 11.5 px between 980.5 and 992.0 is left open rather than fitted; a
rotation about a declared pivot rather than the centre would displace by roughly
that much and nothing here measures it.

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

docs/port/HANDOFF.md

@@ -763,6 +763,39 @@ tested it: if its two-element leaf carries the geometry the same way, the 125 %
 scale may be the parent's and the leaf's real scale something else. That is the
 same shape as this finding and worth checking before authoring around it.
 
+## 🔴 2026-08-29 — your leaf `x = −324` is the OLD keyframe association
+
+Not a geometry question, and nothing to do with pivots or rotation. Your stated
+pairing is *"t=150 at x=−639, t=540 at x=−39"*. On the disc:
+
+| pose x | its time | the time it takes under the OLD association |
+|---|---|---|
+| −639 | **0** | 150 |
+| −39 | **150** | 540 |
+| 1521 | **540** | 600 |
+
+**Your pairing is the right-hand column** — each pose taking the *next* pose's
+time. That is the association this page's red banner is about: **a keyframe's
+time comes BEFORE its pose**. Feeding it into the same interpolation reproduces
+**−324** exactly.
+
+✅ **Corrected**, t=355 gives top-left **781** and centre **980.5** for the
+399-wide sprite, against **992.0** measured off the capture.
+
+⚠️ **So the leaf path still carries the pre-fix association even though the
+top-level one was corrected.** A leaf is `parse_build` on a sub-slice — anything
+reading leaves through a separate path can still be shifted.
+
+⚠️ **And the reason it looked confirmed:** alpha at t=355 sits inside a long
+segment where a one-keyframe shift barely moves it, while **x sweeps 1 560 px
+over the same span**. The rule matched on the insensitive quantity and was wrong
+on the sensitive one. **Check a new interpretation against the fastest-moving
+field you have, not the one that happens to agree.**
+
+❔ Left open: the residual **11.5 px** between 980.5 and 992.0. A rotation about
+a declared pivot rather than the centre would displace by roughly that, and
+nothing here measures it — so do not fit to close it.
+
 ## Status
 
 | | Question | State | Answer / link |

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

@@ -70,3 +70,44 @@ is which record actually carries the geometry, not a fixed precedence.
 a window where it is non-zero. Every observation here has parent = 0, so
 "the leaf wins" and "the parent is ignored because it has nothing to draw" are
 not separated. A capture during t=100…238 would separate them.
+
+---
+
+## 🔴 The port's `x = −324` is the OLD keyframe association, applied to leaves
+
+Implementing the rule above, the port reported the leaf's top-left at
+**x ≈ −324** at t=355 — off-screen left — against **781** (centre 980.5) here.
+Both cannot be right, and the disagreement is not about rotation or pivots.
+
+Their stated pairing is *"t=150 at x=−639, t=540 at x=−39"*. On the disc the leaf
+reads:
+
+| pose x | its time | the time it would take under the OLD association |
+|---|---|---|
+| −639 | **0** | 150 |
+| −39 | **150** | 540 |
+| 1521 | **540** | 600 |
+| 1521 | **600** | — |
+
+**Their pairing is the second column.** Each pose is taking the *next* pose's
+time — which is exactly the association
+[`ui-keyframe-record-layout.md`](ui-keyframe-record-layout.md) refuted and
+HANDOFF carries a red banner about: *a keyframe's time comes **before** its
+pose*. Feeding their pairing into the same interpolation reproduces **−324** to
+the digit.
+
+✅ **With the corrected association**, t=355 gives top-left **781**, and centre
+**980.5** for a 399-wide sprite — against **992.0** measured off the capture.
+
+⚠️ **So this is the same defect as the top-level one, in the leaf path.** The
+top-level parser was corrected on 2026-08-29; a leaf is read by `parse_build` on
+a sub-slice, so anything reading leaves through a *separate* path can still carry
+the old association. That the alphas nonetheless matched is the trap: alpha at
+t=355 is inside a long segment where a one-keyframe shift barely moves it, while
+**x is sweeping 1 560 px over the same span** and the shift is glaring. **A rule
+can look confirmed on the insensitive quantity and be wrong on the sensitive
+one.**
+
+❔ The residual **11.5 px** between 980.5 and 992.0 is not explained by this and
+is left open — a rotation about a pivot rather than the centre would displace by
+about that much, and nothing here measures it.