Clarify add-building batch row semantics

This commit is contained in:
Jan Petykiewicz 2026-04-19 02:08:05 -07:00
commit 32e7d797fe
2 changed files with 14 additions and 4 deletions

View file

@ -301,10 +301,12 @@ Working rule:
EventEffects table proves the actual grouped descriptors are add-building slots, not
special-condition verbs
- the compact opcode-`8` frontier therefore shifts:
the next static-analysis pass should determine whether opcode `8` on that shell-owned
add-building strip means a distinct add-building shell flow, and then continue the candidate
bridge past the currently grounded `503..569` front half of the widened strip, not more
missing-label recovery
direct disassembly of `0x00430270` now shows that the add-building consumer does not branch on
grouped opcode at all for descriptor strip `503..613`; it consumes the descriptor-derived
candidate id, placement count byte `0x11`, and the packed span words at `0x14/0x16`.
The next static-analysis pass should therefore target the remaining span-field meaning and
shell-owned placement-flow ownership on that strip, then continue the candidate bridge past the
currently grounded `503..569` front half of the widened strip, not more missing-label recovery
- the concrete owner strip above that bundle is grounded now too:
`0x00433060` is the direct non-direct serializer loop that writes `0x4e99/0x4e9a/0x4e9b`,
calls `0x00430d70` per live collection row, and sits beside the sibling `0x00433130` size/load