Sylpheed/docs/port/options-screens.md

# The OPTIONS menu tree exists, renders, and is named

**2026-09-03.** `GP_OPTIONS` joined `export_archives` and produced 14 screen
builds. All 14 render; all 14 are now named.

## What they are

| entry | name | English | | entry | name |
|---|---|---|---|---|---|
| 19 | **`options`** | **the root** — GAME / CONTROL / SOUND / SCREEN SETTINGS, BACK | | 21 | `options_jp` |
| 16 | `game_settings` | Auto-Save, View Point, Radio Log, Subtitles | | 18 | `game_settings_jp` |
| 4 | `control_settings` | Control Type, Throttle, sensitivities, Vibration | | 8 | `control_settings_jp` |
| 3 | `sound_settings` | Music / Movie / Voice / SFX Volume | | 5 | `sound_settings_jp` |
| 6 | `screen_settings` | Gamma Correction, R/G/B, NEXT PAGE | | 9 | `screen_settings_jp` |
| 7 | `screen_settings_page2` | White / Black Level Adjust, PREVIOUS PAGE | | 10 | `screen_settings_page2_jp` |
| 20 | `control_customize` | per-action key remapping | | 22 | `control_customize_jp` |

A clean EN/JP pair for every screen, which is itself a check: 14 builds, 7
pairs, no leftovers.

## How they were identified, and why that is stronger than usual here

**By the text the screen renders about itself.** Each was exported, drawn by the
port at rest, and read: the titles and row labels are legible.

📌 That matters because this project has been bitten three times by
identification via **position, size or ordinal** — the sweep strips confused by
size, the plate identified by screen position, `ptcopyright` mistaken for the
plate. A screen that renders the words `SOUND SETTINGS` above four volume rows is
not that kind of inference.

⚠️ **What it still does not establish:** which screen the *game* navigates to
from which. The tree above is read off content, so `control_customize` being
"reached from CONTROL SETTINGS" is a reading of its own legend
(`Ⓨ : Customize` on `control_settings`), not a measured transition. Wiring
anything beyond `main_menu → options` needs the real navigation.

## Not yet done

* **Nothing is reachable yet.** `main_menu` `ptbtn04` still has `goto: null`.
* **`po_pad_slider1` has no sprite** in the export and reports NOT DRAWN.
* **All 14 are `NEVER COMPARED`** by `verify-screen` — reported, not asserted;
  both its allowance and the reference renderer were calibrated on `GP_TITLE`.
* The screens are static: no navigation, no focus movement, no value editing.

---

# ✅ OPTIONS is reachable — and navigation inside it is blocked on a kind

`main_menu` `ptbtn04` now has `goto: "options"`. Walked with the menu harness:
main_menu → ⬇⬇⬇ → Ⓐ → the OPTIONS root renders. Ⓑ backs out.

## ✅ RESOLVED — the rows move. `0x3003` is `0x3002` with the parent bit set

The Decoder decoded it disc-wide: **bit 0 of `kind` is the PARENT FLAG**, and it
carries no role information. Over every `.pak` in `dat/`, `kind & 1` agrees with
"has a parent" on **15 493 elements with zero disagreements**
(`docs/re/ui-kind-bit0-is-has-parent.md`). The OPTIONS rows are parented; the
main-menu buttons are not. Same record class.

So the detector now matches `0x3002 | 0x3003` — **two values listed, not a
mask**. `kind & 0xFFFE == 0x3002` would also catch `0x73002`/`0x73003`, 160
elements whose high bits nobody has decoded, silently and on screens neither
agent has seen.

**Impact measured before re-exporting, not after:** exactly two screens gain
buttons — `options` and `options_jp`, five rows each. No existing screen changes.

Verified by walking it: `main_menu` → ⬇⬇⬇ → Ⓐ → OPTIONS, then ⬇⬇ moves
`po_menu_btn2` → `po_menu_btn3` with the focus ring rendering on the highlighted
row.

📌 **The port was right to wait.** The rejected rule — "carries a focus record ⇒
menu item" — would have reached the same answer here by a second inference from
structure, and would have reclassified elements on screens nobody had looked at.
The field cost one question and needed no inference at all.

## The original section, kept for the shape of the block

The exporter's button detector is `kind == 0x3002 && !focused`. The OPTIONS rows
are **`kind_raw = 0x3003`**, so `role` comes out `unknown`, the export's
`buttons[]` is empty, and up/down move nothing.

| screen | element | kind | focus record | in `buttons[]` |
|---|---|---|---|---|
| `main_menu` | `ptbtn01` | `0x3002` | yes | yes |
| `extras` | `ptbtn11` | `0x3002` | yes | yes |
| **`options`** | **`po_menu_btn1`** | **`0x3003`** | **yes** | **no** |

**What `0x3003` means is not the port's to decide**, so the rule was not widened
here. The circumstantial case is strong — five rows, each carrying a focus
record, on a screen whose own text lists five options — and *circumstantial* is
precisely the standard that has cost this project three separate retractions.
Asked of the Decoder.

⚠️ A tempting alternative rule is "an element with a focus record is a menu item",
which fits both screens. It is still an inference about semantics from structure,
and it would silently reclassify elements on every screen in the export. Not
taken.

## The workflow cost this exposed, worth knowing before repeating it

**A screen name is authored data, but it only reaches the port through a full
re-export** — which re-transcodes both movies. Renaming one screen costs the
whole tree. Not worth fixing today; worth knowing before anyone plans a naming
pass.

## 🔴 And a genuinely dangerous mistake, recorded because it nearly cost the session

Killing a background check with `pkill -f "check-all"` matched **the container's
own entrypoint**, whose command line contains the loop prompt — and that prompt
mentions `check-all`. `pgrep` duly reported the process as still running after it
had stopped, and a `pkill -9` on that pattern could have killed the session
itself.

**Match a process by its actual `comm`, or list with `ps` and check, before
sending a signal.** A pattern that appears in your own instructions is not a
pattern that identifies a process.