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

Refine next owner questions for blocked seams

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 12:56:43 -07:00
commit 4d98967c41
3 changed files with 34 additions and 1 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

@ -2911,6 +2911,18 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
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
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
placed-structure family. The key open questions are whether the compact-prefix/name-pair groups
feed the first-child triplet clone lane, the caller-supplied payload-stem lane, or only the
later route/local-runtime follow-on family; whether cached primary-child slot `[this+0x248]`
becomes the first owner-visible bridge between those side-buffer groups and route-entry rebuild;
and which child fields or grouped rows absorb the side-buffer payload before
`0x00448a70/0x00493660/0x0048b660` become relevant. That keeps the top-ranked next mapping target
explicit as `0x0048a1e0`, `0x0048dd50`, and `0x00490a3c`, with the serializer/load companions and
route/local-runtime follow-ons staying secondary until one concrete child-consumer bridge is
grounded.
The
direct route-entry side of the same family is no longer anonymous either: `0x0048e140`,
`0x0048e160`, and `0x0048e180` are the three direct resolvers over owner fields
`[this+0x206/+0x20a/+0x20e]` into the live route-entry collection `0x006cfca8`. Another shared