re: REFUTE my own units 5 and 6 -- pteff03a IS drawn, the reader was truncating

The two sweeps are batched into ONE additive indices=8 draw, two quads, and
my parser took the first v: match per line and discarded the rest. Every
analysis saw quad A and never quad B. No new capture was needed -- the same
logs units 5 and 6 used already contained it.

Both strips measured: opposite directions matching the declared -639->1521
and 1721->-839, and a size ratio of 1.301 against the declared sy ratio
800/600 = 1.333.

Unit 5 recorded that the PORT's renderer draws pteff03a and treated that as
the port being wrong. The port was right.

Third instance of this class in the corpus (palogo_anima and the six-quad
dump are the others): a truncating reader yields a clean, complete-looking
negative. Reading one raw draw line in full would have caught it -- indices=8
was printed on every line and says two quads outright.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

docs/re/f6-unit11-pteff03a-IS-drawn.md

@@ -0,0 +1,80 @@
+# F6 unit 11 — 🔴 `pteff03a` **is** drawn. Units 5 and 6 are refuted, by my own parser.
+
+**Question:** does the real title draw one sweeping strip or two?
+
+**What the human looks at:** watch the title. **Two** glowing strips cross it in
+opposite directions. Pass = two. Fail = one.
+
+**What this does NOT cover:** their alpha curves, the snap target.
+
+**Instrument:** ⟨capture⟩ — the same two logs units 5 and 6 used. **No new
+capture. The logs always said two; my reader said one.**
+
+## The bug
+
+The sweeps are **batched into a single additive draw** — `indices=8`, eight
+vertices, two quads:
+
+```
+10482 ... blend=0x01010101 ... tex[... h=8154424FFC48FE61]
+  v: [0.54,1.58 BB] [1.08,1.02 BB] [0.24,-1.57 BB] [-0.30,-1.02 BB]   <- quad A
+     [-1.13,1.02 B0] [-0.69,1.81 B0] [0.90,-1.02 B0] [0.46,-1.81 B0]  <- quad B
+```
+
+**My parser took the first `v:` match per draw line and discarded the rest.** So
+every analysis I ran saw quad A and never quad B. `pteff03a` was in the log the
+whole time.
+
+## ✅ Both strips, measured
+
+| | mean length | starts at | travels |
+|---|---|---|---|
+| quad A | **1151 px** | x = −1.66 | **+x** |
+| quad B | **1497 px** | x = +1.98 | **−x** |
+
+Three independent agreements with the declaration:
+
+* **Directions are opposite and correct** — `pteff03` declares −639→1521 (+x),
+  `pteff03a` declares 1721→−839 (−x).
+* **Size ratio 1497/1151 = 1.301** against the declared `sy` ratio
+  **800/600 = 1.333** — 2.4%.
+* Quad A's 1151 px matches the **1134** the older GPU sessions recorded for the
+  `pteff03` strip.
+
+Both hold in `f6` and `f6b`.
+
+## 🔴 What this retires
+
+* [`f6-unit5-pteff03a-never-drawn.md`](f6-unit5-pteff03a-never-drawn.md) —
+  **refuted.** Its "quads in `pteff03a`'s expected height band: NONE" counted
+  first-vertices only.
+* [`f6-unit6-pteff03a-not-submitted-at-all.md`](f6-unit6-pteff03a-not-submitted-at-all.md)
+  — **refuted.** "Absent, not collapsed" was neither; it was unread.
+* The three candidate mechanisms killed while explaining the absence were
+  explaining **a non-fact**. Under R1 they re-open: the instrument that killed
+  them has changed.
+* Unit 5 recorded that *the port's renderer draws `pteff03a`* and treated that as
+  the port being wrong. **The port was right and I was the one to correct.**
+
+## The lesson, and it is the third time
+
+The corpus already carries two entries of this exact shape — `palogo_anima`
+"never appears" against the 8-vertex cap, and a dump that "captured two [of six
+quads], with a well-formed line and no ellipsis". **A truncating reader produces
+a clean, complete-looking negative.** Nothing in unit 5 or 6 looked wrong.
+
+What would have caught it, and what I did only on the third pass: **read one raw
+draw line in full** before trusting a count derived from it. `indices=8` was
+printed on every one of those lines and says two quads outright.
+
+⚠️ Claims that depended on the first-vertex reader and are **not** affected: the
+alpha decomposition in unit 10 (quad A read consistently on both sides), the
+press/no-press comparisons in F5 (same reader both sides), and the pulse ratio
+(single-quad draws). Those compare like with like. The absence claims did not —
+they compared a count against zero.
+
+## Not settled
+
+* Why `pteff03a`'s alpha differs from `pteff03`'s at the same instant (0xB0 vs
+  0xBB above) — the declared curves differ, but I have not fitted them.
+* The snap target, still bounded to `[100,238]`.

docs/re/f6-unit5-pteff03a-never-drawn.md

@@ -1,5 +1,11 @@
 # F6 unit 5 — `pteff03a` is **never drawn**: the game shows ONE sweep, not two
 
+> 🔴 **REFUTED 2026-09-02 by [`f6-unit11-pteff03a-IS-drawn.md`](f6-unit11-pteff03a-IS-drawn.md).**
+> `pteff03a` **is** drawn. It is batched with `pteff03` into one additive
+> `indices=8` draw, and the parser behind this page read only the first
+> vertex of each draw line. The negative below is an artefact of the reader.
+
+
 **Status: ✅ measured ⟨capture⟩ ×1.** 2026-09-02.
 
 **Question:** does `pteff03a` appear anywhere in the capture?

docs/re/f6-unit6-pteff03a-not-submitted-at-all.md

@@ -1,5 +1,11 @@
 # F6 unit 6 — `pteff03a` is not submitted **at any size**: absent, not collapsed
 
+> 🔴 **REFUTED 2026-09-02 by [`f6-unit11-pteff03a-IS-drawn.md`](f6-unit11-pteff03a-IS-drawn.md).**
+> `pteff03a` **is** drawn. It is batched with `pteff03` into one additive
+> `indices=8` draw, and the parser behind this page read only the first
+> vertex of each draw line. The negative below is an artefact of the reader.
+
+
 **Status: ✅ measured ⟨capture⟩ ×1.** 2026-09-02.
 
 **Question:** is `pteff03a` absent from the draw stream, or submitted at zero /