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

Bound infrastructure child-stream restore owner

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 13:25:14 -07:00
commit c3bd896877
3 changed files with 33 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -2908,6 +2908,12 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
`Infrastructure` children one ordinal at a time, tears down the higher extras above ordinal `5`,
refreshes cached primary-child slot `[this+0x248]` when needed, and finishes with the same
world-cell and route-side follow-on family around `0x00448a70`, `0x00493660`, and `0x0048b660`.
The outer owner above that loop is bounded now too: `0x0048dcf0` reads a child count plus one
optional primary-child ordinal from the tagged stream through `0x00531150`, zeroes `[this+0x08]`,
dispatches each fresh child through `0x00455a50 -> vtable slot +0x40`, culls ordinals above `5`,
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 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
@ -2918,8 +2924,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 side-buffer prefix
groups feed the clone-or-payload choice before the later route/local-runtime family runs.
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.
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