f6f8930ee7
The objective text settles what the counter is, so the hunt can be a correlation rather than a value scan: keep every word in the 32 MB heap that fell by the same amount, in the same interval, as a named e010 loss. One event cut roughly eight million words to 1056, so two or three more should leave a handful. The run did not get them. The turn's timeout fired at t=219 s and the probe saved its candidate set only at the end, so the 1056 were discarded and the follow-up attach started from nothing. That is the same mistake already recorded in guest-stalls.md, where an earlier probe deferred all analysis to the end and a timeout killed it with 240 s of data in memory and nothing written. The lesson was written down and then repeated in a new script four iterations later. The attach had a second gap: 535 s with zero losses of any kind, which is indistinguishable from a freeze, and ob_probe2 carried no stall witness so the run cannot say which it was. Both are fixed. Candidates are written after every event and SYLPH_OB_RESUME=1 reloads them so a chained attach keeps intersecting on the same mission, and the witness from wave7_probe is carried here. The underlying pattern is worth naming: each new probe starts from scratch and re-earns the same lessons about saving incrementally and validating liveness. A shared probe harness would stick where written-down lessons have not. The hunt itself is unfinished. No address is identified, and finishing needs a run that catches two or three marked-fighter kills, which is the same combat-effectiveness limit already recorded -- about two per five minutes against a dozen turrets.
2.8 KiB
Hunting REMAINING OB by correlation — method works, run did not finish
Status: ✅ the correlation method is sound and demonstrated; 🔴 the hunt is unfinished; 🔴 two self-inflicted defects, one a repeat.
The method
mission-phase-objectives.md settles what the
counter is: Stage 02 phase 1 asks to "shoot down all invading enemy fighters"
and the hints say red [OB] markers indicate the targets. So REMAINING OB
must fall when a marked fighter dies — and the per-record craft strength already
says exactly when that happens, for a named unit.
So instead of scanning for a value, intersect: keep every word in the 32 MB heap
that fell by the same amount, in the same interval, as an e010 loss. Each kill
event should cut the survivor set hard.
tools/re-capture/ob_probe2.py.
✅ It works — one event cut 8 million words to 1056
t= 219s e010 losses=2 (all=4) words falling by 2: 1056 -> candidates 1056
From ~8 M candidate words to 1056 on a single event. Two or three more should leave a handful.
🔴 The run did not finish, and the candidates were lost
The turn's timeout fired at t = 219 s, and the probe saved its candidate set only at the end — so the 1056 were discarded. The follow-up attach then started from nothing.
This is the same mistake already recorded in guest-stalls.md: "the first attempt deferred all analysis to the end of the run, and the turn's timeout killed it with 240 s of collected data still in memory and nothing written." I wrote that lesson down and then repeated it in a new script four iterations later.
Fixed: candidates are now written to /tmp/ob_candidates.json after every
event, and SYLPH_OB_RESUME=1 loads them so a chained attach keeps
intersecting on the same mission.
🔴 The attach could not tell a quiet mission from a frozen one
The follow-up attach logged 535 s with zero losses of any kind. That is
exactly what a freeze looks like, and ob_probe2 had no stall witness, so the
run cannot say which it was. Also fixed — the witness from wave7_probe is now
carried here.
Two defects in one iteration, both of them things this corpus had already learned. The pattern is that each new probe starts from scratch and re-earns the same lessons; the fix that would actually stick is a shared probe harness rather than a family of one-off scripts.
What is still open
The hunt itself. The method is demonstrated but no address is identified. What it
needs is a run that catches two or three e010 kill events, which is the same
combat-effectiveness limit recorded in
mission-objectives-text.md — the preference knob
gets about two marked-fighter kills per five minutes against a dozen turrets.