Bridge peer-site names to stock building family

This commit is contained in:
Jan Petykiewicz 2026-04-19 15:19:09 -07:00
commit ee8311b3f2
3 changed files with 157 additions and 0 deletions

View file

@ -1324,6 +1324,13 @@
family under the stock assets; the remaining open question is why the later clone chooser favors
this narrower `0x000001f4` stock family over the zero-valued station and maintenance / service
rows.
The peer-site save residue now bridges back into that Tier-2 stock family too. The periodic
company trace can classify nonzero `0x5dc1` post-secondary name pairs against the recovered
nonzero `.bty` header family, and the current grounded overlap set is `TextileMill`,
`Toolndie`, `Brewery`, and `MeatPackingPlant` while `MunitionsFactory` remains the explicit
current residue outside the recovered `0x000001f4` stock header family. So the acquisition-side
post-secondary-byte question and the Tier-2 numbered-bank question now share one narrower
industrial/commercial subset frontier instead of two unrelated broad 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

View file

@ -1268,6 +1268,11 @@ Working rule:
exposes `TextileMill x9`, `Toolndie x2`, and singleton `Brewery`, `MeatPackingPlant`, and
`MunitionsFactory` rows, so the next peer-site slice should treat nonzero post-secondary-byte
rows as a likely industry-like subset rather than a generic placed-structure mode split
- that bridge is explicit now too: the periodic trace can classify those nonzero companion
names against the recovered stock Tier-2 building family, and the current grounded overlap set
is `TextileMill`, `Toolndie`, `Brewery`, and `MeatPackingPlant` while
`MunitionsFactory` remains the clear current residue outside the recovered
`0x000001f4` stock header family
- keep the already-grounded `0x0047fd50` class gate separate from that byte: direct disassembly
now says `0x0047fd50` resolves the linked peer through `[site+0x04]`, reads candidate class
byte `[candidate+0x8c]`, and returns true only for `0/1/2` while rejecting `3/4` and above,