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

Rule out alternate Tier2 BCA import callers

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 14:05:27 -07:00
commit 7769abd618
2 changed files with 18 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1216,6 +1216,15 @@
already-materialized bank/template bytes instead of explaining how live candidates diverge from already-materialized bank/template bytes instead of explaining how live candidates diverge from
the all-zero shipped `BuildingTypes/*.bca` corpus before the later `Port%02d` / the all-zero shipped `BuildingTypes/*.bca` corpus before the later `Port%02d` /
`Warehouse%02d` rebuild. `Warehouse%02d` rebuild.
The constructor/import strip is fixed in the same negative way now too: `0x00438c70` allocates
the live candidate pool through `0x004131f0`, calls `0x004411d90` (currently a no-op stub), and
only then allocates the auxiliary/source pool through `0x0041aa50`, so there is no checked
alternate branch between those constructors. The only current caller of source-record importer
`0x00414490` is `0x00419788`, and the surrounding `.rdata` at
`0x005c93f0/0x005c9400` proves that strip is the stock `"%1*.bca"` scan under
`".\\Data\\BuildingTypes\\"`. So the remaining bank-byte divergence is not hidden inside a
second caller of the BCA parser; it has to happen after the fixed stock `BuildingTypes/*.bca`
import has already run, or through some later non-stock projection seam above it.
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

9
docs/rehost-queue.md
View file

@ -723,6 +723,15 @@ Working rule:
`0x00437737 -> 0x00434f20 -> 0x00412c10` strip. So even the visible startup preseed still `0x00437737 -> 0x00434f20 -> 0x00412c10` strip. So even the visible startup preseed still
consumes already-materialized bank/template bytes rather than explaining how they became consumes already-materialized bank/template bytes rather than explaining how they became
nonzero in the first place. nonzero in the first place.
The constructor/import seam is fixed in the same negative way now too: `0x00438c70` allocates
the live candidate pool through `0x004131f0`, calls `0x004411d90` (currently a no-op stub),
and only then allocates the aux/source pool through `0x0041aa50`, so there is no hidden branch
between those two constructors. The only checked caller of source-record importer `0x00414490`
is `0x00419788`, and the surrounding `.rdata` proves that strip is the stock
`"%1*.bca"` / `".\\Data\\BuildingTypes\\"` scan rather than a map-specific alternate
package path. So the remaining Tier-2 mystery is not “which hidden caller invokes the BCA
parser?”; it is “which later non-stock writer or projection seam makes live
`[candidate+0xba/+0xbb]` diverge after the fixed stock BCA import has already run?”
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 non-stock writer or restore-time projection owner that makes some live candidates recover the non-stock writer or restore-time projection owner that makes some live candidates
reach those later consumer strips with nonzero `[candidate+0xba/+0xbb]` despite the observed reach those later consumer strips with nonzero `[candidate+0xba/+0xbb]` despite the observed