Sylpheed/docs/re/BACKLOG.md

RE backlog

Open items that are not being worked right now. Each entry says what is wrong or unknown, what evidence exists, and what the first step would be. Move an item into INDEX.md (with a structures/…md or a parser + test) once it is actually settled.

---

✅ SOLVED (2026-08-19) — the paint order is a runtime child list, not a table in the file

The screen object the game builds at load time holds two lists of its elements: the declaration-ordered array at +0x08, and a reordered child array at +0x30 — and the second is the paint order. Read live off the title screen and checked against the draw capture: the seven nameable elements sit at child slots 0, 6, 7, 13, 16, 17, 22, strictly ascending, in exactly the captured order. See structures/ui-screen-runtime.md.

Landed rather than left open (2026-08-19): the compositor now paints in the measured order for the two builds that have been read off the running game (the title build and the GAME ARTS/SETA/anima splash) and falls back to declaration order elsewhere. Rendering that exposed a second defect the same capture settles — kind = 0x4 elements are motion-trail ghosts, absent at rest — and the title now composites correctly (captures/title-composited-measured-order.png). Disc-gated test, checked both ways. The Bevy viewer's UI Screens browser calls the same ui_layout::compose, so the fix reaches what a person actually looks at rather than only the CLI's screen render — checked in iso_loader.rs (compose_screen), which also keeps its element table in declaration order, so the per-element visibility toggles still line up.

Derivation found (2026-08-19): the order sorts by the word at +0x08 of the T8aD sprite header — non-decreasing in paint order on both measured screens, with no inversion, and on the splash it explains the whole permutation. See structures/ui-paint-order-key.md.

Wired into the compositor (2026-08-19) and regression-checked. compose sorts by the key for every build except the two whose measured order is hard coded. It reorders 341 of 965 builds, and a disc-gated test asserts every composite's draw list is strictly increasing in (key, declaration index). Against the two screens the corpus had already verified against the running game — the tutorial PAUSE menu and the title main menu — the new order changes 3.8 % and 1.1 % of pixels, max delta 45/255, with no layout change: only blends where translucent sprites overlap.

Still open:

• 🟡 Which order is more faithful on those two verified screens. The difference is too small to decide against the committed side-by-side oracle and no fresh framebuffer capture of either exists. First thing to check if one is taken.
• ❔ The tie-break. Two groups share a key and the game paints them in an order that is not declaration order; the compositor keeps declaration order there.
• ❔ What the field's bits mean — 0x8000/0x80a0/0xa110 look like flag words with a layer in some bits, not a plain depth. Sorting the whole word works on both measured screens; which bits carry the layer is unknown.
• ❔ A third measured permutation, to promote "holds on two" to a rule. The cheapest is a screen whose object is resident at the same time as the title's.
• ❔ 341 builds now composite in an order no capture has checked.

✅ SOLVED (2026-08-19) — _eff glows were being dropped as focused states

compose skips focused-state records, and the flag matched a trailing f in the name. _eff — this UI's word for a glow layer — ends in one. 2 458 elements matched; 54 have the base element they would be the focused version of, and the other 2 404 across 864 bundles are glows. Requiring the pair recovers 587 of them in composable builds; GP_OPTIONS went from two floating brackets to an actual window. The opt link was tried as a replacement and refuted — 221 targets, 2 suffix-matches, and the targets include pjnet_bg.rat. See structures/ui-focus-and-effect-elements.md.

✅ SOLVED (2026-08-19) — the developer-logo splash can be rendered

is_build required a .rat layout child; the splash has none (its elements name their sprites directly). New is_composable + opt-in --all on the screen commands. The splash draws 6/7 elements, glows first, in the order measured off the running game — so the second of the two measured paint orders is now checkable instead of merely recorded. See structures/ui-composable-bundles.md.

Opened by those two:

• ✅ .prm primitives are decoded (2026-08-19). Untextured full-screen colour quads: 0 of 369 has a payload child, kind & 0x10 ⟺ .prm with zero exceptions in either direction, 361/369 are exactly 1280×720 at 100 % in the corner, and the fill colour is the keyframe's fade ARGB — mostly black at some alpha, i.e. the fade-to-black / dim / flash layers. See structures/ui-prm-primitives.md. Still not composited, for the reason below.

• ✅ Element::rest() fixed (2026-08-19): the resting pose is the hold — the longest run of consecutive keyframes with an identical pose — not the longest gap. A keyframe is the start of a ramp toward the next one, so a long gap means the screen spends it arriving at the far end. Verified against the title framebuffer capture by edge correlation: plateau 0.4597 at shift (0,0), old rule 0.1511 and only after a (+3,+8) shift. Fixes six title elements that rested invisible and the fade quad that rested opaque black. See structures/ui-resting-pose.md and tools/re-capture/align_to_capture.py.

• ✅ The keyframe fade alpha is applied (2026-08-19). ARGB, multiplied on top of tint. Title composite vs the running-game capture: 0.4597 → 0.9538 edge correlation at zero shift. No-op on 4 060 of 5 200 sprite elements, hides 687 transient HUD indicators, blanks zero builds. It also exposed a defect in the resting rule — a keyframe group carries the screen's exit animation too, and the tie-break was grabbing it, which erased the word PAUSE; a run ending on the last keyframe is now excluded. See structures/ui-resting-pose.md.

• 🟡 The .prm quads are drawn, opt-in (2026-08-19). ComposeOptions::include_primitives / screen render --primitives. On the title — the one screen with ground truth — it takes mean luminance from +18 % to −1.3 % of the capture (76.30 → 63.72 vs 64.58) and mean abs diff 16.07 → 13.08. Off by default because of the item below.

• 🟡 Where a primitive paints — not in the file; measured and tabled (2026-08-19). 🔴 Refuted twice over: the declaration entry's four unread words are constant (+28=0, +36=0xffffffff, +56=0, +44 a button ordinal), and the bundle carries no data at all for a primitive — the menu build declares three and has zero RATC children for any of them. The layer comes from the game's code. ✅ But it is consistent: pteff02.prm implies a key in (0x8010, 0x8040) on both screens it appears on, pteff00.prm past the maximum on both, palogo_eff0.prm below the minimum. implied_layer_key records those, and derived_paint_order now reproduces the layer-key sequence of all three measured orders, primitives included (element-for- element on 4 of 5 bundle instances; the title differs only inside tied groups). ❔ Still open: primitives whose position has never been measured — pzeff00.prm and pceff00.prm are what wipe the 36 builds, which is why include_primitives stays off by default. A capture of any screen carrying one would close it. See structures/ui-prm-primitives.md.

• 🟡 The tie-break — refuted six ways, and its cost measured (2026-08-19). Elements sharing a layer key: on the menu and splash every tied group comes out in declaration order, which the stable sort already gives. The title is the only screen that discriminates and nothing predicts it (0x8083 ×5 paints eff1, eff2, eff5, eff3, eff4). Refuted: declaration order, RATC child order, first keyframe time, resting time, resting X/Y, and T8aD header words +00 +04 +0c +10. RATC child order is a strict improvement (7 misplaced positions instead of 9, and it recovers the logo grouping) and is exact on the other two screens — not adopted, because on the one screen that can tell them apart it is still wrong. What it costs, exactly: of 3 disagreeing pairs of drawn elements across all three screens, 2 share opaque pixels — ptlogo_back2eff5 vs eff3 (22 568 px) and vs eff4 (32 395 px). The residual is one element's blend on one screen, and it is pinned by a test. The third pair (ptlogo2 vs ptlogo_tm) overlaps by bounding box but shares no opaque pixel; a box test called it a defect and the alpha says otherwise. ✅ Fourth and fifth screens measured (2026-08-19), from GP_SAVE_LOAD, reachable now that the Canary threading fix makes the menu dependable. The 9-element slot-list header is EXACT under the derived rule — two tied groups both in declaration order, unkeyed .prm last — and it is the first screen outside GP_TITLE.pak, so it confirms the rule rather than being fitted to it. The 13-element save/load frame differs in exactly the two known ways: unkeyed pfbase.tbm backgrounds paint first (now covered by implied_layer_key), and the 0xb100 group of four paints 10,11,8,12. 🔴 Refuted: the tie-break is not kind. "Descending kind" reproduces 10,11,8,12 exactly but fails both title groups. Seven candidates refuted now. 🔴 Attempted 2026-08-19 and blocked: advancing past the title is intermittent — 1 success in 3 attempts, same binary, same profile, same procedure. ✅ And now diagnosed one layer deeper: the title does act on Ⓐ — the press spawns a slot-(1F) loader thread (exactly once per run, at the keydown, never in a run that got no press). In the successful boot that thread immediately reads six paths from the on-disc cache and the menu appears; in a failed boot it starts and issues no file I/O ever. So "the title ignores Ⓐ" is withdrawn — the loader stalls. 🔴 Refuted as the cause: the cache-flush crash. All four of today's runs have zero GUEST-THROW, CRASH DUMP and Access Violation; the guest stays alive and polling. ✅ And now measured to the bottom: with kernel logging finally on (LOG_MASK=12 LOG_LEVEL=3 — the scripts' log_mask=13 had Kernel disabled, which is why no boot log ever held a kernel call), a captured failure shows the handler doing everything right — XamUserGetXUID, NtCreateEvent, ExCreateThread(entry=0x821748F0, CREATE_SUSPENDED), NtResumeThread — and the thread then never executing: zero kernel calls of its own, and 00:00:00 host CPU time while the process runs at 546 %. A spinning thread burns CPU; this one never ran. A lost resume is a race, which is the first explanation that fits the ~1-in-3 success rate. ✅ LOCATED AND FIXED (canary a60fe7d11): threading_posix.cc publishes a suspended thread's state_ and its suspend_count_ in two separate lock scopes, and Resume() waits only for state_ before testing if (suspend_count_ == 0) return false. A resumer in that gap drops the resume; the thread then waits on the count forever. The Linux XThread::Resume discards the false, so the guest saw success. Fixed by publishing both under one lock and waiting without releasing it. On the first clean boot after, the loader thread is the caller on 20 kernel-call lines with 4 ResolvePath reads — every failure before had zero of both. 🟡 Still to show: that boots now reach the menu reliably. The post-fix boot is confounded — skip_intro.sh's title test has been wrong twice (an absolute pixel against the wrong surface size, then screen_id.py matching the SQUARE ENIX logo). Now tools/re-capture/is_title.py counts the green Ⓐ glyph: 0 px on the logo, 1520 on a real title. A before/after reliability count over several boots is the remaining work. See canary-scripted-input-traps.md.

• ❔ Blend mode. Everything is straight alpha-over. The near-white flash quads (0xf0ffffff) and coloured ones (0x60ff0000) may be additive. The title capture cannot separate the two — its resting elements are all 0xffffff. A screen with a coloured primitive, captured, would.

• 🔴 What marks a focused state in the file — NOT the declaration entry (2026-08-24). Swept disc-wide and asserted: 54 name-paired focused/base pairs, all 54 with identical kind (all 0x0), no bit ever set on the focused entry and clear on its base, and the only words of the 60-byte entry that ever differ are +48/+52, the pivot. The naming pairing is not standing in for a field — there is no field. ❔ Still open: the .rat record, the RATC child stream, or the game's code. See structures/ui-rat-layout.md.

• 🔴 What makes a bundle a screen rather than a fragment — not the header (2026-08-24). Swept over all 2 859 composable bundles: no bit of the flags word at +0x10 labels a screen (best is bit 13 at 44 % full-screen against a 12.8 % base; the commonest bit is set on 91 % of everything). The population really is mostly fragments — element counts min 1, median 2, p95 23, max 56, and only 365 carry a full-screen element — so the separation is shape, or which bundle references which, and the PAK cannot answer the latter directly because its entries are name-hashed. ✅ By-product: the header is not dead space. +0x18/+0x1c are the design resolution (1280/720 on 98.7 %, asserted), and ✅ +0x08 is the animation length — checked against the keyframe times, which it bounds in 2 313 of 2 313 bundles and is attained by 444, with the ratio peaking at 1.0 rather than near zero (that histogram is what rules out a vacuous bound). 🟡 +0x04 (0x3C0000/0x1E0000 = 60.0/30.0 in 16.16) stays amber: the only supporting evidence is that the twelve 30.0 bundles cap at +0x08=30 while the 2 843 60.0 ones reach 1 440. ❔ +0x0c and +0x10 unexplained. See structures/ui-rat-layout.md.

• 🟡 What opt links — a record→record reference (2026-08-24, measured disc-wide and asserted). All 1 467 links reachable from a declaration table resolve to a RATC child of their own bundle, all are .rat → .rat, none dangle, none self-link. 1 076 (73 %) are the <stem>f focus pattern; the rest are chains between effect records (px_bunk_eff01 → pjex_eff → pjex_eff07), which is also why only 227 targets are declared elements — the middle of a chain is, the end is not. So focus is the commonest use, not the meaning. ⚠️ Coverage: 18 718 raw opt tags exist against 1 467 classified — opt_link reads the first tag of a declared element's record, so ~92 % of occurrences sit deeper in the chains and are untested.

The investigation that got here follows, kept in full because most of it is refutations that were worth the cost.

Where the wave / spawn scheduler lives — the counter is not a roster

Raised by the user 2026-08-24, and it reframes the whole REMAINING OB line of work. A mission does not have a fixed enemy count: the number rises as waves arrive and falls as they are destroyed. So the thing to find is not a list of objectives but an algorithm with parameters — what spawns, where, when, and on what trigger. That also explains every negative so far: a per-entity flag search cannot find a schedule.

Places searched so far:

• ✅ hidden/MiscBin.pak — new to the corpus. 11 REGN + 11 MCOL objects, none name-resolved. REGN's header is now decoded: a per-map uniform spatial grid (bbox, cell size, 5³ or 10³ cells), self-checked 11/11. Its four data sections are unread — the 49 KB object is the cheapest way in. ✅ Section 3 decoded: one 8-byte (count, offset) record per cell followed by 32-byte payload records, payload at align16(index end) — 11 of 11, one record per occupied cell. ✅ And the container is a serialised object graph: every object carries a POF0 pointer-fixup table at exactly header[0x04] + 16 (11 of 11), which is why the internal offsets are absolute file offsets. 🔴 Two payload readings refuted by generalising from the one object they were fitted to (a "bounding-sphere radius" float, and "leaf arrays of count × 4 bytes"). The payload is float-dominated and otherwise ❔. See structures/regn-map-grid.md.

• 🔴 hidden/DefTables.pak is NOT it (checked 2026-08-24). The three unnamed schemas are more model/render tables in the same vocabulary as the named ones — 7e66225f (283 objects) carries RenderFrameModel, FrameAnimLength1st, FrameAnimLoopLength, IsPlayerSE; 634a80ae (183) adds DissolveDistanceMin/Max, RootSEAttach, EnumNodes; a6d68fa1 (138) has no explicit fields at all (defaults only).

• 🔴 The 40 XML entries are XPR2 build manifests with the developers' own source tree — machines\rou_e104\objects\*.xbg, …\images\*.bmp, D3DFMT_DXT1_SRGB. Tempting as a name source for the unresolved hashes, and it does not work: of 82 names × 9 patterns, the only hits are 16 that were already resolved under the known LOD_Frame_*/LOD_Parts_* convention, and the raw source paths hash to nothing in any of the 16 514 TOC entries. The on-disc keys are not the source paths.

• 🔴 STAGES = Static.slb is a false lead. It is a field of the sound table; .slb is an XACT sound bank (structures/sound-slb.md).

• ✅ FOUND — it is the GP_MAIN_GAME_<lang>.pak unnamed objects. Sweeping the 811 unnamed entries by schema turned up schema 3c9ae32e, the per-stage definition record: one per stage (Stage_S01.xpr … Stage_S29.xpr), naming that stage's background, resource package, collision set, message set, nameplates, MapMesh/MapPath, and — the point — its EnumerateSquadron = UnitGroup_S<NN>.tbl. stage\UnitGroup_S02.tbl (0x019fd129) is the Stage 02 roster: 112 records, 112 squadron IDs (TCN001, ADN101, ADT102, …), and a field vocabulary of FormationID / AIID / SideID / Count / DisableInterval plus the unit model (UN_e010_ADAN_Attacker_S, matching our XBG7 names), the MessageSet_*, and the pilot character. DisableInterval is the first direct evidence of the timing knob. Same pass also settled MapPath = test.rgn → the REGN objects. See structures/stage-definition-table.md. 🔴 Refuted along the way: the 16-byte record key is not the squadron ID's name hash (0 of 112).

• ✅ UnitGroup is fully decoded (2026-08-24). Container and field semantics in structures/unit-group-table.md, tool tools/re-capture/unitgroup.py, Stage 02 dump committed at data/unitgroup-s02.txt. A squadron record is Count member tuples — (unit model, message set, n, identity/nameplate) — followed by five named fields Count / SideID / AIID / FormationID / DisableInterval. Validated corpus-wide by two independent self-checks, each 1160/1160 across all 28 stage tables: the Count*4+5 length identity, and agreement with the file's own Enumerate_Squadrons roster. 🔴 Two refutations recorded: the record key is not the squadron-ID name hash, and an earlier "109/111" reading of the squadron-id string base was an artefact of the uniform 7-byte id stride (it shifted every name by three).

• ✅ The rest of the mission-parameter layer is decoded (2026-08-24) — structures/stage-mission-tables.md, tool tools/re-capture/stagetbl.py --follow S02. The real stage record (the one dumped earlier was the _Test template) splits a stage into Phase_1..3 blocks and names Route_S<NN>.tbl, SUBObjectiveSettings_S<NN>.tbl, AIParams_S<NN>.tbl, FormationSet_S<NN>.tbl, nameplate_S<NN>.tbl and more. Route_S<NN>.tbl is the arrival schedule: records named Route_<squadron>_p<phase><kind> holding time-stamped keyframes (time, quat x4, pos x3), tying a UnitGroup squadron to a phase and a path — self-checked FrameCount*8+1 on 1449/1449 route records across 28 stages. AIParams carries directly portable combat tuning (firing/guard/muster ranges and 14 manoeuvre weights per profile). 🔴 Refuted: the 8-value frame is not universal — Formation_Fleet_01/02 use 136 and 4 values per frame.

• ✅🔴 The arrival timetable is found; the entity-count proxy is refuted (2026-08-24) — mission-wave-arrivals.md. Route records' first-keyframe time is the arrival schedule, measured from the start of that route's phase (phase 2 has all 37 routes at t=0). Stage 02 phase 1: 25 at t=0, then 3/3/3/2/1 at t=90/120/170/210/240. 🔴 A live count of 0x820af030 entity records is FLAT at 116 for 210 s — no arrivals visible. 🟡 116 is exactly Stage 02's roster member count, suggesting one pre-allocated record per member (n=1, NOT promoted; the refutation needs another stage's save, which we do not have — only slot 01 / Stage 02 exists). ❔ Still unmeasured: whether the timetable's t is frames or seconds.

