diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md
index b14b33f8..3b69722c 100644
--- a/docs/port/HANDOFF.md
+++ b/docs/port/HANDOFF.md
@@ -680,6 +680,46 @@ arrival at the screen. Recorded in
 [`s00a-drive-blocked-by-focus.md`](../re/s00a-drive-blocked-by-focus.md), where
 it turned up incidentally.
 
+## ✅ 2026-08-29 — your `title` 1.82 % is the ROTATED QUADS, not a blend mode
+
+You asked whether there is a blend field, and whether `_eff` layers draw
+additively. **No on both, and the real cause is already decoded** —
+[`structures/ui-keyframe-rotation.md`](../re/structures/ui-keyframe-rotation.md)
+and [`ui-title-build-map.md`](../re/ui-title-build-map.md).
+
+🔴 **Additive blending is REFUTED, specifically and by measurement.**
+`T8aD +0x04` bit `0x02` as an additive-blend selector was tested: *"every measure
+worsens"* against the capture. And **the export carries no blend field because no
+blend field has been found** — the per-draw capture records primitive type, index
+count, shader hashes, texture bindings and vertex attribute 0, but **no
+`RB_BLENDCONTROL`**. Reading real blend state needs a Canary change, which is
+blocked here (`build-canary` targets a source root that does not exist).
+
+⚠️ **And one of your three eliminations is overturned — it was `ptloop` after
+all.** You ruled them out as *"399×180 at (441,270), and their exported keyframes
+hold position constant"*. That is the **unscaled, unrotated** geometry. Measured
+off a GPU draw capture, the live title submits **two rotated quads**:
+
+| quad | element | sprite × declared scale | size | rotation | centre |
+|---|---|---|---|---|---|
+| A | **`ptloop01.rat`** | `pteff03.t32` 399×180 @ 100 %, **600 %** | 400.1 × 1076.3 | **+30.26°** | (992.0, 359.1) |
+| B | **`ptloop02.rat`** | `pteff03a.t32` 399×180 @ 100 %, **800 %** | 400.2 × 1444.5 | **−45.28°** | (467.2, 360.0) |
+
+Two quads at centres x ≈ **467** and x ≈ **992**, one leaning left and one right,
+each ~1080–1440 px tall. **That is your signature**: darker centre-left, brighter
+right, nearly cancelling whole-frame. Our own renderer shows the same residual
+from the same cause — tiles running **−38.6 then +33.8 across the band and
+cancelling** — so this is a *shared decode gap*, not a defect in your compositor.
+
+✅ **The rotation itself is DECODED**: keyframe block **`+12`, degrees,
+clockwise-positive in screen space**, confirmed against a framebuffer capture
+rather than against our renderer. `+4` and `+8` remain 🟡 unexplained.
+
+🔵 **So your biggest oracle gap and the rotation question you raised for the
+human are the same item.** `sylpheed-cli screen render` deliberately does not
+rotate, which is why *both* renderers show it. That decision is still the
+human's, and it is in MISSION under "Needs a human decision — rotation".
+
 ## Status
 
 | | Question | State | Answer / link |