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

Bind Tier2 candidate clone seed index

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 14:09:36 -07:00
commit 3d1528adfc
2 changed files with 18 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1240,6 +1240,15 @@
naming branch from cloned bit `[candidate+0xba]`. So the unresolved Tier-2 seam is no longer
“find any direct writer to candidate `+0xba/+0xbb`”; it is “find the earlier seed or projection
owner that first makes some source/live rows reach that clone path with nonzero bank bytes.”
The clone-group seam is tighter now too. Candidate dword `[candidate+0x794]` is not a broader
runtime-owned field with many writers: the current direct write set only initializes it to zero
in `0x004120b0` and later assigns it in `0x00412d70` as the selected seed-row index that clones
should follow. The main consumers match that meaning:
`0x0041eba8` compares region-side row key `[row+0x2f2]` against `[candidate+0x794]`,
`0x004cccdc` excludes candidates whose seed-row index already matches an active row key, and
`0x0050a1cd` keeps the same seeded rows out of one later availability branch. So the remaining
Tier-2 seed question is now sharper: which source/live rows become the first seeded rows that let
`0x00412d70` propagate nonzero bank bytes within that clone family?
That candidate-side table now has a grounded fixed record layout too: each entry is a `0x22`-byte
blob with a zero-terminated candidate-name slot at `[entry+0x00..+0x1d]` and one trailing
availability dword at `[entry+0x1e]`, read through `0x00434ea0` and mirrored later into

9
docs/rehost-queue.md
View file

@ -748,6 +748,15 @@ Working rule:
divergence frontier is narrower again: not generic direct stores into candidate rows, but the
earlier seed or projection seam that first makes some source/live rows reach that clone path
with nonzero bank bytes.
The clone-group lane is tighter now too. Candidate dword `[candidate+0x794]` is not a broader
owner-state field written elsewhere; the current direct write set shows it is initialized to
zero in `0x004120b0` and then assigned only in `0x00412d70` as the chosen seed-row index that
later clones should follow. The known consumers now line up with that meaning:
`0x0041eba8` compares region-side row key `[row+0x2f2]` against `[candidate+0x794]`,
`0x004cccdc` excludes candidates whose `[candidate+0x794]` already matches one active row key,
and `0x0050a1cd` keeps the same seeded rows out of one later availability branch. So the open
question is not “who writes the mysterious group id?” but “which source/live rows become the
first seeded rows that let `0x00412d70` propagate nonzero bank bytes within that family?”
So the honest next queue head is now one step earlier again:
recover the non-stock writer or restore-time projection owner that makes some live candidates
reach those later consumer strips with nonzero `[candidate+0xba/+0xbb]` despite the observed