re: the title "slab" is the logo swoosh drawn white and thick, and it

lands on the known tie-break group

Chasing the residual I left open last iteration, and it turns out I had
attributed the port agent's slab to the wrong thing.

First the refutation. My hypothesis was that our dim is applied over the
whole frame rather than beneath the UI where its layer key puts it. If
that were true the logo would render too dark. It reads +2.36 against a
background of -0.74, so the compositor honours the paint order and the
hypothesis is dead.

What the residual actually is: with the dim in place the error is not
uniform but concentrated in one band, running -38.6 in one tile and +33.8
three tiles to its right. Cropping that band from capture and render
shows it immediately -- the game draws the logo's Z swoosh thin with a
pink edge, and we draw it thick and solid white. That, not the missing
dim, is the washed-out slab over the title logo the port agent reported.
The dim explains a uniform +13; this explains the slab.

The elements are ptlogo_back2, its glow, and the five ptlogo_back2eff1..5
segments -- which are also the group carrying this corpus's known
unsolved paint-order tie-break at key 0x8083, on the same screen. I have
recorded that as a lead and explicitly not as a diagnosis, because a
blend-order swap is a poor explanation for white instead of pink and I
would expect a second cause.

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
+  🔴 **A second, separate defect — and it is the "slab".** With the dim in place
-  worse (edge-corr 0.9066, >20 diff px 108 051 → 162 636), so the blend is not
+  the residual is localised to one band (y ≈ 112–225): the game draws the logo's
-  exactly the game's. 🟡 A separate hot spot of +25…+38 sits on the upper-right
+  `Z` **swoosh thin with a pink/magenta edge**, our render draws it **thick and
-  `Z` swoosh, which a capture shows pink in the game and white in our render.
+  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

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
+With the dim in place, the residual is **not uniform** — it is a dark patch beside
-x ≈ 800–1279, y ≈ 112–225 run **+24.8 / +37.8 / +33.3** against ~+12 elsewhere.
+a bright one in one band:
-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.
+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.