Link infrastructure footer gate to presentation owner

This commit is contained in:
Jan Petykiewicz 2026-04-18 17:59:30 -07:00
commit 52d47b6f91
2 changed files with 8 additions and 1 deletions

View file

@ -222,10 +222,15 @@ Working rule:
`[owner+0x3692]` is set, or bit `0x20` in `[child+0x20]` is set; the sibling loop
`0x00529730` only takes the later `0x530280` follow-on when bit `0x40` in `[child+0x20]` is
set.
- That footer-bit consumer strip is tied to a broader higher-layer owner family now too:
`0x005295f0..0x005297b7` repopulates candidate cells through `0x00533ba0`, walks candidate
child lists through `0x00556ef0/0x00556f00`, and honors the same controller mode byte
`[owner+0x3692]` that the atlas already places under the world-window presentation dispatcher.
- That means the remaining infrastructure question is no longer both footer bytes. It is
specifically why the stable `0x000055f3 / 0x0001 / 0xff` tunnel family sets the first footer
byte / bit-`0x20` admission gate while the sparse `0xff0000ff / 0x0001 / 0xff` outlier class
clears it.
clears it, inside that nearby-presentation/controller owner family rather than at the serializer
layer.
- Source-side constructor analysis is narrower now too. `0x00490960` takes:
- mode at stack arg 1
- stem at stack arg 2