From dfcaac221e89e263e2e88cc5b560ad6ef095b359 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Fri, 28 Aug 2026 19:19:14 +0000 Subject: [PATCH] re: the new-game path completes, the intro is only weakly identified, and this container kills long runs Three results, and the middle one is deliberately not upgraded. First: NEW GAME -> DIFFICULTY -> NORMAL -> SELECT DATA -> pick a slot -> a movie plays, with no crash. The previous run's throw at 0x82307128 is therefore not inherent to the menu path -- the same six presses got through it -- which fits the incomplete-cache trigger the corpus already names. n=1 either way, and the note says so. Worth recording because one observation had already hardened once into "A on NEW GAME hangs", and it would have hardened again into "the new-game path crashes". Second: with the path open, the manifest's MS00A -> S00A.wmv finally got a runtime test, and it did NOT reproduce the quality of the attract-movie identification. The first four samples give a clean monotonic S00A playhead of 2, 6, 9, 13 s and the strongest frame matches at 0.916, but the run as a whole is not one advancing timeline, most frames sit at contrast 23-37 where this page's own rule says discrimination is poor, and one high-contrast frame prefers ADV. So it stays amber: consistent with S00A, corroborating the manifest decode, not confirming it. A clean answer needs the 30fps x11grab route rather than 5-second screenshots. Third, and it bounds the rest: the emulator vanished at ~145 s with no crash line in its own log, last entries routine MEM-WATCH at 1.15 GB RSS. Second time this session -- the other was ~50 s into a boot. That is an external kill on a box with ~1 GB free and swap exhausted, not a guest fault. METHOD and the handoff's residue table both now say dynamic experiments here have to fit in about two minutes of guest time, which is why the DELTASABER plates went unseen again: they need a mission load and the run never got there. --- docs/port/HANDOFF.md | 10 +++++++-- docs/re/METHOD.md | 6 ++++++ docs/re/menu-navigation-semantics.md | 17 +++++++++++++++ docs/re/movie-binding.md | 32 ++++++++++++++++++++++++++++ 4 files changed, 63 insertions(+), 2 deletions(-) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 59c6b31..ffce347 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -256,12 +256,18 @@ here until 2026-08-28 and is now settled.) | 🟡 | **the paint-order tie-break** (Q3) | eight candidates refuted; costs one element's blend on one screen | | 🟡 | **GamePart ids behind the buttons** (Q4) | the *screens* are measured; the ids are a name match onto the executable's class names | | ❔ | **the boot transitions in code** (Q6) | bounded as code-not-data, not proven. `sub_821C6458` — the substantial function in `GamePart_Title`'s neighbourhood — has **not been read** | -| ❔ | **`MS00A` → `S00A.wmv` never watched** (Q9) | decoded from the manifest; the one run that reached it crashed at `SELECT DATA` first | -| ❔ | **builds 0/1 and 10/11**, the `DELTASABER` plates (Q2) | never seen on screen anywhere in the boot path, the title-side screens or the attract loop | +| 🟡 | **`MS00A` → `S00A.wmv` watched only weakly** (Q9) | the path completes now, but 5-second screenshots gave a partial playhead, not the clean one the attract test gave. Manifest decode is still the primary evidence | +| ❔ | **builds 0/1 and 10/11**, the `DELTASABER` plates (Q2) | never seen anywhere in the boot path, the title-side screens or the attract loop. A mission load is the remaining candidate and this container kills runs before one completes | The first two share one unblocker — an emulator build whose audio path can be observed — and would be the only entries here that change a port decision. +⚠️ **A container caveat that bounds all of the above:** the emulator has twice +been killed mid-run with no crash line in its own log (at ~50 s and ~145 s), on a +box sitting at ~1 GB free with swap exhausted. Dynamic experiments here have to +fit in roughly two minutes of guest time, which is why several of these residuals +are unfinished rather than unattempted. + ## Reference data Committed alongside the findings, so the port can be built without a disc in the diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 43880c4..8502cda 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -190,3 +190,9 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the "39.5 fps" that was really 0.1 s of matching a stale line — and it disagreed with the true 28.5 fps by enough to have flipped a conclusion. Snapshot `log.count(marker)` before starting and wait for it to *increase*. +* **This container kills long emulator runs.** Twice in one session the + `xenia_canary` process vanished with **no crash line in its own log** — once + ~50 s into a boot, once ~145 s in at 1.15 GB RSS — while the box sat at + ~1 GB free with swap exhausted. Budget dynamic experiments to fit in ~2 minutes + of guest time, take the measurement early, and never read a disappearance as a + guest crash without checking the log tail for one. diff --git a/docs/re/menu-navigation-semantics.md b/docs/re/menu-navigation-semantics.md index 7657d7d..9bd44b8 100644 --- a/docs/re/menu-navigation-semantics.md +++ b/docs/re/menu-navigation-semantics.md @@ -117,3 +117,20 @@ more. This boot opened the main menu on **`NEW GAME`**. Running tally across four boots of the same harness: `TUTORIAL`, `TUTORIAL`, `NEW GAME`, `NEW GAME`. Unchanged conclusion: **do not hardcode it.** + +### The `NEW GAME` path completes — the `SELECT DATA` crash is state, not path + +A second run of the same path, 2026-08-28, **did not crash**: + +``` +NEW GAME → DIFFICULTY → (Ⓐ on NORMAL) → SELECT DATA → (Ⓐ on a slot) → a movie plays +``` + +The previous run's throw at `PC 0x82307128` is therefore **not inherent to this +menu path** — the same six presses got through it. That is consistent with the +trigger `title-crash-stl-tree.md` already names (an incomplete on-disc cache) and +with nothing about `NEW GAME`. 🟡 n = 1 either way; do not read it as "fixed". + +Worth recording because the first observation could easily have hardened into +"the new-game path crashes", which is what "A on NEW GAME hangs" had already +become once. diff --git a/docs/re/movie-binding.md b/docs/re/movie-binding.md index 7323277..889a3c6 100644 --- a/docs/re/movie-binding.md +++ b/docs/re/movie-binding.md @@ -125,3 +125,35 @@ Not a single tap. The failure recorded in black screen. Hammering breaks it; one press does exactly what the button is for. The scripts' `waiting it out (tapping breaks the title)` comment is **too broad**, and it costs every scripted boot ~2.5 minutes. + +## 🟡 `S00A.wmv` watched — weakly, and the weakness is the point + +Reaching the new-game intro finally worked (`SELECT DATA` did not crash this +time), so the manifest's `MS00A → S00A.wmv` was put to the same frame-signature +test that identified the attract movie. **It did not reproduce that test's +quality, and the honest read is "consistent with", not "confirmed".** + +* The first four samples give a clean monotonic `S00A` playhead — **2, 6, 9, 13 s** + across four 5-second samples — and `S00A` beats `ADV` on each. +* The single strongest frame of the run (contrast 47.4) matches `S00A` at + **0.916** against `ADV` 0.714. +* But the run as a whole is **not** the clean advancing playhead the attract test + produced (15 of 19, monotone throughout). Most frames here sit at contrast + 23–37, where the discrimination is poor by this page's own rule, and one + high-contrast frame matches `ADV` over `S00A`. Two locally-consistent runs + (2→13 s, then 86→90 s) do not join into one timeline. + +So the primary evidence that the new-game intro is `S00A.wmv` remains the +**manifest decode**; this run is weak corroboration and is recorded as such. A +clean identification needs denser sampling (the 30 fps `x11grab` route from +[`screen-transitions.md`](screen-transitions.md)) rather than 5-second +screenshots. + +### ⚠️ And the run was killed before the mission load + +The emulator disappeared at ~145 s with **no crash line in its own log** — the +last entries are routine `MEM-WATCH rss=1153MB` — so this was an external kill, +not a guest fault. It is the **second** time this session (the first at ~50 s +into a boot). Long dynamic runs are unreliable in this container, and the +`DELTASABER` plates of [`ui-title-build-map.md`](ui-title-build-map.md), which +would need a mission load, were not reached.