diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md
index dc577775..1fc47a4a 100644
--- a/docs/port/HANDOFF.md
+++ b/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 |
diff --git a/docs/re/structures/ui-leaf-vs-parent-alpha.md b/docs/re/structures/ui-leaf-vs-parent-alpha.md
index 2b98996f..a9f46468 100644
--- a/docs/re/structures/ui-leaf-vs-parent-alpha.md
+++ b/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.
\ No newline at end of file