From 87a5667c9eb08436bcaa566ad0d9d645b796af9b Mon Sep 17 00:00:00 2001 From: Jan Petykiewicz Date: Sun, 19 Apr 2026 14:20:12 -0700 Subject: [PATCH] Narrow Tier2 rebank pass and source rows --- ...ntime-roots-camera-and-support-families.md | 21 +++++++++++++++++++ docs/rehost-queue.md | 21 +++++++++++++++++++ 2 files changed, 42 insertions(+) diff --git a/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md b/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md index 759b792..ca06fa8 100644 --- a/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md +++ b/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md @@ -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 diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md index 4c05979..4abe384 100644 --- a/docs/rehost-queue.md +++ b/docs/rehost-queue.md @@ -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