Save Selector Gate Base Candidates

route map1_01a -> map2_02d; gate offsets 0xe8, 0xea; expected selection index range 0..11; proofFound False; promotion status blocked

Mapping the gate offsets through known context+0xa8 base candidates weakens the party-slot-base path: for party slots, 0xe8/0xea land on later character MP/stat bytes such as Rinshan and Smashu MP fields, not on documented selector-index bytes. Since opcode 0x11 expects a branch-state slot index in the 0..11 range, those stat-byte mappings are not promotion evidence. Loader-aware save/runtime mapping also matters here: 0x004576d8+0xe8/0xea falls into the second loaded save block after the six-byte runtime gap, so those bytes map to save offsets 0x00e2/0x00e4 rather than linear offsets 0x00e8/0x00ea. The viable sources remain an unresolved global/save-runtime buffer or object pointer table mode, so control-flow proof is still blocked.

Failed Gates

• save-runtime-gate-byte-route-sample
• party-slot-branch-state-index
• runtime-pointer-mode-proof
• control-path-gate-base-proof

Missing Evidence

• current selector 2:0 save/runtime sample proving save-runtime gate bytes
• party-slot byte mapping that yields a valid branch-state index instead of stat bytes
• runtime pointer-mode proof selecting the correct context+0xa8 base
• control-path proof that the resolved gate base enables current frontier fallthrough

Evidence Refs

• out/save_selector_gate_offset_sources.json: current gate offsets and inherited/runtime gate-source classification
• out/save_selector_selection_buffer_bases.json: candidate context+0xa8 base modes and static address reference checks
• tools/parse_savedata.py: save-block and field-offset schema used for loader-aware byte classification