diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md
index b4300a41..f3b50a79 100644
--- a/docs/port/HANDOFF.md
+++ b/docs/port/HANDOFF.md
@@ -70,10 +70,19 @@ authored version can be deleted.
   **`pteff02.prm`**, the 25 % dim, and `--primitives` is off by default. **That is
   the "washed-out cyan slab"** — a dim that should be there and isn't, not a glow
   that shouldn't. Because the art is blue-dominant, the shortfall reads cyan.
-  🟡 With the dim drawn the mean is right but per-pixel agreement is slightly
-  worse (edge-corr 0.9066, >20 diff px 108 051 → 162 636), so the blend is not
-  exactly the game's. 🟡 A separate hot spot of +25…+38 sits on the upper-right
-  `Z` swoosh, which a capture shows pink in the game and white in our render.
+  🔴 **A second, separate defect — and it is the "slab".** With the dim in place
+  the residual is localised to one band (y ≈ 112–225): the game draws the logo's
+  `Z` **swoosh thin with a pink/magenta edge**, our render draws it **thick and
+  solid white**. Crop:
+  [`title-swoosh-capture-vs-render.png`](../re/captures/title-builds/title-swoosh-capture-vs-render.png).
+  The elements are `ptlogo_back2.t32`, `ptlogo_back2eff.t32` and
+  `ptlogo_back2eff1…5`. 🟡 Those five are also the group with the **known
+  unsolved paint-order tie-break** (key `0x8083`) — same screen, same elements —
+  but a blend-order swap explains white-instead-of-pink poorly, so expect a second
+  cause. ❔ Not diagnosed.
+  🔴 **Refuted:** it is *not* that our dim covers the whole frame instead of
+  sitting beneath the UI — the logo reads +2.36 against a background of −0.74, so
+  the paint order is being honoured.
 
 * **The title's motion, decoded and attributed.** After building in, the *title
   art* is essentially static — a 22 s capture measures the wordmark region at
diff --git a/docs/re/ui-title-build-map.md b/docs/re/ui-title-build-map.md
index 5dc0a8fd..ddaf6ddb 100644
--- a/docs/re/ui-title-build-map.md
+++ b/docs/re/ui-title-build-map.md
@@ -395,10 +395,42 @@ slightly **worse** — edge-correlation 0.9163 → **0.9066**, and pixels differ
 application is not exactly the game's (blend mode or per-region alpha). Not
 diagnosed.
 
-### 🟡 And a second, localised excess
+### 🔴 The real defect: the logo swoosh is drawn white and thick
 
-The per-tile map shows a hot spot in the **upper right** — tiles at
-x ≈ 800–1279, y ≈ 112–225 run **+24.8 / +37.8 / +33.3** against ~+12 elsewhere.
-That is where the title's `Z` swoosh sits, which a capture from the first
-iteration of this work already showed **pink-tinted in the game and white in our
-render**. Same region, still undiagnosed.
+With the dim in place, the residual is **not uniform** — it is a dark patch beside
+a bright one in one band:
+
+```
+row1 (y 112-225):  -2.0  +3.0  -8.8  -38.6  -17.6  +16.2  +33.8  +24.4
+```
+
+Cropping that band from capture and render
+([`title-swoosh-capture-vs-render.png`](captures/title-builds/title-swoosh-capture-vs-render.png))
+shows it plainly: the game draws the logo's `Z` **swoosh thin, with a
+pink/magenta edge**; our render draws it **thick and solid white**. Too bright to
+its right, too dark where the game's thin stroke actually falls.
+
+**This — not the missing dim — is the port agent's "washed-out slab over the title
+logo".** The dim explains a *uniform* +13; the slab is this.
+
+The elements are `ptlogo_back2.t32` (rest `(71,126)`, pivot `(500,117)` — a
+1000 × 234 diagonal), its glow `ptlogo_back2eff.t32`, and the five
+`ptlogo_back2eff1…5` segments at y ≈ 117–194 — exactly the band that disagrees.
+
+🟡 **A connection worth chasing, not a diagnosis.** Those five segments are the
+group whose **paint-order tie-break is the known unsolved residual**
+([`structures/ui-paint-order-key.md`](structures/ui-paint-order-key.md)): they
+share key `0x8083`, the game paints them `14,15,18,16,17`, the stable sort paints
+`14,15,16,17,18`, and the measured cost is "`ptlogo_back2eff5` against `eff3`
+(22 568 px) and against `eff4` (32 395 px)". **Same screen, same elements.**
+
+❔ But a blend-order swap is a poor explanation for *white instead of pink* — that
+looks like a tint or blend-mode problem, so I would expect a second cause. **Not
+diagnosed**, and recorded as two candidate leads rather than one answer.
+
+### 🔴 Refuted on the way
+
+The obvious guess — *our dim is applied over the whole frame instead of beneath
+the UI, where its layer key puts it* — is **wrong**. If it were, the logo would
+render too dark; it reads **+2.36** against a background of **−0.74**. The
+compositor honours the paint order here.