docs: promote the in-mission freeze - it is now blocking the item behind it

Two more attempts at the OB-flag experiment, both stopped by it: one froze before
the counter could move, the next had the counter at a different address (the
tool refused to run rather than report nonsense) and then froze as well.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-23 19:36:20 +00:00
parent 188e911ec7
commit 15d240bffb

View File

@@ -269,15 +269,20 @@ is what the autopilot needs in order to CHOOSE a target. One run in:
***20 candidate per-entity flag offsets** exist (offsets where exactly 4 of
23 entities share a value) and have **never been put to the second test**,
because the guest froze before the counter could move.
* 🔴 **An in-mission freeze**, intermittent: this run stopped advancing ~10 s
into flight — 724 s of identical `pilot.py` state, two screenshots six seconds
apart byte-identical — while `screen_id` said `flight`, the emulator burned
212 % CPU and every liveness check passed. `frozen.py` detects it in one call
now, and `ob_hunt.py`/`ob_flag.py` abort on it instead of waiting out a
timeout. **What causes it is untouched.**
* 🔴 **An in-mission freeze — now the item in front of everything else**, and it
has a lead: the log ends in **1 171 refused resumes of one thread by one
thread**, against ~7 in a normal boot, and 11 of 79 host threads have zero CPU.
That is the lost-resume signature in a build that already has the lost-resume
fix. `frozen.py` detects the state in one call; `ob_hunt.py`/`ob_flag.py` abort
on it. **Roughly two runs in three.** Next: reproduce with the Kernel channel
on (`LOG_MASK=12 LOG_LEVEL=3`) and map guest handle `F8000240` to a host tid.
See [`mission-freeze-resume-spin.md`](mission-freeze-resume-spin.md).
**First step:** re-run `ob_flag.py` on a run that is advancing — it aborts early
now if it is not. Second step, if that comes back empty: `entities2.typed` only
now if it is not. ⚠️ Attempted again 2026-08-23 and **blocked twice**: one run
froze before the counter could move, and the next put the counter at a different
address (`0xbdb59668` held a float there — the tool refused to run, correctly)
and then froze too. The freeze item above is now the prerequisite. Second step, if that comes back empty: `entities2.typed` only
sees entities whose position *changes*, so a stationary objective is invisible to
it, and the enumeration itself would need widening before a null result means
anything.