Crusader_Decomp/plan-mid.md

Crusader Decompilation Mid-Project Plan

Purpose

This file is the live mid-project tracker for the Crusader decompilation effort.

Keep it focused on:

1. current verified state,
2. active blockers,
3. next resume work,
4. and the remaining path to a reasonably complete decompilation.

Detailed completed analysis belongs in the files under docs/, not in this plan.

Progress Snapshot

Latest verified batch: docs/psx/art-binding-recovery.md now includes a 2026-04-12 live MCP CLUT override routing closure pass on active SLUS_002.68 centered on 0x80041458, 0x80041144, 0x80044bdc, 0x80044e9c, 0x800a9f48, and 0x800a9f66. Current best read is now exporter-critical and path-explicit: main-visible injects authored palette token while special-visible does not; submitter override gate is shared (flags & 0xfffffff0); and active override resolution diverges by submitter/resource-format lane (image-table and sprite format-2 use psx_clut_override_table_by_palette_token[token], sprite non-format-2 uses token as a row key into psx_clut_table_by_resource_bank). Practical consequence is that token 0 is effectively no-override for this world-object path and exporter CLUT logic must branch by route lane plus submitter/resource format instead of flattening token handling. Live artifacts in this batch are targeted comments at 0x800415b0, 0x800412d0, 0x80044e10, and 0x80044eb8.

Latest verified batch: docs/psx/art-binding-recovery.md now includes a 2026-04-12 live MCP wall-family discriminator pass for the exporter regression where atlases repeat and wall faces collapse. Current best read is now split-explicit for 0x003e..0x004f: constructor bind in psx_object_create_simple_record/psx_object_create_compound_record still converges on per-type DAT_800758d8[type], while real divergence happens post-bind through selector install (0x800260e8), frame-token latch (0x80025d68 -> obj+0x94), and stage-1 versus stage-2 route semantics (0x80041458 vs 0x80041144), including main-visible-only authored palette-token injection for >=0x003e. Immediate exporter consequence is to prioritize effective route/latch-state discrimination over inventing a new pre-constructor resource-bank split. Live artifacts in this batch are targeted comments at 0x80046038, 0x80026100, 0x80041554, and 0x80040f88.

Latest verified batch: docs/psx/art-binding-recovery.md now includes the 2026-04-12 VRAM-proof palette/export follow-up for map_renderer/src/lib/psx-cache.js, src/config.js, and src/vue/controller/scene-presentation.js. Current best read is now rule-explicit: mode 1 PSX bundles should not trust bundle header palette index +0x14 as the rendered selector, they should decode against one shared contiguous 256-entry CLUT equivalent to live VRAM row 0xF0, x=0, with the old header value preserved only as diagnostic defaultPaletteIndex. The same batch also closes the static-export omission: the processed PSX catalog already contained 62 maps, so the "single map" symptom was export inclusion/config rather than cache enumeration.

Latest verified batch: docs/psx/art-binding-recovery.md now includes the 2026-04-12 focused no-placeholder exporter follow-up for map 104 in map_renderer/src/lib/psx-cache.js plus renderer provenance surfacing in src/vue/controller/scene-presentation.js. Current best read is now exporter-explicit: mixed-role unresolved buckets no longer fall back to synthetic atlases, they resolve per authored-family + raw-u5 cohort into actual PSX bundle art with preserved mappingSource / artCohort provenance. Focused validation rebuild now exports 1002 art items (52 roots + 950 constructors), 0 fallback items, 1 atlas, and 136 shape definitions for scene fingerprint 3497e7f641856415.

Latest verified batch: docs/psx/map-rendering.md now includes the 2026-04-12 final live map-104 cohort closure pass on active writable SLUS_002.68 anchored to scene fingerprint 3497e7f641856415 (0x0042 roots 0x0022 items 25/35, roots 0x0030 items 30/31, constructor 0x0030 items 85/86, and control 0x0066 item 53) with focused create/update/draw/control inspection at 0x800249f4, 0x80024eec, 0x800131a8, 0x80025d68, 0x80041458, 0x80041144, 0x8002be6c, 0x80013618, and 0x80013688. Current best read is now exporter-actionable: authored route seed split (0x0022 vs 0x0030) remains the strongest safe first-key divider; root-0x0030 and constructor-0x0030 cohorts still fail to diverge at creation and should not be split by origin alone; sampled bit0x0400 and policy/runtime captures remain non-discriminating for this anchor set; and the immediate safe exporter change is route-seed bucketization for unresolved 0x0042 placeholders with conservative hold on deeper heuristics until runtime diagnostics sample concrete non-null values. Live artifacts in this batch are targeted decompiler comments at 0x800249f4, 0x80024eec, 0x800131a8, 0x80025d68, and 0x80041458.

Latest verified batch: docs/psx/map-rendering.md now includes a 2026-04-12 focused live runtime/control-island policy pass on active writable SLUS_002.68 centered on 0x80063e54, 0x80063e68, 0x800675ec, and 0x800675f8 with routing/draw/order consumers at 0x800131a8, 0x80041458, and 0x8002bf0c. Current best read is now split-explicit: island tables are control/runtime gating structures and per-type policy modifies ordering/render/publication behavior, but stage-1 vs stage-2 visible lane choice still hinges primarily on object-local route bit obj+0x1c & 0x0400 and submitter choice remains resource-kind based. Live artifacts in this batch are six conservative helper renames (0x8002e598, 0x8002e484, 0x8002e498, 0x8002e3e8, 0x800308ac, 0x800304c4) plus targeted comments at 0x80039fd8, 0x80013518, 0x80013550, 0x8004161c, 0x8002bf2c, and 0x80034d60.

Latest verified batch: docs/psx/map-rendering.md now includes a 2026-04-12 focused live loader/install pre-constructor closure pass on active writable SLUS_002.68 centered on 0x80039444, 0x8003917c, 0x80045ffc, 0x8002badc, and 0x80040768. Current best read is now install-boundary explicit: WDL load installs type art/state lanes and section-pack pointers before root dispatch; CLUT install is explicit in level_palette_header_apply; detached runtime-stream payload install is explicit in psx_install_level_audio_runtime_stream_bundle; and constructors therefore start with preinstalled art/state/policy/CLUT context instead of raw section-0 rows alone. Live artifacts in this batch are one conservative function rename (0x80040768) plus five targeted decompiler comments across loader/install entry points.

Latest verified batch: docs/psx/map-rendering.md now includes a 2026-04-12 focused live draw-submission closure pass on active writable SLUS_002.68 centered on 0x8004137c, 0x80041458, 0x80041144, 0x80040d44, 0x80044bdc, and 0x80044e9c. Current best read is now submission-explicit: both world-visible lanes select submitter by bound resource kind (kind==5 image-table else sprite), both consume live frame token obj+0x94, and CLUT resolution converges on psx_clut_table_by_resource_bank with optional psx_clut_override_table_by_palette_token[(flags>>8)]. The strongest lane split is palette-token injection: main-visible ORs authored high-byte token (source+0x06 or +0x0c) into submit flags, while special-visible does not, giving an executable-backed discriminator for unresolved placeholder-family export behavior.

Latest verified batch: docs/psx/map-rendering.md now includes a 2026-04-12 focused live selector/transition pre-latch closure pass on active writable SLUS_002.68 centered on 0x80018578, 0x8001bca0, 0x8001e6e8, 0x800260e8, and 0x80025d68 with direct row bytes from 0x80063c1c and 0x80063d68. Current best read is now stage-explicit: type-0x0042 pre-latch reseat is early-gated by view margin and object lane bit 0x0020; transition row lookup remains DAT_80063a00 -> DAT_80063b4c; selector 3/4 effects route through psx_object_select_state_script install (obj+0x9e) before final live frame-token latch at obj+0x94 in psx_object_advance_state_script. Live artifacts in this batch are five targeted decompiler comments at 0x80018578, 0x8001bca0, 0x8001e6e8, 0x800260e8, and 0x80025d68, plus a new exporter implication section for map-104 placeholder-family splitting by pre-latch selector versus latched frame token.

Latest verified batch: docs/psx/map-rendering.md now includes a 2026-04-12 focused live type-art install and constructor-binding closure pass on active writable SLUS_002.68 centered on 0x80045ffc, 0x800249f4, 0x80024eec, 0x80038f18, and 0x80041458 with globals 0x800758d8/0x800758c8. Current best read is now lane-explicit from load/install to draw: install writes active-header slot then resolves kind-4/5 resource and commits built-resource cache; constructors consume active-header by type and either reuse built-resource (kind 5) or build per-instance resource; draw uses ctor-bound obj+0x10 resource and live obj+0x94 frame token with submitter selected by resource kind. Live artifacts in this batch are five targeted decompiler comments at 0x80045ffc, 0x800249f4, 0x80024eec, 0x80038f18, and 0x80041458 to preserve exporter-relevant semantics for unresolved map-104 families.

Latest verified batch: docs/psx/map-storage-model.md now includes a 2026-04-12 live section-0 authored-family descriptor-dispatch closure on active SLUS_002.68 centered on 0x800256b0, 0x800258cc, and descriptor table lane 0x80063118/0x80063220/0x800626f8. Current best read is now convergence-explicit: unresolved families 0x0042, 0x0049, and 0x0055..0x0063 share descriptor row 0x800626f8 (slot0 0x80013618, slot1 0x80013688, slot2 0x800254c8) for both root-dispatch and constructor-placement section-0 records, so type divergence should be pursued in per-type banks/policy/state lanes rather than in section-0 descriptor callback identity.

Latest verified batch: docs/psx/map-storage-model.md now includes a 2026-04-12 live object-creation/state-selection closure pass on active SLUS_002.68 centered on psx_object_create_simple_record, psx_object_create_compound_record, psx_spawn_compound_record_advance_state_once, psx_spawn_simple_record_set_active_flag, psx_object_select_state_from_transition_table, psx_object_advance_state_script, and psx_type42_transition_selector_tick. Current best read is now chain-explicit from authored row to visible frame: constructors copy authored u5 into obj+0x1c and seed selector via u4; transition/reselection lanes can mutate selector/low control bits; psx_object_advance_state_script latches final live frame token into obj+0x94; projection/draw consume obj+0x94 directly through psx_resource_frame_* helpers with submit path chosen by bound resource kind. Live artifacts in this batch are one helper rename (0x8003a37c -> psx_queue_global_draw_tint_pulse_once), two supporting data labels (0x80067544, 0x80067614), and targeted decompiler comments across spawn/select/latch/projection entry points.

Latest verified batch: docs/psx/map-storage-model.md now includes a 2026-04-12 live loader/storage ownership clarification pass on active SLUS_002.68 centered on wdl_resource_bundle_load_by_index (0x80039444), psx_lzss_unpack_into_level_buffer (0x8003b00c), psx_lzss_pack_level_buffer (0x8003aba8), and psx_load_type_state_banks (0x8003917c). Current best read is now ownership-explicit in extractor terms: 0x80067838 is promoted to psx_level_section_pack_base, 0x800676d8 to psx_level_clut_table_ptr, the 0x3e00 compressed/decompressed lane (0x8006b5d8 -> 0x8006769c) is confirmed as persistent runtime substrate with save-side repack parity, and constructor consume-site 0x80024c60 now explicitly links loader-installed psx_type_simple_component_bank[type] payloads to live behavior program fields.

Latest verified batch: docs/psx/map-storage-model.md now includes a 2026-04-12 live marker/control runtime-island clarification pass on active SLUS_002.68 centered on 0x80063e54, 0x80063e68, 0x800675ec, and post-load mode-action sequencing at 0x80039ef4. Current best read is now control-explicit: the selector/map tables are post-load and slot-gating control structures (not direct art lanes), runtime block persistence is guarded by snapshot sentinels (0x80031878/0x80031a3c), and a previously anonymous bounded marker-action queue family (0x80030cf0/0x80030dfc/0x80030ed4/0x80030ebc, count at 0x80067798) now has conservative live names/comments to preserve queue-mediated transition behavior.

Latest verified batch: docs/psx/map-rendering.md now includes a 2026-04-12 live visibility-routing and draw-lane clarification pass on active SLUS_002.68 centered on psx_object_integrate_motion_and_route_visible, psx_main_visible_list_sort_range, psx_main_visible_order_graph_unlink_pair, psx_main_visible_order_graph_detach_object, psx_draw_main_visible_object, psx_draw_special_visible_queue, psx_sprite_resource_submit_frame, and psx_image_table_submit_frame. Current best read is now rule-explicit: stage-1 routes through main-visible list/sort and stage-2 routes through the special-visible queue; ordering uses dependency-graph links with policy-bit influence (0x0008, 0x0600); submitter choice is strictly resource-kind (kind==5 image-table else sprite); main-visible applies authored palette-token overrides while special-visible does not; and submitters converge on CLUT selection through psx_clut_table_by_resource_bank with optional override via psx_clut_override_table_by_palette_token[(flags>>8)].

