Ground infrastructure child construction strip

This commit is contained in:
Jan Petykiewicz 2026-04-18 15:29:56 -07:00
commit e80f7333f0
3 changed files with 156 additions and 78 deletions

View file

@ -3057,6 +3057,19 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
then closes `0x55f3`. So the remaining infrastructure problem is row-to-record mapping inside
the `0x38a5` stream and which chooser/seed values reach those string lanes and footer bytes, not
identifying the per-child loader family.
The source side is tighter now too. The paired chooser siblings already bounded above this seam
call `0x00490960` directly beside `0x0048a340/0x0048f4c0/0x00490200`, and `0x00490960` copies
selector fields into the child object (`[this+0x219]`, `[this+0x251]`, bit `0x20` in
`[this+0x24c]`, and `[this+0x226]`), allocates a fresh `0x23a` `Infrastructure` child, seeds it
through `0x00455b70` with caller-supplied stem input plus fixed literal `Infrastructure` at
`0x005cfd74`, attaches it through `0x005395d0`, seeds position lanes through
`0x00539530/0x0053a5b0`, and can cache it as primary child in `[this+0x248]`. The sibling
`0x00490200` then reads the same seeded lanes `[this+0x206/+0x20a/+0x20e]` back through the live
route collection at `0x006cfca8`, compares them against the current owner using
`[this+0x216/+0x218/+0x201/+0x202]`, and behaves like a route/link comparator layered above the
same child payload fields that `0x004559d0` later serializes. So the remaining infrastructure
problem is which chooser branches feed `0x00490960` which stem/selector tuples for each
grounded save-side class, not where the child payload lanes come from at all.
The smaller attach helper `0x00490a3c` is now bounded too: it conditionally allocates one
`Infrastructure` child from a caller-supplied payload stem, attaches it to the current owner, and
then seeds three caller-supplied position lanes through `0x00539530` and `0x0053a5b0`. The