re: the skewed draw is not the swoosh -- refuting the identification five

iterations of work were built on

I flagged last iteration that "draw 2 is the swoosh" was an inference I
had never checked. Checking it took one line, and it is wrong.

Converting the quads from NDC to screen space: quad A spans y -209 to
925, quad B spans y -292 to 1012. Both cover the full screen height and
run well off it. The swoosh, ptlogo_back2, rests at (71,126) and is a
234-pixel band at y 126 to 360. Draw 2 is not it.

A candidate offered as one: the two ptloop sweeps. pteff03a is 399x180
with element scale (100,800), so 399x1440, and pteff03 carries (100,600)
-- two long thin sprites, two quads, and the drawn vertex alphas 0xC3 and
0xB6 sit inside the 0x80 to 0xff ramp those records declare. Not
confirmed; no texture or position match was made.

If that is right it matters, and I have written it conditionally rather
than acting on it: our renderer parks those sweeps at their final
keyframe, both off screen, and draws nothing, while the game draws them
across the screen. That would mean the capture caught them mid-sweep
inside their t=150 to 600 window, and that the "groups hold" reading
needs re-examining for those two elements.

What this cost is worth stating plainly. Five iterations -- the additive
blend test, the pivot analysis, the vertex-colour capture -- were built
on an identification made by elimination on one screen and never checked
against the draw's own coordinates. The eliminations themselves stand,
because each was measured against the capture rather than against the
identification. The chain that pointed them at ptlogo_back2 did not.
METHOD takes the general form.

docs/re/METHOD.md

@@ -310,3 +310,10 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   next route "because it reads the blend state". It does not — checking the
   capture's own source showed it records textures and vertex attributes and no
   blend registers. A named next step is a claim like any other.
+* **Name the element from the draw's own coordinates before building on it.** A
+  skewed draw in a title capture was called "the swoosh" because the swoosh is the
+  screen's only diagonal element — an identification by elimination, never checked
+  against the draw's NDC extent. It was wrong: the quads span the full screen and
+  beyond, the swoosh is a 234-pixel band. Five iterations of analysis pointed at
+  the wrong element on the strength of it. Converting the coordinates takes one
+  line and should come first.

docs/re/REFUTED.md

@@ -35,6 +35,10 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
+* "the rotated draw in the title's capture is the `Z` swoosh
+  (`ptlogo_back2*`)" → **mine, and refuted.** Its quads span y −209…925 and
+  −292…1012 in screen space; the swoosh is a band at y 126…360.
+  [`ui-title-build-map.md`](ui-title-build-map.md)
 * "the keyframe words at `+4`/`+8`/`+12` are always zero" → they are non-zero in
   4.81 %, 4.56 % and 15.82 % of 72 287 blocks disc-wide, reading as **degrees**
   (±180, ±90, 120). The original note was a sample artefact.

docs/re/ui-title-build-map.md

@@ -673,4 +673,39 @@ unidentified.
 swoosh. It is the only skewed geometry in the capture and the swoosh is the only
 diagonal element on the screen, so the inference is reasonable — but it was not
 confirmed by matching the draw's texture or screen position to that element, and
-should be.
+should be.
+
+## 🔴 The skewed draw is NOT the swoosh — my identification was wrong
+
+Converting draw 2's quads from NDC to screen space settles it:
+
+| quad | screen corners | bbox |
+|---|---|---|
+| A | (1088,−209) (1434,−7) (896,925) (550,727) | x 550…1434, **y −209…925** |
+| B | (−186,−7) (96,−292) (1120,727) (838,1012) | x −186…1120, **y −292…1012** |
+
+These span the **full screen height and well beyond it**. The swoosh
+(`ptlogo_back2`, rest `(71,126)`, 1118 × 262) is a **band** at y 126…360. Draw 2
+is not it.
+
+🟡 **A candidate, offered as one:** the two `ptloop` sweeps. `pteff03a.t32` is
+399 × 180 and its element carries scale **`(100,800)`** — 399 × 1440 — while
+`pteff03` carries `(100,600)`. Two long thin sprites, two quads, and the drawn
+vertex alphas `0xC3`/`0xB6` sit inside the `0x80`→`0xff` ramp those records
+declare. **Not confirmed** — no texture or position match was made.
+
+⚠️ **If** that is right it has a consequence worth flagging: our renderer parks
+those sweeps at their final keyframe (`x = 1521` and `−839`, both off-screen) and
+draws nothing, while the game draws them across the screen — which would mean the
+draw capture caught them **mid-sweep**, inside the `t = 150…600` window, and that
+the "groups hold" reading needs re-examining for these two elements specifically.
+Conditional on an unconfirmed identification, so recorded and not acted on.
+
+### What this costs
+
+Five iterations of swoosh work — the additive-blend test, the pivot analysis, the
+vertex-colour capture — were built on "the skewed draw is the swoosh", an
+identification made by *elimination on one screen* and never checked against the
+draw's own coordinates. The eliminations themselves stand (they were measured
+against the capture, not against the identification), but the chain of reasoning
+that pointed at `ptlogo_back2*` did not.