Sylpheed/docs/re/isl-trigger-queue.md

✅ What appends to the trigger queue — built-in 25, not the engine

structures/isl-builtins.md took the trigger queue at phase+272 a long way — its layout, its live count at +272+20, and the generic appender sub_8226EAB8 — and stopped at: "What actually appends a node is still unidentified." Its suggested next step was a gdb watchpoint on a running emulator.

It is a static question after all.

The search that works

sub_8226EAB8 is a shared list helper with 16 callers, so it cannot be identified by name. But the corpus records that the trigger container embeds its inner list at +12, so the caller must hand it container + 12. Two of the 16 do:

0x8226E208   addi r3, r30, 12
0x8226A2B4   addi r3, r29, 12

and in the second, r29 is set 34 instructions earlier:

8226A22C  addi r29, r24, 272     ; r24 = the ScriptPhase
8226A2B4  addi r3,  r29, 12      ; -> phase + 272 + 12
          bl   0x8226EAB8        ; the generic append

phase + 272 + 12 is exactly the inner list whose count the corpus watched at phase + 272 + 20. sub_8226A0D8 is the appender.

🔑 And it is a BUILT-IN, so the script appends its own triggers

sub_8226A0D8 is ScriptPhase vtable slot 28, and slot 28 is what built-in 25's stub tail-calls. Its entry is the standard built-in shape — r3 = the phase, r4 = the local[] base, [phase+324] indexed by local[4].

There are ZERO real bl 0x8226A0D8 instructions in the image. It is reached only through the vtable, i.e. only as a built-in. So the queue is populated by the script, not by the engine — which retires the residual "the engine moves records into the phase's queue each frame" reading that isl-builtins.md already flagged as unsupported by its call site.

Built-in 25's argument shape agrees with the corpus's independently measured tables: it is in UNIT_ARG (a unit at local[4]) and in SYM1_SLOTS[12] (a symbol-table-1 name — a route, message or objective — at local[12]).

🔴 REFUTED: this does not explain the unreachable routines

The attractive next step was that built-in 25 carries the coroutine entry a trigger fires, which would have seeded the 389 routines reachable from no static entry. It does not.

At Stage 02's built-in 25 sites, taking each staged operand as a code offset from the phase base:

staged slot	values	landing on an instruction boundary
0	2	0 — 0 %
4	2	0 — 0 %
8	2	0 — 0 %
12	2	0 — 0 %
control: an arbitrary 4-aligned offset	—	38.7 %

Nothing scores even at chance. And the scale is wrong anyway: built-in 25 has only 2 call sites in Stage 02 — far too few to account for ~15 % of the code being unreachable.

So the trigger queue is now identified, but what starts the unreachable routines remains open, and it is not this.

🟡 Not settled

• What a trigger node contains, and what consumes it. The append is located; the node's own layout is not read.
• The other +12 caller, 0x8226E208 in sub_8226E160, appends to some other embedded list — not shown to be the trigger queue.
• Built-in 25 is still unnamed. "Appends to the trigger container" is what it does mechanically; what the trigger means needs the consumer.