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 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 `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. 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 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 stores at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side
portrait/string refresh helpers over a different id-keyed collection rooted through 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 `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 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? `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 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 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 availability dword at `[entry+0x1e]`, read through `0x00434ea0` and mirrored later into

21
docs/rehost-queue.md
View file

@ -746,6 +746,15 @@ Working rule:
corpus shows no `MachineShop` string at all. That moves the queue head again: the live corpus shows no `MachineShop` string at all. That moves the queue head again: the live
`PortNN` / `WarehouseNN` family is now more plausibly a setup-payload candidate-table / source `PortNN` / `WarehouseNN` family is now more plausibly a setup-payload candidate-table / source
row projection problem than a hidden stock-BCA stem problem. row projection problem than a hidden stock-BCA stem problem.
The fixed candidate-table rows behind that hint are now checked directly too:
`runtime inspect-candidate-table` shows the same contiguous block in all three maps with
`Port00` at row `35` / file 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 question
is no longer whether those names exist as stable scenario rows; it is how that stable
candidate-table cluster is projected into the later aux-record bank and then into the live
clone families.
The direct `+0xba/+0xbb` writer census is narrower now too. The obvious newly surfaced stores The direct `+0xba/+0xbb` writer census is narrower now too. The obvious newly surfaced stores
at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side portrait/string at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side portrait/string
refresh helpers: they walk a separate id-keyed collection through `0x0053f830`, free and refresh helpers: they walk a separate id-keyed collection through `0x0053f830`, free and
@ -771,6 +780,18 @@ Working rule:
and `0x0050a1cd` keeps the same seeded rows out of one later availability branch. So the open 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 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?” first seeded rows that let `0x00412d70` propagate nonzero bank bytes within that family?”
The later rebank-or-clone owner is narrower now too. Direct disassembly of `0x00419230` shows
one outer pass over bank selector `0` then `1`, with an inner `12`-ordinal sweep each time.
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. That moves the queue head one step earlier again: identify
which qualifying source rows first satisfy each `(bank, ordinal)` pair before `0x00419230`
ever clones or renames them.
So the honest next queue head is now one step earlier again: So the honest next queue head is now one step earlier again:
recover the setup-payload or restore-time projection owner that carries those static recover the setup-payload or restore-time projection owner that carries those static
`PortNN` / `WarehouseNN` rows into the live candidate clone families with nonzero `PortNN` / `WarehouseNN` rows into the live candidate clone families with nonzero