diff --git a/docs/port/f6-what-starts-the-sweep.md b/docs/port/f6-what-starts-the-sweep.md
index a397279f..ce6fee97 100644
--- a/docs/port/f6-what-starts-the-sweep.md
+++ b/docs/port/f6-what-starts-the-sweep.md
@@ -250,3 +250,73 @@ into `check-all`.
 
 ⚠️ It fits a **constant** rate. A stalling guest clock or uneven capture drops
 raise the residual rather than being absorbed, which is deliberate.
+
+---
+
+# 🔴 Unit c — the port draws a sweep the game's capture does not, and I owe a correction
+
+## First, the correction: my refutation was right in outcome and WRONG in its reason
+
+I challenged the Decoder's by-size identification on the ground that *"both
+sweep sprites are 399×180, so size cannot separate them"*. **That was wrong.** I
+compared the source PNGs and never looked at the leaf declarations:
+
+| leaf | sprite | declared scale | **drawn height** |
+|---|---|---|---|
+| `pteff03` | 399×180 | `[100, 600]` | **1080 px** |
+| `pteff03a` | 399×180 | `[100, 800]` | **1440 px** |
+
+The *drawn* quads differ by a third, which is exactly the 3.15 vs 3.62 NDC the
+Decoder was separating by. **Size distinguishes them fine.** The hold was still
+correct and the check I asked for still found a real defect — but it found a
+different one (one element double-counted, and a set presented as a series), and
+my stated reason did not survive. Recorded because a right answer reached by a
+wrong argument is the kind that gets cited later for the wrong reason.
+
+## And it makes the real finding sharper
+
+Because size *does* separate them, the Decoder's line — *"`pteff03a` does **not**
+appear in this capture at all"* — is well-evidenced rather than incidental. They
+looked for a distinct size and found nothing.
+
+**The port draws it.** Asked directly, at three instants:
+
+```
+t=120  drew 9: ptbase2, pteff03, pteff03a, pteff04, ...
+t=180  drew 10: ptbase2, pteff03, pteff03a, pteff04, ...
+t=240  drew 10: ptbase2, pteff03, pteff03a, pteff04, ...
+```
+
+`pteff03a` is on screen in the port from t≈108 (it crosses x=1280 there) until
+t≈521, travelling **right-to-left** at 800 % vertical scale while `pteff03` runs
+left-to-right at 600 %. The capture covers that window and contains only
+`pteff03`.
+
+> **So the port appears to render a second light sweep, larger and travelling the
+> opposite way, that the game does not draw during the title build-in.**
+
+⚠️ **Absence in one capture is not absence in the game**, and this is one
+capture, read by one probe, identified by size. It is a lead, not a finding. But
+it is the first thing in F6 that is *visible*, *port-side*, and *checkable by a
+person in seconds* — which is what this whole exchange has been missing.
+
+## What did NOT work, recorded so nobody repeats it
+
+I tried to isolate the two sweeps visually by differencing title frames at
+several `--time` values. **It failed and the output is not evidence**: at those
+instants the whole title is still animating — logo, effects, copyright — so the
+difference is the entire screen rather than the sweeps. Frame-differencing
+isolates motion only when everything else is still, and during a build-in nothing
+is.
+
+## The unit, and it is one question for a person
+
+> **On the real game's title screen, is there ONE light streak sweeping across,
+> or TWO travelling in opposite directions?**
+
+Pass for the port as it stands: two. If the game shows one, `pteff03a` is drawn
+here and should not be — and an extra glow arriving at t≈108 is a very good
+candidate for *"the glow starts too early"*.
+
+**Not covered:** the start time of `pteff03` itself, which is still open; and the
+parent-alpha question, still 🟡.