# Capital-ship placement — does the `e106` result generalise? (WIP, 2026-07-31)

**Status:** 🚧 **WIP, time-boxed session.** Two results so far: a static audit across all
22 stage containers (done, below) and a first in-mission F10 capture run in Stage 02
(done — three capture logs, but **no capital-ship part correlated**; see "Open").

Context: [`BACKLOG.md`](BACKLOG.md) — "Capital ships assemble wrong in the viewer",
reported 2026-07-30. The oracle and the correlator already exist
([`ship-placement-runtime-capture.md`](ship-placement-runtime-capture.md)); the open
question is whether the rules derived from the one validated ship (`e106`, Stage_S01)
hold for other classes.

## 1. Static audit across all stages (offline, reproducible)

```
cargo run --release --example ship_audit -- ../sylph_extract/hidden/resource3d
```

87 lines of output, of which:

- **Only two OUTLIER lines, and they are the same ship twice**:
  `Stage_S03`/`Stage_S27`, `f002_bdy_05` centroid `[-1398 6251 918]`, `dist=6540`
  vs a cluster spread of `1071`. Every other assembled ship in every other stage
  has all parts inside its own cluster.
  → **The user-visible breakage is NOT a gross static-placement outlier for most
  classes.** Whatever is wrong in the viewer is either subtler than "part flung far
  away" (wrong rotation, wrong mirror, missing part) or lives in the viewer, not in
  `assemble_ship`. `f002_bdy_05` is a genuine, separate, reproducible static bug.
- **MULTIKEY**: joint tracks with more than one keyframe, which `read_trs9`'s
  single-key read does not model. Recurring rigs: `e_rou_f104` (3), `e_rou_f105` (2),
  `e_rou_f106` (2), `e_rou_e102` (6), `e_rou_e108_Missile_open` (2), `e_rou_e501` (1),
  and the `e901` boss with 2–15 tracks per pose. Several of these (`Missile_open`, the
  `e901_attack*` poses) are obviously *animation* and harmless for a static pose; the
  plain hull rigs `f104`/`f105`/`f106`/`e102` are **not** obviously animation and are
  the best hypothesis for a class-specific assembly error. ❔ **HYPOTHESIS — not
  verified.** `e106`, the one validated ship, has **no** multikey tracks, which is
  exactly how a rule that only works for single-key rigs could have passed unnoticed.

Raw audit output is reproducible with the command above (not checked in; it is
deterministic from the disc).

## 2. First in-mission capture run (Stage 02)

New tool: [`tools/re-capture/ship_capture_session.sh`](../../tools/re-capture/ship_capture_session.sh)
— one blocking session (per the session-lifetime rule): boot → Stage 02 in flight →
N× {screenshot, F10, small yaw}. Each F10 writes its own
`xenia_ship_capture_NN.log` next to the binary.

Run 2026-07-31, 5 presses requested:

- **Boot to in-flight took 24 s** (`skip_intro.sh` skipped the movie at 1 s and 6 s,
  title at 11 s, HUD shield bar at 24 s) — much faster than the ~100 s in the notes.
- **3 of 5 F10 presses produced a log** (`_01`…`_03`, 2964 / 3111 / 3668 draws).
  Logs (8–10 MB each) and the screenshots are at `/sylph-home/re/shipcap/`; not
  committed for size. One screenshot is checked in as
  [`captures/shipcap-stage02-launch.png`](captures/shipcap-stage02-launch.png).
- The screenshot confirms the capture frames are real in-mission combat frames
  (HUD live, `REMAINING OB 004`, ACROPOLIS + a Destroyer labelled on screen, a
  capital-ship hull filling the bottom of the frame).

### Result: no correlation yet ❌

```
correlate_capture xenia_ship_capture_03.log Stage_S02 <id> bdy_01
```
for `f101` (ACROPOLIS), `f105`, `f106`, `e105` reports *"no draw matches any LOD
(culled/off-screen?)"* for essentially every part — only two speculative LOD tries
(`f101_bdy_03` vcount 90 `[l]`, `e105_wep_01` vcount 60 `[l]`) and **zero accepted
matches**.

That is a **negative result, and it is not yet explained**. Facts collected:

- The capture is not empty or degenerate: 3668 draws in `_03`, top shaders
  `0xDA51B0745ABF85D2` (1258), `0xE0BAFB4F520FE441` (1091), `0xEEA84C59D7F95371` (770).
  None is the `e106` ship-shader hash from the 2026-07-26 capture; the F10 path does
  not filter by hash, so this alone is not the cause.
- Large vertex counts *are* present (3024, 2772, 1736, 1612, 1240 …), so capital-ship-
  sized geometry is being drawn.

Candidate explanations, **untested**:
1. the Stage-02 capital ships on screen are drawn from LOD/damage variants
   (`_d00`, `_m`, `_l`) whose vcounts the correlator's variant list does not cover;
2. the position-validation step rejects otherwise-correct vcount hits (the capture
   dumps ≤64 positions — a set-membership test against the wrong variant fails);
3. the ships in view at launch are drawn by a *different* draw path than `e106` in
   Stage_S01 (e.g. instanced/batched), so no single draw equals one part.

**First step next session:** take the largest few vcounts in the capture and ask which
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.

## 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.