Narrow tier2 stock selector to machine shop outlier

This commit is contained in:
Jan Petykiewicz 2026-04-19 15:38:14 -07:00
commit cf6d36b8e7
4 changed files with 176 additions and 5 deletions

View file

@ -1347,6 +1347,20 @@
non-stock”; it is which stock alias-root cluster is selected and why later clone/replay paths
prefer the nonzero `0x000001f4` cluster while the peer-site residue can still surface a
zero-family `WeaponsFactory`-side root.
The stock-cluster-to-selector join is explicit now too. The checked-in `name_0x5e` + `.bca`
selector summary shows every grounded alias cluster is zero-selector by default, including the
nonzero `0x000001f4` clusters (`TextileMill x9`, `LumberMill x4`, `MeatPackingPlant x4`,
`Distillery x2`, `Toolndie x2`) and the zero-family `WeaponsFactory x6` cluster. The only
surfaced nonzero joined outlier is `MachineShop` inside the nonzero `TextileMill` cluster
(`byte_0xba = 0x3f`, `byte_0xbb = 0x00`). So the next Tier-2 source-selection pass should no
longer ask whether whole alias clusters map to nonzero bank bytes; it should ask why one
specific stock row inside the `TextileMill` cluster surfaces a nonzero selector while its peer
rows stay zero.
The global stock `.bca` selector report narrows that again: the exact `MachineShop.bca`
signature (`byte_0xb8 = 0x00`, `byte_0xb9 = 0x80`, `byte_0xba = 0x3f`, `byte_0xbb = 0x00`) is
unique across the checked-in stock corpus. So the remaining Tier-2 source frontier is not a
broad hidden family of nonzero stock rows; it is one surfaced stock-file outlier plus whatever
later clone/replay logic amplifies it into the numbered banked rows.
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
@ -1362,6 +1376,13 @@
naming branch from cloned bit `[candidate+0xba]`. So the unresolved Tier-2 seam is no longer
“find any direct writer to candidate `+0xba/+0xbb`”; it is “find the earlier seed or projection
owner that first makes some source/live rows reach that clone path with nonzero bank bytes.”
The top-level stock handoff above that clone pass is tighter now too. Direct disassembly of
`0x004196c0` shows the broader stock `*.bca` rebuild loop formatting the wildcard path rooted at
`0x005c93fc`, iterating the local `0x005c8190/0x005c8194/0x005c819c` find-first/find-next
strip, calling the per-file stock loader `0x00414490` for each hit, and only then
tail-calling `0x00419230`. So the remaining Tier-2 source problem is increasingly “which stock
rows that rebuild admits or seeds with nonzero bank bytes” rather than “which unrelated later
service invokes the banked clone pass.”
The stock owner chain above those parser fields is explicit now too:
`0x00438c8e -> 0x004131f0 -> 0x00412fb0 -> 0x004120b0` constructs root `0x0062b268`, and the
adjacent `.rdata` strings at `0x005c93f4..0x005c940e` prove that `0x00412fb0` is the