From b67f8d5c596ea1a0c52db4cee943abda7d5fbe61 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Mon, 24 Aug 2026 00:41:59 +0000 Subject: [PATCH] docs: fourth bit-level attempt - frozen again, but caught in a minute Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE --- docs/re/mission-freeze-and-ob-flag.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/docs/re/mission-freeze-and-ob-flag.md b/docs/re/mission-freeze-and-ob-flag.md index 77680612..942d5fb4 100644 --- a/docs/re/mission-freeze-and-ob-flag.md +++ b/docs/re/mission-freeze-and-ob-flag.md @@ -251,3 +251,21 @@ Of the Stage 02 runs that have reached flight, roughly half end early — a free or a GAME OVER when the escorted ACROPOLIS or the craft is lost — and the scan needs the run to survive **two** counter transitions. Nothing here fixes that; it is why three attempts produced one filter between them. + + +### A fourth bit-level attempt (2026-08-24) — the guard earned its keep + +`ob_bitflag` now picks the counter's address itself from the three seen so far, +so the run started immediately at flight entry: + +``` +HUD=4 RAM=4 at 0xbdb59668 +[A] counter=4 entities=31 +[A] (offset,bit) pairs set on exactly 4: 207; clear on exactly 4: 22 +GUEST FROZEN — the counter was never going to move +``` + +The freeze was caught in about a minute by `frozen()` instead of consuming the +whole 700 s window — which is the difference the guard makes, and the only thing +this attempt bought. Still **no verification**: four runs, four windows, zero +second transitions.