Ground infrastructure footer-bit consumers

This commit is contained in:
Jan Petykiewicz 2026-04-18 17:57:20 -07:00
commit ebee1a3a58
2 changed files with 11 additions and 4 deletions

View file

@ -217,10 +217,15 @@ Working rule:
`0x01 / 0x00`, and fixed prior profile span `0x03` in both saves, while
`0xff0000ff / 0x0001 / 0xff` stays on prelude `0x0001 / 0xff`, fixed short-flag pair
`0x00 / 0x00`, and widely scattered prior profile spans in both saves.
- That means the remaining infrastructure question is no longer broad exact-class identity. It is
specifically what those two short-flag families mean and why a minority of tunnel rows route
into the sparse `0xff0000ff / 0x0001 / 0xff` outlier class instead of the stable
`0x000055f3 / 0x0001 / 0xff` tunnel family.
- Direct consumers of those footer bits are grounded now too: `0x00528d90` only admits the child
when the explicit caller override is set, the surrounding global override byte
`[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 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.
- Source-side constructor analysis is narrower now too. `0x00490960` takes:
- mode at stack arg 1
- stem at stack arg 2