From c2b7c937928e55983cf5920cec496eb471ce4332 Mon Sep 17 00:00:00 2001
From: Sylpheed RE agent <agent@localhost>
Date: Wed, 26 Aug 2026 23:57:01 +0000
Subject: [PATCH] re: correct my own OB write-up -- I refuted a stale status
 line, not an open question
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The section I added last iteration claimed to be testing an untested 🟡 and
concluded "the address is run-dependent, always re-derive".  Both halves were
wrong, and the evidence was already further down the SAME file:

 - cross-run stability was not untested -- the body records 0xbdb59668 carrying
   the counter in 3 of 5 measured runs and reading a hard 0 in the other two.  The
   stale claim was in the status line at the top, which I took at face value.
 - "always re-derive" is worse advice than the rule the file already gives: try
   0xbdb59668 first, check it against the HUD, re-scan only when it reads 0.

What my run genuinely adds is a SIXTH data point with a new failure mode: the
address read neither the counter nor 0 but 95748078, constant over four samples.
Status line rewritten to match the body (🟡 recurs but not universal), so the
document no longer contradicts itself.
---
 .../structures/mission-objective-counter.md   | 31 ++++++++++++++-----
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/docs/re/structures/mission-objective-counter.md b/docs/re/structures/mission-objective-counter.md
index 86863af0..073b1f24 100644
--- a/docs/re/structures/mission-objective-counter.md
+++ b/docs/re/structures/mission-objective-counter.md
@@ -1,14 +1,31 @@
 # `REMAINING OB` — the mission's own objective counter, in RAM
 
-**Status:** ✅ `CONFIRMED` for one Stage 02 run: a **big-endian u32** whose value
-is exactly the HUD's `REMAINING OB`, verified across two transitions it was not
-selected by. ❌ **the ADDRESS is run-dependent — measured 2026-08-26, see below.**
-❔ what it counts, and whether objective-marked entities carry a flag.
+**Status:** ✅ `CONFIRMED` as a **big-endian u32** whose value is exactly the
+HUD's `REMAINING OB`. 🟡 the ADDRESS recurs but is not universal — `0xbdb59668`
+carried it in 3 of 5 measured runs, read a hard 0 in 2, and read garbage in a
+6th (2026-08-26). ❔ what it counts, and whether objective-marked entities carry
+a flag.
 
-> ## ❌ Cross-run stability: REFUTED (2026-08-26)
+> ## 🟡 A sixth run, and a new failure mode (2026-08-26)
 >
-> The 🟡 above said cross-run stability was untested. It is now tested, and the
-> address does **not** carry over. A fresh Stage 02 run (guarded route, stage
+> ### ❌ First, a correction to this very section
+>
+> As originally written this section claimed to be *testing an untested* 🟡, and
+> concluded "the address is run-dependent — always re-derive". Both halves were
+> wrong, and the evidence was already further down **this same file**:
+>
+> * Cross-run stability was **not** untested. The status line at the top said so,
+>   but the body had tested it repeatedly — `0xbdb59668` carries the counter in
+>   **3 of the 5** runs measured, and reads a **hard 0** in the other two. I
+>   refuted a stale *status line* and presented it as news.
+> * "Always re-derive" is worse advice than the rule this file already gives:
+>   **try `0xbdb59668` first, check it against the HUD, and re-scan only when it
+>   reads 0.** A scan costs ~5 minutes; the check costs seconds.
+>
+> ### What this run actually adds
+>
+> A **sixth** data point, and a failure mode not previously seen: the address
+> read neither the counter nor 0 but **95748078**, constant over four samples. A fresh Stage 02 run (guarded route, stage
 > asserted via `assert_stage.py UN_f101_TCAF_Acropolis`):
 >
 > | | |