Latest verified batch: docs/psx/map-storage-model.md now includes a 2026-04-12 live runtime-bank/art-install clarification pass on active SLUS_002.68 centered on 0x8003917c, 0x80045ffc, constructor consumers, and type-bank globals 0x800758c8/cc/d0/d4/d8 plus policy table pointer 0x800675f8. Current best read is now role-split and loader-to-renderer explicit: state-bank installs seed scripts/components/extents; art installs resolve active-header and built-resource lanes with post-install alias behavior; and policy-table install at load bridges into world draw/order/interaction consumers. Live artifacts in this batch are two evidence-backed renames (0x8003917c -> psx_install_type_state_script_component_extents_banks, 0x80045ffc -> psx_install_type_art_active_header_and_built_resource) plus targeted decompiler comments at 0x800396cc, 0x800399b4, 0x8003970c, 0x800399f4, 0x80039ad0, 0x8003977c, 0x800460c8, 0x800460d4, 0x800398f0, and 0x80041604.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-12 live countdown-versus-slot frame-order closure centered on map-54 split 0x800208f0 and world-frame call order at 0x8002b830. Current best read is now ordering-explicit: countdown terminal mode split/write runs before behavior and deferred-control lanes that can reach slot-0x0f arm sink 0x800232f0, so boundary timing pressure is strongest, failure-side suppression is plausible, and plain countdown-success direct causality remains weakest. Live artifacts in this batch are conservative decompiler comments at 0x8002b830, 0x80020900, and 0x800232f0.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-12 live authored-producer reachability correction pass centered on 0x80026710, 0x8002677c, 0x80027ecc, and 0x800214ac. Current best read is now guard-corrected: 0x80026710 bounds record arg-count (word0-1 < 0x0a), not opcode value, so opcode 54 -> subop 49 -> sink 0x800214ac remains a viable authored-program lane. Practical consequence is that strongest candidate producer context is again the type-state behavior record stream seeded from psx_type_simple_component_bank[type], with tuple (0x0f,0x0a,0x04) classified as authored-static source data transported through optional runtime arg-index remap.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-12 live progression-latch timing pass centered on 0x80027548, psx_map_progression_table, and map-54 boundary transitions. Current best read is now ordering-explicit: 0x80027548 stages next_map via psx_level_session_set_next_map_id into deferred latch DAT_800678d0, current_map_id only commits at session rollover (0x80031edc), and natural tuple miss risk is therefore a deferred preemption window (54 -> 55 rollover before slot-0x0f (0x0a,0x04) emit), not a same-tick overwrite race.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-12 live synthesis-only conservative-stabilization pass for the natural in-level JL-9 event lane. Current best read is now wording-stable without overreach: callback entries 0x8002745c/0x80027548 stay classified as indirect callback-table targets (no direct callers), countdown tick 0x80020794 stays classified as world-frame control timing with explicit map-54 boundary split, and live comments now explicitly separate timing/context evidence from still-unproven direct tuple-production proof.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-12 live callback-table ownership pass on region 0x800641f0..0x80064220 for entries 0x8002745c and 0x80027548. Current best read is now owner-explicit: this region is part of psx_behavior_opcode_handler_table (DAT_800641ac) dispatched by psx_object_behavior_opcode_dispatch (0x8002677c), with exact indices 0x15 and 0x19; selection is opcode-driven from behavior program words, while the only proven active caller lane still enforces (opcode_word-1) < 0x0a at 0x80026710, so these entries remain topology/timing evidence rather than the strongest direct proven producer lane for slot-0x0f arm. Live artifacts in this batch are conservative decompiler comments at 0x8002685c, 0x80026710, 0x8002745c, and 0x80027548.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-12 live slot-0x0f subcase taxonomy pass beyond tuple (0x0a,0x04) on active SLUS_002.68. Current best read is now family-explicit: surrounding 0x0f branches cluster as transition/countdown/objective-state and message lanes (0x0a/1..3, 0x0a/0x2e, 0x01/1, 0x04/1, 0x06/0x42), while (0x0a,0x04) remains the only recovered eligibility-arm write to psx_debug_extra_channel_gate under non-hidden header-state-3 predicates. Live artifacts in this batch are one conservative rename (0x80049014 -> psx_audio_cdxa_select_and_play_cue) plus targeted decompiler comments at 0x80023154, 0x800231b0, 0x8002321c, 0x80023334, 0x80023390, 0x800236d8, and 0x800237cc.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live transition-callback provenance pass centered on 0x8002745c and 0x80027548. Current best read is now provenance-explicit and timing-aware: both entries are indirect callback-table targets from region 0x800641f0..0x80064220 (no direct caller xrefs), 0x8002745c can carry or suppress slot-0x0f tuple opportunity depending on branch (DAT_80078a14==0 path calls 0x80020f7c, alternate path skips it), and 0x80027548 progression apply (map_progression_table[current_map_id]) makes natural tuple firing more timing-sensitive by advancing transition state before later control-event handling.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live producer-side authored-source closure pass centered on the action-record frame consumed by psx_level_gate_slot_dispatch_from_action_record (0x800214ac). Current best read is now loader-explicit: psx_load_type_state_banks (0x800391f0) installs psx_type_simple_component_bank[type] from level bundle type-state payloads, object constructors seed component program_base/pc from that bank (0x80024c60/0x80024c88), and behavior tick/dispatch (0x80026740 -> 0x8002677c -> 0x80027ecc) transports authored operands into the sink frame. Practical consequence is that tuple (slot,arg1,arg2)=(0x0f,0x0a,0x04) now looks authored-static at source context with runtime index-resolution as transport, while exact emitting type-row attribution remains open. Live artifacts added in this batch are conservative decompiler comments at 0x80039250, 0x80024c60, and 0x80026740.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live countdown-versus-slot-family structure check driven by the timed-segment failure clue. Current best read is now causality-tight: psx_control_event_countdown_transition_tick (0x80020794) and psx_control_event_apply_countdown_step (0x800205e8) are in the world-frame countdown lane, while natural JL-9 arm remains slot-dispatch lane (0x800214ac -> table 0x800640a0 -> slot0f 0x800230e4 -> writer 0x800232f0) with no recovered direct countdown-to-slot call edge; practical consequence is that timer behavior is likely related by shared control-state/timing pressure rather than being the same direct feeder branch.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live multi-map last-mission chain validation pass centered on psx_map_progression_table, selector-to-map mapping, and late transition helpers. Current best read is now split-map explicit: map 54 is still the strongest natural selector anchor (0x0f -> 54), while maps 55..58 are downstream transition phases in the same slot-0x0f gate family (map_to_slot[54..58]=0x0f) with contiguous progression (54->55->56->57->58->0xff), which better explains the JL-9 gate-host family without displacing 54 as the most reproducible natural host.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live synthesis pass driven by two new clues (timed failure and multi-map last mission) with fresh caller/xref evidence from active SLUS_002.68. Current best read is now ranking-explicit: optional scripted event inside the countdown/transition chain is strongest, countdown-branch timing miss second, map-to-map transition interaction third, and plain countdown-success branch weakest; practical consequence is that next runtime validation should prioritize tuple-emission observability (slot 0x0f, 0x0a/0x04) at the map-54 boundary path (0x800208f0) with progression callback context (0x80027548).

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live alternate-feeder search centered on sink targets 0x800214ac and 0x800230e4 with explicit control/deferred/callback lane checks. Current best read is now tighter in one key way: no new direct literal/table feeder into either sink was recovered beyond 0x800636d4 -> 0x800214ac and 0x800640dc -> 0x800230e4, so the strongest non-54 -> 49 candidate is currently transition/control-driven (psx_level_gate_slot05_handler at 0x80022068, psx_control_event_slot0e_handler case-6 at 0x80023074, and helper callsite 0x8002748c into psx_control_event_apply_level_channel_preset) rather than a newly proven behavior-opcode producer path.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live level-54 boundary clue pass for natural MFM4 failures. Current best read is now map-specific and timing-tight: psx_control_event_countdown_transition_tick (0x80020794) has an explicit split at current_map_id 0x36 (<=54 -> mode 0x1a, >54 -> mode 0x1b), and additional optional late control lanes (psx_level_gate_slot05_handler (0x0a,0x28) plus progression callback 0x80027548) can advance state before slot 0x0f (0x0a,0x04) arm writes psx_debug_extra_channel_gate. Practical consequence is that natural failure is now best explained as optional-path/timing miss around map-54 late transitions, not wrong-host selection.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live slot-handler sibling recovery pass centered on psx_level_gate_slot_handler_table (0x800640a0) with newly created table-entry functions at 0x800215fc, 0x80021810, 0x800219e4, 0x80021fac, 0x80022214, 0x800222e8, 0x800223cc, 0x800226e0, 0x800227ac, 0x80022b50, 0x80023854, and 0x80023af0, plus a control-pair rename at 0x80022940. Current best read is now sibling-explicit across slot-family 0x0a..0x0f: adjacent 0x0a subcases are control/message/transition lanes, while slot 0x0f case (0x0a,0x04) remains the only recovered sibling branch that arms psx_debug_extra_channel_gate at 0x800232f0.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live upstream-producer closure pass for psx_level_gate_slot_dispatch_from_action_record (0x800214ac). Current best read is now structure-explicit: the sink consumes a pointer-frame (record+0/+4/+8/+c) forwarded from psx_behavior_subopcode_dispatch (0x80027ecc) as local_60+1, and those pointer fields are produced in psx_object_behavior_opcode_dispatch by either direct pointer words or index-resolved slot pointers (base + index*4). Practical consequence is that tuple (slot,arg1,arg2)=(0x0f,0x0a,0x04) is now bounded as behavior-script-produced pointer data rather than a sink-local immediate constant, while the exact shipped authored producer instance remains an open runtime-trace target.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live event-only synthesis continuation pass for the natural gate-arm lane. Current best read is now slightly tighter but still conservative: 0x800230e4 is promoted to psx_control_event_slot0f_handler (slot-family role, not single-branch setter), slot-table entries 0x800640d4/0x800640d8/0x800640dc are explicitly labeled as slot 0x0d/0x0e/0x0f handler entries, and comments at 0x80064284 and 0x800636d4 now preserve the key split between structural topology (54 -> 49 -> sink) and still-unproven active reachability beyond the known <0x0a caller lane.

Latest verified batch created a dedicated event-only working note at docs/psx/jl-9-in-level-event.md. Current best read is now organized around the natural gate-arm problem specifically: sink dispatcher 0x800214ac..0x800215f8, slot-family handlers 0x0d/0x0e/0x0f, exact arm tuple (slot 0x0f, arg1 0x0a, arg2 0x04), host family {54,55,56,57,58,82}, and the still-open upstream authored producer. Practical consequence is that future JL-9 event passes should resume from the dedicated event note instead of re-mixing event-only details into the broader passcode and inventory note.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 sink-feeder-only closure pass on live SLUS_002.68 centered on 0x800214ac..0x800215f8 with explicit argument-byte loads at 0x800215cc/0x800215e0. Current best read is now artifact-tight: 0x800214ac is promoted as psx_level_gate_slot_dispatch_from_action_record; dispatch slot is loaded from *(*(record+0)); handler args are loaded from *(*(record+8)) and *(*(record+0xc)); and the JL-9 gate-arm tuple is bounded to slot 0x0f with (arg1,arg2)=(0x0a,0x04) into psx_set_debug_extra_channel_gate (0x800230e4) through psx_level_gate_slot_handler_table[0x0f] at 0x800640dc. Upstream table topology is now preserved in live comments as psx_behavior_opcode_handler_table[54]=0x80027ecc and psx_behavior_subop_handler_table[49]=0x800214ac, while active reachability from the currently proven gameplay caller path remains bounded by (opcode_word-1) < 0x0a at 0x80026710.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 host-level closure pass dedicated to natural JL-9 event hosting across family {54,55,56,57,58,82} using live table bytes and late-transition caller checks. Current best read is now ranking-explicit: map 54 remains the strongest natural host because it is the reciprocal selector-anchored slot-0x0f entry (0x0f -> 0x36), while 55..57 stay plausible transition-phase hosts, 82 remains family-valid but weakly anchored for published-code replication, and 58 is now de-prioritized as a stable host because psx_map_progression_table[58] = 0xff marks terminal progression pressure; practical failure model for natural MFM4 is now timing/event-miss (missing tuple (0x0a,0x04) before hidden phase), not passcode decode mismatch.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live caller/context reassessment around 0x80026690 / 0x8002677c with a sibling control-runner check. Current best read is now split cleanly between active proof and topology: the only proven caller into psx_object_behavior_opcode_dispatch remains the <0x0a bounded lane at 0x80026710, while 54 -> 49 -> 0x800214ac remains structurally valid table linkage but should be deprioritized as an immediate active explanation until a second caller/context lane is recovered. The same batch also lands conservative live artifacts (0x80027ecc function creation/name and 0x80020f7c rename with caller-bound comments).

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live MCP late-objective pass focused on mission-complete text handlers, transition siblings, and uncommon reward-branch outcomes in the slot 0x0d/0x0e/0x0f control-event family. Current best read is now path-tight: slot 0x0e case 0x0a/6 is a concrete late transition that applies selector 0x0f, selector 0x0f is the only sampled direct selector lane into channel 0x0f, and natural JL-9 gate arm remains bounded to slot 0x0f case 0x0a/4 (0x800232f0) under hidden==0 && runtime_header_state==3; practical consequence is that the remaining blocker is now specific authored event provenance inside that channel-0x0f family, not branch existence.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live closure pass dedicated to decoding the control-event 0x0a family around 0x80022c6c..0x80023390. Current best read is now sibling-explicit: slot 0x0d (0x80022c6c) and slot 0x0e (0x80022ea8) are recovered as mission-complete/control-event siblings to slot 0x0f (0x800230e4), and tuple (0x0a,0x04) remains the strongest natural pre-hidden gate-arm branch because it is the only recovered in-family case that writes psx_debug_extra_channel_gate under hidden==0 && runtime_header_state==3.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 event-only synthesis pass for the natural JL-9 in-level gate-arm lane plus a conservative live Ghidra naming/comment sweep on still-raw central entities. Current best read stays intentionally split between what is proven and what is only topology: sink-side event evidence remains strong (0x800214ac..0x800215f8 -> slot 0x0f -> 0x800230e4, tuple branch 0x0a/0x04 at 0x800232f0), while upstream 54 -> 49 is retained as structural table linkage pending proof of a second active caller/context beyond the known (opcode_word-1) < 0x0a guard at 0x80026710.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 active-caller recheck focused on natural gate-arm production into sink dispatcher 0x800214ac..0x800215f8. Current best read is now priority-corrected: sink-side tuple closure remains strong (slot 0x0f, arg1 0x0a, arg2 0x04 into 0x800230e4), but the only proven gameplay caller lane into psx_object_behavior_opcode_dispatch remains bounded by (opcode_word-1) < 0x0a at 0x80026710, so the earlier 54 -> 49 path should stay as table topology and be deprioritized as an immediate active explanation until a second caller/context lane is recovered.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 user experiment follow-up that materially weakens MFM4 as the main mystery. Current best read is now experiment-backed: a natural MFM4 trial did not yield JL-9, while JFM4 plus manual gate byte 0x8006739d = 0x01, then L0SR, then R1 + Circle, still produced JL-9. Practical consequence is that MFM4 remains the best natural prime candidate on code grounds, but the dominant unresolved question is now the natural in-level gate-arm event rather than the passcode choice itself. Deferred user experiments to revisit later are 2, 4, 5, and 6 from the current emulator test plan.

Latest verified batch: docs/psx/jl-9-investigation.md now includes user-validated downstream closure for the forced JL-9 test. Current best read is now causal-explicit: manual byte poke 0x8006739d = 0x01, then L0SR, then R1 + Circle successfully produces JL-9, which proves the late hidden/input grant half is correct and that the gate byte alone is sufficient for the extra 0x0d branch once hidden trigger runs. Practical consequence is that the more direct thing being bypassed is the natural in-level gate-arm event, while MFM4 is now demoted from “lead candidate” to “best natural prime candidate” for recreating the same latch without manual memory edits.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 hard-clear-theory check and manual gate-poke closure. Current best read is now split cleanly: the "beat the game on hard, then enter L0SR" story remains weak-to-medium because completion/congratulation handlers were found but no direct bridge from endgame flow into psx_debug_extra_channel_gate was recovered; meanwhile the practical emulator route is now strong, because psx_debug_extra_channel_gate is confirmed as byte 0x8006739d, read as nonzero at 0x8002fff4, with no recovered clear in inspected session/load/menu paths, so manual 0x01 poke + hidden L0SR + R1 + Circle is now the best forced test for the extra 0x0d lane.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 published-mission-code sweep against the user-supplied level-code table. Current best read is now candidate-explicit: ordinary decode rows are i=0x00..0x0e, ordinary selector return is s=i+1, and first-char difficulty only writes psx_level_runtime_header_state. Practical JL-9 consequence is that MFM4 (Level 15 hard) is now the only strong published-code prime recovered so far, because ordinary row i=0x0e yields selector s=0x0f, maps through DAT_80063e54[0x0f]=0x36, and lands in gate family DAT_80063e68[54]=0x0f while also setting runtime_header_state=3; LRTN/MRTN/PRTN remain strong negatives because the ?RTN family clears header state to 0.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 reachability-correction pass on the previously claimed step-2 producer chain. Current best read is now split cleanly between topology and proof: table topology still shows DAT_800641ac[54] = 0x80027ecc and DAT_80063610[49] = 0x800214ac, but static reachability currently proves only one caller to psx_object_behavior_opcode_dispatch (0x80026740) and that path bounds (opcode_word-1) < 0x0a before dispatch, so high-index entries are not yet proven active from the known path. Practical consequence is that sink-side gate-writer evidence remains strong (0x800214ac..0x800215f8 -> DAT_800640a0[0x0f] = 0x800230e4, args 0x0a/0x04), while the open upstream task is now narrowed to recovering a second proven caller/context that can feed high behavior-opcode indices.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 step-2 producer-path closure pass for the gate-arm dispatcher source. Current best read is now structurally explicit upstream: psx_object_behavior_opcode_dispatch table index 54 reaches handler 0x80027ecc, which secondary-dispatches through DAT_80063610[subop]; sub-op 49 maps to 0x800214ac, which then performs the level-gated slot dispatch into DAT_800640a0[0x0f] = 0x800230e4 with arg bytes from record pointers (0x800215cc/0x800215e0). Practical consequence is that step-2 is now identified as an in-level behavior/control opcode event lane (54 -> 49), with the remaining open item narrowed to one concrete authored mission/object instance rather than the producer subsystem itself.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 NRTN/?RTN decode-to-apply closure over 0x8003ec8c, 0x80034c14..0x80034ddc, and 0x80021138. Current best read is now delay-slot exact: special index 0x0f clears psx_level_runtime_header_state but returns raw selector 0x10, eval maps through DAT_80063e54[0x10]=0x3f, and caller therefore does not take the s0==0 skip; apply executes selector-0x10 case at 0x8002142c (writes DAT_800675e4=0x1d, common helper a0=0x36). Practical JL-9 consequence remains strict: NRTN/?RTN does not itself satisfy gate-arm predicate runtime_header_state==3 and cannot alone coexist with the required non-hidden gate-arm state.