• ✅🟡 Motion-independent liveness probe works; n is probably craft-per-member (2026-08-24) — mission-liveness-probe.md. Enumerating by definition pointer instead of by motion removes the ±10 noise (monotone 298→280). The hunting pilot does kill (hull crossing at t=57s). 🔴 "No births in 164 s" does NOT separate the wave models — everything is pre-allocated, so an arrival must be a STATE CHANGE, not an allocation. 🔴 n = craft-per-member is WITHDRAWN (re-tested 2026-08-24): sites really are entities 1:1 (all same-unit gaps ≥0x1000, hull plausible 298/298), so the confound was not the explanation — and with it gone, DeltaSaber_T, Player and Acropolis all come out at exactly 2× sum(n). An undershoot is explainable by phases; an overshoot is not. n back to ❔. Formation slot count also rejected (630 turret slots vs 214 live). ✅ Side result: FormationSet FrameCount = slot count. 🔴 A direct pointer link between them is REFUTED (2026-08-24, roster-to-craft-link.md): 0/116 roster records point at a craft base and 0/300 craft point at a roster base. They sit in distinct regions (0xbc372c00–0xbc9bc720 vs 0xbdb2fd80–0xbdcd1d80). Craft count varies run to run (296/298/300), so it must only be compared WITHIN a run. ❔ Still open: the expansion rule. Four candidates now dead — Count, n, formation slots, head pointers. ✅✅ SOLVED (2026-08-24): the link is a pointer at roster_base + 0x08. The delta histogram spiked at +0x08 with exactly 300 hits for 300 craft. Verified on something a coincidence cannot survive — each side's unit type resolved by a different chain (craft via def pointer +0x130, record via +0x04 name chain) — agreeing 300/300, 0 disagreements, fan-out [(1,300)]. Fan-in: only 41 of 116 records have craft (2×24, 4×1, 8×4, 18×12 = 300). ⇒ an arrival is craft appearing for a record that had none; a kill is that count decreasing — both attributable to a named squadron, hence to a route. ✅ Blocker downgraded (2026-08-24): the baseline DOES reproduce — two more runs give 116 roster records flat from t=0 (not a load race) with craft declining 300→288 and 296→280, so losses are observable. Raw hits == distinct VAs (116 == 116), so the VA-aliasing explanation is 🔴 refuted too. 🟡 The single 42/170 run stays unexplained; rule adopted: discard a run that disagrees with 116 rather than interpreting it, and reproduce any finding in ≥2 runs.

• ✅🔴 Six runs, no arrival — plus an accidental control (mission-arrival-watch.md, 2026-08-24). Deployment reproduces byte-for-byte (116 records, 300 craft, 41 deployed, strengths 2×24/4×1/8×4/18×12). ✅ Losses require the player: an unpiloted run held at exactly 300 craft for 240 s / 22 samples, vs 16–20 losses in each piloted run — so NPC crossfire destroys nothing on its own. 🔴 Zero 0→n arrivals in either condition, ~15 min cumulative. 🔴 Prime suspect REFUTED (2026-08-24): the clock is running — mission-clock-advances.md. With no pilot, 286 heap words advance linearly, a large cluster in lockstep at 16.5/s, which is the emulator's known ~14–19 fps. 🟡 New leading explanation: the runs were far too short in GAME time — at ~55% of wall-clock, the longest 240 s run reached only t≈132, past the t=90/120 route entries but nowhere near t=170/210/240. ✅🔴 Long run done (2026-08-24): per-record tracking works — watched ONE turret squadron fall 18→14→12→10→8→6→4→2 over seven loss events while deployed held at 41. 🔴 Still no arrival at 234 s wall (≈129 game-s), past both t=90 and t=120, so the "too short" explanation no longer covers those (it still covers t=170/210/240; the run was cut at 240 s by the turn timeout, not the planned 330 s). 🟡 Sharper hypothesis: the squadron ended at 2, never 0 — no squadron has ever been eliminated in any run, so the trigger may be elimination, not damage. 🔴 Elimination test UNRUN (2026-08-24): the hunting pilot died at t=83 s with the squadron at 14. ✅ But the player's own record hit 2→0 — first n→0 ever seen, so the signal does register elimination (no arrival followed; weak, it was the player not an enemy squadron). ✅ KEY: after player death the mission is frozen — 288 craft, zero losses, zero arrivals for 220 s / 18 samples. The usable window is player survival, not probe duration. 🔴 Harness bug found+fixed: a sed had stripped the probe args, so every derived probe ran on defaults — the previous "cut by the turn timeout" claim was wrong (it hit its own 240 s default). ✅🔴 DONE + REFUTED (2026-08-24): SYLPH_KEEPOUT=1400 gives a pilot that kills and survives (hull 1500, asset 100 %, 8 losses). An enemy squadron was eliminated — e007 Turret 2→0 at t=163 s, deployed 41→40, first ever — and no arrival followed in ~90 s of valid observation (two further losses in that window prove the mission was live). ⇒ "a wave is released when a squadron is wiped out" is refuted; event-gating generally is not (thresholds, objectives, specific squadrons untested). 🔴 Guest stalled at ~t=255 s — last 400 pilot lines have 1 distinct speed vs 236 in the first 400 — so trailing flat samples in ANY earlier run may be a frozen guest, not a quiet mission. Probe now carries a frame-rate tick witness printing *** GUEST STALLED ***.

• ✅🔴 The stall witness WORKS and is now mandatory (guest-stalls.md, 2026-08-24). Validated against the pilot's independent telemetry (35 distinct speeds all run, 1 in the last 400 lines; witness flagged t=27 s). It immediately discarded a run that would otherwise have read as "no arrivals across 313 s" — worthless, the game was frozen for 90 % of it. Rule: a stalled run is discarded, and every write-up must state the witness result. 🔴 Stalls are frequent and early — last three long runs stalled at ~255 s, 83 s and ~27 s. 🟡 Leading suspect: the probe itself — it reads the whole 32 MB heap plus ~300 preads every 12 s while lavapipe renders, and AGENT.md warns a full scan competes for every core. ✅ CONFIRMED (2026-08-24): the probe was causing the stalls. The no-probe control ran 300 s clean — 211/257/250/241/200 distinct speeds per 60 s window, no decline — against probed runs stalling at 27/83/255 s and ending on 1 distinct speed. The instrument was degrading what it measured, exactly as AGENT.md warned. Control is n=1: acted on, not proven. ⚠️ Consequence: every "no arrival" result was collected under a struggling or frozen guest — none is as strong as written, and the arrival question needs re-running with cheap sampling before silence means anything. ✅ Fix VERIFIED (2026-08-24): wave7_probe.py (enumerate once, then poll only the hull word per known craft, ~1.2 KB/sample, rescan every 90 s) ran 0 stalled samples and produced 19 losses vs 8 — starving the emulator had been suppressing the activity the probe existed to watch. 🔴 Its one apparent arrival (0→2 at t=259 s) is FLICKER, not a wave — it reverted to 0 fifteen seconds later, and the same log shows a record reading 13 then 14 with no event printed because only decreases were surfaced. Count stands at 0 confirmed arrivals in 11 runs. Probe now prints every increase and requires an arrival to persist across 2 samples.

• ✅🔴 Run 12 (2026-08-24): persistence rule works; stall witness does not. 16 losses / 290 s with a bound pilot, 0 confirmed arrivals (twelve runs now). One increase surfaced (13→15) and correctly not counted — exactly the flicker that nearly became "first arrival". 🔴 The single-word tick witness gives FALSE POSITIVES: 13 samples flagged GUEST STALLED while recording losses in the same samples, which a frozen guest cannot do. Cause: it took the first word in a 4 MB window with a plausible rate; intermittent counters pass that test. timer_probe had already solved this (286 candidates, modal rate ~17/s) and the lesson was not carried over. Fixed to a majority vote over the modal-rate cluster, plus explicit RUN UNVALIDATED when no witness exists.

