e64965b3f9
question expected One iteration, as the mission gates it, and no Ready Room work started. The two criteria it named both pass. It is NOT 3D: the corpus already holds a capture of the running screen and it is a flat six-item menu in the same visual language as the title. And unrecoverable paths do not mean unrenderable screens -- content enumeration finds 60 builds in the 1106 entries. What kills it is something the question did not ask. GP_READY_ROOM.pak does not appear to hold the Ready Room's own menu at all. Two signals agree: the four largest builds composite to briefing panels -- a planet readout, unit markers, direction arrows -- and, much harder, the 902 bundles declare 317 distinct element names of which NONE matches any of the six labels on the screen (takeoff, brief, hangar, pilot, option, mission, ready all return nothing). The pak is the briefing / tactical-map content behind the BRIEFINGS item. If this is ever picked up, the first job is finding where the menu lives -- GP_BUNK.pak is the obvious place -- not naming this pak's keys. The probe also reaches back into something already delivered: kind == 0x3002 finds ZERO buttons across all 902 bundles here, while GP_TITLE has 16. 0x3002 is one member of a 0x3000 family with sub-bits, and this pak uses 0x3000/0x3004/0x300c/0x3008. Nothing in the milestone changes -- every screen in scope is GP_TITLE -- but the handoff now says not to ship that equality as a general button test.