Latest verified batch: docs/psx/jl-9-investigation.md now records a 2026-04-11 correction to the earlier Mission 16 / developer-office theory. Current best read is that the attractive DAT_80063e54[0x0f] = 0x36 -> DAT_80063e68[0x36] = 0x0f chain was the wrong table index for the runtime ?RTN path; the live caller path uses returned selector 0x10, maps through DAT_80063e54[0x10] = 0x3f, and only later executes selector-0x10 apply logic with common-helper a0 = 0x36. Practical consequence is narrower: office-like content may still be involved, but current static evidence no longer proves that NRTN/?RTN places the session directly inside the slot-0x0f gate family.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 hypothesis check for the exact NRTN -> in-level office event -> ?0SR/L0SR -> input 0x1e recipe. Current best read is now classification-explicit: the two-phase structure remains code-backed (pre-hidden gate-arm at 0x800232f0 then hidden/input trigger at 0x80013154..0x80013174), dispatch evidence still supports a real in-level slot-0x0f gate-arm path via 0x800214ac..0x800215f8 into 0x800230e4, but the exact player-visible office event and deterministic NRTN role are still not singularly closed by static evidence; practical status is therefore plausible but unproven rather than contradicted.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 clarification pass on what user-facing "step 2" actually means. Current best read is now much less misleading: the gate-arm write is not a second passcode-screen action but an in-level scripted/control dispatch routed through 0x800214ac..0x800215f8, where DAT_800640a0[0x0f] = 0x800230e4 (psx_set_debug_extra_channel_gate) and the exact writer tuple is (slot 0x0f, param_2 0x0a, param_3 0x04); meanwhile hidden ?0SR / L0SR still uses the shared passcode decoder but returns selector 0, so it does not follow the ordinary nonzero mission/apply-load branch. Practical consequence is that the current JL-9 recipe is now explicitly normal passcode prime -> in-level scripted gate-arm event -> hidden passcode -> R1+Circle, with the remaining blocker narrowed to naming the concrete in-level event.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 step-2 caller narrowing pass on the gate-arm writer path (0x800230e4 -> 0x800232f0). Current best read is now dispatch-concrete: reachability is through an indirect level-gated dispatcher at 0x800214ac..0x800215f8 (DAT_80063e68[current_level] compare + DAT_800640a0[a2] handler table), with slot 0x0f resolving to psx_set_debug_extra_channel_gate; handler arguments are loaded from action-record byte pointers; and the exact gate-arm tuple is tightened to (dispatch index 0x0f, param_2 0x0a, param_3 0x04), narrowed to a small level-scripted family where DAT_80063e68 == 0x0f (54..58,82) rather than a single globally named menu callback.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 gate-survivability closure pass across passcode application, level-load/session loops, and menu-reset helpers. Current best read is now lifecycle-explicit: psx_debug_extra_channel_gate (0x8006739d) remains one-writer/one-reader (0x800232f0 set, 0x8002fff4 read) with no recovered static clear in inspected load/menu paths; hidden decode (0x8003ed28) still returns selector 0 and skips normal apply/load branch checks around 0x80034d84; and practical two-phase ordering remains non-hidden gate arm first -> hidden/input trigger later, with step 2 supported after a level load in the same running session.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 passcode-screen semantics closure for the normal-versus-hidden entry question and the JL-9 sequence wording check. Current best read is now user-flow explicit: normal and hidden passcodes both route through psx_passcode_screen_eval_current_entry/psx_passcode_decode_to_mission_selector; hidden 0x10 still sets psx_hidden_passcode_flag in that same decoder; and the unnamed caller block around 0x80034c14 has distinct immediate branch behavior for eval return 0 versus nonzero before transition/setup calls. Practical consequence is that the existing JL-9 sequence remains directionally right on two-phase logic (pre-hidden gate arm then hidden/input trigger) but is now marked operationally under-specified until one live trace pins the exact player-visible producer for param_2==0x0a,param_3==4 into psx_set_debug_extra_channel_gate.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 gate-arm caller-path closure around psx_set_debug_extra_channel_gate (0x800230e4) and the exact writer at 0x800232f0. Current best read is now sequence-tight: the writer executes only in the param_2==0x0a,param_3==4 branch; the store requires psx_hidden_passcode_flag==0 && psx_level_runtime_header_state==3; and the required runtime_header_state==3 comes from the normal passcode first-char delta branch at 0x8003ed58 rather than special hidden/sibling passcode branches. Practical closure remains two-phase (normal non-hidden state-3 prime -> gate-arm event -> hidden passcode -> input code 0x1e) with one bounded remaining gap: naming the exact player-visible producer for the 0x0a/4 event inside the nearby undefined dispatch block.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 RP-16 startup/default follow-up that pushed on undefined nearby init stubs, startup mode-action dispatch callsites, selected-id writer closure, active-channel writes, and level mode/difficulty tables. Current best read is tighter and still negative for startup RP-16: committed_selected_item_id has only two recovered writers (0x80039f68 reset-to-zero and 0x8002f170 table-commit sink), startup dispatch remains 8 -> (optional 2) -> 4 without a direct commit call, and scanned channel_commit_row_selected_item_id rows (0x00..0x19, table at 0x80064355 with selected byte at +9) contain no sel=0x01. Practical classification remains RP-16 not a proven startup/default weapon while preserving 0x01 as a real non-startup row.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 special-passcode priming closure pass over ?0SR/?RTN/?QQQ versus psx_level_runtime_header_state, psx_hidden_passcode_flag, and psx_debug_extra_channel_gate. Current best read is now branch-tight: ?RTN (0x0f) clears runtime-header state to 0, ?0SR (0x10) sets hidden flag to 1, ?QQQ (0x11) returns sentinel 0x12 without priming runtime-header state, and none of these specials can independently satisfy gate-arm (hidden==0 && header_state==3) at 0x800232f0; practical JL-9 closure remains a two-phase flow where gate-arm is pre-hidden and hidden/input trigger occurs afterward.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a strict executable-only 2026-04-11 JL-9 validation lane over passcode decode, input-code mapping, gate write, grant call, and selected-id commit sink. Current best read is now narrowed to one concrete blocker for an exact user-facing recipe: code proves hidden index 0x10 arm + input code 0x1e + gate read at 0x8002fff4 + late unlock(0x0d) and commit sink at 0x8002f168/0x8002f170, but still does not independently map one deterministic player-visible action that drives the 0x800232f0 writer path (psx_set_debug_extra_channel_gate, param_2='\\n' case 4) under hidden==0 && runtime_header_state==3. Practical next closure is therefore one live caller-arg probe on 0x800230e4/0x800232f0, not another broad sweep.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 lifecycle closure pass for psx_debug_extra_channel_gate (0x8006739d) and psx_hidden_passcode_flag (0x80067454) across session init, passcode decode/arm, and debug grant entry. Current best read is now explicit and condition-tight: hidden flag has bounded set/clear points (0x8003ed28/0x8002bab8 set, 0x8002b9e4 timed clear), extra gate remains one-writer/one-reader with no recovered static clear (0x800232f0 set under hidden==0 && header_state==3, 0x8002fff4 read for late 0x0d unlock), and the strongest practical JL-9 sequence is now a two-phase A->B->input flow where gate-arm occurs pre-hidden and grant trigger occurs during hidden-mode timer.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 RP-16 startup/default-init closure pass over post-load reset, mission/loadout init, difficulty/mode-transition apply, and selected-id writer coverage. Current best read is now explicit for the startup question: psx_level_post_load_runtime_reset clears committed_selected_item_id to 0 before dispatching mode actions, psx_weapon_channels_init_mode_loadout and psx_weapon_channels_apply_mode_transition_state contain no fixed selected-id 0x01 seed, and recovered fixed-immediate commit callsites (0x11, 0x12, and one context-specific 0x01) occur in gameplay/control lanes rather than the named startup initializer path. Practical classification is now RP-16 not proven startup/default weapon while still remaining a real executable-backed row with unresolved non-startup acquisition role.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 input-side closure pass for the hidden/debug JL-9 trigger path. The active database now carries conservative input-map helper promotions (0x80042ec4 -> psx_input_map_install_profile, 0x8002abb8 -> psx_input_map_set_code_to_padmask, 0x8002abe0 -> psx_input_map_update_state_for_pad, 0x8002adbc -> psx_input_map_get_code_and_edge) plus new decompiler comments at 0x80042ec4, 0x8002abe0, and 0x80012c30. Current best read is now explicit and executable-backed: psx_object_update_runtime_input_modes gates debug grant on local_14 == 0x1e; input code 0x1e resolves through an exact-match 0x32-entry map; and that code maps to mask 0x2800 in every recovered profile branch, corresponding to the practical chord R1 + Circle under the active digital pad bit layout.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 section0-slot closure pass for JL-9 legit-path testing. Current best read is now decisively tighter: psx_section0_dispatch_root_seed_marker_channel_table seeds slot 0x14 as (kind=3, channel=0x0d), psx_section0_dispatch_root_apply_packed_channel_actions dispatches kind 3 into psx_weapon_channel_unlock_and_seed_markers(channel), and shipped PSX scene-cache root records contain authored bytes with (byte & 0x3f)==0x14 across 22 maps (119 hits / 3298 scanned root records). Practical consequence is that non-debug shipped data can in fact drive the unlock(0x0d) lane; remaining uncertainty is route/timing reachability in ordinary play, not byte-path existence.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 live SLUS_002.68 passcode decode closure pass centered on psx_passcode_screen_eval_current_entry (0x80034e38), psx_passcode_decode_to_mission_selector (0x8003ec8c), and table block 0x80064bbc/0x80064bd0/0x80064be4/0x80064bf8. The pass closes the transform math (entry[1..3]-0x1b triplet match + first-char delta lane), recovers concrete table bytes from memory, and confirms special index behavior: 0x10 sets psx_hidden_passcode_flag, 0x0f clears psx_level_runtime_header_state, and 0x11 returns sentinel 0x12, with all three bypassing first-char validation. Current strongest string closure is hidden/debug ?0SR (canonical L0SR when selector is 0), plus ?RTN and ?QQQ sibling specials. Practical JL-9 consequence remains a staged hidden/debug gate path (hidden flag + input code 0x1e + psx_debug_extra_channel_gate) rather than an ordinary direct unlock lane.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 final-enable-sequence closure pass for the JL-9 hidden/debug lane at 0x8002ba9c, 0x800232f0, 0x8002fd90, and 0x8002fff4. Current best read is now explicit in executable terms: final 0x0d unlock is gated by psx_debug_extra_channel_gate read at 0x8002fff4; that gate is written only under psx_hidden_passcode_flag==0 && psx_level_runtime_header_state==3 at 0x800232f0; grant entry itself requires psx_hidden_passcode_flag!=0 plus input code 0x1e at 0x80013174; and the strongest practical outcome is a two-phase hidden flow rather than a guaranteed one-action trigger.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 RP-16 classification pass around selected-id 0x01 with direct row/acquisition/HUD evidence. Current best read is tighter in four concrete ways: row 0x01 (0x80064690) is real structured weapon-definition data (RP-16) rather than invalid filler; primary shop direct-unlock progression still runs through 03..0c and does not include 0x01; the observed shop-side 0x01 table entry sits in the secondary 0x0a..0x0e ammo-top-up branch (0x8002e32c) rather than primary unlock helper 0x8002e5f0; and HUD short-label lookup for selected weapon id remains table-driven through FUN_800455d4 (0x80064e90 / 0x80064e9c) with row-name identity still anchored by inline row bytes. Practical classification is now "real early row with legacy/startup/placeholder-like behavior" rather than "invalid/unused slot", pending one concrete non-debug acquisition writer.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 legitimate-acquisition verdict pass using emulator-grounded selected-id mapping (0x8014577e, 0x0c=JL-2, 0x0d=JL-9) as hard anchor. Current best read is now explicit by lane: normal loadout and shop direct unlock paths remain capped at <=0x0c; hidden/debug input gate still leads to the only recovered fixed-immediate unlock(0x0d) site (0x80030004); scripted packed-action dispatch remains the only plausible non-debug 0x0d exception but is still authored-data dependent and unproven in shipped section0 content; practical classification therefore remains JL-9 strongest hidden/debug-conditioned rather than presently proven normal-flow unlock.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 broad acquisition-systems pass over default loadout/init, mission transition mode apply, pickups, shops, scripted packed awards, and debug grant paths for ids 0x0d (JL-9) and 0x01 (RP-16?). Current best split is now explicit and source-backed: ordinary loadout and shop front path remain <=0x0c with no direct 0x0d; debug grant still conditionally unlocks 0x0d behind psx_debug_extra_channel_gate; scripted/pickup data-driven paths can still produce either id when authored; and 0x01 is not excluded from normal content because the shop channel map contains 0x01 in the alternate branch and low-id action commit paths also accept it.

Latest verified batch: docs/psx/jl-9-investigation.md now records a 2026-04-11 live SLUS_002.68 reconciliation pass that incorporates the user-verified selected-weapon byte map at 0x8014577e (00..0d) and tightens the old local-id-versus-row-id ambiguity. Current best model is explicitly two-domain: callers feed compact channel/local codes into psx_apply_channel_effect_and_commit_selected_item_id (0x8002ef34), then 0x8002f15c resolves through channel_commit_row_selected_item_id[(channel*10)+9] into committed row-id domain (00..0d) before 0x8002f168 stores to the nested runtime +0x1c field family that includes the selected byte at 0x8014577e. This corrects earlier shorthand that could imply direct caller-code equality with committed selected row id.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a focused 2026-04-11 live SLUS_002.68 gate-closure pass for the exact JL-9 visibility preconditions requested around psx_debug_extra_channel_gate, psx_hidden_passcode_flag, and the selected-weapon watch at 0x8014577e. Current best read is tighter in four practical ways: DAT_8006739d remains one-writer/one-reader (0x800232f0 write, 0x8002fff4 read); DAT_80067454 writer/reader roles are now bounded across decode/arm/reset/input handlers; unlock-capable channel-0x0d entry points are explicitly separated into debug bulk grant versus scripted packed-action dispatch; and normal-lane evidence still clusters at <=0x0c while non-debug shipped 0x0d authoring remains unproven. The pass also landed one conservative live rename (0x8002ba9c -> psx_hidden_passcode_arm_runtime_state) plus durability comments at 0x8002bab8, 0x80013154, 0x8002fff4, and 0x8002f170.

Latest verified batch: docs/psx/jl-9-investigation.md now captures the decisive starter-only RAM compare against the earlier all-weapons dump and retracts the previous 0x1456fc inventory-list hypothesis. The compact 0x1456fc..0x145748 0x0002..0x000b sequence is unchanged across both dumps and is therefore not the live owned-weapon list; the dynamic lane starts at 0x14574c and the strongest current field closure is now byte 0x14577e (0x0c in the all-weapons dump versus 0x02 in the starter-only dump), which executable-side passes tie to selected/committed weapon row-id state inside the nested runtime +0x1c field family. The compare also keeps 0x67944 interesting as a changing watch (0x0000000b versus 0x00000001) but downgrades it to unproven because no direct static xrefs were recovered for 0x80067944. Current best read is now channel-state ownership plus dynamic runtime current-weapon fields, not a contiguous owned-id inventory array.

Latest verified batch: docs/psx/jl-9-investigation.md now captures a focused live SLUS_002.68 ownership-model pass tied to the observed dump split (0x801456fc..0x80145748 static, 0x8014574c..0x801457d0 changed). Current best read is tighter in four concrete ways: ownership query is channel-state based (psx_marker_channel_mode_is_enabled reads psx_marker_channel_runtime_block[(channel*4)+0x34]), per-channel ammo/step state is +0x6c (via psx_marker_channel_get_mode_step_value and channel add/unlock helpers), active selected channel is byte +0x32, and commit-to-weapon resolution remains table-driven (channel_commit_row_table[(channel*10)+9] at 0x8002f15c into idx*0x26 row access at 0x800315d8) rather than a direct contiguous owned-id list. The live database also fixes a symbol collision by renaming 0x8002fd90 to psx_debug_grant_weapon_channels_and_ammo, preserving explicit post-gate extra unlock semantics at 0x8002fff4 -> channel 0x0d.

Latest verified batch: docs/psx/jl-9-investigation.md now adds a focused live SLUS_002.68 runtime-ownership pass on RAM block 0x8014574c..0x801457d0 and closes the strongest current interpretation for watched byte 0x8014577e (file offset 0x14577e). Current best read is now tighter in four concrete ways: 0x14577e sits inside the nested player-runtime +0x1c field family reached through DAT_800789f8 -> +0x8 -> +0x18 -> +0x1c; that field family is written from channel_commit_row_selected_item_id in psx_apply_channel_effect_and_commit_selected_item_id and reset in psx_set_debug_extra_channel_gate; the surrounding block shape matches heap-resident per-object runtime state initialized by psx_object_create_simple_record; and the observed byte delta 0x0c (all-weapons) versus 0x02 (starter-only) is therefore strongest as selected weapon row-id metadata, not primary ownership/ammo/HUD-cache storage.

