fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: close the objective-counter address item in the backlog

Browse Source 
Keeps the refutation next to the confirmation rather than replacing it, and
records the rule a future session actually needs: try 0xbdb59668, check it
against the HUD, re-scan when it reads 0.

What stays open under it is unchanged and is the part that matters for the
autopilot - what the counter counts, and whether an OB-badged entity carries a
flag in its entity object.

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 18:39:40 +00:00
parent dd39cdd03d
commit 2a844e6da9
1 changed files with 13 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
docs/re/BACKLOG.md
View File

@@ -231,7 +231,7 @@ shared checkout (202 files, no submodule churn), profile bootstrapped with the
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
## ✅ SOLVED (2026-08-23) — the mission objective counter is at `0xbdb59668`, and the hunt is automated
🔴 **`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
@@ -242,17 +242,19 @@ 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).
🟡 **A clean scan has now been run** (HUD confirmed `004` on both sides of it,
filtered at a confirmed `012`): 17 candidates, one of which is **`0xbdb49668`** —
the run-1 address minus exactly `0x10000`, same page offset `0x9668`, which only
**2 of 39 596** candidates share. Amber, not green: the later sample landed
during the GAME OVER flash with no HUD on screen, so the survivors are
*unrefuted* rather than confirmed.
✅ **Settled the same day, once the HUD stopped costing a human round trip.**
`ob_read.py` reads the three digits by normalised template correlation and
`ob_hunt.py` runs the whole method unattended; run 4 then gave **one** survivor
from 35 897, selected on `004 → 008` and verified on the unselected `008 → 012`,
plus three live paired RAM/HUD readings. The blocker was never the pilot's
survival — the evidence lives in the first four minutes of the stage, and the
earlier runs simply could not look often enough to catch the `008` step.
**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. Both attempts so far
died the same way — the escorted ACROPOLIS is lost while `pilot.py` sits in
EVADE/RETIRE, and `REMAINING OB` then holds one value for ten minutes.
🔴 Yesterday's refutation **stands, refined**: the address is not universal (runs
2 and 3 read a hard 0 there while the HUD counted), but it is not meaningless
either — it recurs exactly, and run 3's amber candidate sits one 64 KB page below
it at the same page offset `0x9668`. Rule: try `0xbdb59668`, check it against the
HUD, re-scan (~5 min, `ob_session.sh`) when it reads 0.
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.