From 4fa222d8103e3d846d2291a6706f254ab2ff74ac Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Sun, 23 Aug 2026 18:04:29 +0000 Subject: [PATCH] docs: a clean scan for REMAINING OB, and one candidate that is hard to dismiss With the launcher repaired the scan could be run the way the method asks: the HUD was confirmed at 004 immediately before AND after the 0.9 s scan, and the filter was taken at a confirmed 012. That leaves 17 candidates from 39596. One of them is 0xbdb49668 - the run-1 address minus exactly 0x10000, at the same page offset 0x9668. Checked rather than admired: of all 39596 words holding 4 at scan time, exactly TWO sit at that page offset, so a survivor landing there by chance is a ~5e-5 event. The reading it suggests is testable - the counter sits at a fixed offset in an allocation whose base moves by whole 64 KB pages. Recorded as amber, not green, and the reason is written down: the later sample that killed 10 of the 17 was taken during the GAME OVER flash, with no HUD on screen, so the seven survivors are unrefuted rather than confirmed. The mission ended because the escorted ACROPOLIS was lost at ~13 min while pilot.py sat in EVADE/RETIRE; REMAINING OB held at 012 for the ten minutes before that, so there was no transition to verify against. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE --- .../structures/mission-objective-counter.md | 43 +++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/docs/re/structures/mission-objective-counter.md b/docs/re/structures/mission-objective-counter.md index 81ffb349..14c8acf9 100644 --- a/docs/re/structures/mission-objective-counter.md +++ b/docs/re/structures/mission-objective-counter.md @@ -107,3 +107,46 @@ that is still *engaging*, which is the same constraint **Unchanged and still open:** what the counter counts, and whether an `OB`-badged entity carries a flag in its entity object. Nothing in this pass touched that. + +## ๐ŸŸก 2026-08-23 (later) โ€” a third run, a HUD-clean scan, and one candidate that is very hard to explain away + +With the launcher repaired the scan could finally be run the way the method +asks. **HUD confirmed `004` immediately before *and* after the scan** (0.9 s), so +the 39 596-entry candidate set is valid at that value; then filtered when the +HUD was confirmed at `012`. + +| step | HUD | candidates | +|---|---|---| +| scan | `004` (confirmed both sides) | 39 596 | +| filter | `012` (confirmed) | **17** | +| later sample | โ€” (see caveat) | 7 still 12 | + +**The survivor of interest is `0xbdb49668`** โ€” the run-1 address `0xbdb59668` +**minus exactly `0x10000`**, at the identical page offset `0x9668`. + +**That is not a cheap coincidence, and it was checked rather than admired.** Of +all 39 596 words holding `4` at scan time, exactly **2** sit at page offset +`0x9668`; one of those two is in the 17, and it is this one. A survivor landing +there by chance is a ~5 ร— 10โปโต event. The reading it suggests โ€” the counter lives +at a fixed offset inside an allocation whose **base moves by whole 64 KB pages** +between runs โ€” is a testable claim, not a story: a third scan should again land +on `โ€ฆ9668`. + +**Why this is ๐ŸŸก and not โœ…, stated plainly.** The corpus's own rule is that a +candidate is believable once it tracks a transition it was *not* selected on, +against the HUD. This one has not done that yet: + +* The "later sample" that killed 10 of the 17 was taken **during the GAME OVER + flash** โ€” the escorted ACROPOLIS was lost at ~13 min โ€” so the HUD counter was + not on screen. The ten that *moved* are genuinely refuted; the seven that did + not move are merely **unrefuted**, which is a much weaker thing, and the + counter may simply be frozen once the mission ends. +* Between the filter and the mission end, `REMAINING OB` sat at `012` for about + ten minutes: `pilot.py` spent the window in EVADE/RETIRE at hull 822/1500 and + killed no objectives, so there was no transition to use. + +**The one experiment that settles it:** a run where the pilot is still engaging, +scanning and filtering as above, then watching `0xbdb4ยท9668`-equivalent across a +HUD-verified change. The blocker is the pilot's survival, not the method โ€” and +the same run would answer whether the page offset repeats, which is the stronger +result of the two.