Latest verified batch: docs/psx/jl-9-investigation.md now adds a focused live SLUS_002.68 ownership/xref pass on the user-tracked block 0x80067938..0x80067958, with direct closure on the 0x80067944 ambiguity. Current best read is now tighter in four concrete ways: 0x80067944 has no recovered static xrefs in this image under word/halfword/byte probes and is therefore not currently supported as selected-weapon-id or selected-row-id storage; 0x80067938 is reaffirmed as psx_ctor_placement_section_ptr installed by wdl_resource_bundle_load_by_index and consumed by psx_apply_deferred_control_command as constructor/deferred-control section state; nearby 0x8006793c/0x80067940/0x80067948 are input-mode dispatch state in psx_object_update_runtime_input_modes; and 0x80067954/0x80067958 are present/spec-upload draw-env state with one conservative helper promotion (FUN_800461d0 -> psx_draw_progress_overlay_and_swap_drawenv).

Latest verified batch: docs/psx/jl-9-investigation.md now closes the compact local-id versus weapon-row-id question for live SLUS_002.68 as a table-driven conversion, not a standalone arithmetic helper. The new strongest chain is caller channel/local code -> psx_apply_channel_effect_and_commit_selected_item_id(0x8002ef34) -> channel_commit_row_selected_item_id[(channel*10)+9] load at 0x8002f15c -> committed_selected_item_id -> idx*0x26 resolver at 0x800315d8 from base 0x8006466a, with concrete JL mapping local/channel 0x0b -> row 0x0c (0x80064832, JL-2) and local/channel 0x0c -> row 0x0d (0x80064858, JL-9). Three durable live comments were added at 0x8002f15c, 0x800315d8, and 0x8001d3fc to preserve this conversion model for future RAM-dump reconciliation passes.

Latest verified batch: docs/psx/jl-9-investigation.md now closes the user-reported pointer delta near selected-weapon state watches (0x80078248 in all-weapons versus 0x800782b8 in starter-only) as a render double-buffer artifact, not a weapon/inventory struct discriminator. Live SLUS_002.68 decompiles now show psx_platform_init seeding both draw-env records, paired disp-env records at +0x5c, and DAT_80067954 flipping between them in psx_present_frame_and_flip, render_reset_draw_state, and FUN_800461d0. Current practical consequence is tighter scope: this nearby pointer lane should no longer be treated as selected-weapon ownership state, and weapon identity work should stay on the channel-commit and weapon-row resolver path.

Latest verified batch: the earlier 0x1456fc / 0x145744 / 0x67944 patch-candidate story is now superseded by the starter-only compare and should be treated as withdrawn. 0x1456fc..0x145748 is static across both dumps, so it is not the live owned-weapon list; byte 0x14577e is now the strongest executable-backed dynamic selected-weapon row-id field, while 0x67944 remains only a changing watch without direct static-xref closure.

Latest verified batch: the earlier watched-value shorthand JL-?=11 has now been superseded by direct emulator verification of the selected-weapon byte at 0x8014577e: 0x0c = JL-2, 0x0d = JL-9, with the full 00..0d row-id map now captured in docs/psx/jl-9-investigation.md. This removes the older inference step for JL-2 versus JL-9 identity and shifts the remaining work entirely onto legitimate-acquisition proof and RP-16 classification.

Latest verified batch: docs/psx/jl-9-investigation.md now captures the current blocker much more precisely after another multi-lane SLUS_002.68 pass. The strongest RAM-side lead has moved decisively to dense small-byte runtime clusters around file offsets 0x133000, 0x133416, and 0x1335d4, with a weaker secondary candidate around 0x422c..0x4440; by contrast, the earlier DAT_80064355[(channel*10)+9] field is now explicitly documented as not acting like a plain final JL row id in the sampled dump. On the code side, 0x8001E37C is now promoted to psx_handle_special_input_code, which is the strongest current upstream helper for the hidden 0x1e trigger range, while the ammo-side helper family is now tighter through newly named marker/runtime helpers. The remaining blocker is now singular and concrete: one executable-side inventory/HUD anchor is still needed to prove which of the current RAM candidate regions is the real live weapon-slot table.

Latest verified batch: docs/psx/jl-9-investigation.md now captures a third targeted six-agent SLUS_002.68 cycle that sharpened both the RAM and input-code stories without yet fully closing them. The main negative result is now explicit: the candidate commit-table byte at DAT_80064355[(channel*10)+9] does not show plain 0x0c/0x0d values in the sampled main-RAM dump rows, so that exact field is not behaving like a direct final JL row id in this capture. The strongest new positive lead is elsewhere in the same dump: denser table-like 0x0c/0x0d clusters now stand out around file offsets 0x133000, 0x133416, and 0x1335d4, which are better candidates for real live inventory/slot state and should be the next RAM target. The same pass also promoted 0x8001E37C to psx_handle_special_input_code, tightening the upstream side of the hidden-passcode trigger path even though the exact 0x1e -> button-chord mapping still remains open.

Latest verified batch: docs/psx/jl-9-investigation.md now captures another six-agent SLUS_002.68 pass focused on the JL-2 ammo lane, the JL-9 debug trigger path, the 2 MiB main RAM dump, and direct inventory/HUD mapping helpers. The strongest new clarification is on the trigger story: executable evidence now closes hidden passcode active -> gated input code 0x1e -> psx_debug_grant_weapon_channels_and_ammo -> extra 0x0d unlock behind psx_debug_extra_channel_gate, but still does not prove that input code 0x1e specifically means R1 + Circle. The same pass also tightened the RAM-dump read without rejecting it: binary/Crusader - No Remorse Weapons Main Ram.bin is still plausible main RAM and now has candidate compact slot-like records near file offsets 0xA0/0xB0/0xC0, but the dump still needs one confirmed executable-side inventory/HUD anchor before it can decode the runtime weapon list. Live database cleanup in the same pass also added 0x800232f0 -> psx_set_debug_extra_channel_gate and reinforced the selected/equipped chain around 0x8002ef34, 0x8002f15c, 0x800315d8, 0x8003d02c, and 0x800424ac.

Latest verified batch: docs/psx/jl-9-investigation.md now records a fresh six-agent SLUS_002.68 pass that added a second runtime-artifact lane instead of only rechecking the executable. The new distinction is now explicit: binary/Crusader - No Remorse Memdump Weapons.bin remains a VRAM/HUD artifact, while binary/Crusader - No Remorse Weapons Main Ram.bin is plausible 2 MiB PSX main RAM but still not self-decoding enough to resolve the selected JL-? slot as JL-2 versus JL-9 without the executable-side id/name chain. The same pass also tightened the live database around the selected/equipped path with fresh comments on 0x8002ef34, 0x8002f15c, 0x800315d8, 0x8003d02c, 0x800424ac, and explicit extra-unlock naming at 0x80030004 -> psx_weapon_channel_unlock_and_seed_markers, while keeping JL-2 AMMO as the strongest current normal-lane lead.

Latest verified batch: docs/psx/jl-9-investigation.md has now been normalized after a new six-agent SLUS_002.68 pass instead of continuing to accumulate repeated follow-up narratives. The same batch adds two concrete deltas: the checked binary/Crusader - No Remorse Memdump Weapons.bin artifact now has a narrower runtime-artifact read as PSX VRAM with HUD/icon-atlas content but no direct slot-RAM proof for JL-2 versus JL-9, and the next weapon-side unknown is now better framed as JL-2 ammo/storage behavior because JL-2 AMMO exists at 0x800642b6 while JL-9 still remains the stronger extra hidden/debug-conditioned lane. The live PSX database also gained a few more small durable artifacts in this pass, including the explicit helper name psx_weapon_channel_unlock_and_seed_markers at 0x80030004 plus confirming HUD/commit comments around 0x8002f15c, 0x800323b0, 0x80042690, and the weapon-def base 0x8006466a.

Latest verified batch: docs/psx/jl-9-investigation.md now records a narrow 2026-04-11 follow-up on live SLUS_002.68 that split symbolic cleanup from runtime-artifact checking. The live PSX database now carries evidence-backed JL-lane data names (psx_hidden_passcode_flag, psx_debug_extra_channel_gate, psx_level_runtime_header_state, channel_commit_row_table, channel_commit_row_selected_item_id, committed_selected_item_id, psx_weapon_spawn_type, psx_weapon_spawn_audio_event_id, and psx_weapon_spawn_state_selector), while the checked binary/Crusader - No Remorse Memdump Weapons.bin artifact is now explicitly reclassified as a full 1 MiB PSX VRAM dump rather than slot/inventory RAM. The same pass also sharpens the next pivot if the extra hidden/debug lane remains JL-9: JL-2 now has direct JL-2 AMMO string evidence (0x800642b6) without a matching plain JL-9 AMMO peer, so the next useful unknown becomes JL-2's ammo/storage and normal-acquisition behavior rather than more blind JL-9 existence proof.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 MCP-only direct mapping proof pass for the requested chain on live SLUS_002.68: channel commit (0x8002ef34) -> committed item id load from DAT_80064355[(channel*10)+9] at 0x8002f15c -> row-indexed weapon-def access with explicit idx*0x26 stride at 0x800315d8/0x8003160c from base 0x8006466a -> concrete row split 0x0c=0x80064832 (JL-2) vs 0x0d=0x80064858 (JL-9). The note now also includes row-byte diff evidence from MCP compare (+0x24: 0x4b -> 0x0f, name-field byte 0x32 -> 0x39) and records that 0x800322b4..0x800325f8 remains only supporting UI-tail evidence (0x0121 -> 0x013f), not the primary commit/resolver path.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 MCP-only row-field consumer trace for JL-2 (0x80064832) versus JL-9 (0x80064858) on live SLUS_002.68. The new closure is lane-level: shared +0x1c=0x18 still converges through psx_weapon_def_apply_spawn_profile_by_index (0x8003d02c) into the same type-indexed active art-header bind path in constructors (0x800249f4 / 0x80024eec via DAT_800758d8), while diverged +0x24 (0x4b vs 0x0f) remains consumed as a compact transition/state selector (returned from 0x8003d02c, then used in callers like 0x80018bc4/0x80018bf8) rather than a direct base-resource pointer. Current best answer is shared base-art lane with distinct selector/state lane, and runtime capture is still required only for exact final frame/resource-token closure.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 MCP-only four-lane acquisition comparison on live SLUS_002.68 across normal loadout (0x8002f814), shop (0x8003de68), scripted grant (0x800311f4..0x800313b4), and debug grant (0x8002fd90). The strongest new discriminator is address-local and explicit: only debug grant performs the post-0x0c extra unlock call (0x80030004 -> psx_weapon_channel_unlock_and_seed_markers(0x0d)) behind DAT_8006739d read at 0x8002fff4, while the L0SR-linked gate chain remains 0x8003ed28 (DAT_80067454=1) -> 0x80013154/0x80013174 -> 0x8002fd90. Current best conclusion remains that the extra post-L0SR non-PC weapon lane is JL-9 (0x80064858, index 0x0d) rather than JL-2 (0x80064832, index 0x0c), with three conservative new comments at 0x8003de68, 0x80031344, and 0x80030004.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 MCP-only recheck of the hidden passcode to extra-unlock chain on live SLUS_002.68. The practical read is tighter: hidden decode branch at 0x8003ed28 sets DAT_80067454, runtime input gate at 0x80013154/0x80013174 reaches psx_debug_grant_weapon_channels_and_ammo, and the extra late unlock remains a second gate (DAT_8006739d at 0x8002fff4) for index 0x0d. Current direct conclusion remains that the extra late unlock lane maps to JL-9 (index 0x0d) rather than JL-2 (0x0c), with the remaining closure target narrowed to one direct UI label-resolver chain plus full DAT_8006739d writer-context classification.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 MCP-only pass that tightened the unresolved 0x800323xx lane and selected-id tail evidence in live SLUS_002.68. The lane is now anchored as render-mode UI state via psx_render_mode_dispatch (0x800350a8) and callback table 0x800648b4, with psx_ui_state_handler_322b4_color_cycle driving DAT_800678f8 from 0x80064880 and a terminal toggle 0x0121 -> 0x013f, then consumed by psx_hud_draw_selected_item_tile_bar at 0x800424ac. This batch also landed conservative naming/comments (0x8003ddcc, 0x800424ac, and comments at 0x800323b0, 0x800323e4, 0x80042690) and keeps the strongest current JL read as selected-id-backed (JL-2 ~ 0x0121, JL-9 ~ 0x013f) while direct channel-number equivalence remains a dedicated follow-up target.

Latest verified batch: docs/psx/jl-9-investigation.md now includes a 2026-04-11 shipped-map weighting follow-up that keeps executable-side evidence authoritative and uses scene-cache evidence as support. Current best read tightens one practical decision: JL-2 remains the stronger normal-lane shipped candidate (0x0c), while JL-9 remains the stronger exceptional/debug-conditioned lane (0x0d behind DAT_8006739d). The pass also leaves concrete continuation anchors: current DAT_8006739d writer condition at 0x800232f0, late-mode candidate range (46..58 and 63) from 0x80063e68, and dense section0 cache targets (map 46/49/63) for direct placement correlation.

Latest verified batch: docs/psx/jl-9-investigation.md now records a focused live SLUS_002.68 row-to-consumer pass that resolves the earlier JL-9 selector ambiguity. Current best read is tighter in three concrete ways: the candidate pair is corrected to JL-2(+0x24=0x4b) versus JL-9(+0x24=0x0f) while both keep +0x23=0x0e; both rows still converge through shared +0x1c=0x18 into the same type-indexed base art bind path (psx_weapon_def_apply_spawn_profile_by_index -> object constructors -> psx_type_art_active_header_bank[type]); and the +0x24 consumer lane is now evidenced as transition/spawn-state-facing rather than direct bundle-id-facing. Remaining closure stays narrow: runtime capture is still required to export final JL-9 frame/resource identity with certainty.

Latest verified batch: docs/psx/jl-9-investigation.md now adds a direct UI/state disambiguation pass for the hidden-passcode "all weapons received" outcome on live SLUS_002.68. The previously suspicious 0x800323xx lane is now recovered as render-mode UI color/flash handling (psx_render_mode_dispatch callback table at 0x800648b4, 0x80064880 halfword ramp into DAT_800678f8, consumed by FUN_800424ac tile-color writes), not weapon-name display/selection logic. The strongest identity proof now sits in the commit path: psx_apply_channel_effect_and_commit_selected_item_id commits DAT_80064355[channel*10], channel 0x0d row at 0x800643ce stores item id 0x0d, and weapon-def index 0x0d is row 0x80064858 (JL-9) versus index 0x0c row 0x80064832 (JL-2).

Latest verified batch: docs/psx/jl-9-investigation.md now includes a narrow 2026-04-11 reconfirmation pass over hidden passcode decode and late weapon unlock gating in live SLUS_002.68. The new evidence closes two practical points: DAT_8006739d usage in this image is now exhaustively bounded to one writer (0x800232c0) and one reader (0x8002fd90), and the extra conditional unlock call in psx_debug_grant_weapon_channels_and_ammo is now tied to index 0x0d as the post-0x0c final JL lane, strengthening the JL-9-over-JL-2 conclusion for the hidden/debug route while keeping one explicit caveat that a single direct UI label resolver chain was not recovered in this pass. This batch also landed small durable artifacts in the live database: FUN_8003ddcc -> psx_shop_entry_get_mode_gated_cost_by_slot, new thin wrappers psx_script_dispatch_packed_channel_actions_from_object (0x800203b0) and psx_script_dispatch_marker_mode_action_from_byte (0x800203ec), and targeted decompiler comments at 0x8003de68, 0x8002fff4, and 0x80064858 to preserve the 0x0c (JL-2) versus 0x0d (JL-9) acquisition split.

Latest verified batch: docs/psx/jl-9-investigation.md now consolidates the focused live SLUS_002.68 JL-9 / hidden-passcode / debug-leftover sweep instead of leaving those results spread across subagent-only Ghidra edits. The live PSX database now has a tighter weapon-side helper family (psx_weapon_marker_activate_by_index, psx_weapon_marker_add_with_cap_by_index, psx_weapon_def_get_u16_with_mode_gate, psx_weapon_def_apply_spawn_profile_by_index, psx_weapon_shop_try_apply_entry, psx_debug_grant_weapon_channels_and_ammo, and the passcode decoder/generator pair), and the practical read is sharper in four ways: JL-9 is now closed as a real final indexed PSX weapon-definition row rather than a stray string; the hidden passcode decoder is now directly recovered as transformed table logic instead of only inferred from folklore; the strongest current how do you get JL-9 answer is a hidden passcode branch that sets DAT_80067454 and then reaches the bulk weapon-unlock helper's extra late channel; and the remaining PSX gaps are now narrower again, concentrated in exact channel -> JL-9 proof, exact sprite/frame/resource mapping, and exact level-placement correlation rather than in the broader existence question.