• ✅🔴 Run 13 (2026-08-24): the vote is better, the threshold was wrong, and freezes persist. Graded output (11→9→7→4→1→0 of 31) is coherent, and the drop to 0/31 at t=183 s coincides exactly with the last loss — a real freeze, 106 s of nothing after. 🔴 But "<half = stalled" marked the WHOLE run stalled including samples where craft died: 11/31 advancing is healthy. Cause: the modal cluster was 93/s, not the ~16.5/s frame rate — bursty subsystem counters. Fixed: prefer the 8–40/s frame-rate band, stall only when ZERO advance.

• 🔴 Witness attempt 3 still unreliable (2026-08-24): only 5 candidates in band, and 0/5 moved in samples where craft died — a real 24/s counter cannot miss 15 s. Cause was mine: the candidate search had been narrowed to 4 MB when the witness was bolted in, while timer_probe searched the full 32 MB and found 286 with a clean ~17/s cluster. Fixed: full-region search once at startup + warn when <8 witnesses.

• ✅ WITNESS VALIDATED (2026-08-24, 4th attempt): full-region search gives 6500 candidates → 32 witnesses at 21/s, and the flags have zero contradictions with the loss data (the one loss is unflagged; every flagged sample has no losses). That is the check the three previous versions failed.

• 🔴 The freeze is now THE blocker. Onset across runs: 27, 45, 83, 183, 255 s (median ~83 s) — usable window is 1–4 min and unpredictable. This run froze at 45 s with 1 loss, useless for arrivals despite a working instrument. ⚠️ Being honest: the "cheap" probe still reads 32 MB at startup + 32 MB every 90 s, and the new calibration added two more 32 MB reads — the 45 s freeze came right after it. 🔴 The trim BROKE the witness (17 candidates, 0/17 on every sample of a run with 13 losses) — reverted; two 32 MB reads once at startup is the price of a working witness. ✅🟡 Instead, disabling the periodic rescan LARGELY removes the freeze — corrected from "removes" after more runs: clean at 210/240/300 s but frozen at 60 s on a fourth. Tally — heavy probe froze at 27/45/83/183/255 s; cheap+rescan at 183 s; cheap, no rescan: 3 of 4 clean past 200 s. A large probability improvement, not a fix. Practical rule: run, check the witness, discard frozen runs (3 clean of 5 now: clean 210/240/300, frozen 60/90).

• ✅ BLOCKER REMOVED (2026-08-24): the emulator survives BETWEEN Bash calls in a turn (checked: 611 s elapsed, still running after the launching call returned), so observation is not capped by one call. tools/re-capture/attach_session.sh attaches pilot+probe to a live mission and attaches CHAIN. Cumulative 435 s verified-live on one mission (300 s clean + 135 s of an attach before it froze), craft 300→258 (42 destroyed), 0 confirmed arrivals — covering route entries t=90/120/170/210; t=240 missed by one second. 🟡 Coverage assumes the 55 % wall→game factor; the witness has measured 8–24/s across runs, and at the low end the same window covers only ~117 game-s (t=90 only). Pinning the tick rate would make this sharp.

• ✅🟡 (2026-08-24) The 42-anomaly is STAGE 01, and it hands us two results. Rescans stuck at 42 (not a load race); live RAM holds UN_S01_Asteroid_cmesh_* and UnitGroup_S01.tbl with S02 absent — the launch sometimes loads Stage 01 (the discard rule caught every such run). ✅ That supplies the refutation test recorded as blocked for lack of a second stage: S01 static 42 members / 13 units vs live 42 records / 13 definitions, composition 20/20, 6/6, 5/5, 2/2 — one record per member now holds on two independent stages. 🟡 Route times are almost certainly FRAMES: S01 phase 2 has t=1500/1800/2100, which as seconds is 25–35 min into one phase (implausible) but at 30 Hz is 50/60/70 s. ⇒ S02's t=90…240 would be 3–8 seconds, all before the probe's first sample (~25 s in) — explaining every null result, and consistent with deployed=41 already at t=0. Test: sample at flight+2 s vs flight+30 s — a reordering of the probe, not new decoding.

• ✅🔴 (2026-08-24) Early sampling done; still flat. early_probe.py cuts setup from ~25 s to 0.5–0.8 s (no calibration, no labelling, bytes.find scan). At flight+0.8 s deployed=41 already, flat for 252 s (only 41→40, one squadron wiped). 🔴 The --wait variant caught the READY ROOM, not flight — the roster is built before take-off, so waiting for it is not catching mission start; that window (deployed=39, craft=276, flat 200 s) tests nothing. 🟡 But ready room 39/276 vs flight 41/300 suggests deployment is a single step at TAKE-OFF, not a schedule unfolding in-mission (different runs, so suggestive only). Next: one ~400 s run spanning ready room → take-off → flight to catch the 39→41 step in one continuous series.

