re: the Stage-02 capture drew no capital ship at all — invert the match, then control range

Inverting the capture↔part question (invert_capture over one container,
vcount_index over all 166) identifies every large draw in the 2026-07-31
capture: the player's own DeltaSaber (10891 verts), its weapon packs, the
backdrop and particles. Of f101/e105/e106 only 1-3 of 15-37 resources have a
drawn vcount, each a 44-225-vertex far-LOD/effect piece whose count collides
with dozens of unrelated resources.

So the zero-correlation was not an LOD-list gap, not over-strict position
validation and not a different draw path: the ships were too far away to be
drawn. approach_capture.py flies at a locked capital ship and presses F10 per
range band, stamping each capture with its distance.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/re/ship-placement-capture-generalisation.md

@@ -89,12 +89,65 @@ Candidate explanations, **untested**:
 decoded part in `Stage_S02.xpr` has that count (invert the match), instead of asking
 per-part whether a draw exists. That distinguishes (1)/(2) from (3) immediately.
 
+## 3. The inverted match — the ships were never drawn (2026-08-10) ✅ explained
+
+The inversion was run and it settles the negative result. Two new tools:
+
+```
+cargo run --release --example invert_capture -- <capture.log> Stage_S02 [top_n] [--ship f101]
+cargo run --release --example vcount_index  -- ../sylph_extract/hidden/resource3d <capture.log>
+```
+`invert_capture` asks, of the capture's own vertex counts, which resource in one stage
+container has that count; `vcount_index` asks the same across **all 166 containers**
+(5480 resources), so a draw whose geometry lives in `Common.xpr`, a `rou_*` weapon pack
+or a `DeltaSaber_*` player-craft pack is identified instead of coming back "unknown".
+
+On `xenia_ship_capture_03.log` (3668 draws, Stage 02):
+
+| capture vcount | draws | what it is |
+|---|---|---|
+| 10891 | 28 | **`DeltaSaber_T:f001`** — the player's own craft |
+| 6000 | 14 | `Stage_S02:n006_02` — backdrop |
+| 1096 / 1008 / 841 / 215 / 127 | 14–112 | `rou_f001_wep_*` — the player's weapons |
+| 417 / 279 / 201 / 167 | 104–448 | `Base:j00*`, `ptc_pack:*` — HUD/particles |
+| 8 / 4 / 3 / 1 | 317–590 | particle quads |
+
+- **Not one capital-ship hull part appears.** Per ship: `f101` **1 of 15** resources had a
+  drawn vcount (`f101_bdy_03_l`, 90 verts), `e105` 3 of 37, `e106` 3 of 34 — and each of
+  those hits is a 44–225-vertex `_l`/`_b` piece whose count also collides with dozens of
+  unrelated resources, i.e. probably not even the ship.
+- The 3668 draws span **~14 frames** per F10 press and use only **10 distinct vertex
+  shaders**, and the player's own craft is captured at **full detail with its `c0..c2`
+  WVP rows** — so the capture path itself is healthy and unfiltered.
+- The screenshot ([`captures/shipcap-stage02-launch.png`](captures/shipcap-stage02-launch.png))
+  agrees once read carefully: the hull "filling the bottom of the frame" is the **player's
+  own craft** in the chase view. The nearest contact on the HUD is a wingman's engine trail.
+
+**So hypothesis (3) is dead, and (1)/(2) never applied.** The correlator's message
+"no draw matches any LOD (culled/off-screen?)" was literally true: the ships were far
+enough away that the renderer drew nothing of them. `correlate` additionally cannot
+anchor without the reference part, and `f101_bdy_01` was never drawn at any LOD.
+
+**The variable that was never controlled is RANGE.** New tooling closes that gap:
+[`tools/re-capture/approach_capture.py`](../../tools/re-capture/approach_capture.py)
+locks onto a capital ship (definition size-radius ≥ 150 = not a fighter), flies at it
+with navigator.py's drift compensation and CPA avoidance, firing disabled, and presses
+F10 as each range band is crossed (8000 / 6000 / 4500 / 3000 / 2000 / 1400 / 900),
+stamping every capture with its distance in `approach-bands.jsonl`. Driver:
+[`ship_capture_close.sh`](../../tools/re-capture/ship_capture_close.sh). Besides giving
+the correlator a full-detail frame, the stamped bands measure the game's own **LOD
+ladder** per part, which the reborn renderer needs anyway.
+
 ## Honest summary
 
 - ✅ Static assembly is **not** grossly broken across stages — 1 outlier ship
   (`f002_bdy_05`), reproducible.
 - 🟡 A concrete, testable hypothesis for class-specific breakage exists (multikey joint
   tracks on `f104`/`f105`/`f106`/`e102`; `e106` has none).
-- ❌ The runtime oracle did **not** reproduce on a second ship class yet. The capture
-  pipeline works end-to-end (boot → F10 → logs); the correlation step is where it
-  stops. **NEEDS-HUMAN / next session**, do not assume the `e106` rules generalise.
+- ❌ The runtime oracle has **not** reproduced on a second ship class yet — but the
+  reason is now known and is not a format or correlator bug: **the captures were taken
+  at ranges where no capital-ship geometry is drawn at all** (§3, verified by inverting
+  the match against all 5480 decoded resources). Do not assume the `e106` rules
+  generalise; equally, do not read the zero-match as evidence against them.
+- ▶ Next: run `ship_capture_close.sh` so the capture happens with a hull actually on
+  screen, then re-run `correlate_capture` on the closest band.