Latest verified batch: docs/psx/map-rendering.md and docs/psx/map-viewer-plan.md now capture the next six-agent PSX table-typing pass rather than another broad sweep. The live database now promotes DAT_80067938 to psx_ctor_placement_section_ptr, DAT_800676d8 to level_clut_table_ptr, DAT_80067840 to psx_control_opcode_stream_table, and DAT_80063e54/0x80063e68 to paired per-level selector/channel tables, while the earlier DAT_800675ec marker/control runtime block now has a stronger local field map centered on +0x34, +0x6c, and +0x88/+0x8c. Current best read is tighter in three practical ways: the constructor-placement section is now clearly a section-pack root with subordinate indexed control rows rather than one opaque blob; the CLUT and opcode-stream tables are now pushed off the shortlist of direct 0x0042 art discriminators and into palette/control support; and the real remaining structural blocker family is now the level-indexed 0x63e54/0x63e68/0x675ec control island plus the exact installed rows fed from the decompressed/runtime-bank install chain.

Latest verified batch: docs/psx/map-rendering.md now records a storage-mapping pass on live SLUS_002.68 that stayed off broad draw-path analysis and traced ownership from WDL section installs through compressed-state unpack into runtime banks consumed by type 0x0042 object creation/presentation. The live database now also carries four small evidence-backed names in this lane (FUN_8003b00c -> psx_lzss_unpack_into_level_buffer, FUN_8003aba8 -> psx_lzss_pack_level_buffer, DAT_8006b5d8 -> psx_level_state_compressed_blob, DAT_8006763c -> psx_level_heap_cursor) plus targeted comments at 0x80039af0 and 0x800249f4. Current best read is tighter in one practical way: the map-storage ownership chain is now concretely anchored from level-load section pointers to constructor/draw-time bank consumers, and the remaining blockers are narrowed to unresolved subordinate table schemas and per-item map-104 0x0042 resource/state correlation.

Latest verified batch: docs/psx/map-rendering.md now captures a focused PSX type-policy provenance pass around DAT_800675f8 / psx_type_policy_table_ptr for map 104 type 0x0042 and control type 0x0066. The live SLUS_002.68 database now adds one safe reader rename (0x8001408c -> psx_update_nearest_policy80_contact_marker) plus targeted comments at 0x800398f0, 0x8002bf0c, 0x80041604, and 0x800140c8 that pin installation and major consumer roles. Current best read is tighter in three practical ways: pointer provenance is now explicit as level-load section-pack storage (single writer at 0x800398f0 in wdl_resource_bundle_load_by_index), consumer coverage now extends beyond the older 0x1000/0x0600/0x2000 set to additional policy bits (0x0008, 0x0010, 0x0020, 0x0080, 0x0100, 0x0800, 0x4000, 0x8000), and the fixed map-104 sample rows (25/30/31/35/85/86 and control 53) still show runtimeDiagnostic.typePolicy.word=null, confirming concrete row-word capture remains a runtime export gap rather than an executable-static decode gap.

Latest verified batch: docs/psx/map-rendering.md now captures a focused object-local route-bit provenance pass for fixed map 104 0x0042 sample items 25/30/31/35/85/86 at the decisive obj+0x1c & 0x0400 branch in psx_object_integrate_motion_and_route_visible. Current best read is now stricter and evidence-backed: psx_object_create_simple_record (0x80024b48) and psx_object_create_compound_record (0x80025040) remain the strongest object-local writers because they copy authored u5 directly into obj+0x1c; inspected named mutators in the same lane (psx_type42_transition_selector_tick, psx_object_select_state_from_transition_table, psx_object_advance_state_script, psx_apply_deferred_control_to_live_objects, psx_object_handle_control_pair_0a) change other route/control bits but did not reveal a direct object-local 0x0400 set/clear transform; and recovered 0x0400 writes remain nested/global (psx_object_state_machine_dispatch_tick nested runtime write at 0x8001a078, global policy write in psx_object_handle_control_pair_0a at 0x80022a14). The remaining gap stays narrow: a live capture is still required to close object-local 0x0400 provenance for this sample pack.

Latest verified batch: docs/psx/map-rendering.md now records a focused frame-geometry pass on active SLUS_002.68 following the selector/latch bridge into exact width/height/origin consumers. The live evidence chain is now explicit from psx_object_select_state_script (obj+0x9e install) and psx_object_advance_state_script (obj+0x94 latch) into psx_project_object_main_visible / psx_project_object_special_visible_queue, then into psx_resource_frame_origin_x/y and psx_resource_frame_width/height. Current best read tightened one step further: for the fixed map 104 0x0042 sample pack, 64x40 versus 64x64 is most strongly a live frame-token (obj+0x94) outcome within a shared type resource lane, not a late presentation modifier; the remaining closure task is a compact live sample of bound-resource kind plus latched frame token for items 25/30/31/35/85/86.

Latest verified batch: docs/psx/map-rendering.md now captures a broad but concrete table-inventory pass against live SLUS_002.68 focused on unresolved map 104 / type 0x0042 storage and rendering coverage. The live database now adds six marker-channel/runtime-state helper names (0x8002f190, 0x8002f250, 0x80031840, 0x8003185c, 0x80031878, 0x80031a3c) and targeted table comments on 0x80063e68, 0x800675ec, and 0x80063e54. Current best read is tighter in two practical ways: the known descriptor/transition/runtime-bank tables are reaffirmed as shared/generic infrastructure rather than a missing unique 0x0042 fork, and the 0x80063e54/0x80063e68/0x800675ec level-indexed control island is now promoted as a high-value unresolved table family worth explicit struct/table mapping in the next batch.

Latest verified batch: docs/psx/map-rendering.md and docs/psx/map-viewer-plan.md now capture another six-agent concrete map 104 0x0042 pass over the same fixed sample pack instead of broadening the search surface. The live PSX database now also names two selector-overlap probes, the runtime snapshot/release helpers, and a wider root marker/channel helper family. Current best read is tighter in three practical ways: the 64x64 versus 64x40 split still looks more like shared-resource / different-frame-state behavior than a different constructor bind path; the selector-to-frame bridge is now explicit through obj+0x9e install, obj+0x94 latch, and the later frame-geometry consumers; and the stage-1 versus stage-2 branch point is now explicit in psx_object_integrate_motion_and_route_visible, even though the exact live 0x0400 provenance for this sample pack still needs capture. The next map 104 pass should therefore stay on items 25/30/31/35/85/86 and capture bound resource identity plus live frame/state and route-bit state at the decisive branch instead of widening heuristics.

Latest verified batch: docs/psx/map-rendering.md and docs/psx/map-viewer-plan.md now capture the first concrete map 104 0x0042 runtimeDiagnostic follow-up against exported scene items rather than another generic six-track theory pass. The live PSX database now names the spawn-side selector bridge (psx_transition_spawn_and_seed_selector_from_record), a root-family decoder helper (psx_section0_dispatch_root_find_marker_record_by_channel), two nearby resource-upload helpers, the type-policy pointer (psx_type_policy_table_ptr), and the transition row tables (psx_type_transition_mode_policy_rows, psx_type_transition_selector_rows). Current best read is tighter in four practical ways: the root and constructor section-0 families now have explicit named entry points but still converge through the same shared 0x0042 descriptor row; constructors are now proven to seed obj+0x1c by directly copying the authored lane word, so exported initialWord values are meaningful authored state; the strongest recovered 0x0400 control is still nested-state-side rather than a direct object-local 0x0042 writer; and DAT_800675f8 is now better modeled as a level-loaded per-type policy pointer, not a per-lane discriminator. The next map 104 pass should therefore sample bound-resource identity plus live frame/state against the fixed item set (item:25/30/31/35/85/86) rather than widening donor logic or revisiting descriptor speculation.

Latest verified batch: docs/psx/map-rendering.md, docs/psx/map-viewer-plan.md, and map_renderer/src/lib/psx-cache.js now capture both sides of the next PSX narrowing step. The live Ghidra work stayed split across six non-overlapping 0x0042 tracks, and the viewer exporter now serializes the resulting channel model as a per-item runtimeDiagnostic payload in scene version psx-runtime-record-probe-v10. Current best read is now operationally tighter: the next map 104 pass no longer needs to rediscover which fields matter, only to populate the exported channels for representative 0x0042 items with live evidence for pre-latch selector dispatch, latched state, object-local route flags, nested runtime state, resource kind, and the live type-policy word.

Latest verified batch: docs/psx/map-rendering.md, docs/psx/map-viewer-plan.md, and docs/psx/psx.md now capture another six-track live SLUS_002.68 PSX batch with deliberately separate coverage areas instead of overlapping helper sweeps. Current best read is tighter in four ways: the per-type art/cache pair is now named by behavior (DAT_800758d8 = psx_type_art_active_header_bank, DAT_800758c8 = psx_type_art_built_resource_bank); psx_type42_transition_selector_tick now has an early eligibility gate through psx_object_is_within_view_margin before it can emit selector 3/4 ahead of the later latch copy; the root-dispatch-side 0x0042 mode gate still looks control-only rather than a distinct map-facing presentation family; and the anonymous control-island recovery now proves 0x0400 writes in the wider nested runtime state machine and related policy controls without yet pinning a direct object-local obj+0x1c |= 0x0400 writer. The next 0x0042 discriminator is therefore narrower again: a concrete runtime sample now needs to separate pre-latch selector dispatch, latched obj+0x94, object-local obj+0x1c, nested runtime state words, and bound resource kind instead of treating them as one flat route/state bucket.

Latest verified batch: docs/psx/map-rendering.md, docs/psx/map-viewer-plan.md, and docs/psx/psx.md now capture the next focused live SLUS_002.68 follow-up on unresolved 0x0042 rather than another broad render pass. Current best read is tighter in five ways: type 0x0042 is now pinned to exact descriptor-table slot 0x80063220 -> 0x800626f8; both section-0 constructor placements and root-dispatch rows still enter that same generic create/update/release family; type 0x0042 now also has a dedicated transition helper psx_type42_transition_selector_tick that can dispatch low turning selectors 3/4 before the +0x94-style runtime latch copy; obj+0x1c writer behavior is clearer because constructors seed it from authored u5 while psx_object_select_state_from_transition_table only mutates bit 0x0002; and DAT_800675f8 now reads as policy bits (0x1000 nearby-publication suppression, 0x0600 stage-1 ordering class, 0x2000 semitrans policy) rather than as the missing main route discriminator. The remaining next-step discriminator is therefore narrower again: concrete 0x0042 samples need to correlate pre-latch selector dispatch, latched obj+0x94, obj+0x1c bit 0x0400, and bound resource kind, not just raw u5 or generic transition-row contents.

Latest verified batch: docs/psx/map-rendering.md, docs/psx/map-viewer-plan.md, and docs/psx/psx.md now capture one more six-track live SLUS_002.68 PSX pass centered on unresolved 0x0042 routing. Current best read is narrower in four practical ways: constructor and root-dispatch records both hand authored flags into obj+0x1c; 0x0020 is still the broad world-visible gate, 0x0002 still reads as orientation/extents behavior rather than a lane split, and 0x0400 is now the strongest recovered stage-2 special-visible selector; psx_object_select_state_from_transition_table now gives a concrete per-type selector source ahead of psx_object_select_state_script; psx_load_type_state_banks now reads as the DAT_800758cc/d0/d4 installer while psx_stream_install_type_runtime_banks is the packed-stream helper that can also install DAT_800758d8; and DAT_80067794 is now tighter as save/transition runtime-header state via psx_snapshot_level_runtime_header_block / psx_apply_level_runtime_header_block, not as the missing 0x0042 art-binding source. The next executable-backed discriminator is therefore more specific again: sample representative map 104 0x0042 objects through obj+0x1c, obj+0x10, obj+0x9e, and obj+0x94, plus the DAT_80063b4c transition-table row for type 0x0042, instead of spending another batch on raw u5 or descriptor-table speculation.

Latest verified batch: docs/psx/map-rendering.md and docs/psx/map-viewer-plan.md now consolidate the full six-track live SLUS_002.68 PSX sweep instead of leaving the result fragmented across individual helper passes. Current best read is narrower in a way that changes the next execution order: unresolved 0x0042 is no longer plausibly blocked on a missing unique per-type descriptor fork or on HUD/overlay presentation behavior. 0x0042 still shares the generic 0x003e..0x0050 descriptor cluster, constructor-placement 0x0042 still reads as a compound -> advance-state -> main-visible route inside that generic family, both world-facing lanes choose sprite versus image-table submitters from the bound resource header kind, and the HUD/overlay lane remains an explicit non-map-facing exception that can branch from overlay-slot policy instead of normal world-object kind checks. The next practical discriminator for viewer recovery is therefore representative runtime-bank/state/resource-kind evidence for map 104 0x0042 families, especially the split between constructor-placement u5=0x0020 and root-dispatch u5=0x0030/0x0022, not more broad donor reuse or descriptor-table speculation.

Latest verified batch: docs/psx/map-rendering.md now records a focused live SLUS_002.68 world-frame/render-wrapper cleanup around 0x80031f0c, 0x80031f9c, 0x800320bc, 0x80039dc4, 0x8003977c, and 0x800391f0. The live PSX database now names 0x80031e0c as psx_lset_session_loop, 0x80031f0c as psx_lset_world_frame_wrapper, 0x80031f6c as psx_lset_session_teardown, 0x800350a8 as psx_render_mode_dispatch, 0x80039ef4 as psx_level_post_load_runtime_reset, and 0x80044104 as psx_present_frame_and_flip, with direct technical comments set at the same loader/bank/runtime-header anchors. Current best read is tighter for reconstruction work: this lane now provides a clean evidence-backed chain from map-index bundle load and per-type bank install through runtime-header application to per-frame world visible draw and display flip, reducing ambiguity between storage decode and final presentation wrappers.

Latest verified batch: docs/psx/map-rendering.md now records a focused live SLUS_002.68 main-visible ordering/update cleanup around 0x8001263c, 0x80012c30, 0x8002d59c, 0x8002d778, 0x8002ca74, and 0x8002e064. The live PSX database now has the missing parent function object covering the 0x80012b44/60/c0/f0 lane (psx_object_integrate_motion_and_route_visible) plus explicit helper names/contracts for psx_object_update_runtime_input_modes, psx_main_visible_list_swap_entries, psx_main_visible_order_graph_unlink_pair, and psx_main_visible_order_graph_detach_object; direct technical decompiler comments were also applied to the update/rebucket/sort call sites and sort entry points. Current best read is tighter for exporter coherence: object update now cleanly resolves into state advance -> optional projection -> conditional rebucket -> optional nearby-interaction publish, while stage-1 draw submission remains refresh-gated and dependency-sorted before psx_draw_world_visible_passes consumes the slice.

Latest verified batch: docs/psx/map-rendering.md now captures a focused live SLUS_002.68 resource creation/submission cleanup around 0x80044434, 0x800444e4, 0x80044614, 0x80044bdc, 0x80044e9c, and 0x80045ffc. The live PSX database now also renames 0x800445c8 to psx_overlay_slot_clone_bound_resource and 0x80044fa4 to psx_resource_release_image_vram_slot_if_needed, with stale "verified by subagent pass" comments replaced by technical comments in the local HUD/overlay lane. Current best read is tighter for viewer art binding: kind 5 is the image-table submit path, kind 4 is the single-image bound sprite path, and the special-visible lane remains palette-override-distinct from main-visible despite sharing the same kind discriminator.

Latest verified batch: docs/psx/map-rendering.md now records a focused live SLUS_002.68 interaction/reselection cleanup around psx_type4_reselect_motion_state and psx_object_update_nearby_interactions. The live PSX database now names 0x80028050 as psx_object_test_strict_nonoverlap_flag8_pair, 0x800281d4 as psx_object_test_strict_nonoverlap_flag8_subject, 0x80028700 as psx_object_adjust_param9c_by_view_side, 0x800287bc as psx_object_update_param9c_from_contact_target, 0x80028eb4 as psx_object_apply_contact_push_bias, and 0x8002923c as psx_object_spawn_type11_contact_proxy, with concise technical decompiler comments added at each entry. Current best read is tighter for exporter work: post-spawn contact handling in this lane mutates runtime extents/width state (+0x30..+0x38, +0x9c) and can spawn type-0x11 contact proxies in-flow, so unresolved-family art fallback logic should continue to model these as runtime interaction effects rather than as static constructor-placement fields.

