re: S1 -- the Ready Room probe is a no-go, and not for the reason the

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.

docs/port/HANDOFF.md

@@ -37,7 +37,7 @@ authored version can be deleted.
 | Q8 | menu audio bindings | ❔ open | cue table complete, event binding is not |
 | Q9 | video binding + playback rules | 🟡 partial | `ADV.wmv` is the boot intro; new-game intro unidentified |
 | Q10 | music-bank sub-wave roles (intro+loop?) | ✅ answered | **two stems of one performance, played together** — sample-synchronous, equal duration, 32/32 banks. **Concatenating is wrong.** Not a seamless loop either — [`structures/bgm-two-stems.md`](../re/structures/bgm-two-stems.md) |
-| S1 | Ready Room go/no-go | ❔ open | probe not run |
+| S1 | Ready Room go/no-go | ✅ **no-go** | it is 2D and enumerates fine (60 builds), but `GP_READY_ROOM.pak` holds **briefing/tactical-map** content, not the six-button Ready Room menu — [`ready-room-probe.md`](../re/ready-room-probe.md) |
 
 ## Already settled — the port can rely on these today
 
@@ -55,7 +55,13 @@ authored version can be deleted.
   `GP_TUTORIAL`, `GP_OPTIONS`, `GP_MISSION_SELECT` are the likely destinations by
   name — an inference, not a measurement).
 * **Buttons are identifiable as data.** Element kind `0x3002` = button, `0x0` =
-  decoration, `0x10` = primitive. ✅ decoded.
+  decoration, `0x10` = primitive. ✅ decoded **for the title-side screens**.
+  ⚠️ `0x3002` is one member of a `0x3000` family with sub-bits, and it is not the
+  only button kind on the disc: `GP_READY_ROOM`'s 902 bundles contain **zero**
+  `0x3002` and use `0x3000` / `0x3004` / `0x300c` / `0x3008` instead. Nothing in
+  this milestone changes — every screen in scope is `GP_TITLE` — but do not ship
+  `kind == 0x3002` as a general button test.
+  (The kind is the 4th `u32` of the 60-byte declaration entry, at `+40`.)
 * **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is
   ✅ correct for a vertical menu and is **not** a decoded neighbour graph — the
   disc's real navigation structure is unknown, and `opt ` is *not* a focus link

docs/port/MISSION.md

@@ -75,7 +75,7 @@ alongside it.
 | **Q8** | **Menu audio.** Which BGM per screen; which cue on move / confirm / back / error. The cue table is complete; the event binding is not | Cue names bound to events, with how you established each |
 | **Q9** | **Video binding.** Which movie is the boot intro vs the new-game intro; whether playback is skippable and what ends it | Named movies plus the playback rules |
 | **Q10** | **What are a music bank's sub-waves?** `BGM_001.slb` is three sub-waves — 10 KB, 4.47 MB, 4.67 MB — and we currently **concatenate them blindly** into one 347 s track. Two near-equal halves could be intro + loop, or two variations, or two halves of one piece. A menu that loops its music needs to know which | The role of each sub-wave, established for at least the menu BGM. "Concatenate" is a decision, not a default — right now it is a default nobody chose |
-| **S1** | **Ready Room probe.** *Gated* — one iteration, then stop | A written go/no-go (see below) |
+| **S1** | ~~**Ready Room probe.**~~ **DONE 2026-08-28 — [no-go](../re/ready-room-probe.md).** It is 2D and enumerates fine, but the pak is briefing/tactical-map content, not the Ready Room menu | ✅ go/no-go written |
 
 ## Known unknowns — say so, do not fill them in
 

docs/re/INDEX.md

