# 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](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](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](mission-objectives-text.md) — the preference knob
gets about two marked-fighter kills per five minutes against a dozen turrets.