Latest verified batch: docs/psx/map-rendering.md now records a focused live SLUS_002.68 presentation-lane cleanup around the HUD/overlay pass and adjacent helpers. The live PSX database now names 0x80035cc0 as psx_overlay_slot_create, 0x80036000 as psx_overlay_slot_release, 0x80038114 as psx_overlay_slot_step_color_fade, and 0x800388a8 as psx_hud_overlay_init_resources, with direct technical decompiler comments replacing one earlier generic "verified by subagent pass" note at psx_draw_hud_overlay_pass. Current best read is tighter for viewer work: psx_level_session_loop -> psx_hud_overlay_init_resources seeds HUD resources during level-session startup, psx_draw_world_visible_passes still executes world stage-1 then stage-2 lanes before calling psx_draw_hud_overlay_pass, and the psx_overlay_slot_* table is a non-map-facing presentation queue layered after world routing rather than a source of authored map geometry. The practical implication is narrower false-match risk: unresolved map-family art fallback should not reuse evidence from this overlay slot lane, because these slots are UI/presentation primitives independent of section-0 map record dispatch and world-object projection.

Latest verified batch: docs/regret-hidden-debugger-investigation.md now also records the debugger-side cleanup pass after the first .unk loader/runtime split, the final exhaustive Regret-side caller sweep, and the first practical seeding/simulation model. The live REGRET.EXE database now has the source-pane constructor/pointer/draw/viewport methods, the source-buffer create/load/split/destroy chain, the breakpoint-table helpers, the current-entry push/pop helpers, the interpreter saved-farptr helpers (13f0:0000/003c), the interpreter-context create/init pair (13f0:00e8/0244), the shared slot-chunk accessor at 13f8:1d72, and the named interpreter wrapper at 13f8:10da that feeds usecode_debugger_interpreter_hook. The practical consequence is sharper than before: the remaining blocker is not can we export readable source or even can compiled usecode carry line numbers, because retail Remorse already can, and it is no longer what else in Regret might still be debugger-related. The remaining blocker is now narrowly where inside the already-identified interpreter dispatcher/runtime path does Regret seed the current-entry stack, and how can that same engine-side path be reused or reproduced for stable RUN/step behavior, with the strongest current simulation route now being a small in-process reuse of existing VM context data rather than blind external memory poking or offline-only source-file tricks.

Latest verified batch: docs/jp-remorse-hidden-debugger-investigation.md now records the first debugger-focused comparison pass on /ja/CRUSADER.EXE. Current best read is narrower than the No Regret result but still decision-relevant: the JP Win32 build clearly retains broad executable cheat/debug machinery, yet live byte searches on the active image found no hits for the classic hidden usecode-debugger UI bundle (Goto Line, Watch what?, Inspect what?, Global name, Search for, FILE NOT FOUND, Unable to open this file, Nothing to find, Not found, Done) even though the same method still recovers positive-control strings like JASSICA16, Immortality enabled., and Cheats are now active.. The practical consequence is that JP currently strengthens the broad Win32 cheat/debug preservation story, but not the JP preserved the missing retail debugger bootstrap theory; No Regret remains the stronger sibling-build anchor for the hidden-debugger unlock problem.

Latest verified batch: docs/regret-hidden-debugger-investigation.md now records the forcing-options pass as well as the structural recovery. Current best read is now split cleanly between the analytical and practical sides: analytically, Regret still matters because it recovers the missing writer/bootstrap and the live 1480:6972 vtable override; practically, it also matters because it is now the first build where a debugger bring-up looks realistically forceable without rebuilding the subsystem. The current ranked Regret-side forcing order is: small executable patch into usecode_debugger_open_modal or the break/step auto-open path first, live memory forcing only if the debugger object already exists second, and -u / custom EUSECODE.FLX only as a hybrid context-generator after code or memory has already armed the debugger. That means Regret is now both the best comparison anchor for retail and the best live hack target if the immediate goal is simply to make the menu appear.

Latest verified batch: docs/retail-debugger-entry-options.md now reopens the hidden-debugger entry question with the stronger current live database instead of treating it as only a patch-history problem. Current best read is now sharper in a way that affects next-step choice: fresh live data-use recovery still shows no recovered writer for 1478:659c/659e, fresh decompiles of usecode_debugger_open_for_current_unit, usecode_debugger_open_modal, usecode_debugger_gump_create, and usecode_debugger_handle_event confirm that the debugger UI/event bundle is real but only useful after a valid break-state object and gump already exist, and the retail -u override remains the lowest-risk non-EXE experiment surface without yet proving a script-visible bootstrap for that object. The practical consequence is that the preferred next move is no longer more speculative retail patching first; it is a focused No Regret / JP comparison for a surviving debugger bootstrap/writer, with -u-backed EUSECODE experiments held as the least invasive indirect test surface.

Latest verified batch: docs/startup-map-patch-file.md now closes the long-standing startup string Using map patch file. tightly enough to stop treating it as a vague debug/status artifact. Current best read is that Init_Everything prints that line only when static\fixed.dat exists, and the later fixed-map cache path then prefers the loaded static\fixed.dat archive handle over the base fixed.dat handle for map/fixed-object reads. The remaining uncertainty in this lane is now narrow: whether any later consumer does a finer-grained fallback/merge than the first recovered chooser, not what the startup line is referring to in the first place.

Latest verified batch: docs/psx/psx.md, docs/psx/map-rendering.md, docs/psx/map-viewer-plan.md, and docs/psx/art-binding-recovery.md now tighten the PSX render-side model another step in both Ghidra and the viewer exporter. The earlier DAT_800758d4 consumer finding remains intact and is still wired into the viewer-side cache path as explicit companionExtents metadata, but the bigger practical change in this batch is the first measured art-binding recovery pass for the viewer exporter: the PSX cache builder now treats large zero-block DAT_800758d8 constructor-placement bands as inherited-art candidates, first via same-map DAT_800758cc script-signature donors and then via a constrained nearest-donor fallback inside the current 0x003e..0x0064 family. That rebuild moved the scene set from 58,262 fallback items / 1,714 bundle-mapped items to 25,038 fallback items / 34,938 bundle-mapped items, making early representative maps such as 0, 9, and 43 mostly real-art while leaving map 104 and the remaining 0x0042 / 0x0055..0x0063 constructor-placement band as the clearest unresolved outliers. The newest live follow-up now sharpens the next branch enough to change execution order: psx_draw_main_visible_object applies authored palette overrides only for type bands 0x003e..0x00ab (source+0x06 high byte) and >=0x00ac (source+0x0c high byte), psx_draw_special_visible_queue skips those overrides entirely, and psx_sprite_resource_submit_frame versus psx_image_table_submit_frame resolve the same high-byte token through different CLUT tables. The latest coherence pass narrows that again in a way the exporter has to respect: psx_level_session_loop installs CLUT tables during level load via wdl_resource_bundle_load_by_index -> level_palette_header_apply -> level_palette_upload_cluts, both constructors bind the drawable resource at spawn from DAT_800758d8, psx_object_integrate_motion_and_route_visible advances state and routes objects into stage-1 versus stage-2 visibility, and psx_main_visible_list_sort_range dependency-sorts the stage-1 slice before draw submission. The newest six-track subagent sweep closes two more structural gaps: 0x0042 still shares the generic descriptor cluster used across 0x003e..0x0050 instead of owning a unique descriptor fork, and the root-dispatch u5=0x0022 versus u5=0x0030 split currently looks like a main-visible presentation/orientation variant rather than a separate draw lane. The viewer-side donor fence now reflects that narrower read: mixed-family and mixed-u5 provisional donor merges for unresolved generic-family types are blocked, so map 104 0x0042 is back on explicit placeholders instead of one shared false wall. The practical remaining gap is therefore narrower now: not "why are most PSX scenes placeholders" and not even just "which palette index is right", but "which runtime-bank/state/resource-kind combination explains the remaining 0x0042 presentation families without reopening broad donor heuristics."

• Overall useful decompilation progress: about 59%
• Reasonable uncertainty band: about 56% to 64%
• Top 100 far-call target coverage: about 86%
• Segment spread with meaningful analysis: about 34% to 40%
• Tooling maturity for continued work: about 83%

Measured live naming floor for CRUSADER.EXE right now:

• total functions: 3032
• non-anonymous functions: 1795
• remaining FUN_/nullfn_ placeholders: 1237
• raw named-function coverage: 59.2%
• largest current anonymous segment clusters: 1000 (166), 10e8 (62), 1190 (35), 13e8 (23), 13c8 (22)

Why The Estimate Moved

• The NE CRUSADER.EXE database now has materially more named functions, better caller-role coverage, and broader comment-backed provenance than when this tracker was first drafted.
• The startup/display lane is no longer a top active section. Its outer ownership and control flow are stable enough that it should stay closed unless new caller evidence changes the model.
• The cheat/debug lane is also much tighter: the jassica16 latch, the broader -laurie gate, the ~ runtime toggle, the F7-family overlays, the F10/Ctrl behavior, and the 0x410 CD-transfer-display branch are now separated well enough that this lane is mostly documentation and cleanup, not architecture recovery.
• The USECODE/VM lane has moved from broad structure guesses to a partial runtime model: core loader/runtime helpers are named, owner-loaded slot arithmetic is verified against extracted corpora, several masked-create helpers have real contracts, and the major remaining uncertainty is now the upstream selector/caller path rather than the storage format itself.
• The map-renderer crosswalk lane also removed a lot of lingering shape ambiguity by closing more controller/helper families directly from extracted corpora plus scene evidence.
• The combat-tactic data lane is also now materially tighter: COMBAT.DAT is no longer just a named-tactic hint source, but a documented bytecode archive with stable per-record names, verified block structure, a decoded shipped opcode subset, and a practical family-level behavior map for the Dumb, Pivot, Advance, Careful, marker-shuttle, and step-out-shoot tactics.

Current Verified State

Primary Tracking Assets

• crusader_segment_coverage_ledger.csv remains the main executable-wide coverage tracker and should be updated after each verified batch.
• crusader_decompilation_notes.md is an index, not the place for long-form analysis.
• CRUSADER.EXE remains the default live Ghidra target.
• Verified CRUSADER-RAW.EXE work remains a supporting evidence base for ports, naming provenance, and caller/context cross-checks.

Strong Or Stable Areas