@@ -152,6 +152,7 @@ files, which is how the same ground got covered twice.
 | [`ui-quad-class-foothold.md`](ui-quad-class-foothold.md) | The guest's UI quad class — a foothold found from the capture's vertex layout |  🟡 PROBABLE for the identification below (it is a static read, but |
 | [`menu-navigation-semantics.md`](menu-navigation-semantics.md) | The title menu — how it moves, and where each button goes |  ✅ measured: wraps both ends, Ⓑ restores focus, ⬅➡ inert; 4 of 5 destinations driven. 🟡 GamePart id is a name match, ❔ `NEW GAME` untested |
 | [`screen-transitions.md`](screen-transitions.md) | Between two screens — a fade through black, and where its timing lives |  ✅ the fade quad's keyframe group is decoded (disc-wide: per-pak all-or-nothing; `GP_TITLE` = the 6 screens, not the 6 overlays); the ~0.4 s fade-OUT is measured, not on the disc |
+| [`ready-room-probe.md`](ready-room-probe.md) | S1 — the Ready Room probe: no-go, and not for the reason expected |  ✅ it is 2D and enumerates (60 builds), but the pak is briefing/tactical-map content; and `kind == 0x3002` finds 0 buttons there |
 | [`ui-title-build-map.md`](ui-title-build-map.md) | Which `GP_TITLE` build is which screen state |  ✅ CONFIRMED for title / `PRESS Ⓐ` / main menu / `EXTRAS` against live captures; the archive is 8 screens × EN/JP, and "6/8/9 are submenus" is withdrawn |
 | [`ui-title-paint-order-capture.md`](ui-title-paint-order-capture.md) | The title screen's paint order, measured from the guest's draw submissions |  ✅ CONFIRMED — the order in which the running game paints the title |
 | [`upstream-baseline.md`](upstream-baseline.md) | A stock-upstream baseline runs Stage 02 crash-free |  ✅ CONFIRMED — upstream canary_experimental + only the pad |

docs/re/REFUTED.md

@@ -35,6 +35,15 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
+* "`GP_READY_ROOM.pak` holds the Ready Room screen" → its 317 distinct element
+  names contain **none** of the six visible labels; it is the briefing /
+  tactical-map content behind the `BRIEFINGS` item.
+  [`ready-room-probe.md`](ready-room-probe.md)
+* "the Ready Room might be 3D with a UI overlay" → it is **2D**; the pak carries
+  zero 3D containers.
+* "element kind `0x3002` is *the* button kind" → title-side only. All 902
+  `GP_READY_ROOM` bundles have **zero** `0x3002`; that pak uses `0x3000`,
+  `0x3004`, `0x300c`, `0x3008`. `0x3002` is one member of a `0x3000` family.
 * "the transition between menu screens is a cut" → it is a **fade through
   black**; a 0.5 Hz screenshot burst simply samples too slowly to see it.
   [`screen-transitions.md`](screen-transitions.md)

docs/re/ready-room-probe.md

@@ -0,0 +1,90 @@
+# S1 — the Ready Room probe: **no-go**, and not for the reason expected
+
+**Status:** one iteration, as [MISSION §S1](../port/MISSION.md) specifies. This is
+the written go/no-go. No Ready Room work has been started.
+
+## Recommendation: no-go
+
+Not because it is 3D — **it is not** — and not because the names are
+unrecoverable. Because the probe found that **`GP_READY_ROOM.pak` does not appear
+to contain the Ready Room's own menu screen at all**, so the question the mission
+framed ("only 6 of 1 106 names resolve, is that a week or a quarter?") is aimed at
+the wrong target. And it is outside the five-screen milestone regardless.
+
+## What the probe measured
+
+### ✅ It is 2D. This is not a 3D room with a UI overlay.
+
+The corpus already holds a framebuffer capture of the running screen,
+[`captures/ready-room-extra-mode.png`](captures/ready-room-extra-mode.png): a flat
+menu — a `READY ROOM` wordmark, six labelled items (`TAKE OFF`, `BRIEFINGS`,
+`HANGAR`, `PILOT LOG`, `OPTIONS`, `MISSION CHANGE`), a focus ring, and an
+`Ⓐ : OK / Ⓑ : Mission change` footer — in exactly the visual language of the
+title menus. There is no model viewport. The pak's own entry list carries **zero
+3D containers** (no `XPR2`, no `XBG7`).
+
+So the mission's own no-go-by-definition criterion is **not** met. That part is a
+go.
+
+### ✅ Enumeration by content works — 60 builds
+
+`sylpheed-cli screen list` finds **60 screen builds**. The 1 106 entries break
+down as **902 RATC bundles, 192 IDXD objects, 6 `ttf`, 6 `LSTA`**. The worry that
+unresolvable *paths* would mean unrenderable *screens* is unfounded here.
+
+### 🔴 But none of it is the Ready Room menu
+
+Two independent signals, and they agree.
+
+**Rendered composites are briefing panels.** Four of the 60 builds — the largest
+and most element-rich (18, 26, 44 and 9 elements) — composite to a planet
+information panel, unit markers and direction arrows:
+[`ready-room-pak-builds.png`](captures/ready-room-probe/ready-room-pak-builds.png).
+Tactical-map material, not a six-item menu. ⚠️ **4 of 60 sampled** — this alone
+does not close it.
+
+**The name census does close it much harder.** The 902 bundles declare **317
+distinct element names**, all under a `pb*` prefix family:
+`pbfriendly` (330), `pbacropolis` (168), `pbrhino` (48), `pbsub` (204),
+`pbtab` (48), `pbcm` (132)… Searching all 317 for any of the six visible labels —
+`takeoff`, `take_off`, `brief`, `hangar`, `pilot`, `option`, `mission`, `ready` —
+returns **nothing**. The only `main` hits are `pbmain_btn1..3.t32`,
+`pbmain_window.t32` and their `_eff` glows, which appear in 9- and 4-element
+*fragments*, not a screen, and are declared **kind 0** (decoration).
+
+Read together: this pak is the **briefing / tactical-map** content that sits
+*behind* the Ready Room's `BRIEFINGS` item, and the Ready Room's own menu lives
+somewhere else. Note the GamePart table has both `10 GP_BUNK` and
+`11 GP_READY_ROOM` ([`challenge-mission-gate.md`](challenge-mission-gate.md) §3),
+and `GP_BUNK.pak` is a separate archive that was not examined here.
+
+### 🔴 And a caveat that reaches back into the delivered corpus
+
+**`kind == 0x3002` finds zero buttons in this pak.** All 902 bundles, 0 hits —
+while `GP_TITLE` has 16. What `GP_READY_ROOM` uses instead:
+
+| kind | count |
+|---|---|
+| `0x3000` | 491 |
+| `0x3004` | 406 |
+| `0x300c` | 135 |
+| `0x3008` | 60 |
+| `0x3001` | 6 |
+| `0x3002` | **0** |
+
+So `0x3002` is one member of a `0x3000` **family** with sub-bits, and "element
+kind `0x3002` is a button" — a ✅ row in [`HANDOFF.md`](../port/HANDOFF.md) — is
+sound for the title screens and **must not be applied as an equality test
+elsewhere**. For the five-screen milestone nothing changes; for anything beyond
+it, test the family.
+
+*(The kind field is the 4th `u32` of the 60-byte declaration entry, at `+40`.
+Calibrated on `GP_TITLE` build 6, where it reads `0x3002` for exactly the three
+`EXTRAS` buttons and `0x0` for the decorations.)*
+
+## If it is ever picked up
+
+The first job is **not** naming this pak's keys. It is finding where the Ready
+Room's six-button screen actually lives — `GP_BUNK.pak` is the obvious first
+place to look, and the same content-based `screen list` / name-census pass costs
+one iteration there.