From f4a5a84142381c000572bfa7005071832fccdd36 Mon Sep 17 00:00:00 2001
From: Sylpheed RE agent <agent@localhost>
Date: Tue, 25 Aug 2026 13:47:56 +0000
Subject: [PATCH] re: correction -- the script reads its own flags via built-in
 9

Last iteration ended with 'what reads the flag file is unknown' after an offset
search failed. The framing was wrong: I was hunting an engine-side reader, but
the consumer is the script itself, through built-in 9 (read_freg), which loads
[phase+88][i] into the double result register.

Stage02.ssb calls read_freg 12 times -- the same count as set_flag (12) and
clear_flag (12) -- so the latch is symmetric and entirely inside the VM. That
closes the middle of the set_flag -> ... -> END_PHASE chain: one coroutine
latches, another reads it back and branches.

Also records an unconfirmed observation: op10 + op13 pairs with consecutive
small immediates and their own code offsets look like a case/branch dispatch.
Flagged as a pattern, not named -- neither handler has been read.
---
 docs/re/structures/isl-builtins.md | 39 ++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/docs/re/structures/isl-builtins.md b/docs/re/structures/isl-builtins.md
index 452cdbd1..1d78151b 100644
--- a/docs/re/structures/isl-builtins.md
+++ b/docs/re/structures/isl-builtins.md
@@ -145,6 +145,45 @@ missing it meant every unit predicate printed with **no arguments at all**
 complete and was silently empty where it mattered most. Both staging forms are
 now handled.
 
+## ✅ Correction: the script reads its own flags — no engine reader needed
+
+Last iteration ended with "what reads the flag file is unknown", after an offset
+search failed and a promising hit in `sub_8226D740` turned out to be a trigger
+record. **The framing was wrong.** I was looking for an *engine-side* reader;
+the consumer is the **script itself**, through built-in **9** (`read_freg`),
+which loads `[phase+88][i]` into the double result register `[phase+176]`.
+
+`Stage02.ssb` calls it **12 times** — the same count as `set_flag` (12) and
+`clear_flag` (12). So the latch is symmetric and entirely inside the VM:
+
+```
+set_flag(i)   ->  [phase+88][i] = 1.0 , [phase+120][i] = 1
+read_freg(i)  ->  [phase+176]   = [phase+88][i]
+clear_flag(i) ->  zero entry i, or all 32 when the argument is -1
+```
+
+That closes the middle of the `set_flag → … → END_PHASE` chain: a condition
+coroutine latches a flag, and another coroutine reads it back with `read_freg`
+and branches on it.
+
+## 🟡 `op10` + `op13` look like a switch
+
+Seen repeatedly, e.g. at `0x5774`:
+
+```
+op13  -> 0x5448
+op10  imm 4
+op13  -> 0x54F0
+op10  imm 5
+op13  -> 0x5598
+```
+
+Consecutive small immediates each paired with their own code offset is the shape
+of a **case/branch dispatch**, and `op12` is already confirmed as the
+unconditional jump. **Not confirmed** — the handlers (`0x82271598` for op10,
+`0x82271830` for op13) have not been read, and I am not going to name them from
+a pattern alone.
+
 ## 🟡 Not settled
 
 * **Three handlers resisted**: id 55 (`vt35`, 411 instructions, returns a float),