• seg001 gameplay/input/projectile work is stable enough to support verified raw-name ports into live NE work.
• The raw 0007 rendering/camera/tile-visibility lane has a strong structural map and now acts more as supporting evidence than as a primary unknown.
• The 0008 dispatch-helper and 000c state/transition lanes have broad partial coverage, including enough caller-side structure to support practical NE naming work.
• The VM/USECODE lane now also has one earlier compiled-side producer anchored beyond the old direct Item_GetDamaged / StorageDataProcess_Run callers: AreaSearch_CollideMove is now verified as a paired 0x20b / 0x20c collision-process producer, and the local seg031 queue helpers are named structurally in the live database.
• That same collision-storage producer surface is now wider too: current direct callers are all movement/physics/animation-side (Item_LegalMoveToPoint, Item_LegalMoveToPointWithCollisionInfo, gravity, animation, supersprite, and fast-area gravity cleanup), and no verified non-collision producer reaches the 0x236 queue yet.
• The movement/collision lane is tighter at the helper level too: the step-aware seg029 sweep wrappers, the seg031 release-side queue cleanup pair, and the adjacent seg090 directional cache-offset helper are now named in the live database, so the remaining uncertainty in this lane sits earlier in caller policy rather than in the local helper layer.
• The startup/display lane is materially closed. Shared dispatch-entry ownership, seg126 file-backed control flow, seg127 fade control, and the surrounding palette/presentation helpers are now understood well enough that they should not stay in the live critical path.
• The cheat/debug lane is mostly closed at the behavior level. The secret-sequence matcher, broader cheat gates, F7 overlays, F10 modifier path, Ctrl+L location popup, Ctrl+Q = 0x410 CD-transfer-display toggle, -debug, and -laurie are all separated far more cleanly than before.
• The hidden usecode-debugger lane is now structurally understood as a layered orphaned subsystem: seg109 UI pieces, seg1408 break-state helpers, and the seg1418 interpreter handoff are no longer conflated.
• The USECODE/VM lane now has a workable compiled-side model around entity_vm_runtime_create, entity_vm_runtime_owner_resource_create, entity_vm_context_create_from_slot_index, the masked-create hub at 000d:463a, the persistence/load helpers, and the owner-loaded slot/value arithmetic.
• The owner-loaded body/range model is no longer speculative. Class-selection uses class_id + 2, header/subentry math matches extracted corpus output, and concrete body windows for NPCTRIG, EVENT, and related families are now verified.
• The map-renderer/documentation lane now has a stronger shape/controller crosswalk. Recent closures include CRUMORPH, NPC_ONLY, WATCHNS, WATCHEW, CRYOBOX, CRAZYEW, CRAZYNS, VIDEOBOX, PANELEW, GENERATR, and cross-game DEATHBOX, with viewer-side links kept conservative where actor-side state is still runtime-only.
• The command-line/startup lane is much tighter across both games: -warp <mission> [x y z], -mapoff, -egg, startup teleporter selection, and the -u EUSECODE root override all now have practical behavior models instead of folklore-level descriptions.
• The PSX lane is no longer just side inventory. Retail/pre-alpha bundle loading, mission-briefing/passcode structure, the reduced-content pre-alpha disc, and now the retail map object's last projection stage all have dedicated notes and enough stable naming to support future targeted passes.
• The Remorse class-lift preparation lane now has a usable document cluster: overall plan, candidate inventory, endpoint spec, ABI constraints, family notes for EntityDispatchEntry and SpriteNode, a conservative Entity family split, a VM runtime/owner-resource layout note, a compatibility-header draft, and one grouped resume index.
• The same class-lift prep lane is now more execution-ready: the 0x4588 broker family has its own focused object note, the toolchain story has a dedicated fingerprint-evidence note, and there is now a concrete first-batch class-authoring checklist ready for the first MCP-backed namespace/struct/vtable pass.
• The live Remorse class-authoring lane now also has its first bounded NPC AI family lifted as class owners instead of flat process names: Remorse::NPCActionProcess plus StandProcess, PaceProcess, SurrenderProcess, GuardProcess, and LoiterProcess now exist in-session with their direct create/run/destroy surfaces moved under class ownership, while the shared guard/loiter idle helper remains a free function on purpose until a stronger single-class owner emerges.
• The live Remorse VM class-lift lane also recovered from a decompiler breakage in Remorse::EntityVmRuntime::Create: the root cause was a hidden-return-storage allocator helper signature at 1000:42e2, Create now decompiles again, and the provisional /Remorse/EntityVmSlotEntry datatype now exists with the stable +0x1e..+0x24 buffer-pair fields named.
• The live Remorse VM class-lift lane is tighter again: the old UsecodeProcess_* context lifecycle bodies at 1420:0eec, 1420:10b6, 1420:10da, 1420:1162, 1420:118f, and 1420:1278 now live under Remorse::EntityVmContext::{CreateFromSlotIndex, FreeBuffer, SyncGlobalValueAndDispatch, Destroy, Save, Load}, with short raw 000d: provenance comments preserved on each entry.
• The same VM class-lift lane tightened one step further through local PyGhidra fallback once the live run_write_script(...) route still returned 404 No context found for request: /Remorse/EntityVmContext is now a real datatype, entity_vm_slot_entry_create_or_clear and InitSlotOwnerBuffers now carry EntityVmSlotEntry *, AcquireSlotForEntity now returns EntityVmSlotEntry *, and InitSlots / ReleaseSlots now take direct EntityVmRuntime * this.
• That pass also made the remaining blocker more precise: Create still cannot hold a fully typed far this without reintroducing hidden __return_storage_ptr__ corruption, so it was restored to the verified split-word custom-storage signature instead of forcing a broken prettier form.
• Tooling follow-up from that same batch is now clearer too: live MCP read-only Python is usable when Ghidra starts with PyGhidra enabled, but write-side repairs still had to fall back to closed-project local PyGhidra because MCP does not yet expose a constrained live write-script or equivalent custom-storage edit path.
• The live VM class-lift lane tightened slightly again in-session: 1420:19fd Remorse::EntityVmRuntime::EnsureSlotChunkLoaded now carries a real EntityVmSlotEntry * local for the acquired slot path, so the slot-entry cache tail fields decompile directly instead of through anonymous undefined4 pairs.
• The matching MCP gap is also clearer now: the old apply_class_layout dry-run null failure no longer reproduces for /Remorse/EntityVmContext, but the real write path still behaves like the older storage-preserving build. Actual apply_class_layout and direct set_function_this_type calls on the context lifecycle methods still fail with Storage size does not match data type size: 2, and live run_write_script(...) still returns 404 No context found for request even with explicit target selectors.
• Closing the GUI and dropping to the local PyGhidra fallback then landed the blocked context typing work cleanly: CreateFromSlotIndex, FreeBuffer, SyncGlobalValueAndDispatch, Destroy, Save, and Load now all carry EntityVmContext * this as their first parameter in CRUSADER.EXE, which confirms the newer dynamic-storage rewrite is sound even though the live MCP session still is not taking it.
• The next live verification pass tightened two details. First, the new checked-in storage-aware prototype endpoint still is not the build currently serving the active GUI session: direct live POSTs to /set_function_prototype_storage still answered with the legacy set_function_prototype failure body, and the alias route still returned 404 No context found for request. Second, the direct callers of CreateFromSlotIndex still mostly consume the result as a base process object, so the current conservative UsecodeProcess * return should stay in place until the inheritance-aware datatype story is explicit.
• The refreshed live MCP build moved that forward materially: set_function_prototype_storage(...) now reaches the real storage-aware implementation in-session and the active-program run_write_script(...) path now executes instead of failing with 404. The new blocker is narrower and more concrete: bare stack: offsets at 10 and above currently need 0x prefixes to preserve the intended stack slots, __cdecl16far still normalizes to plain __cdecl, and Create still cannot collapse to a single EntityVmRuntime * this because the datatype itself still resolves to a 2-byte pointer size.
• The same live batch also tightened the slot-entry class model: /Remorse/EntityVmSlotEntry now carries match_key_farptr, owner_chunk_count, and owner_data_base in addition to the earlier owner-buffer and chunk-state tails, which makes InitSlotOwnerBuffers, AcquireSlotForEntity, and EnsureSlotChunkLoaded read more like object code and less like anonymous offset arithmetic.
• The next live batch tightened the adjacent helper map too: the old unnamed 1420:1d72, 1420:1d8d, and 1420:1e17 helpers are now entity_vm_runtime_get_slot_chunk_ptr_at_offset, entity_vm_runtime_release_slot_chunk_ref, and entity_vm_runtime_try_unload_slot_chunk, which makes the slot-entry lifecycle around load, refcount release, and conditional unload materially easier to navigate.
• The latest live batch turned that helper lane into a small shared record model: /Remorse/EntityVmLoadedChunkRecord now carries the stable next_*, saved_chunk_*, slot_index, and chunk_index anchors, entity_vm_runtime_try_unload_slot_chunk now takes EntityVmLoadedChunkRecord * and returns byte in AL, and entity_vm_runtime_apply_to_matching_owner_rows now iterates over a typed loaded-chunk record instead of anonymous stack-pair scratch state.
• The adjacent interpreter-side lane is slightly tighter too: local helper 1418:003c is now interpreter_pop_saved_farptr, and the only verified Interpreter_NextUsecodeOp release path at 1418:3330 is commented as a save/restore boundary around entity_vm_runtime_release_slot_chunk_ref instead of being left as anonymous stack traffic.
• The live class-authoring state moved forward too: Remorse::EntityVmSlotEntry now exists as a real class owner in CRUSADER.EXE, CreateOrClear moved under it with an explicit this parameter and AX pointer return, and the runtime-local chunk helpers plus owner-row iterator/debug path now sit under Remorse::EntityVmRuntime instead of Global.
• The next live pass improved the runtime class surface further: GetSlotChunkPtrAtOffset now carries the recovered runtime_farptr/slot_index/chunk_index/intra_chunk_offset signature and still returns its far pointer in DX:AX, while ApplyToMatchingOwnerRows now carries the recovered runtime_farptr/slot_index_filter/chunk_index_filter signature and still returns its boolean in AL.
• The latest live pass removed the old runtime-wide 2-byte-this bottleneck for this cluster: Create, InitSlots, ReleaseSlots, DebugDumpSlotMemory, ReleaseSlotChunkRef, GetSlotChunkPtrAtOffset, TryUnloadSlotChunk, ApplyToMatchingOwnerRows, and EnsureSlotChunkLoaded now all accept an explicit 4-byte EntityVmRuntime * this through /Remorse/EntityVmRuntime *32 custom storage in-session. The remaining live type gap is narrower again: exact /Remorse/EntityVmSlotEntry *32 return/parameter typing still fails on AcquireSlotForEntity and InitSlotOwnerBuffers, so those positions are currently held as neutral dword placeholders instead of prettier but broken slot-entry pointer types.
• That slot-entry gap is now closed too, and the pointer cleanup widened beyond the runtime core: AcquireSlotForEntity now returns EntityVmSlotEntry *32, InitSlotOwnerBuffers now accepts EntityVmSlotEntry *32, EntityVmOwnerResource::{Create,Destroy} now carry explicit 4-byte this, and the simple EntityVmContext lifecycle methods now do the same. The main remaining VM signature outlier is CreateFromSlotIndex, whose argument pack still needs caller-side recovery rather than just pointer-width cleanup.
• The next family switch also landed: Remorse::UsecodeDebuggerBreakState now exists as a real class owner with a 0x2f2 provisional datatype plus a first method batch for construction, breakpoint gating, breakpoint table helpers, callstack helpers, and step-state helpers.
• That debugger batch is already tighter than the initial shell: 1408:01a5 is now verified as BreakpointRemove, 1408:02f5 is now verified as CallstackPushFrame, breakpoint entries are recovered as 0x0b inline-name-plus-line records, and callstack entries are recovered as 0x15 inline-name-plus-three-dword records even though the trailing dword semantics remain open.
• The next pass landed the debugger struct rewrite in-session too: /Remorse/UsecodeDebuggerBreakpointEntry, /Remorse/UsecodeDebuggerCallstackEntry, and the updated /Remorse/UsecodeDebuggerBreakState array layout now exist live instead of only in notes, and the only verified CallstackPushFrame caller now narrows those three trailing dwords to source_stream_target_farptr, current_frame_payload_farptr, and still-neutral aux_farptr.
• The latest debugger class-lift pass closed two more bounded gaps without overpromoting semantics: 1408:0230 now lives under Remorse::UsecodeDebuggerBreakState::BreakpointFindFirstForUnitAtOrAfterLine as the breakpoint-table lower-bound helper for (unit_name, line_number) queries, and the retail vtable root at 1478:65ab is now resolved enough to show that MaybeBreakOnCurrentLine dispatches slot 0 into a shipped no-op stub while slot 1 currently returns zero through a second inert method.
• The next debugger follow-up also closed the planned seg109 consumer pass: 13a0:0291 plus its helper 13a0:045c now show that the current callstack entry's +0x09 lane is a real source-stream cursor consumed byte-by-byte by the debugger formatter and that +0x0d is the paired current-frame payload context used for expression/watch rendering. The remaining open tail-field question is now mostly aux_farptr, not the first two dwords.
• That naming decision is now landed live rather than only in notes: /Remorse/UsecodeDebuggerCallstackEntry now names offset +0x09 as source_stream_cursor_farptr with an in-session field comment, and CallstackPushFrame now carries the same parameter name in its signature. The debugger-family residue is therefore narrower again: mainly aux_farptr, plus whether the seg109 formatter helpers deserve stable names.
• That last formatter-helper hesitation is now closed too. The seg109 consumer pair is no longer anonymous in-session: 13a0:0291 now lives as usecode_debugger_format_expression_to_shared_buffer, and 13a0:045c now lives as usecode_debugger_format_descriptor_expression. The debugger-family residue is therefore narrower again: mainly aux_farptr, plus any future evidence that the retail-stub callback slots ever had non-retail behavior.
• The follow-up retail caller pass did not widen aux_farptr either. get_callers(1408:02f5) still reports only 1418:051d Interpreter_NextUsecodeOp, that caller still pushes literal zero for the trailing field, and the current seg109 formatter consumers still read only +0x09 and +0x0d. For now the right live result is to keep aux_farptr intentionally neutral rather than invent a prettier but weak name.
• The next bounded class-family step landed too. Remorse::SpriteNode now exists live in CRUSADER.EXE, and the first strong 000b: batch is re-anchored into live 1360: by preserved offset delta from 000b:326e -> 1360:046e: Destroy (1360:046e), IsDirty (1360:0580), MarkDirty (1360:05a6), DispatchEvent (1360:0cb2), and UpdateAndDispatch (1360:12ee) are now class-owned with in-session provenance comments. The remaining SpriteNode work is narrower and safer than before: mainly the constructor side, the exact live anchor for GetOrTraverse, and later vtable/datatype authoring rather than basic family existence.
• That same SpriteNode pass also moved beyond method ownership into datatype work: /Remorse/SpriteNodeBase now names child_or_next_farptr, local_x_offset, local_y_offset, and dirty_flags, and /Remorse/SpriteNodeVtable now exists as a provisional slot shell exposing +0x14, +0x18, +0x20, and +0x24.
• The constructor side is now started too: 1360:036a lives as Remorse::SpriteNode::Create with an in-session caveat comment that preserves the remaining wrapper uncertainty. The live search for the old 000a:b988 GetOrTraverse anchor is still open, but the family no longer lacks a constructor-style entry outright.
• That remaining traversal gap is now closed too. 1360:0955 now lives as Remorse::SpriteNode::GetOrTraverse, and the decompiler comment records the currently safest read of the helper: recurse over child-linked nodes, adjust the incoming query coordinates by the local offsets, and return either the matched node or the default sentinel through the out pointer. The main SpriteNode residue is therefore structural again: constructor-wrapper split, deeper slot naming, and subtype layout boundaries.
• The next bounded-family start is now landed too. Remorse::CacheBackendObject exists live with 1250:0000 promoted as Create; the decompiler itself carries explicit old 0009:5600 segment metadata on that body, and the current comment records the 0x20-byte allocation plus file-handle/method-table initialization path. That family is still only at its constructor shell, but it is now a live class-lift lane instead of a pure inventory entry.
• The broader Tier 1 Remorse class sweep is now closed too. EntityVmOwnerResource gained two real accessor wrappers in-session (QueryMaterializationSize and MaterializeChecked) plus a corrected outer-wrapper layout (0x14 bytes total, embedded file base at +0x00..+0x07, helper vtable at +0x08, owner-row table at +0x0c); CacheBackendObject gained the first two non-constructor class methods (LoadEntryTableFromManifest and InitFixedEntryTable) plus a tighter live layout read around +0x10/+0x14/+0x16/+0x18/+0x1c; and SpriteNode::DispatchEvent now ties concrete event codes to concrete vtable slots instead of generic placeholder slot names.
• The next broader Remorse batch also has its first post-Tier-1 live foothold now. PresentationCallbackBroker is no longer note-only: 12d0:0513 and 12d0:0656 are now live as Remorse::PresentationCallbackBroker::{InitOnce, TeardownOnce} with comments tied directly to the 0x4588/0x458c/0x4590/0x4594/0x4595/0x45a6 lifecycle cluster. The same pass also clarified that WatchEntityController and DialogMenuObject still need a second re-anchor pass before any live authoring: first-pass searches on the obvious type/vtable/callback constants hit unrelated camera/process and controller-save functions rather than safe class-family matches.
• That second pass is now partly closed. The old WatchEntityController create lane maps onto the live Camera_Init / Camera_CreateProcess cluster at 1180:0000/0045, so those functions now carry provenance comments instead of a weaker forced rename; DialogMenuObject still lacks a safe live re-anchor after a second search on the obvious 0x28b5/0x27ca/0x2843 leads; PresentationCallbackBroker now has its raw 0009:b1c3 finalize-phase caller re-anchored live as allocator_phase_finalize_pass plus two preserved live slot +0x0c callers at 1278:0616 and 1320:1588; CacheBackendObject gained SetEntryNameAndTag at 1250:0910; and the widened SpriteNode::Create caller map now shows that the 0x34 allocation path is the compact shared node constructor used by many GumpCreate_* wrappers.
• The next planned pilot family also started for real: Remorse::EntityDispatchEntry now exists in-session with provisional /Remorse/EntityDispatchEntryBase and /Remorse/EntityDispatchEntryVtable datatypes, so this family is no longer just a note cluster. The remaining blocker is now concrete rather than vague: the current source note still points at older 0008: / 000d: anchors that are not yet ported back onto the live CRUSADER.EXE method objects, so the first base-method ownership move has to wait on that mapping step instead of being guessed.
• That mapping step is now partially closed too. The older 0008:ba00 base cluster ports into live 11e0: by offset, and the first base-method batch now lives under Remorse::EntityDispatchEntry: InitBase, SetSourceType, SetEventTypeChecked, SetGroupId, Unlink, and IncrementGroupId. The next blocker on this family is therefore narrower again: not whether the pilot can move methods at all, but which live segments carry the remaining word-list, timed/periodic, and runtime-state methods from the older 0008: / 000d: notes.
• The runtime-state follow-up is now partially closed too. FadeProcess_Create is explicitly tagged by the decompiler as old 000d:7e00, FUN_1440_0278 matches the old 000d:8078 release path by both offset delta and behavior, and both now live under Remorse::EntityDispatchEntry as InitRuntimeState and ReleaseRuntimeState with a new /Remorse/EntityDispatchEntryRuntimeState overlay datatype. That leaves the remaining EntityDispatchEntry pilot work in a narrower end-of-day state: mainly the word-list destroy lane and the timed/periodic constructor cluster, not the core base or runtime-state surfaces.
• That pilot moved one more bounded step in-session too. The periodic/timed branch from the old 0008: note cluster is now re-anchored live onto 11e0: well enough to move six more methods under Remorse::EntityDispatchEntry: ConstructVtable3AD2 (11e0:14fb), ConstructVtable3AA6 (11e0:1814), SetUpdatePeriodAndReschedule (11e0:187e), TickPeriodic (11e0:1913), EnableActiveCounters (11e0:19e6), and DisableActiveCounters (11e0:1a33). Each now has an in-session provenance comment tying it back to the old 0008: anchor, so the remaining EntityDispatchEntry blocker is narrower again: the word-list-owned subtype still has no live function objects in the expected 11e0:2000..25a1 window, and a bounded boundary scan did not yet yield safe entries to promote.
• That remaining EntityDispatchEntry blocker is now closed by a re-anchor correction. The expected 11e0:2000..25a1 window is not code in the current live database; the old 0008:da00..dfa1 word-list-owned subtype actually lives in the 11e8: MList_* cluster, with 11e8:0000 carrying explicit old 0008:da00 segment metadata in the decompiler. That full batch now also lives under Remorse::EntityDispatchEntry: SetWordList0408Terminated, FreeWordList, Destroy, EnsureWordListContains, AppendUniqueWord, RemoveWordValue, GetWordAt, SetWordAt, and FindUnflaggedWordById10, each with an in-session provenance comment. The remaining question on this pilot family is therefore modeling depth rather than location: whether the 11e8: word-list branch deserves its own explicit derived/overlay datatype instead of remaining a method cluster under the shared class owner.
• CreateFromSlotIndex is no longer a raw anonymous pack either: the live signature now separates owner_source_farptr, pitemno_farptr, mode_flags, slot_index, value_add_offset, intra_chunk_offset, ucparam_farptr, and ucparamsize, with explicit AX:DX return storage restored even though the endpoint still textualizes the function conservatively as plain dword __cdecl.

Areas That Are No Longer Live Priorities

• Startup/display transition recovery is no longer a front-line blocker unless overlap repair becomes necessary for adjacent work.
• The general cheat/debug key matrix no longer needs broad exploratory work.
• The -debug switch is no longer an open mystery; remaining work there is mostly sink-side cleanup and documentation.
• The earlier executable-patch experiments around the hidden debugger are documented history, not a current decompilation priority unless new evidence changes the entry model.

Live Blockers

1. The main remaining VM uncertainty is the real upstream selector/caller path into entity_vm_opcode_sequence_run and adjacent masked-create helpers. One earlier producer is now closed at AreaSearch_CollideMove for the 0x236 collision-storage family, but the owner-loaded class-family chooser and any broader non-collision producers are still upstream-dark.
2. The dark masked-materializer wrappers still need caller-role recovery, especially the signed-additive slot-0x0a / slot-0x0b pair and the surrounding higher-slot wrapper ladder.
3. The callback object rooted at 0x4588 still lacks a behaviorally safe subsystem name even though its allocation/finalize neighborhood is better constrained.
4. A few hot or awkward function ranges still lack clean function objects or good boundaries, especially around 000c:db68, 000e:ffb0, and several caller-dense gaps in 0007, 000b, and 000e.
5. Weakly covered resource/data-loader families and non-CALLF far-pointer relocations are still a second-pass blocker for some object/table recovery work.
6. The segment ledger has improved, but it still trails the actual verified state in the notes and Ghidra database. Promoting known segments from documented evidence remains real work, not bookkeeping trivia.

