re: the JP-locale capture is not blocked -- I stopped one grep too early

Last iteration I wrote into MISSION.md that a Japanese-locale capture is
impossible here, because user_language is DECLARE_int32 at four call
sites with no DEFINE and no entry in xenia-canary.config.toml. That is
true, and it was not the question. The language is PERSISTED:
kernel_state.cc builds XConfig over <storage_root>/xconfig.settings,
SetDefaults() only supplies a value when the file has none, and the file
is writable. Checking where a setting is stored rather than where it is
configured turned "blocked, needs a human decision" into a two-line edit.
Withdrawn from MISSION.md; METHOD and REFUTED lines added.

The field is located from struct landmarks rather than a hard-coded
offset, and the check re-runs on every invocation so it fails loudly if
the layout moves:

  music_volume 0.7f at User+449  -> BE float at 2727 -> User base 0x8e6
  language          at User+44   -> reads 1 (kEnglish) at 0x912
  country           at User+64   -> reads 103 (US) at 0x926

XLanguage::kJapanese = 2 (xbox.h:307). set_console_language.py wraps it
with a backup and a --restore.

The capture itself is still NOT taken, for a smaller reason than I
claimed. A run with the locale set to Japanese booted fine but never
reached the title in 787 s: wait_title.sh's green-(A) oracle never fired
and burst-sampling found no frame correlating above 0.18 with either
build-7 render -- the run sat in the attract loop. So it needs a longer
or pad-driven run, not a rebuilt emulator. Emulator stopped, lock
cleared, locale restored to English.

Nothing is decided about the keyframe-time association or the rest()
rule; this only changes what standing between us and deciding them.
This commit is contained in:
Sylpheed RE agent
2026-08-29 00:05:58 +00:00
parent 6d246c7a97
commit 0f1c0f4e14
4 changed files with 125 additions and 11 deletions

View File

@@ -426,3 +426,19 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
answer: a census control asked for the two rotated elements of `GP_DIALOG`
build 0 and got zero, from a bundle that genuinely has none. `screen list`
prints the mapping; use it rather than assuming identity.
* **"There is no flag" is not "there is no way".** I declared a Japanese-locale
capture impossible in this container because `user_language` is `DECLARE`d and
never `DEFINE`d, so no cvar exists to pass. That was true and not the question.
The language is *persisted*: canary builds `XConfig` over
`<storage_root>/xconfig.settings`, `SetDefaults()` only supplies the value when
the file has none, and the file is writable. One grep further — for where the
setting is **stored** rather than where it is **configured** — turned a
"blocked, needs a human decision" into a two-line edit. When you conclude a
capability is absent, check the persistence layer before writing it up.
* **Locate a binary field from struct landmarks, not from a hard-coded offset.**
`user.language` was found by scanning for `music_volume`'s `0.7f` (a known
default at a known relative offset), then cross-checking `language == 1` and
`country == 103` against the emulator's own `SetDefaults()`. Three agreeing
landmarks, no offset assumed, and the check re-runs every invocation — so the
tool fails loudly if the layout moves instead of silently patching a
neighbouring field.