docs: the REMAINING OB address does not survive a run - refuted twice over

0xbdb59668 reads 0 in two independent Stage 02 runs while the HUD counts
004 -> 008 -> 012. Not an unmapped read: SEEK_DATA at that offset returns the
offset itself and the next hole is 5 MB later, so it is an allocated,
zero-filled word. The address was a per-run artefact, exactly as that file
already suspected it might be; the method is the durable result.

Re-finding it in the new run also failed, and both failures are recorded because
they are the instructive part. Two candidates were produced and both died on the
corpus's own rule -- verify across a transition you did not select on:
0xbc2377dc went 12 -> 18 while the HUD stayed 012 and read 3 two minutes later,
and 0xbd295b04 was plain noise.

One correction to the method note in that file: the scan is not slow. Over the
live /dev/shm image it takes 0.9 s. The real trap is that REMAINING OB climbs
004 -> 012 within about four minutes as waves spawn, so a scan is only valid if
the HUD is confirmed to hold the same value immediately before AND after it --
which is why the earlier 4-then-8 intersection came back empty.

What blocked finishing: with pilot.py retired at hull 340/1500 nothing was
killing objectives and the counter sat at 012 for five minutes, so there was no
later transition to filter on. What the counter counts, and whether an OB-badged
entity carries a flag, is untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-23 17:16:07 +00:00
parent c905b3b6ad
commit d412347c37
3 changed files with 93 additions and 0 deletions

View File

@@ -199,6 +199,50 @@ See [`structures/ui-composable-bundles.md`](structures/ui-composable-bundles.md)
The investigation that got here follows, kept in full because most of it is
refutations that were worth the cost.
## The dynamic-RE state is not in git, and it was gone
**Found 2026-08-23.** Everything the oracle runs on — the baseline emulator
binary, the Xbox profile, the Stage 02 save, the shader/code caches — lives
outside both repos and had been wiped. `sylph-doctor` says "all good" without
any of it; the first symptom is `NO PROFILE on disc` one second into a boot.
**Rebuilt and verified by driving it** (LOAD GAME lists the slot → READY ROOM →
Stage 02 flight): [`dynamic-re-state-restore.md`](dynamic-re-state-restore.md)
carries the recipe — incremental rebuild of `auto/upstream-baseline` in the
shared checkout (202 files, no submodule churn), profile bootstrapped with the
*instrumented* binary's `--create_profile_if_none`, and the committed
`savedata-stage02-5pct.bin` installed **without** an Xbox content header, which
`ContentManager::ListContent` does not need.
**Open, and cheap:**
* 🔎 **`launch_mission.sh` does not finish unattended on restored state.** It now
reaches the READY ROOM and stops on **BRIEFINGS** — its `step up; tap A` for
TAKE OFF is swallowed because a fixed `sleep 28` precedes it. Replacing that
sleep with a wait for the screen (`screen_id.py`) is the whole fix. Both runs
on 2026-08-23 were finished by hand from where it stopped.
***Nothing guarantees this state survives the next container.** If it is
meant to, the profile + save + `bin/` copies want a home inside a repo or a
named volume; that is a call for the user, not for an agent.
## The mission objective counter's ADDRESS is per-run
🔴 **`0xbdb59668` is refuted as a durable address** (2026-08-23): 0 in two
independent Stage 02 runs while the HUD read `004`/`008`/`012`, on an allocated
(not sparse) page. The **method** stands; the number does not, and every session
must re-scan. Two candidates from the re-scan were themselves refuted by the
corpus's own "verify across a transition you did not select on" rule. Detail and
the corrected method note (the scan takes **0.9 s** — the trap is the counter
climbing `004 → 012` in four minutes, not scan duration) in
[`structures/mission-objective-counter.md`](structures/mission-objective-counter.md).
**First step for whoever takes it:** a run whose pilot is still *engaging* when
the scan happens, so a later transition exists to filter on — `pilot.py` had
retired to hull 340/1500 and the counter then sat at `012` for five minutes.
The follow-on that the autopilot actually needs is unchanged and untouched:
❔ what the counter counts, and whether an `OB`-badged entity carries a flag in
its entity object.
## The declaration table is not a paint order on every screen
**Found 2026-08-17**, building the Explorer's UI Screens browser on