• ✅🔴 (2026-08-24) DEPLOYMENT IS RESOLVED AT MISSION LOAD. One continuous series, 64 samples over ~380 s from roster-appearance through the ready room, take-off (IN FLIGHT at +47 s) and flight: deployed=41, craft=292, zero changes throughout. 🔴 My own "deployment happens at take-off" is withdrawn — the 39/276 vs 41/300 gap was cross-run variance; within one run there is no step. ⇒ Stage 02 phase 1 has NO observable in-mission arrival: 41 of 116 records are deployed before the ready room ends, and nothing changes in the ready room, at take-off, or in up to 435 s of verified-live flight with 42 kills. Route times most likely encode fly-in animation timing applied at load, not release times (frames reading: S01's t=2100 → 70 s at 30 Hz). ❔ Phases 2 and 3 are entirely untested — every run has stayed in phase 1, and phase advance was never located; a phase transition is now the most likely place an arrival could exist.

• 🟡 (2026-08-24) ANSWER: enemies come into play PER PHASE, deployed at phase start — mission-phase-deployment.md. Static: phase 1 = 37 squadrons / 42 members, phase 2 = 36, phase 3 = 49. Dynamic: deployed = 41 from the first instant, never changing. 41 vs 42 — the deployed set IS the phase-1 roster. That makes everything coherent: all 116 records exist at load but only the current phase holds craft; no arrival was ever seen because phase 1 never completed; route times are within-phase fly-in timings, not release times. ⚠️ The off-by-one is unexplained and recorded, not rounded away. ❔ Single remaining question: what advances a phase. It is directly observable (deployed would jump), did not happen in 435 s with 42 kills, and SUBObjectiveSettings names 9 objectives but carries no trigger. Unsearched: StageMessageSet_S02.tbl (never resolved) and the PE in guest RAM.

• ✅🔴 (2026-08-24) Message tables searched; trigger NOT there. ✅ StageMessageSet_S02.tbl resolved — prefix is message\, not stage\ (closes a long-standing ❔). ✅ message\UnitMessageSet_S02.tbl has CrewCount + PresetMessage_Phase1/2/3 — a THIRD independent table family organised around phases, after the stage record and route names. 🔴 Refuted: ScriptMessage_S02_msg.tbl's promising third field is a radio delivery category (None 105, Emergency 33, Killed 5, Noise 5; arg is 1 in every record), not mission control flow. ❔ No table anywhere carries a phase-advance condition — everything found is a consequence of the phase, never its cause. ⇒ the logic is in code, and default.xex is encrypted on disc, so the decrypted image exists only in guest RAM. That is the honest end of the static search.

• ✅🟡 (2026-08-24) The mission script is READABLE — and phase 1 never advanced because the pilot killed the wrong things. mission-objectives-text.md. ✅ language\*_local_string.tbl is IXUD, UTF-16-BE (prefix language\, a third convention) — that encoding is why earlier dumps looked like garbage. ✅ Stage 02's nine sub-objectives in words ("You destroyed all enemy fighters!", "You sunk all enemy warships!", "You destroyed all enemy cruise missiles!"). ✅ Phases confirmed twice over: the guide script is three acts — marked attackers → warship engine/weapons/shield → missiles — matching the per-phase rosters, with phase 3's UN_e201_ADAN_ISCMissile ×9 exactly matching SUBOBJ_013. 🟡 Phase-1 objective is stated outright: destroy the MARKED ATTACKERS (UN_e010_ADAN_Attacker_S, 4 squadrons) — but every loss line in every run reads UN_e007_ADAN_Turret, because SYLPH_HUNT/KEEPOUT were built for turrets. 42 kills were the wrong 42. Test: a pilot that prioritises e010 over e007, watching deployed jump from 41.

• ✅🚧 (2026-08-24) SYLPH_PREFER works; the blocker is now COMBAT, not RE. Preference knob added (matching units ×0.05, others ×4.0). One clean 320 s run (0 stalls): 8 turret kills vs 2 e010 — real effect (was ~1 across ALL prior runs) but weak; commitment + proximity keep pulling back to turrets, which outnumber attackers 108:16 in craft. deployed stayed 41, no advance. 🚧 Quantified blocker: phase 1 fields 16 Attacker_S craft; at 2 per 320 s clearing them needs ~2560 s ≈ 43 min of verified-live flight across many chained attaches, against a ~2-in-5 freeze rate. Everything needed to OBSERVE the advance is built and validated — roster link, liveness, stall witness, chained attaches, discard rule. What is missing is a pilot good enough to finish the objective. User's choice: (1) invest in the pilot (game-playing, uncertain); (2) accept the static answer (structure, rosters, routes, objective texts all decoded and cross-confirmed; only the trigger is inferred); (3) one 40+ min chained run betting against freezes.

• ✅✅ (2026-08-24) THE OBJECTIVES, FROM THE GAME'S OWN TEXT — pinned by tests/phase_objectives_disc.rs; TextIndex::objectives(stage, phase) already existed. S02 phase 1: "Shoot down all invading enemy fighters while watching out for attacks on the ACROPOLIS" (lose: ACROPOLIS sunk). Phase 2: "Protect the CALIBAN until it has entered the safe zone" — positional, not a kill count, so phase triggers are NOT all the same kind. Phase 3: "Destroy the interstellar cruise missiles headed for Schlos Base" (matches the 9 ISCMissile + SUBOBJ_013). ✅ [OB] = objective marker — hints say "Red mission markers [OB] indicate your targets", so REMAINING OB at 0xbdb59668 is phase-1 progress and is the right signal to watch, not deployed. Closes a loop to the first session. 🔴 Method lesson: the crate already knew this — several iterations reconstructed it the hard way; grep -rl TextIndex crates/ would have saved the detour. ❔ Minor: ixud.rs says UTF-16BE, localization.rs says LE — one comment is wrong.

• ✅🔴 (2026-08-24) REMAINING OB hunt: method works, run unfinished (remaining-ob-hunt.md). Correlate heap words against named kill events instead of scanning for a value: one e010 event cut ~8 M words to 1056. 🔴 But the probe saved candidates only at the END and the turn timeout discarded them — the exact mistake already recorded in guest-stalls.md four iterations earlier. 🔴 And the follow-up attach logged 535 s of zero losses with no stall witness, so it cannot say whether the guest was quiet or frozen. Both fixed (save per event + SYLPH_OB_RESUME=1 resume; witness carried over). Pattern worth acting on: each new probe starts from scratch and re-earns the same lessons — a shared probe harness would stick where written-down lessons have not. Needs 2–3 e010 events, i.e. the same combat limit. 🔴 SYLPH_HZ=3 refuted as a lever: it gave the LOWEST frame rate (8/s) with the most kills, so pilot polling is not the throttle.

• ✅🔴 (2026-08-24) OB hunt, second attempt. ✅ Incremental saving verified — one e010 event at t=241 s wrote 1187 candidates to disk before the turn timeout fired; session now clears the file at launch since offsets are only valid within one emulator instance. 🔴 The correlation had no value filter: survivors were float bit patterns (1044450858 ≈ 0.1f) whose integer forms differed by the loss count. Fixed — candidates must be small non-negative integers (0 ≤ v < 1000) in both samples. 🔴 The attach was FROZEN, not merely unproductive: 25 of 26 samples flagged GUEST STALLED. The witness worked; the summary just quoted "0 events" before checking it. Rule: read the witness FIRST, before interpreting what a run showed. ❔ Still no address; needs 2–3 e010 events in non-stalled samples.

• ✅🔴 (2026-08-24) OB hunt: method PROVEN, turret tracking REFUTED. With the value filter, an attach watching frequent turret losses narrowed 374 → 2 → 0 across three events — exactly how a correlation search should behave, ending in a refutation rather than fizzling: no plain u32 in 0xBD000000–0xBE000000 decrements with turret kills. Witness checked first: 12/25 samples stalled but all four events fall in the early non-stalled stretch. 🟡 The negative fits the objective text — phase 1 asks for fighters, so a marked-target counter should ignore turrets; it also rules out REMAINING OB being a general kill tally (it ignored ten turret deaths). ❔ Still needs 2–3 e010 events; one clean 220 s run produced zero.

• ✅🔴 (2026-08-24) Kill-free HUD route works; BE-u32 assumption REFUTED. ob_by_hud.py reads the counter off screen (ob_read.py) and intersects heap words equal to it — no kills needed. Four readings at HUD=4 narrowed 6156→4312, then HUD read 11 and the intersection collapsed to 0. ⇒ within 0xBD000000–0xBE000000 as big-endian u32 the counter does not exist; it may be u16/u8/LE or outside the region. Both previous hunts assumed BE-u32, so this eliminates the assumption rather than just failing. 🟡 The value went UP, 4→11, which a pure countdown should not do — candidates: wrong HUD cell, misread digits (template strip covers only 0 1 2 4 8; most samples read 00?/???), or a counter that can rise. Next: widen the scan to u16/u8 and LE, and beyond the heap — one function, no combat cost. Also extend ob_digits.png.

• 🔴 (2026-08-24) Widened to 7 encodings; run inconclusive. ob_by_hud.py now keeps a candidate set per encoding (u32be/le, u16be/le at both alignments, u8) as byte offsets. u32le is tightest at 154 vs u32be's 4452 — a hint, not a result. 🔴 HUD read 4 at every sample, so nothing collapsed; and counts were byte-identical across five samples in all seven encodings from t=136 s, which is what a freeze looks like. The probe had no witness — now added. ⚠️ Fourth probe written without one, third flat run that cannot be told from a freeze; the recurring fix is the shared harness noted earlier. Needs two HUD readings at different values in non-stalled samples.

• ✅ (2026-08-25) SHARED PROBE HARNESS built and verified (probe-harness.md, tools/re-capture/probeharness.py). Makes structural the four lessons that were re-learned in four separate probes: built-in stall witness (says UNVALIDATED when absent rather than reporting zero stalls), emit() flushes every line so a timeout cannot destroy results, baseline discard with rescan (Probe(baseline=116) refuses to start on a different stage), and summary() putting the witness first. Also provides craft()/strengths()/alive()/heap() so a new probe writes only its own logic. ✅ Verified: deploy_probe.py reimplements the deployment watch in ~40 lines vs 150, first live run clean — 116 roster, 32 witnesses at 10/s, 0 stalled, 7 losses, TSV written incrementally. ⚠️ Existing probes deliberately not ported — they work and other docs cite their results.

• ✅✅ (2026-08-25) REMAINING OB FOUND AND VERIFIED: big-endian u32 at 0xbdb59668. On the new harness, the HUD changed 4→8 and the intersection collapsed in one step to a single u32be survivor (with u16be/u8 hits being the low half/byte of the same word). Verified live: HUD 012 vs mem@0xbdb59668 = 12. Independently rediscovers the address the earliest sessions found by digit-transition hunting. 🔴 Corrects the earlier "u32be refuted" — that came from intersecting on a HUD reading of "11" which was almost certainly a misread, since ob_digits.png only has templates for 0 1 2 4 8 and misreads rather than rejects other digits. A single bad input permanently poisons an intersection; the reader's confidence scores were printed but never gated on. 🟡 The counter INCREASES: 4 → 8 → 12 in ~5 min, measured in memory. Marked objective targets are being added during the mission — the arrival question again, now with a one-word signal instead of a 32 MB scan. Next: watch this address across a whole mission.

• ✅🔴 (2026-08-25) OB address is RUN-DEPENDENT; watcher now self-sufficient. Two fresh launches: mem@0xbdb59668 = 3165285888 (MISMATCH) then 4 (MATCH) against HUD=4. The confirmation gate refused to report from the bad one — the old "recurs in ~5 of 7 runs" note is right. ob_watch.py now hunts the address on the current run when confirmation fails. ✅ HUD reader is now confidence-gated (every digit ≥0.80, margin ≥0.05 — the rule ob_read's own docstring states), closing the hole that produced the wrong u32be refutation. 🔴 OB flat at 4 for 250 s (witness clean, 0/50 stalled) while the pilot fired on 1635 of 1964 ticks at marked attackers — constant fire, zero decrements, so it destroyed none. Fire rate itself rose from 4.6% to 83% with no more kills. ❔ The earlier 4→8→12 rise is NOT reproduced — both readings were HUD-confirmed, so the rise is not a stable property of the first five minutes; recorded as unreproduced rather than explained away.

• ✅🔴 (2026-08-25) THE MISSION BLACK-SCREENS AT ~4.5 MIN — that is what ends every run. Two-segment OB watch: segment 1 clean (0/50 stalled, OB steady at 4 for 250 s); segment 2 on the same live emulator got NOT IN A MISSION. Player never died (hull 1500 throughout), pilot log stops at t=267 s with byte-identical lines, screen now entirely black (mean=(0,0,0)). This is the known pre-existing mission-end freeze, caught in the act. 🔴 Corrects "chained attaches extend the window" — the emulator surviving is not the mission surviving; ~4.5 min is a hard per-mission bound and chaining does not cross it. ⇒ Anything needing >4.5 min of one mission is not doable on this build, including clearing 16 marked fighters at ~2 kills/5 min. The freeze is now the highest-value target: fixing it unblocks arrivals, phase advance and the OB series at once. ❔ The 4→8→12 OB rise is now unreproduced in 3 of 4 runs.

• ✅🔴 (2026-08-25) Freeze: one new data point, and the INDEX was the real bug. ✅ New evidence closing the resume-spin lead from the other side: the 2026-08-25 freeze log has 0 resume was refused (vs 2447 in an older healthy-ish log) — a mission can freeze with none at all, so the warning is not even necessary, let alone sufficient. 🔴 Also refuted today: the BaseHeap::Release failed burst is not a freeze signature (routine; spans lines 1044–5210 in a log that runs 2 700 lines further). 🔴 Both were already settled in mission-freeze-resume-spin.md, as was 0xbdb59668 — that is twice in one session that existing work was redone. Cause is mechanical: INDEX.md listed 20 of 43 notes and none of the recent ones, so searching it returned nothing. ✅ Fixed: INDEX.md now has a generated table of all 59 notes with title + status and says to search it before starting. Regenerate when notes are added.

• ✅🔴 (2026-08-25) Freeze frontier: wait confirmed, but info args won't work. ✅ Verified the frozen frame's export by ordinal: the shim's (unsigned short)176 = 0xB0 = KeWaitForSingleObject (xboxkrnl_table.inc:190) — previously read off frame names, now pinned. 🔴 Corrected: the doc's "the handle is one info args away" is wrong for this binary — readelf shows 0 debug sections, symtab only (27 807 entries). Not stripped ≠ has debug info; gdb can name frames and nothing inside them. Two routes, costs recorded: (1) prologue-guided stack read of XObject::Wait's spilled this — no rebuild, keeps the oracle identical, but per-frame archaeology; (2) a RelWithDebInfo build via build-canary — makes this and all future freeze questions easy, at a full compile and a binary differing from the one every other measurement used.

• ✅ (2026-08-25) Route 1 is viable and cheap — this is in %rbx. Static analysis, no run spent: XObject::Wait's prologue does mov %rdi,%rbx at 8fbc9c, so this sits in a callee-saved register rather than a stack slot. And the binary carries .eh_frame with 127 231 FDEs (Release builds keep it for C++ exceptions), including one covering 8fbc90..8fbde2 that tracks rbx explicitly. ⇒ from a frozen thread, frame 3 + info registers rbx gives the XObject* being waited on, and x/gx $rbx → vtable symbol (in symtab) gives its concrete type — no DWARF and no rebuild needed. Revises the previous entry, which called route 1 "per-frame archaeology" and route 2 (RelWithDebInfo rebuild) the way to make it easy. Next: execute on a frozen run — two gdb commands per thread.

• ✅🟡 (2026-08-25) Wait-object read WORKS: the object is an xe::kernel::XEvent. Executed under gdb: frame 3 → rbx → x/1gx $rbx = 0x5555562db8f0 = PIE base + 0xd878f0 = vtable for xe::kernel::XEvent (+16 for offset-to-top/RTTI) — exact. Same vtable on every sampled waiting thread, different this each, so many threads waiting on different XEvent instances. No DWARF, no rebuild, as predicted. 🟡 Two caveats, both recorded not glossed: (1) this is a healthy-play snapshot (screen_id = flight), not the freeze — boot under gdb costs ~300 s and the whole thing must fit one call (a timeout kills the process group and took the emulator with it once), leaving too little to reach the ~267 s freeze; (2) the this addresses (0x7ffd…, 0x7ffc…) look like host stack, not heap, so either xenia places them unusually or rbx isn't Wait's this after unwind. Check: dump a few words at $rbx — XEvent-like (vtable, KernelState, handle) vs saved registers.*

• 🟡 (2026-08-25) Refined: TWO wait types, and the read self-checks. Re-extracting per thread (not by grep): of 18 XObject::Wait frames, 8 have [rbx] = vtable for xe::kernel::XEvent+16, 2 = vtable for xe::kernel::XSemaphore+16, and 8 hold a non-vtable mmap pointer. ⇒ waits are on XEvent and XSemaphore; "it's an XEvent" was the majority, not the whole picture. ✅ The 8 misses are the method validating itself — a polymorphic object's first word is always a vtable, so a value only counts if [rbx] resolves to a vtable for … symbol; rbx simply wasn't restorable for those frames. That also dissolves the "looks like stack" worry: 0x7ffc… is the shared mmap region (stacks and big allocations), and the vtable check, not the address range, is the discriminator. 🔴 The follow-up run adding /proc/maps classification + x/8gx never booted (EMULATOR GONE at 0s, stale emulator/lock from the prior gdb session), so that check and the frozen capture are still unrun.

• ✅ (2026-08-25) WITHDRAWN: the 8 "unrestorable rbx" reads were WaitMultiple. rbx was restored fine on all 18. The backtrace grep matched XObject::Wait as a substring, so WaitMultiple frames were pooled in and read with the wrong rule — Wait keeps this in rbx (8fbc90: mov %rdi,%rbx) but WaitMultiple keeps the XObject** array (8fbfc0: mov %rsi,%rbx), so [rbx] there is objects[0], an object pointer needing a second deref. Confirmed live: re-reading with the matching rule per frame resolves 30/30 objects across 23 wait frames, nothing unresolved — XEvent 20 / XSemaphore 9 / XTimer 1 (data/waitobj-s02.txt). XTimer was invisible before because its only thread is a WaitMultiple one. Every WaitMultiple thread waits on a pair; T78/79/80 and T64/65 are worker groups sharing a handle. 🟡 %ebp is not a usable count — WaitMultiple reuses it at 8fc158 — so the array is bounded by reading until an entry stops resolving. What survives: the object types and the self-validating read.

• 🔴 (2026-08-25) The frozen capture is STILL unrun — the freeze did not happen. Two captures in one run (200 s and 367 s of mission), and screen_id reads flight at both, plus at ~470 s with a drifting frame mean. So the labelled healthy -> frozen diff is two healthy captures, and its 20 -> 18 is three threads exiting, not a freeze. 🟡 This also questions the "~270 s black-screen" bound these runs are planned around — confound not ruled out: gdb slows the emulator (boot to title took 207 s), so 470 s wall-clock may be far short of 270 s guest time. Next: reach the freeze by its actual trigger rather than a clock, or measure guest time under gdb so the wait is set in the right units. Chaining Bash calls within one turn works and is no longer the limit — the emulator survives between calls; this run spent ~900 s across three.

• ✅✅ (2026-08-25) FROZEN CAPTURE TAKEN — and the per-thread diff is the result. freeze_waitobj.sh split into boot/watch; watch waits for the event (frozen.py + in_flight) instead of sleeping a guessed interval, and caught it first try. Hard stop, not a hitch: a frame minutes later is max_pixel_delta=0 against the capture. Same run, same mission (data/waitobj-s02.txt): 20 → 24 wait frames, XEvent 19 → 23, XSemaphore 8 → 7, XTimer 1 → 1. 🔑 17 of 24 threads sit on the EXACT object they were already on — so this is not a whole-emulator stall. What moves: T105/T67/T68 park on Wait(XEvent) and T69 on Wait(XSemaphore) having been running; T74 and T75 move off a semaphore onto an event (the only threads that change what kind of object they wait for → chase these first); T50 drops WaitMultiple(XEvent,XEvent) → Wait(XEvent).

• 🔴 (2026-08-25) WITHDRAWN: the T74/T75 signature. It does not reproduce — in run 2 they are on Wait(XEvent) while healthy and stay there. My error: the healthy state is not fixed either, so a one-sample-per-state diff cannot separate a freeze transition from ordinary variation between two instants. ✅ What survives two independent captures: T68 and T69 go from not-waiting to waiting in both runs (T69 on a semaphore, T68 on an event, both times), and the bulk of threads are untouched (17/24 run 1, 21/24 run 2) ⇒ not a whole-emulator stall now has two captures behind it. Next: repeat the capture several times inside ONE healthy run to learn which thread states are stable before reading any frozen diff as meaningful.

• ✅ (2026-08-25) CORRECTION: screen_id == flight is NOT a freeze test. The previous entry used it to rule out a freeze. frozen.py exists precisely because a frozen mission still classifies as flight (its docstring: 724 s of identical state, 212 % CPU, classifier happy). Re-testing the saved frames says that run was genuinely healthy — right, but by luck. And the "~270 s black-screen" bound those runs were planned around is not a thing: the freeze does not black the screen and keeps no clock (onsets 27/45/83/183/255 s).

• 🟡 (2026-08-25) One data point that OUR INSTRUMENT provokes the freeze. Run flew ~670 s clean with only the pilot; a heavy-CPU inducer (heavy_read.py cpu) started at 08:59:54 and it froze at 09:00:48 — 54 s later, inside the 27–255 s band. Consistent with the existing tally but n=1, not causal (confounder: elapsed mission time). ⬆️ UPGRADED to n=2 (2026-08-25): run 2 put the inducer on from flight start and froze ~96 s in (10:07:20 → 10:08:56). Both freezes sit inside the 27–255 s band; the only long clean stretch is the only window with no inducer. Contrast is sharp, confounder still untouched. ✅ Refuted en route: the I/O was never the cost — a full uncapped walk of every allocated extent is 371 MB in 0.1 s, all page cache; the expense is Python-level CPU, ~4.2 s a pass. Settle it with: alternating inducer-on/off windows within a run, several runs, compared per unit of mission time — cheap now watch is event-driven.

• 🚧 BLOCKER: t=210/240 unreachable in one turn — superseded, see above; it rested on an untested assumption that a turn is one shell call. 595 s shell cap − ~220 s boot (a ~190 s title movie that cannot be tapped through) − ~25 s startup = ~350 s observation ≈ 193 game-seconds. t=90 needs 164 s wall ✅, t=120 → 218 s ✅, t=170 → 309 s ✅ (only on a non-frozen run), t=210 → 382 s ❌, t=240 → 436 s ❌. No number of runs fixes this. Unblocking needs a decision I should not make alone: (1) a safe way to skip the title movie — it is >half the budget, and would roughly double the window to ~297 game-s, covering everything; or (2) a longer shell timeout. The rescan existed only to catch newly-allocated craft, which the roster work showed never happens.

• ✅ Run 16: the first TRUSTWORTHY negative. Validated witness, no stall on any sample, guest demonstrably live (8 losses) ⇒ 0 confirmed arrivals over 210 s of verified-live flight ≈115 game-seconds. Establishes that nothing arrives in the first ~115 game-s of Stage 02 phase 1 while the player kills 8 craft. Does NOT settle the question — t=170/210/240 route entries are still out of reach.

• ✅ Run 17 reproduces it (n=2): no stalls through t=240 s (~132 game-s), 9 losses, 0 confirmed arrivals — so nothing arrives past the t=90 and t=120 route entries either. 4 flicker ups correctly rejected (~1/min, which is why the persistence rule matters). 🔴 Startup eats ~100 s of a ~350 s budget: enumerate_craft iterated every 4-byte word of 32 MB in Python (8M steps) to find 14 fixed needles. Replaced with bytes.find() per definition VA — not yet run; if it recovers that time the window reaches ~340 s ≈ 187 game-s, finally covering the t=170 entry. Also: the 42-record anomaly recurred and the discard rule correctly refused the run; a rescan-until-baseline retry is now in place to test whether it climbs. All three witness failures share one pattern: a shortcut in selecting the witness, each caught only by the flagged samples contradicting losses in the same output.

• ✅ Bind failure fixed + abort verified: entities2 self finds the player by MOTION, so a stationary craft at mission start is invisible; the session now holds throttle 3 s before each attempt. One run correctly aborted after 3 failures rather than flying unattended; the next bound immediately (11 losses, 0 confirmed arrivals — 14 runs). 🔴 The cheap probe froze too (t≈183 s), so the earlier "0 stalled samples" validation is superseded; with n=1 per arm (control clean 300 s, heavy 27–255 s, cheap 183 s) it is unresolved whether cheap sampling helps or the freeze is stochastic. ⚠️ Usable window ≈3 min per run regardless — design experiments to fit or to survive a freeze. ⚠️ The "0 stalled samples" that validated the cheap probe came from the unreliable witness and should be re-confirmed. Also fixed: bind now retries 3× and aborts rather than flying an unattended craft (one run was wasted that way). ❔ Multi-squadron threshold test still not run (zero losses that run). ⚠️ The ~210 s title movie at boot is the binding constraint on observable game time per turn. Earlier framing: mission-per-record-strength.md — one run gives 116 records/300 craft, the next 42/170, same disc, save and script. Save drift is REFUTED (savedata untouched since 2026-08-23) and the guest was not frozen (pilot telemetry shows live engagement). Also: zero arrivals and zero losses in 190 s of hunting — weak evidence against clock arrivals at t=90/120/170 s, and no test of event-gating at all because nothing was killed (fc=0, hull never moved). Next: (1) sample the roster-record count repeatedly WITHIN one run to tell a load race from a run-specific constant; (2) get a confirmed kill — the pilot reaches 259 m and still misses, so the gap is accuracy, not engagement.

• 🟡 COMPETING MODEL (user, 2026-08-24): waves are event-gated, not clock-driven — released by kills/objectives rather than at a fixed time, with the route's start time being a post-trigger delay. Fits the evidence better: both probe runs used the survival pilot (kills nothing) and saw no arrivals, which a clock model does not explain. DisableInterval also gains a referent. 🟡 Supporting: no DisableInterval=Yes squadron has a delayed route (55/55 at t=0, vs ~3.7 expected if independent, p≈0.02) — suggestive, NOT conclusive, deliberately not promoted. Test: same stage twice, kill nothing vs kill aggressively; cheapest precondition is whether REMAINING OB (0xbdb59668) moves in one and not the other.

• 🔴 Diffing inside the 116 records did not find the arrival flag (2026-08-24, same doc). 10 of 116 records are dynamic, 106 never change a byte in 170 s — 🔴 the "10 of 116 dynamic" figure is WITHDRAWN — a hunting run measured 41–56 records changing per tick; I had changed two variables at once (record bound and pilot) so the discrepancy is unattributed. The roster identity is unaffected: it now rests on the 10/10 unit-composition match. Earlier note, kept for history: the "turrets don't move" hedge was withdrawn after the user pointed out that early-mission "Turret" is a craft type, which the data confirms (UN_e007_ADAN_Turret flies under AI_ADAN_CraftSquadron_*, never AI_Structure). Lesson: check a unit's AIID, not its English name. No field transitions in groups of 3 at the predicted times. Blocked on two of my own defects: the record→unit-ID label resolved to ? for all 116 (reuse unit_discover.py, do not re-derive), and RECLEN=0x200 was assumed, not measured — the busiest fields sit at the very end of the window, which is what spilling into the next object looks like. Fix both before diffing these records again.

• 🔴 Probed 2026-08-24 and refuted the cheap hypothesis — the phase state is NOT adjacent to the loaded table strings; see mission-phase-runtime.md. The run did confirm dynamically that every table the static decode predicts is resident in guest RAM and findable by name, which validates the whole static layer against a running mission. Next handles: watch Route_ADN101_p1F actually fire against entity positions, or work back from the SUBOBJ_*_Mes_L1 HUD strings; the phase state is more likely near the known mutable REMAINING OB counter at 0xbdb59668 than near the tables.

Superseded first step: find what advances a phase — the stage declares Phase_1..3 and routes are phase-tagged, but nothing static found so far says what ends a phase. This is the point where the oracle should be measured rather than reasoned about: fly Stage 02 and watch for the phase transition. Also open: the route-name kind letters F/S/A/M/B, what activates a sub-objective, and StageMessageSet_S<NN>.tbl which does not resolve in GP_MAIN_GAME_E.pak.

Superseded first step: find where the arrival interval values live. DisableInterval is only a per-squadron flag (Yes for 31 of 1160); the durations, spawn triggers and arrival positions are not in UnitGroup. The stage record names two untouched candidates: Formation_*.tbl (formation geometry, possibly its timing) and EnumSquadron_Test.tbl. Also still open: the 4-byte record key. the member field n — SETTLED 2026-08-25, see below. the missing S17–S23 stage records — SETTLED 2026-08-25, and half the premise was wrong.

• ✅ n is the number of units the member tuple instantiates, filling slots of the squadron's formation. FormationSet_S<NN>.tbl records are slot lists — 1 + 8·FrameCount fields, exactly (4→33, 14→113, 30→241, 32→257). Resolving every squadron's FormationID and comparing: sum(n) ≤ FrameCount holds 1159/1160 across all 28 stages, 0 unresolved, 539 filling the formation exactly. The lone violation is a debug leftover (S20, AI_Test / MessageSet_test, Formation_1_only with n=2) and is recorded, not swept up. The old "n is not the _NN suffix of FormationID" was right but drew the wrong conclusion — the suffix IS FrameCount, so n=9 against _30 just means 9 units in 9 of 30 slots.
• ✅ FormationID resolves by an in-table roster, not by hashing — 0/16 resolve via name_hash; FormationSet_S02.tbl has 17 records for 16 formations and the extra one carries no FrameCount, its fields being (tag, name, "") with the tags equal to the record keys. Same convention as Enumerate_Squadrons. Second sighting — treat it as the rule for the next table.
• ✅✅ (2026-08-25) 387-vs-~300 SOLVED — the probe double-counts. The squadron→phase map was on the disc all along, in the Route_S<NN>.tbl record names (Route_<squadron>_p<N><kind>, 120/120 for S02); 108/111 S02 squadrons map, the 3 misses are route-table typos and all phase 2. Phase 1 Σn = 151, and its member multiset {1×25, 2×1, 4×4, 9×12} matches the measured craft-per-record fan-in {2×24, 4×1, 8×4, 18×12} bucket for bucket at exactly 2× ⇒ 300 = 2 × (151 − 1), the −1 being the known 41-vs-42 off-by-one (probably the player). The 2× is the instrument, not the game: a 2× reading needs 16 Delta Sabers for 8 named pilots, and breaks Σn ≤ FrameCount in 20 of 37 phase-1 squadrons (16 on Formation_1_only, one slot) where 1× has 0. All three measured totals being even is a further tell. ⚠️ Static argument about a dynamic measurement — it says the number cannot mean what we thought, not what is being double-counted; that needs a run against the craft-scan counting rule. See mission-phase-membership.md.
• 🔴 Refuted with it: UnitGroup has no phase/spawn/delay field (1019 = ΣCount·4 + 5·111, every slot accounted, positional tags are sequential indices); DisableInterval is No for all 111 S02 squadrons (its 31 corpus Yes records are only S04 and S14, all GNN***); stage\EnumSquadron_Test.tbl does not exist — that candidate is dead.
• ❔ What ADVANCES a phase is still unknown and is not in the data: swept the stage record and every table it names plus the message\ family for interval|time|phase|delay|wave|spawn|arrival|trigger|start|appear|event|condition — only FrameCount and PresetMessage_Phase1/2/3 hit. It is in the executable.
• 🟡 Does NOT close the 387-vs-~300 gap in roster-to-craft-link.md. Σn over Stage 02 is 387 vs 296–300 live craft, but that was measured mid-mission after kills and squadrons deploy across phases, so they are not comparable as they stand. The earlier rejection of n assumed everything deploys at once — still untested. The record-key derivation also stays ❔ (the tag is not name_hash; a second hash function is unidentified).
• ✅ S18–S23 stage records were never missing. stagetbl.py Stage_S18 returns a full six-record definition and always would have; it was never run. They omit the literal Stage_S<NN> (no per-stage .xpr; AIParams/weapons/strings/ subobjectives/nameplate/collision all come from a shared _Tutorial set), so an enumeration keyed on that literal skipped all six. Counting distinct *_S<NN> names across all 1119 decompressed entries: UnitGroup and Route cover 28 stages (S01–S16, S18–S23, S24–S29); Stage literal and AIParams 22; SUBObjectiveSettings 16 (story only). Tutorial records carry the same Phase_1/2/3 shape, so the tutorial is not a special mission type at the data layer. Dump in data/stage-tutorial-records.txt.
• ✅ S17 alone is genuinely absent — it appears in none of the five families. Not a stage that lost its data; it does not exist. Matches the family split in challenge-mission-gate.md (story 1–16, tutorial 18–23, challenge 24–29).
• 🔴 Refuted: GP_TUTORIAL.pak does not hold the tutorial stage config — 2 entries, both RATC, zero IDXD, exactly like GP_CHALLENGE.pak.

The dynamic-RE state is not in git, and it was gone

Found 2026-08-23. Everything the oracle runs on — the baseline emulator binary, the Xbox profile, the Stage 02 save, the shader/code caches — lives outside both repos and had been wiped. sylph-doctor says "all good" without any of it; the first symptom is NO PROFILE on disc one second into a boot.

Rebuilt and verified by driving it (LOAD GAME lists the slot → READY ROOM → Stage 02 flight): dynamic-re-state-restore.md carries the recipe — incremental rebuild of auto/upstream-baseline in the shared checkout (202 files, no submodule churn), profile bootstrapped with the instrumented binary's --create_profile_if_none, and the committed savedata-stage02-5pct.bin installed without an Xbox content header, which ContentManager::ListContent does not need.

Open, and cheap:

• ✅ launch_mission.sh finishes unattended again (2026-08-23, later): boot → title → LOAD GAME → slot 01 → READY ROOM → TAKE OFF → IN FLIGHT at 34s, pilot bound and engaging. Two defects, not one: the fixed sleep 28 for LOAD → READY ROOM (now wait_screen.sh readyroom), and the READY ROOM being drawn before it is usable — Preparing to Sortie, TAKE OFF greyed, which whole-image statistics cannot see (1.7 units of blue) so take_off_armed.py tests the label. A third defect fell out of the same run: wait_flight.sh was testing pixel (450,640) "inside the SHIELD bar" of a 1280×720 window, while screenshot crops to the 1279×675 game surface — it lands between the SHIELD and ARMOR bars. That is the long-standing "reported NEVER REACHED FLIGHT while plainly in flight" note, now explained and fixed.
• ❔ Nothing guarantees this state survives the next container. If it is meant to, the profile + save + bin/ copies want a home inside a repo or a named volume; that is a call for the user, not for an agent.

✅ SOLVED (2026-08-23) — the mission objective counter is at 0xbdb59668, and the hunt is automated

🔴 0xbdb59668 is refuted as a durable address (2026-08-23): 0 in two independent Stage 02 runs while the HUD read 004/008/012, on an allocated (not sparse) page. The method stands; the number does not, and every session must re-scan. Two candidates from the re-scan were themselves refuted by the corpus's own "verify across a transition you did not select on" rule. Detail and the corrected method note (the scan takes 0.9 s — the trap is the counter climbing 004 → 012 in four minutes, not scan duration) in structures/mission-objective-counter.md.

✅ Settled the same day, once the HUD stopped costing a human round trip. ob_read.py reads the three digits by normalised template correlation and ob_hunt.py runs the whole method unattended; run 4 then gave one survivor from 35 897, selected on 004 → 008 and verified on the unselected 008 → 012, plus three live paired RAM/HUD readings. The blocker was never the pilot's survival — the evidence lives in the first four minutes of the stage, and the earlier runs simply could not look often enough to catch the 008 step.

🔴 Yesterday's refutation stands, refined: the address is not universal (runs 2 and 3 read a hard 0 there while the HUD counted), but it is not meaningless either — it recurs exactly, and run 3's amber candidate sits one 64 KB page below it at the same page offset 0x9668. Rule: try 0xbdb59668, check it against the HUD, re-scan (~5 min, ob_session.sh) when it reads 0. The follow-on that the autopilot actually needs is unchanged and untouched: ❔ what the counter counts, and whether an OB-badged entity carries a flag in its entity object.

What REMAINING OB counts — and an in-mission freeze in the way

2026-08-23. The address is settled (above); what it counts is not, and it is what the autopilot needs in order to CHOOSE a target. One run in:

• 🔴 Not a live class head-count. Counter 4 against 8 attackers / 7 friendly Delta Sabers / 7 turrets / 1 player — no class matches, no pair sums to it.
• 🔴 The per-entity flag is REFUTED (2026-08-23, final): sample A at counter 12 over 120 entities gave 2 candidates; the counter went 12 → 11 and neither survived. Within ±0x400 of the position triple there is no 4-byte word whose shared-value population tracks the counter. ❔ Not ruled out: a single bit ORed into a word that also varies (the test needs an exact shared value), anything outside that window, and anything on entities entities2 cannot see — it types by position changing, so stationary objectives are invisible. 🔴 The bit-level differential is REFUTED too (2026-08-24): two independently selected transitions in one run — scan at 4 filtered on 4→8 (29 of 710 survive), scan at 8 filtered on 8→12 (2 of 197) — and the intersection is empty. No per-entity bit in either polarity tracks the counter; 16 of pass 1's survivors were the same word +0x250 with different bits, i.e. a shared value, not a flag. Earlier note: 🔎 Built (ob_bitflag.py, 2026-08-24) and run three times with no verification yet: one window was spent on a mission that had already ended in GAME OVER, one hit the same dead mission, and the third had the counter at a different address and then froze after a single filter. Sample A alone gives ~187 set-polarity + 33 clear-polarity candidates at counter 4, so the second transition is the whole test.
• ⚠️ Attrition is now the dominant cost of every in-mission item. Roughly half the runs that reach flight end early — a freeze, or a GAME OVER when the ACROPOLIS or the craft is lost — and a scan needs the run to survive two counter transitions. frozen.in_flight() at least makes a dead run say so immediately instead of waiting out its window.
• ✅ What the counter's neighbourhood IS — the HUD glyph quads (2026-08-24). The four pointers that move with it lead to objects whose vtable is 0x820B2A64: 32 slots, methods 0x823c43b0…0x823c45a0, three construction sites in sylpheed.db. Each instance is a textured quad — a pixel size (34×42 for a digit) and four vertices of (colour, u, v) — and the UV rectangle × 1280×768 reproduces that pixel size to a rounding step, so the font atlas size is measured, not guessed. See structures/hud-glyph-quad.md.
• 🔴 The counter is not "hostiles left" either. It held at 012 for fifteen minutes of live flight while the ADAN population fell 132 → 93.
• ✅ But it decrements when the player kills: 12 → 11 with 411 fire=1 samples and YOU KILLED WARPLANES 0003 on the HUD — the first decrement seen, and the first run where the player's guns were part of the experiment.
• ✅ pilot.py never fires — ROOT CAUSE FIXED (2026-08-23): flight_probe.Pad was writing to the vgamepad FIFO, dead since the uinput pad was replaced by --hid=file, so every axis, trigger and button from every flight tool went into a file nothing reads while /tmp/xenia_pad.txt stayed empty. The craft was never being flown. Verified: full stick went from 0.00° of heading change to 12.72°, and the attitude matrix from d 0.0000 to d 0.4438 — which also refutes the "stale attitude matrix" suspicion. ✅ And the second half: the PITCH stick sign was inverted. Measured on a 45° error, both sides, two pulse widths, with the opposite sign as control: the pilot's sign grew the error every time, the opposite shrank it every time. Fixed, and the pilot fires — fire=1 in 43 of 1 732 samples against 0 of 13 521, aim down to 2.3°, range median 43 km → 6.3 km, and the HUD's own ammunition counters moving. 🟡 Still open: YOU KILLED is 0000 after 250 s of firing and REMAINING OB is still 012 — whether it destroys anything is the next measurement, and the objective-counter item is waiting on it. ⚠️ findrot_global.py, findself.py, findspeed.py, selfstate.py still write to the dead FIFO and ctrl_probe.py/target_probe.py still use pad.f; all flagged in place, none repaired. See pilot-never-fires.md.
• ✅ EMULATOR GONE is SOLVED — it was this project's own Stop hook (2026-08-24), which kill -9s xenia_canary at the end of every agent turn. Every "mysterious" death was a turn boundary. Operational rule: an emulator experiment must complete inside one turn — nothing can be left running for a later tick, and a watcher armed for 1 500 s only watches the rest of this turn. Memory pressure was raised and refuted along the way; that measurement stands, it just was not pointing at anything.
• 🔴 An in-mission freeze — the item in front of everything else. Reproduced with the Kernel channel on. 🔴 The resume-spin lead is refuted by its own control: a still-flying run has more refused resumes (2 738) than a frozen one, because the game runs a self-suspending worker and the host refusal is one per cycle by design. ✅ What is established instead: the guest is spinning, not deadlocked — over 10 s while frozen the main thread is in state R gaining 409 ticks, guest threads ~680 in total, and not one kernel call is made. So it is guest code waiting on guest memory. ✅ Seen from inside (2026-08-24, gdb): all 79 threads are in a wait — guest threads in KeWaitForSingleObject/NtWaitForSingleObjectEx, the GPU processor idle, the main thread in poll() — while the process still burns 1 253 ticks / 10 s, 403 of them in the TimerQueue thread and ~280 each in two guest threads the backtrace shows blocked. So they are cycling through a timed wait, and the CPU burn is in the kernel layer's wait path, not in guest code. No Canary build was needed: XENIA_BIN pointing at a gdb wrapper keeps the lockfile and satisfies ptrace_scope=1. 🔴 Reading the wait target from the log is blocked by cost: KeWaitForSingleObject is kHighFrequency and silent without --log_high_frequency_kernel_calls=true, and with it the emulator is 17 minutes into a boot with a black screen and 175 MB of log. ✅ Built (canary auto/re-wait-timeout-probe 820696c11, --log_stuck_waits=true, binary at /sylph-home/re/bin/waitprobe/): counts consecutive timeouts on the same object per thread and logs at 100 then every 500. Healthy-run control measured — 27 lines over 25 minutes, all one thread polling one Event at guest VA BE56BB5C with a ~30 ms timeout, so the freeze signal is a new (thread, object) pair, not the presence of output. 🔴 A freeze WAS caught (2026-08-24) and the probe says nothing. It froze 9 s into the watcher's window, in flight, and reported the healthy baseline only — one pair, same object VA, no new (thread, object) pair — while the CPU signature was unchanged (1 255 ticks/10 s, 401 in the TimerQueue thread). So the freeze is not a thread looping on timeouts against one object. Two blind spots survive: waits cycling over different objects (the streak resets, so they are invisible), or waits that succeed rather than time out (nothing for a timeout counter to count — which fits the self-suspending worker seen cycling successfully in the kernel log). ✅ v2 built and its baseline is itself a result (canary 597740046): it counts every call per thread per second with the distinct-object count and the return value. On a healthy 22-minute run the main thread cleared 500 calls/s in 224 windows, peaking at 1 235/s over up to 13 distinct objects, and the result was X_STATUS_SUCCESS in all 314 windows — not one timeout. So the game's normal mode is hundreds of successful waits a second across many objects, which is exactly what v1 could not see. 🟡 Consequence: 500/s is not self-selecting, so the freeze signal must be a different shape — far above 1 235/s, a new thread, or a non-SUCCESS result. Next: a frozen sample to compare against; runs 5 and 6 did not freeze (GAME OVER at ~22 min, and still healthy at 10 min). Three runs in a row have now failed to freeze (the third ended in GAME OVER), and the probe's healthy control is measured three times — 27, 24 and 36 lines, always the same single pair. frozen.py detects the state in one call; ob_hunt.py / ob_flag.py abort on it. Roughly two runs in three. See mission-freeze-resume-spin.md.

First step, revised: make pilot.py shoot, then re-run ob_flag.py. The freeze is no longer the blocker it looked like — a 25-minute run stayed animating — and the actual obstacle is that nothing the pilot does moves the counter, so there is never a second sample. If the counter still will not move when the player is killing things, the next question is what does move it, and the objective card's own wording ("shoot down all invading enemy fighters") is the place to start. Second step, if that comes back empty: entities2.typed only sees entities whose position changes, so a stationary objective is invisible to it, and the enumeration itself would need widening before a null result means anything.

See mission-freeze-and-ob-flag.md.

The declaration table is not a paint order on every screen

Found 2026-08-17, building the Explorer's UI Screens browser on ui_layout. Status: 🔎 open — the pause menu is right, the title screen is not.

ui-rat-layout.md says the bundle's element declaration table lists elements "in back-to-front order", verified 11/11 on the tutorial pause bundle. That holds — the tutorial and in-mission PAUSE builds both composite correctly, and pgpeff02a → parent 3 / pgp_ttrl_btn10 at (546,288) / the 70 px button pitch all reproduce exactly.

GP_TITLE.pak build 7 does not. Painting in declaration order puts ptbase2.t32 (the full-screen background art, element 13) on top of the ptlogo1/ptlogo2 wordmarks (elements 0–5), which the real title screen obviously does not do. The pause bundles never caught this because their elements barely overlap.

What has been ruled out: there is no depth/layer key in the 60-byte declaration entry. Dumping every word across the title build's 30 entries, the unknown fields are constant — +28 is 0 everywhere, +44 is 0xffffffff everywhere, +56 is 0 everywhere — and +36, which the doc lists as 0xffffffff, is not a depth either: it is 0/1 only on the kind = 0x4 repeated-instance entries (ptlogo1/ptlogo2 copies), i.e. an instance index. So the order is not recoverable by sorting the table on any field it carries.

What that leaves. The background group is contiguous — elements 12, 13, 14 are pteff00.prm, ptbase2.t32, pteff04.t32, and 12 carries kind = 0x10, a flag no pause element has (theirs are 0x0 / 0x1 / 0x3002). pteff02.prm at 17 has it too. So 0x10 marking a PRMD primitive, and primitives opening a layer that draws beneath what precedes them, is the cheapest hypothesis — but it is a hypothesis, and "draw the .prm group first" would fit this one screen without being evidence of anything.

First step: composite GP_MISSION_SELECT / GP_READY_ROOM / GP_OPTIONS, which have both a background and overlapping foreground elements, and see whether their background sits at a 0x10-adjacent index too. Two more screens agreeing turns the hypothesis into a rule; one disagreeing kills it. The Explorer's screen render/screen info commands make that a minute's work per screen, and the per-element visibility toggles isolate a suspect element.

Meanwhile the viewer paints in declaration order and does not pretend otherwise — a screen whose background lands on top is showing you this bug, not a decode failure.

2026-08-18 — measured against the running game; three orderings refuted, and half the symptom was a different bug

The premise is confirmed by the oracle, which this entry had not had: a framebuffer capture of Canary on the title screen (captures/title-screen-oracle.png) shows the PROJECT SYLPHEED wordmarks (elements 0–5) drawn over ptbase2.t32 (element 13), which is a full-screen background. Declaration order is therefore not the paint order on this screen, and no reading of the element table changes that.

But part of what the render showed was not the paint order at all. In the capture ptbase2 covers the whole screen; the compositor drew it as a 960×540-visible slab starting at (320,180), because a keyframe's scale was being grown from the keyframe's corner instead of about the declared pivot. Fixed, and pinned against the capture by cross-correlation (peak at (0,0)) — see structures/ui-rat-layout.md. That was a real defect worth separating out: it moves 865 of the disc's 5 130 resting placements, on every screen, independently of any ordering question.

Three candidate orderings are now dead, all cheaply:

• The placement region is not a second ordering. Its keyframe groups carry an explicit element index, so they could be stored in a different order — they are not, on every build on the disc (placement_region_order_is_never_a_second_ordering,

  500 builds, identity every time).

• The RATC child order is not it either. For the title build it is the declaration order with the .prm elements absent — strictly less information, and it has no place to put ptbase2 other than where the table already puts it.
• Reverse declaration order is refuted by the same capture: it would draw ptbase2 (13) over ptcopyright (28), and the copyright line is visible.

The 0x10-adjacency first step was run, and it does not survive. The background is adjacent to a kind = 0x10 .prm element on both screens that have one — but on opposite sides. GP_TITLE build 7 is 12 pteff00.prm (0x10), 13 ptbase2.t32, 14 pteff04.t32; GP_MISSION_SELECT build 0 is 0 px_mission_base.tbm, 1 px_mission_eff00.prm (0x10). So "the .prm opens a layer that draws beneath what precedes it" cannot place both, and no rule keyed on the .prm's position orders the background. GP_READY_ROOM and GP_OPTIONS turned out not to be the third and fourth witnesses this entry hoped for: neither of their largest builds carries a .prm or a full-screen background at all, so they cannot discriminate.

What is still open, stated plainly: nothing in the bundle has been found that orders element 13 behind elements 0–5. Every ordering the file itself carries is now either identical to the declaration table or refuted by the capture. The next step is no longer static — it is either the guest code that walks this table, or a per-draw capture of the title screen showing the order the game submits.

Blocker, checked rather than assumed. The obvious move is to reuse Canary's existing RE instrumentation, which is already in the built binary on sylpheed-re. Neither hook can answer this:

• --log_draws (command_processor.cc) de-dups by a vertex-declaration fingerprint — shader hash + primitive type + per-stream element formats/offsets + index-buffer guest base — and writes each distinct one once. A screen's sprites share a declaration, so they collapse; and the record carries no texture identity and no per-frame submission order, only first-seen order. It is a mesh-format log, not a draw-order log.
• The F10 ship capture does preserve per-draw order within a frame and de-dups on (vertex base, WVP transform, index range), which would separate the elements — but it explicitly drops UI draws: if (pos_off_bytes < 0 …) return; // no float-position stream (UI/effects) — skip. It requires an f32x3 position attribute, which a 2D quad stream does not have.

So this needs a new hook in Canary — log each draw in submission order with its bound texture fetch (or its screen-space quad), gated behind a cvar the way the other two are — and therefore a build-canary run. That is the cost to state up front rather than discover halfway in; it is not a container limitation, just a long build plus a title-screen run.

2026-08-18 (later) — the hook was built and run; the order is now measured

log_ui_draws exists (Canary branch auto/re-ui-draw-order), and the title screen's paint order is ground truth rather than a candidate: ui-title-paint-order-capture.md.

Background first, then the back2 glow pair, then ptlogo1 + ptlogo_tm, then ptlogo2, then ptcopyright, then the PRESS Ⓐ BUTTON plate — i.e. declaration indices 13, 22|24, 23, 0, 11, 1, 28 and then two elements that are not in build 7 at all. Two more orderings die on that evidence (keyframe start time, resting-keyframe time), and one structural fact reframes the whole item: the screen composites two bundles (build 7 plus the one-element build 2 that is the button), so no single build's element table can be the paint order whatever its order.

Still open, and now sharper: the rule. The bundle's 60-byte declaration entry carries no depth field (dumped, above); the per-element .rat record has not been checked for one against this ground truth, and nothing yet explains how the two bundles are sequenced. Both are static questions again — the oracle side is answered.

2026-08-18 (third pass) — the bundle does not carry the order at all

Three more places checked, all empty, so the static avenue for this item is exhausted (detail and evidence in ui-title-paint-order-capture.md):

• the geometry has no depth. A UI quad's attribute 0 is k_32_32_32_FLOAT, so it carries a Z — and every Z in the capture is 0.00000. Submission order is the entire ordering.
• the declaration table has no key. Every word of every entry dumped for the build the game actually runs: +28 0, +32 0xffffffff, +36 0xffffffff (except an instance index on kind = 0x4), +44 0xffffffff, +56 0.
• the placement region has none either, including its per-group lead word, which is 0 for all 24 groups; and the region is followed straight by the RATC child stream, so there is no table hiding behind it.

Also corrected: the running screen is build 4, not the largest build 7 that screen info defaults to — the two disagree on sprite sizes and the capture matches build 4. The conclusions are unchanged, the indices are not.

So the next step is the guest code, not the file: the splash draw path from the emulator-era work (sub_821CC7A0, item vtable 0x820b30b4) submits with exactly the PS hash E59B2B3D this capture sees, and xenia-rs/sylpheed.db is available in the container.

And a second screen is NO LONGER BLOCKED, but it is not routine either. The main menu has been reached (screenshot in canary-scripted-input-traps.md), so the "Ⓐ is dead" reading is withdrawn. Not routine after all — see the 2026-08-19 tables in canary-scripted-input-traps.md: 4 of 5 successes without --log_ui_draws, 0 of 7 with it. An interleaved series refuted the boot-time confound (the latest title of all, 268 s, accepted Ⓐ; a 232 s title refused), and no mechanism exists for the flag — it is read only when F10 arms a capture, and F10 was never pressed. The variable was removed rather than believed — F10 now arms the capture unconditionally — and with it gone a fresh run still failed, so the flag is not the cause either. Net: Ⓐ succeeds about half the time and nothing measurable predicts which; five explanations are eliminated. The input path is now mapped statically (entry_point → sub_8216EA68 main loop → sub_822F1AA8 per-frame input → sub_82457038 pad poll → XamInputGetKeystrokeEx), and the poll itself is not state-gated, so the gate is in a consumer further up. Until that is separated, capturing a screen and navigating to it in the same run is not dependable. The earlier claim, kept: the title that ends the boot sequence accepts a single Ⓐ (2 of 2 at the time); the title the attract loop returns to accepts nothing (Ⓐ, START, B, BACK, X, Y — dozens of delivered presses). The proposed tell was refuted on the way: the two states draw 13 identical quads, ptbtn00 included, so they differ only to the guest. Recipe: first title after boot, one tap, and never tap during the boot (88 presses over the intro ends on a permanent black screen).

The second screen is captured — the main menu, GP_TITLE build 5 — and it does not discriminate: its background sits at declaration indices 1–2, so "declaration order" and "background first" predict the same sequence. Same failure mode as GP_READY_ROOM/GP_OPTIONS. The next screen worth capturing is one whose background sits late in its table, as the title's does.

The earlier reading, kept because it is what the evidence looked like: the title's Ⓐ leads into a content/save path that crashes the guest with --mem_watch=true and stalls it with --mem_watch=false. Three separate traps had to be cleared to establish that much — see canary-scripted-input-traps.md, which also carries the reproduction and the fix for two of them.

2026-08-18 (fourth pass) — the crash is named, and the code avenue is scoped

The crash PC resolves to an MSVC std::map/set erase that throws std::out_of_range from the game's cache-manager flush, and the trigger is now controlled: an incomplete on-disc cache throws ~100 s into a boot, a complete one never does. The access violation people have been chasing is only that throw returning, because this build does not unwind guest EH. And the handoff's suspect #1 is eliminated — cold cache with --mem_watch=false throws just the same, which withdraws a claim made here yesterday. See title-crash-stl-tree.md. That is a by-product of this item and belongs to whoever picks up the crash bisection.

For the ordering itself, three more negatives, all recorded in ui-title-paint-order-capture.md: the two time-based orderings were re-checked against build 4 (the previous pass used build 7's numbers, and build 7 is not what runs) and both still fail on the same element; and a fresh candidate — painter's order by resting Y — reproduces the capture to within a single transposition but is refuted by ptlogo_tm and by the background, so it is not the rule either.

The code avenue is scoped rather than walked: the splash item vtable 0x820b30b4 is real (25 slots, three construction sites), RTTI carries no class names disc-wide, and the format tags are fourcc immediates behind a virtual call rather than strings — so this needs a deliberate read of the UI engine, not a keyword search.

Capital ships assemble wrong in the viewer

Reported: 2026-07-30, by the user. Status: ✅ format-side cause found and fixed 2026-08-12 — see below for the 2026-08-10 diagnosis this supersedes.

The remaining format-side defect this entry pointed at (a shared turret decoding ~100× too large in some containers) was real and is gone. e303_wep_01 decoded as a 1600×2100×4800 block in Stage_S02, swallowing the e106 hull; requiring an index buffer to cover its vertex pool exactly moved it to the block every other container agrees on, and it now decodes 49×23×42 everywhere and places at ±179 on the hull. The same fix repaired e106_bdy_03 (a 600×1600×998 slab) and moved 29 anchors disc-wide, 22 of which had been carrying another resource's geometry under their own name. See structures/xbg7-mesh.md.

Two things are worth carrying forward rather than closing:

• the assembler was audited and exonerated — every composite node carries scale 1.0 and an orthonormal matrix, so nothing on that side inflates a part;
• no metric caught this. Coverage, cross-container consistency, the capture oracle and the twin invariant were all green while a 1 600-unit slab sat through the ship. It was found by rendering the ship and looking at it, and the numeric screens written afterwards to automate that check both failed.

The 2026-08-10 diagnosis follows, and its viewer-side pointers still stand.

Status (2026-08-10): 🔎 the format layer is exonerated. Runtime captures of three classes (f105, e105, e106) at controlled range reproduce assemble_ship to ≤0.43 units in translation and to 0.000 in rotation for every part that does not move; see ship-placement-capture-generalisation.md §4. So look at the viewer: first that it passes include_external = true (iso_loader.rs:4012 — with false an e106 loses its bridge and both nacelles, 5 parts instead of 11), then its own transform stack.

One real format-side bug was found on the way and is fixed: index-less parts (e105_brg) never matched their GN_Bridge_01 hardpoint, so 34 (stage, ship) entries — e102, e104, e105 across Stages 02–29 — assembled without a bridge. The other apparent exception (e105_eng_01 rotation) was an aggregation artefact and is 0.000.

The original report and its reasoning follow.

The reborn viewer builds capital ships from the split XBG7 parts via sylpheed-formats::ship::assemble_ship, and they come out wrong — parts in the wrong place / wrong orientation.

Why this is a real finding and not a known limitation: the RE write-up ship-placement-runtime-capture.md declares static assembly ✅ exact as of 2026-07-26 — 9-channel joint tables [TX TY TZ RY RX RZ SX SY SZ], Euler Ry·Rx·Rz, with ship::tests::static_assembly_matches_runtime_capture asserting static == runtime capture (T < 1.0, R < 0.02). So either the viewer is not using that path, or the claim generalises worse than the test suggests.

The likely gap: that test is one ship — the e106 destroyer, 8 parts plus two nacelles, two turrets and the hull mirror. Nothing pins the other classes. Rules that were derived from e106 and could easily be e106-specific:

• the engine cluster rig mounted at GN_Engine_01 (two mirrored nacelles + centre);
• "X-reflect the shared-geometry twin whose lateral offset opposes the geometry's dominant side" — a heuristic, not a decoded flag;
• cross-id turret instancing (×2).

First step (the oracle already exists): re-run the runtime capture on a different capital ship and diff static vs captured, exactly as e106 was done — F10 in the capture-ship-placement build of xenia-canary-native dumps the ship shader's c0..c2 WorldViewProjection rows per part; WV_ref⁻¹ · WV_p is the ship-space rigid transform, which is ground truth. Pick a class whose rig differs from e106 (different engine count, a ship with no sld, a carrier). Then extend static_assembly_matches_runtime_capture into a per-ship table so a regression in one class cannot hide behind e106 passing.

Also worth ruling out first, cheaply: that the viewer's own transform stack (scale, handedness, node-instance recursion) is not re-breaking a correct assembly — compare the viewer's placement against assemble_ship's output directly before blaming the format layer.

---

Viewer: include_external is already on — that hypothesis is dead

Checked 2026-08-11. The item above names "first that it passes include_external = true (iso_loader.rs:4012)" as the cheap first step. It does: ShipBrowser::show_external defaults to true (iso_loader.rs:643), the checkbox reads it (ui.rs:1593) and it is threaded through RequestShipRender → build_ship_model → assemble_ship unchanged (ui.rs:1689, iso_loader.rs:4012). So a ship rendered by the viewer is the full external assembly, not the bare hull.

The viewer also does not have a transform stack of its own to blame: it bakes ScenePart::apply straight into the vertices and rotates normals by the same p.m (iso_loader.rs:4030-4062), so its placement is assemble_ship's output by construction. What remains unexcluded, in order of cheapness: the mirror handling (det < 0 reverses triangle winding only — a reflected part keeps its reflected geometry), Xbg7Model::models_named resolving the wrong sub-model when a resource name repeats, and the exhaust cones. Next step is a visual: the diagnosis has run out of things it can settle by reading, so the viewer needs to be run against a known-good class (e106) and its render compared with ship_render's.

---

Viewer: the duplicate-resource-name hypothesis is dead too

Checked 2026-08-11. The diagnosis above left three candidates for why capital ships assemble wrong in the viewer: mirror handling, Xbg7Model::models_named resolving the wrong sub-model when a resource name repeats, and the exhaust cones. The second is now refuted, and comprehensively.

build_ship_model resolves each placement with base.iter().find(|m| m.name == p.resource) (iso_loader.rs:4041) — first match wins — so a repeated resource name inside a container would silently draw the wrong geometry. It cannot happen: decoding every XBG7 resource in all 22 stage containers gives 4 603 resources and zero repeated names.

Stage_S01  62/62      Stage_S07 323/323     Stage_S13 290/290     Stage_S25 351/351
Stage_S02 304/304     Stage_S08 388/388     Stage_S14  22/22      Stage_S26 318/318
Stage_S03 214/214     Stage_S09 316/316     Stage_S15 386/386     Stage_S27 321/321
Stage_S04 179/179     Stage_S10   7/7       Stage_S16  65/65      Stage_S28 118/118
Stage_S05  92/92      Stage_S11 157/157     Stage_S24 162/162     Stage_S29 386/386
Stage_S06 266/266     Stage_S12 376/376

Per-ship it is tighter still: e106 wants 9 distinct names and decodes exactly 9 models for 11 placements; e105 9 for 9; f105 5 for 6. Every placement resolves to the one model it names.

So two of the three candidates are gone (this one and include_external), leaving mirror handling and the exhaust cones — and the still-untried visual comparison, which remains the right next step.

---

Viewer: mirror handling and the exhaust cones are cleared too — the static avenue is exhausted

Checked 2026-08-11. Both remaining candidates were tested across every ship on the disc, and neither shows the reported signature.

Mirror handling. The concern was that ScenePart::apply bakes R·(S·v)+T while the viewer takes its winding-flip decision from det(m) alone and rotates normals by m alone — both ignoring s. A mirror encoded as a negative scale would then reflect geometry without flipping winding, drawing the part inside-out. It never happens: across 1 485 assembled parts in all 22 containers there are 22 mirrored parts, every one with det(m) < 0, and zero parts with a negative scale or a non-uniform one. apply_twin_mirrors writes the reflection into m (negating its X column), so the viewer's flip always fires, and ignoring s for normals is harmless because s is always uniform.

Exhaust cones. These are the one piece of geometry the viewer invents — a cone at each GN_Jet/GN_SJet frame, because the real engine geometry is recessed and the game draws FX there instead. If they landed wrongly they would read exactly as "a part in the wrong place". Across 335 assembled ships, 192 of which have exhaust frames, not one cone sits outside its hull's bounding box (tolerance 10 % of the axis span).

Caveat, stated rather than glossed: "inside the hull box" does not prove a cone is right — orientation and size are untested, and a cone could be wrong while still inside. What it does rule out is the reported symptom for that part.

So every mechanism this diagnosis proposed is now eliminated: include_external, duplicate resource names, mirror handling, and cones-in-the-wrong-place. The format and assembly layers pass every static test available, and the visual comparison is no longer merely the next step — it is the only remaining one. Render e106 in the viewer beside ship_render's output of the same assemble_ship result; if they agree, the bug is in neither and the original report needs re-grounding against a specific ship and a specific expectation.

---

⚠️ DIAGNOSED 2026-08-12 — a mis-decode; the locality fix was written, then withdrawn

Resolution at the end of this entry. Kept in full because the two wrong turns along the way (a "stray volume", then "monotonic anchoring") are the useful part.

⚠️ The format layer is NOT exonerated — but the cause is a MIS-DECODE, not a stray volume

Found 2026-08-11 by finally doing the visual, which the notes above kept naming as the next step. It overturns their conclusion.

Render e106 from the static assembly and from the baked runtime capture and compare — ship_render does both:

	placements	parts
runtime capture (ground truth)	8	bdy_01…04, brg_01, eng_01, eng_02, wep_02_01
assemble_ship(--static)	11	the same 8, plus e303_wep_01 ×2 and a second e106_eng_01

The render makes it obvious: the destroyer sits inside a white slab that dwarfs it (capture). That slab is e303_wep_01, and its own geometry is:

e303_wep_01     172 verts, 110 tris   bounds X[-1000, 600] Y[-1050, 1050] Z[-2400, 2400]   1600 x 2100 x 4800
e106_wep_02_01 1002 verts, 772 tris   269 x 179 x 417      ← what a real e106 turret looks like
e106_brg_01     202 verts, 202 tris   105 x  76 x 305

110 triangles, perfectly round axis-aligned bounds, and bigger than the ship it is mounted on.

CORRECTION (same day, one iteration later): it is not a volume — it is a bad decode

The first reading of this was that e303_wep_01 is a collision/trigger volume the assembler wrongly draws. That is wrong, and the evidence that settles it is decoding the same resource from every container that holds it:

Stage_S01   172 verts 110 tris   X[-24.5, 24.5] Y[0.0, 23.4] Z[-20.8, 20.8]   ← 49 × 23 × 42, a turret
Stage_S02   172 verts 110 tris   X[-1000, 600] Y[±1050]      Z[±2400]         ← 1600 × 2100 × 4800
Stage_S03…  172 verts 110 tris   49 × 23 × 42  (correct)
Stage_S08   …                    1600 × 2100 × 4800
Stage_S26   …                    1600 × 2100 × 4800

Same resource, same vertex and triangle count, decoding correctly in eleven containers and wrongly in exactly three (Stage_S02, S08, S26). So:

• the placement is legitimate — e303_wep_01 is a small shared turret, cross-mounted on e101 and e106, and at its true size it is unremarkable;
• the original author's explanation of the capture's silence (vbase dedup) stands, and my "dedup would show one, not zero" objection does not survive: with the correct decode the turret is small, ordinary geometry;
• the defect is in the mesh decoder, which resolved this resource's vertex data differently in three containers.

The render and the symptom are real; the cause named in the first version of this entry was not.

The part that matters more than this one resource

The decoder can produce wrong geometry without declining. The XBG7 audit counted 814 resources it refuses — a visible, honest failure. This is the other kind: e303_wep_01 decodes "fine" in Stage_S02 and is silently 100× too large. Screening for the signature (bounds that are exact multiples of 50 with a span over 1000) flags 22–32 models in each of S02, S03, S08, S26, S27 — but that screen also catches legitimate e_rou_* composite proxies, so it is a candidate list, not a count of bugs.

Next: diff the anchor scan's chosen vb0 for e303_wep_01 between Stage_S01 (correct) and Stage_S02 (wrong) — same resource, two outcomes, so the divergence is directly observable — then use whatever distinguishes them to add a post-decode sanity check, so a silent 100× mis-decode becomes a decline.

Why this was missed

assemble_ship treats every rou_* node in the composite as a drawable part, and the doc comment states the cross-id mount as intended behaviour — "INCLUDING repeated instances and cross-id turret mounts (rou_e303_wep_01_root ×2 on the e106 hull)" — with ship::tests::static_assembly_matches_runtime_capture asserting count("e303_wep_01") == 2. The absence from the capture was explained away as vbase dedup, but dedup would show one instance, not zero.

The test cannot catch it either: it walks the capture's parts and looks each up in the static output, so extra static placements are invisible to it. That is the same shape of gap as the earlier include_external hypothesis — a test that can only fail one way.

Scope, stated carefully

Sweeping all 335 assembled ships for the signature ship-scale span with under 400 triangles flags 20 ships and 58 placements over 28 distinct resources (e005_ant_*, f001_ant_*, f002_bdy_*, f301_barrel, f303_body, e303_wep_01, …). Only the e106/e303_wep_01 case is proven — by render, by capture absence, and by geometry. Some of the others may be legitimately large low-poly parts, and each needs the same three checks before being called a bug.

Still true, and independent of the correction above: static_assembly_matches_runtime_capture walks the capture's parts and looks each up in the static output, so extra static placements can never fail it. That is worth fixing regardless — it is the same one-way-test shape as the earlier include_external hypothesis.

Also unchanged: only two cross-id placements exist fleet-wide (e303_wep_01 on e101 ×24 and e106 ×36, across 335 assembled ships), so cross-id mounting is a narrow, real feature rather than a systemic guess.

---

Resolution (2026-08-12)

anchor_pool_mesh took the first candidate in file order from a container-global scan, so a resource could be handed another resource's block whenever both shared (stride, vertex count, index count). Fixed by anchoring each resource near its descriptor neighbours (two-pass: learn, then re-anchor).

• it took inconsistency 125 → 51 with coverage unchanged, and made e106 render correctly (after)
• but it flipped the e106 twin-mirror decision, which static_assembly_matches_runtime_capture (ISO-gated, so it skips in a plain cargo test) catches against the runtime capture — so it was reverted
• the user-reported "capital ships assemble wrong" is therefore diagnosed, not yet fixed; see xbg7 for what the real fix needs

Still open from this entry: static_assembly_matches_runtime_capture walks only the capture's parts, so extra static placements still cannot fail it.

2026-08-18 — that last line was stale, and the residual gap is now closed too

The one-way-test complaint had already been fixed when this entry was written down: 64d372c (the revert commit itself) added an extras check, so "extra static placements cannot fail it" has not been true since. Checked rather than assumed — perturbing the expectation makes the test fail with the real disc behind it, so it runs and is live, not a SYLPHEED_ISO-less skip.

But it compared a set of resource names, which leaves one direction open: a resource placed twice when the capture lists it once changes no set. That is not hypothetical — a duplicated instance is exactly what a bad node walk emits, and the two legitimate duplicates here (e106_eng_01, e303_wep_01) are the reason the test had to special-case counts at all. Replaced with the full multiset, pinned to the e106 ground truth:

e106_bdy_01 1  e106_bdy_02 1  e106_bdy_03 1  e106_bdy_04 1  e106_brg_01 1
e106_eng_01 2  e106_eng_02 1  e106_wep_02_01 1  e303_wep_01 2

— 9 resources, 11 placements, against the capture's 8 dedup'd parts. That subsumes the two hand-written count assertions, and it now fails on an extra resource, a missing one, and a duplicated one. Refuted before believing: declaring e106_bdy_01 twice makes it fail, with the real multiset on the left.

Not closed by this, and worth keeping separate: the multiset is e106's alone. The generalisation this entry originally asked for — a per-ship table so a regression in one class cannot hide behind e106 passing — still needs a runtime capture of a second capital ship.

That entry's stated blocker is stale (checked 2026-08-19): the ship capture is in the current build — RequestShipCaptureFrame / CaptureShipDrawForRE are in command_processor.cc on auto/re-ui-draw-order, and F10 wrote a 2.9 MB xenia_ship_capture_01.log from this session's binary. No separate capture-ship-placement build is needed.

Update 2026-08-19: the mission is now REACHABLE. With the Canary threading fix, tutorial_launch.sh drives boot → title → menu → TUTORIAL and the mission loads and renders (flight HUD, "Go to the box on your screen"). It then freezes under 13 243 crash dumps, all at 0x82307128, preceded by exactly one guest C++ throw — identical frames 6 s apart, no new dumps, 400 % CPU. So the blocker moved from "cannot reach a mission" to "the mission freezes". 🔴 The cache is REFUTED as the cure (3 runs): the missing entry \aab216c3\6 was real and got written, and the run with a complete cache stormed anyway — 11 497 dumps, all 0x82307128. ✅ But a usable window exists: both post-cache runs ran the mission with exactly 2 crashes for 56–80 s before the storm, where the first run was at 641 by t+24 s. The ship capture needs F10 armed inside that window. ✅ Done, and the mission ran with ZERO crashes — first clean mission run, fully rendered. 🔴 But the capture contains no ship geometry: 181 deduped draws, 180 sharing one vertex shader, all screen-space, none 3D — against a known-good 2.9 MB capture from an earlier session. The 8 000-draw budget was not the limit and the scene was rendering. ⚠️ The "cache refuted" claim above is overstated: this run used the same complete cache as tut4 and got 0 crashes vs 11 497, so variance dominates. 🔴 Corrected: nothing is broken. Ship geometry is stride=24 prim=4 with a large vcount (vcount=10891 for a real one); this capture has one prim=4 vcount=6 quad and the 2.9 MB "known-good" file has no prim=4 at all — it is a UI capture (1 303 of 1 582 draws are stride=24 prim=13, the UI sprite shader). The earlier "3D draws" test counted UI sprite coordinates as 3D. The capture recorded what was on screen, and the tutorial's opening has no capital ship. What remains is what the capture doc always said: play into a real mission and frame a ship side-on — gameplay driving, not a menu step, and the original was taken on HW Vulkan where this container has lavapipe. 🔴 The resume-refused lead (1 663 on one thread) is REFUTED: that thread did execute, and KeWaitForSingleObject / NtWaitForSingleObjectEx are kHighFrequency, which is unlogged unless --log_high_frequency_kernel_calls=true — so a parked thread is invisible and the refusals are just the guest kicking a worker blocked on an object. Method note: the title-loader finding rested on host CPU time, not log silence, which is why it stands and this did not.

What blocked it before was the cache-flush crash, not navigation — measured 2026-08-19. tools/re-capture/tutorial_launch.sh (which retries whole boots, because re-pressing the same title never works) gets all the way from the title through the main menu to DIFFICULTY and then SELECT DATA, and the guest dies there at 0x82307128 — the same std::map/set erase as the boot-time throw, 537 stacked dumps, with --mem_watch=false. See title-crash-stl-tree.md.

So a second capital-ship capture needs that crash dealt with first. Everything up to the save-slot screen is now scripted and works, and one run got past it — SELECT DATA reached with zero crashes, slot chosen, the game proceeding into a cinematic — before crashing at the same 0x82307128. The crash is intermittent in where it fires, not whether, so there is no menu route around it. See title-crash-stl-tree.md for the end-to-end measurement and for what has been ruled out (--mem_watch=false, twice).