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

Narrow Tier2 rebank pass and source rows

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 14:20:12 -07:00
commit 87a5667c9e
2 changed files with 42 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1235,6 +1235,15 @@
stable offsets `0x6f77`, `0x7087`, `0x70cb`, and `0x7241`, while the same map corpus shows no
`MachineShop` string at all. So the live `PortNN` / `WarehouseNN` family now looks more like a
setup-payload candidate-table / source-row projection problem than a hidden alternate BCA stem.
The candidate-table rows behind that map hint are fixed now too. Direct
`runtime inspect-candidate-table` reads over those same three maps show the same contiguous
block every time: `Port00` at row `35` / offset `28535`, `Warehouse00` at row `43` / offset
`28807`, `Port01` at row `45` / offset `28875`, and `Warehouse01` at row `56` / offset `29249`,
with the surrounding `Port02..11` / `Warehouse02..11` rows staying in the same contiguous
cluster and each carrying availability trailer `0x00000001`. So the remaining Tier-2 source
problem is no longer whether those names exist as stable scenario rows; it is how that fixed
candidate-table cluster is projected into the later aux-record bank and then into the live clone
families.
The direct `+0xba/+0xbb` writer census now rules out a broad false lead too. The obvious new
stores at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side
portrait/string refresh helpers over a different id-keyed collection rooted through
@ -1259,6 +1268,18 @@
`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?
The later rebank-or-clone owner is bounded now too. Direct disassembly of `0x00419230` shows one
outer pass over bank selector `0` then `1`, with an inner `12`-ordinal sweep for each pass. For
each `(bank, ordinal)` pair it scans already-linked aux/source rows by owner candidate id
`[entry+0x173]`, requires nonzero bank byte `[candidate+0xba]` or `[candidate+0xbb]`
accordingly, prefers a previously materialized target whose ordinal field `[entry+0x187]`
already matches, otherwise clones one qualifying source row, copies the optional heap planes by
size `([entry+0xb8] * [entry+0xb9] << 5)`, stamps `[entry+0x187] = ordinal+1`, writes the
visible stem at `[entry+0x22]` from `Warehouse%02d` or `Port%02d`, mirrors that stem into the
exact-match key at `[entry+0x04]`, and finally rebinds `[entry+0x173]` by exact stem match back
into the live candidate pool. So the remaining Tier-2 source problem moves one step earlier
again: identify which qualifying source rows first satisfy each `(bank, ordinal)` pair before
`0x00419230` ever clones or renames them.
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