Bind Tier2 candidate clone seed index

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

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