mission-phase-advance.md recorded the bytecode as not on the disc. It is; the earlier grep failed because every pak entry is Z1+zlib, so no name is plaintext. The loader resolves table KEYS, not a filename: GamePart name -> GP_SCRIPT -> script.tbl (name_hash 0x75FE4656), whose SCRIPTS record is a 40-field manifest mapping MISSION1..MISSION29 to StageNN.ssb. Verified: Stage02.ssb is 226,596 bytes, md5 aff69b5a..., byte-identical across all six language paks. 28 scripts exist; S17 is the missing one -- which agrees with the table sweep (S17 in none of the five families) AND with the loader guard sub_8225EC78 'if (n == 16 || n > 32) return', proving that mission number is 0-based. Three independent routes to the same conclusion. Header decoded from ScriptMission::Load rather than guessed: version, code offset 0x24, two symbol tables. Stage02 symtab1 = 326 symbols (197 message ids, 119 route names, 10 subobjectives), symtab2 = 122 (111 unit ids, 11 characters). Two loops close: the 111 unit ids are exactly the 111 UnitGroup_S02 squadrons, and the route names appear as SCRIPT SYMBOLS -- which is why nothing in the executable parses Route_*_p<N>* names. The _pN convention is the script's. Refuted: the .embsec_ sections are code (32,368 instructions, 108 functions), not script; MiscBin.pak and DefTables.pak have zero hits. Open: the 25 ISL opcodes and 147 built-ins are not decoded, and the mission-level stream at +0x24 is only partly read.