jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Bind infrastructure side-buffer load path

Browse source
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
Download patch file Download diff file Expand all files Collapse all files

18
docs/control-loop-atlas/runtime-roots-camera-and-support-families.md
View file

@ -2914,6 +2914,16 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
and restores cached primary-child slot `[this+0x248]` from the saved ordinal. So the rebuild
strip is consuming an already-materialized child stream rather than parsing the compact side
buffer directly.
The upstream handoff is explicit 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. That means
the `0x38a5` side-buffer seam is now a proven direct upstream feed into the child-stream restore
owner rather than only a candidate cache or serializer-side neighbor.
The child loader family is explicit 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 problem is row-to-record mapping inside the `0x38a5` stream, not identifying the
per-child loader family.
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
@ -2924,10 +2934,10 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
then republishes the two sampled triplet bands through `0x0052e8b0` and `0x00530720` after
attaching through `0x005395d0`. The non-clone branch still seeds the same literal
`Infrastructure` child but attaches through `0x0053a5d0` instead. That means the next unknown is
no longer whether this strip owns the child/rebuild seam at all, but which upstream owner
materializes the child stream that `0x0048dcf0` consumes, and whether the side-buffer prefix
groups feed that materializer, the direct payload-stem lane, or only the later
route/local-runtime family.
no longer whether this strip owns the child/rebuild seam at all, but which exact `0x38a5` rows
or compact-prefix regimes map to the child count, saved primary-child ordinal, and per-child
`+0x40` payload callbacks inside that direct load path, and which restored child fields still
retain those embedded name-pair semantics before the later route/local-runtime family runs.
The
remaining closure target above the grounded `0x38a5` side-buffer seam is therefore narrower now:
the next safe static pass should start at this exact attach/rebuild strip, not at the whole