Files

Sylpheed RE agent e64965b3f9 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.

2026-08-28 18:24:48 +00:00

4.2 KiB

Raw Blame History

S1 — the Ready Room probe: no-go, and not for the reason expected

Status: one iteration, as MISSION §S1 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: 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.

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. 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 §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 — 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.

4.2 KiB Raw Blame History