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/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
`PortNN` / `WarehouseNN` family is now more plausibly a setup-payload candidate-table / source
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
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
@ -771,6 +780,18 @@ Working rule:
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?”
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:
recover the setup-payload or restore-time projection owner that carries those static
`PortNN` / `WarehouseNN` rows into the live candidate clone families with nonzero