Current Focus

1. Keep the live NE CRUSADER.EXE lane as the default working surface, using raw/full-EXE and standalone-segment work only as supporting evidence.
2. Keep the VM/USECODE lane focused on selector recovery, caller-role recovery, and record-shape confirmation rather than repeating storage-format validation that is already closed.
3. Promote ledger coverage from existing verified notes before broadening into fresh executable-wide sweeps.
4. Use overlap repair only where it unlocks an active high-payoff lane.
5. Use the map-renderer/tooling lane to validate shape ids, map placements, and viewer semantics before promoting additional static-object names in Ghidra.
6. Keep the PSX lane focused on the final lane-aware state/resource/frame/palette bridge now that the first post-spawn interaction/reselection cluster is named; avoid broad renderer-side heuristics that bypass those runtime paths or flatten main-visible and special-visible palette behavior together.

Next Resume Point

1. Resume the hidden-debugger lane from docs/regret-hidden-debugger-investigation.md, docs/jp-remorse-hidden-debugger-investigation.md, and docs/retail-debugger-entry-options.md: use No Regret, not JP, as the primary sibling-build anchor and compare retail CRUSADER.EXE directly against the now-closed Regret bootstrap/state-hook/runtime map. The concrete next target is no longer another broad Regret sweep; it is the smallest retail analogue of Regret 1398:0000, the missing writer for retail 1478:659c/659e, and any retail interpreter-side handoff that could be reattached without the wider old patch chains.
2. In parallel with that comparison, keep the -u / replacement-EUSECODE.FLX lane alive as the least invasive practical experiment surface: prefer monitor/computer, SURCAM*, and NPCTRIG families over generic container scripts, and look only for indirect compiled control bridges rather than assuming usecode can already construct the debugger state directly.
3. Continue broad sweeps in the same 12f8 / 13c8 / 13f8 UI-gump neighborhood so the next write window can harvest more obvious virtual-slot and wrapper names before switching back to deeper caller-policy work.
4. Resume from docs/ne-hole-filling-priorities.md only after the current UI edge stops yielding cheap structural wins; the immediate best candidates are the remaining anonymous sibling methods in the main-menu, quick-save/load/exit, and adjacent button-gump families. Current side-cluster progress: the live session now has named media/audio helpers (FlicPlayProcess_Destroy, FlicWaitProcess_Destroy, MusicPlayerProcess_RunNoop, MusicPlayerProcess_Destroy, AssProcess_Destroy, FlicWaitProcess_VtableSlot10TickAndMaybeAdvance, MusicPlayerProcess_VtableSlot10Noop, AssProcess_VtableSlot5ClearCreatedFlag, AssProcess_VtableSlot6SetCreatedFlag, VideoPlayer_InitializePlayback, VideoPlayer_OpenMediaFiles, VideoPlayer_AllocPlaybackBuffers, VideoPlayer_OpenMoviListAndPrimeStreams, VideoPlayer_StopAndDestroyWrapper, VideoPlayerProcess_VtableSlot11Noop, File_Exists, VideoPlayer_FormatErrorMessage, VideoPlayer_AdvanceChunkCursor, VideoPlayer_AdvanceChunkCursorWrapper, VideoPlayer_LoadAudioChunk, VideoPlayer_LoadVideoChunk, VideoPlayer_BlitDecodedFrame, Music_RestorePreviousTrackFromStack, Music_LoadStateAndReplayCurrentTrack, Music_SaveState, ASS_StoreInitCallbackState), a fully named savegame UI cluster (SavegameNameField_MapInputChar, SavegameMenu_Destroy, SavegameMenu_HandleKey, SavegameMenu_HandleSlotAction, SavegameSlot_DrawCornerDecorations, SavegameSlotGump_Create, SavegameSlotGump_Destroy, SavegameNameField_HandleKey, SavegameSlot_HandleClick, SavegameSlot_BeginEditOrActivate, SavegameNameField_Draw, SavegameSlot_Select, SavegameSlot_GetLabelPtr, SavegameSlot_SetLabel, File_CloseAndMaybeFree), a newly named main-menu shell (MainMenu_Destroy, MainMenu_DrawCornerDecorations, MainMenu_HandleButtonClick, MainMenu_HandleKey, MainMenu_ActivateSelection) plus one additional main-menu subcluster (MainMenuOptionsPanel_Create, MainMenuOptionButtonGump_Create, MainMenuOptionButtonGump_HandlePointerEvent, MainMenuOptionButtonGump_SelectPeer, MainMenuOptionButtonGump_Draw), a tightened help-gump subcluster (HelpGump_RefreshPage, HelpGump_HandleAdvanceAction, HelpGump_HandleNavigationKey, HelpGump_RunAmbientSfxTick), a cleaned-up 10f8: item-type helper pair (ItemScript_AppendBytes, ItemTypeflagRecord_ResetDefaults), a large ownership-backed process cleanup batch (MapJumpProcess_Destroy, FadeProcess1_Destroy, AnimProcess_Destroy, ItemProcess_Destroy, SuperSpriteProcess_Destroy, OneFrameDelayProc_Destroy, CameraProcess_Destroy, KeyDaemonProcess_Destroy, KeyboardProcess_Destroy, AccWaitProcess_Destroy, SystemTimerProcess_Destroy, BiosProcess_Destroy, CustomWaitProcess_Destroy, DumbTimerProcess_Destroy, CycleProcess_Destroy, FadeProcAlt_Destroy, MyTimerProcess_Destroy), a companion broad slot-method batch (MapJumpProcess_VtableSlot10AdvanceItemFind, AnimProcess_VtableSlot10DispatchByPort, FadeProcess2_VtableSlot10BlendTowardTargetPalette, AttackProcess_VtableSlot10DispatchByClip, WaitProcessFamily_VtableSlot10DispatchByPair, AccWaitProcess_VtableSlot10DispatchByAnimation, BiosProcess_VtableSlot10DosRealFarCall, CustomWaitProcess_VtableSlot11ArmAndRun, MyTimerProcess_VtableSlot10IncrementCounterOnTick, BaseCameraProcess_VtableSlot10SetViewportRect, BaseCameraProcess_VtableSlot11FreeBuffer), a broad UI/gump ownership cleanup batch (StdIntHandlerProcess_Destroy, GumpShared_DestroyNoop, KeyboardInputHandler_DestroyNoop, GumpShared_VtableSlot10Noop, KeyboardInputHandler_VtableSlot10Noop, KeyboardInputHandler_VtableSlot11Noop, ButtonGump_Destroy, KeypadGump_Destroy, KeypadButtonGump_Destroy, HelpGump_Destroy, RunCreditsProcess_Destroy, QuickSaveLoadExitGump_Destroy, Gump13f80383_Destroy, Gump13f80383_Draw), another structural process-family cleanup batch (AnimProcess_RunNoop, Process1048_0000_RunNoop, Process1048_0000_Destroy, AnimPrimitiveProcessSomethingElse_Destroy, AnimPrimitiveProcessFamily_VtableSlot11CallSlot3, Process1188_0000_RunOnTimerDelta, Process1188_0000_Destroy), and a final tiny conservative broad-sweep batch (SystemTimerProcess_RunNoop, Gump13f80383_VtableSlot10Noop, Gump13f80383_VtableSlot11Noop). The next defensible step can now keep sweeping broadly for ownership-backed leftovers, push deeper into subordinate menu/dialog families, or return to unfinished media helpers.

The latest micro-batch also corrected one structural naming mistake in the shared gump lane: GumpShared_VtableSlot3Noop, GumpShared_VtableSlot7Noop, GumpShared_VtableSlot8Noop, GumpShared_VtableSlot9Noop, GumpShared_VtableSlot16Noop, and GumpShared_VtableSlot17Noop now replace the older keyboard-only labels after direct table reuse showed those no-op slots are shared by help/menu/gump families.

The newest broad-sweep UI batch tightened three more local families without needing deeper subsystem claims: GumpShared_DestroyCommon is now the shared gump base destroy helper at 12f8:02e4; the quick save/load/exit modal now has QuickSaveLoadExitGump_Create, QuickSaveLoadExitGump_HandleChildButtonEvent, QuickSaveLoadExitGump_HandleKey, and QuickSaveLoadExitGump_DrawLabel; the adjacent main-menu options-panel wrapper lane now has MainMenuOptionsPanelButtonGump_Create, MainMenuOptionsPanelButtonGump_DrawLabel, MainMenuOptionsPanelButtonGump_Select, and MainMenuOptionsPanelButtonGump_Deselect; and a second 13c8: options-menu lane now has MainMenuOptionsMenu_{Create,Destroy,GetOptionRect,HandleChildButtonEvent,HandleKey,DrawTitle} plus MainMenuOptionsMenuButtonGump_DrawLabel. The next low-risk follow-up in this same neighborhood is therefore narrower again: remaining anonymous sibling methods in 13c8: / 13f8: and any matching button-gump virtual slots in 1308: that can be named structurally from local family behavior. 5. Stay on the VM lane and move one step earlier than the now-mapped movement/collision helper set around AreaSearch_CollideMove: the local seg029/031/090 helper layer is now named, so the next work is the policy/dispatch layer that decides when those legal-move, gravity, animation, or supersprite paths instantiate the local 0x236 collision-storage queue, plus verification of whether any non-collision producer feeds the same StorageDataProcess_Create / Run family. 6. Recover caller roles for the remaining dark signed-additive masked wrappers, especially the slot-0x0a / slot-0x0b pair, and compare them against the now-anchored slot-0x12 caller pattern. 7. Tighten the higher-slot wrapper ladder around 0005:3115..31da so future event-label promotion depends on compiled caller behavior instead of external tables. 8. Tighten the seg006 masked-helper caller chains so the local state-selector/value family can be tied to concrete gameplay subsystems. 9. Classify the paired seg070 loops behind entity_vm_runtime_owner_resource_create, especially which temporary buffers and record schemas each family populates. 10. Stay on the Remorse VM class-lift batch while the repaired runtime lane is warm: use the now-recovered CreateFromSlotIndex caller pack to decide whether any remaining scalar positions deserve stronger typedefs, but keep the return semantically conservative until the base-process inheritance model is explicit enough to justify a prettier live return type. 11. Stay on the new Remorse NPC action-process class-lift lane while seg033 is warm: the owner-first move is done, so the next bounded pass should recover process-function-table slot order, inspect StandProcess::Run and PaceProcess::Run for equally strong family-local helpers, and decide whether a provisional /Remorse/NPCActionProcess datatype is safe or whether the family should remain owner-only for now. 12. The current broader Remorse follow-up batch is now materially tighter: WatchEntityController is effectively re-identified as the live camera-process create lane, DialogMenuObject is the last compact family here without a safe live re-anchor, PresentationCallbackBroker now has install/teardown plus both slot +0x08 and preserved slot +0x0c caller evidence, CacheBackendObject has its indexed entry writer, and SpriteNode::Create now looks like the shared compact node constructor for GumpCreate_* wrappers. The clearest next unresolved items are therefore: a safer live reanchor for DialogMenuObject, a decision on whether the camera-process lane should stay under the stronger live Camera_* naming or also receive a class-owner layer, deeper slot +0x0c payload classification in the broker lane, and higher-level subtype/layout work above the compact SpriteNode base. 13. In the local GhidraMCP upgrade lane, add support for dual POST body decoding (application/json plus form-urlencoded) and a constrained live write-side PyGhidra endpoint family so future custom-storage/type repairs can stay inside the active MCP session when Python is enabled. 14. Promote additional ledger rows directly from already-verified docs and live comments, especially where segments already deserve Foothold, Partial, or Deep; the new seg029 step-aware sweep batch, seg031 queue-release batch, seg090 movement-helper batch, seg033 NPC-process foothold, and seg032 item-type foothold should be the immediate template. 14. If the VM lane stalls, revisit 000e:ffb0 from the now-better-constrained video/audio caller windows and try to recover an adjacent non-overlapped helper before attempting broad boundary repair. 15. Continue the map-renderer cross-check lane by building one conservative shape-id/map-placement crosswalk from shapedata_more_complete.txt, extracted corpora, and authored scene evidence before promoting more trigger-heavy classes in NE. 16. Keep the PSX pre-alpha lane alive as a secondary target: classify the LoadExec callers, test whether the stale TALK1.XA path is still reachable, and compare the shipped LSET1 bundles against the retail extractor outputs. 17. Continue the retail PSX state/art lane from the new art-binding recovery baseline: keep DAT_800758d4 on the runtime-bounds side unless new family-specific evidence contradicts it, treat map 104 plus the remaining 0x0042 / 0x0055..0x0063 zero-block constructor-placement band as the primary regression target, and trace the next family-specific callers around psx_type4_reselect_motion_state, FUN_80028c94, constructor-side resource creation, and the drawable-resource/frame submission lane until the remaining donor-based fallback logic can be replaced with an executable-backed lane-aware alias/resource/frame/palette rule. The first practical split to preserve is now explicit in the live database: main-visible objects can consume authored override bytes from different source offsets by type band, while the special-visible queue does not, and the next renderer-side check should keep the full coherence order intact: load-time CLUT install, spawn-time resource bind, frame-time state advance and routing, then stage-1 dependency sort before submission.

Remaining Work To Reach A Reasonably Complete Decompilation State

1. Coverage And Tracker Completion

• Keep turning the seeded 145-row ledger into a trustworthy whole-program dashboard.
• Sweep remaining lightly covered segment clusters by adjacency and call relationships rather than one-off function hunting.
• Keep the plan, the docs, the ledger, and the live Ghidra comments synchronized after each verified batch.

2. VM / USECODE / Scripting Lane

• Close the upstream selector/caller path into the sequencer and masked-create families.
• Finish separating owner-row-backed data from runtime-decoded control streams and dispatch-entry seed records.
• Expand caller-backed event-label promotion only where binary behavior and slot reuse agree.
• Keep maturing the tooling bridge from extracted corpora into compiled-side annotation/import workflows.

3. Callback / Allocator / Object-Role Lane

• Classify the 0x4588 callback object strongly enough for a real subsystem name.
• Separate generic cache/allocator mechanics from game-specific client behavior where caller evidence supports it.
• Keep low-level helper names conservative until behavior, not just structure, is clear.

4. Rendering / Animation / UI Support Lanes

• Keep the rendering/palette/animation lanes focused on caller-side semantics and cleanup, not exploratory renaming in isolation.
• Revisit 000e:ffb0 and adjacent overlap-heavy video helpers only when the payoff is clear.
• Use map-renderer evidence and extracted corpora to validate static-object and helper/controller naming before promoting it into live NE work.

5. Data / Resource / Relocation Coverage

• Tackle deferred non-CALLF far-pointer relocations when they are needed for active table/object recovery.
• Broaden weakly covered resource/data-loader families where they block real subsystem classification.
• Keep external references like ScummVM or older disasm corpora as evidence aids, not rename authority.

Priority Order

1. VM / USECODE selector and caller recovery
2. Coverage-ledger refinement from already-verified notes
3. Callback-object classification around 0x4588
4. High-value boundary repair when it unlocks active work
5. Broader segment sweeps and second-pass data/relocation work
6. Secondary map-renderer and PSX follow-up lanes

Evidence Anchors

Primary files backing this plan state:

• crusader_segment_coverage_ledger.csv
• crusader_decompilation_notes.md
• docs/overview.md
• docs/ne-hole-filling-priorities.md
• docs/crusader-disasm-reference.md
• docs/raw-porting-progress.md
• docs/raw-0008-000c.md
• docs/raw-000a-000d.md
• docs/raw-000e.md
• docs/far-call-targets.md
• docs/usecode-roundtrip-ir.md

Update Rule

Update this file when one of the following happens:

• the headline estimate changes materially,
• a live blocker is resolved,
• a subsystem moves from structural to behavioral understanding,
• a segment cluster is promoted materially in the ledger,
• or the next resume point changes enough that the current handoff would mislead the next pass.

Keep this file short. Move detailed completed analysis into the appropriate file under docs/ and leave only the current state, blockers, and forward path here.