# 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.