Walked the container's list from +16 for 200s. The structure holds: +20 tracks the node count, nodes chain through their first word, and entries appear as the mission runs (0 -> 1 -> 2, then stable). The record layout does not. I expected node+8 to hold small symbol indices, which the pop's out-parameters made natural. Every field is a guest heap pointer (0xBC..), so trigger records reference objects rather than table indices, and those objects are unidentified. Also records a false resolution I introduced: a line printed 'f4=0(ADN101)' because the raw value is 0 and my formatter mapped index 0 to symbol-table-2's first entry. ADN101 is not in that record -- the pretty-printer invented a name for a null. A resolver must refuse values that were never indices. And corrects the previous section: sub_8226E3B8 is a CLEAR, not a push. Its tail decrements a counter, calls an erase helper, and loops while [+20] != 0. So built-in 100 clears the queue then rebuilds the thread list, matching the built-in table's own wording; 'push' was my label, not the disassembly's. Two callers: vt2 (script) and 0x8226D420 (an engine site). What appends a node is still unidentified.