Bind infrastructure side-buffer load path

This commit is contained in:
Jan Petykiewicz 2026-04-18 13:28:15 -07:00
commit 0d3e6c598d
3 changed files with 40 additions and 12 deletions

View file

@ -51,12 +51,24 @@ Working rule:
and restores cached primary-child slot `[this+0x248]` from the saved ordinal. That means the
child/rebuild loop is consuming an already-materialized child stream rather than parsing the
`0x38a5` compact-prefix seam directly.
- The upstream handoff is grounded now too: `0x00493be0` is the tagged collection load owner over
`0x38a5/0x38a6/0x38a7`, and it feeds each live infrastructure record straight into
`0x0048dcf0` after restoring one shared owner-local dword into the `0x90/0x94` lane. So the
remaining infrastructure question is no longer whether `0x38a5` reaches the child-stream restore
path at all; it is which exact rows or compact-prefix regimes map to the child count, saved
primary-child ordinal, and per-child `+0x40` payload callbacks inside that direct path.
- The child loader identity is closed now too: local `.rdata` at `0x005cfd00` proves the
`Infrastructure` child vtable uses the shared tagged callback strip directly, with
`+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining
infrastructure frontier is row-to-record mapping inside `0x38a5`, not “which loader family does
this child use?”.
- The smaller helper `0x00490a3c` is narrower now too: it allocates one literal `Infrastructure`
child, seeds it through `0x00455b70` with caller-provided stem input, attaches it through
`0x005395d0`, seeds position lanes through `0x00539530/0x0053a5b0`, and optionally caches it as
the primary child. So the next concrete infrastructure question is which upstream owner
materializes the child stream that `0x0048dcf0` consumes, and whether `0x38a5` feeds that owner
or only a separate payload/cache lane.
maps the direct `0x38a5` rows into the child count, primary-child ordinal, and per-child payload
callbacks consumed by `0x0048dcf0`, and which restored child fields still retain those embedded
name-pair semantics before route/local-runtime follow-ons take over.
- Reconstruct the save-side region record body on top of the newly corrected non-direct tagged
region seam (`0x5209/0x520a/0x520b`, stride hint `0x06`, `Marker09` record stems) now that the
`0x55f3` payload is known to be fully consumed by the embedded profile collection on grounded