re: REMAINING OB found and verified — big-endian u32 at 0xbdb59668

Ported onto the shared harness, the HUD changed from 4 to 8 and the intersection
collapsed in a single step: one u32be survivor at 0xbdb59668, with the u16be and
u8 hits at 0xbdb5966a and 0xbdb5966b being the low half and low byte of that same
word.

Verified live rather than asserted. Reading screenshot and memory together three
times, the one legible HUD frame showed 012 against mem@0xbdb59668 = 12; the
other two frames were unreadable rather than mismatched. This independently
rediscovers the address the earliest sessions found by digit-transition hunting,
by a completely different method.

It also corrects an earlier conclusion. A previous run intersected HUD readings
of 4 and then 11, got zero survivors in every encoding, and that was written up
as eliminating big-endian u32 for the whole region. This run shows u32be holds
the counter, so the refutation was wrong. The likely cause is the input:
ob_digits.png has templates for 0 1 2 4 8 only, so values containing other
digits are misread rather than rejected, and "11" was probably one of those. A
single bad reading poisons an intersection permanently, because it removes the
true address and nothing later can restore it. The lesson is that an
intersection method needs individually verifiable inputs -- the reader's
confidence scores were printed but never gated on.

One observation reopens the arrival question in a useful way: the counter
increases, 4 then 8 then 12 across about five minutes, measured in memory so not
a digit misread. A count of remaining marked targets that rises means targets
are being added during the mission. That does not contradict the deployment
finding, since the roster is fixed at load, but it does mean the game marks new
objective targets as the mission proceeds. Watching this one address across a
whole mission is now the obvious next experiment and costs almost nothing.

docs/re/BACKLOG.md

@@ -642,6 +642,21 @@ search cannot find a *schedule*.
   watch in ~40 lines vs 150, first live run clean — 116 roster, 32 witnesses at
   10/s, **0 stalled**, 7 losses, TSV written incrementally. ⚠️ Existing probes
   deliberately **not** ported — they work and other docs cite their results.
+* ✅✅ **(2026-08-25) `REMAINING OB` FOUND AND VERIFIED: big-endian u32 at
+  `0xbdb59668`.** On the new harness, the HUD changed **4→8** and the intersection
+  collapsed in one step to a single `u32be` survivor (with `u16be`/`u8` hits being
+  the low half/byte of the same word). **Verified live**: HUD `012` vs
+  `mem@0xbdb59668 = 12`. Independently rediscovers the address the earliest
+  sessions found by digit-transition hunting.
+  🔴 **Corrects the earlier "u32be refuted"** — that came from intersecting on a
+  HUD reading of "11" which was almost certainly a misread, since `ob_digits.png`
+  only has templates for **0 1 2 4 8** and misreads rather than rejects other
+  digits. **A single bad input permanently poisons an intersection**; the reader's
+  confidence scores were printed but never gated on.
+  🟡 **The counter INCREASES: 4 → 8 → 12** in ~5 min, measured in memory. Marked
+  objective targets are being **added during the mission** — the arrival question
+  again, now with a one-word signal instead of a 32 MB scan. **Next: watch this
+  address across a whole mission.**
 * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;
   it rested on an untested assumption that a turn is one shell call. 595 s shell cap − ~220 s boot (a ~190 s title movie that cannot be
   tapped through) − ~25 s startup = **~350 s observation ≈ 193 game-seconds**.

docs/re/remaining-ob-hunt.md

@@ -258,3 +258,73 @@ Two HUD readings at **different** values, in non-stalled samples. The counter
 changes on kills, so this lands back on the combat limit — unless a phase change
 or another event moves it. The earlier 4 → 11 observation shows it does move,
 which is what makes the approach worth continuing.
+
+---
+
+# ✅ FOUND AND VERIFIED: `REMAINING OB` is a big-endian u32 at `0xbdb59668`
+
+## The run
+
+Ported onto the shared harness (`ob_hunt2.py`), the HUD changed **4 → 8** and the
+intersection collapsed in one step:
+
+```
+t=126s  HUD=4  u32be:8717  u32le:163  u16be:13844  u16be@1:3319  u16le:832  u8:36635
+t=191s  HUD=8  u32be:1     u32le:0    u16be:1      u16be@1:2     u16le:0    u8:3
+t=254s  HUD=8  (unchanged)
+```
+
+Resolving the survivor:
+
+| encoding | address |
+|---|---|
+| **`u32be`** | **`0xbdb59668`** |
+| `u16be` | `0xbdb5966a` — the low half of the same word |
+| `u8` | `0xbdb5966b` — the low byte of the same word |
+
+All three are the same location. The `u16be@1` pair and the other `u8` hits are
+elsewhere and did not survive as a coherent field.
+
+## ✅ Verified live against the HUD
+
+Read three times, twenty seconds apart, screenshot and memory together:
+
+```
+HUD='0?2'   mem@0xbdb59668 = 12      (HUD frame unreadable)
+HUD='012'   mem@0xbdb59668 = 12      MATCH
+HUD='???'   mem@0xbdb59668 = 12      (HUD frame unreadable)
+```
+
+The one legible frame agrees exactly. **`REMAINING OB` is a big-endian `u32` at
+`0xbdb59668`** — independently rediscovered by value-intersection, and landing on
+the same address the earliest sessions found by digit-transition hunting.
+
+## 🔴 Correction: the earlier "big-endian u32 refuted" was wrong
+
+An earlier run intersected HUD readings of 4 and then **11** and got zero
+survivors in every encoding, which was written up as eliminating `u32be` for the
+whole region. This run shows `u32be` holds the counter.
+
+The likely cause is the reading itself: `ob_digits.png` only has templates for
+**0 1 2 4 8**, so any value containing 3/5/6/7/9 is misread rather than rejected,
+and "11" was probably one of those. A single bad reading poisons an intersection
+permanently — it removes the true address and nothing later can bring it back.
+
+**Lesson: an intersection method needs its inputs to be individually verifiable.**
+The HUD reader's confidence scores were printed but never gated on; a minimum
+score would have dropped the bad frame instead of trusting it.
+
+## 🟡 The counter *increases*: 4 → 8 → 12
+
+Across roughly five minutes the value went 4, then 8, then 12 — measured in
+memory, so not a digit misread. A counter of *remaining* marked targets that
+rises means **targets are being added during the mission**.
+
+That is the arrival question again, and now with a cheap, reliable, one-word
+signal instead of a 32 MB scan. It does not contradict
+[mission-phase-deployment.md](mission-phase-deployment.md) — the roster's
+deployment is fixed at load — but it does mean the game *marks* new objective
+targets as the mission proceeds.
+
+Watching this one address across a mission is now the obvious next experiment,
+and it costs almost nothing.