Box in Tier-2 source family rows

This commit is contained in:
Jan Petykiewicz 2026-04-19 16:18:10 -07:00
commit 07ae8b693a
5 changed files with 485 additions and 10 deletions

View file

@ -116,6 +116,14 @@
all-zero. So the remaining load-side question is no longer whether the bare `Port` / `Warehouse`
row carries the stock exception; it is why one warehouse-shaped industrial peer in that same
alias family carries the lone selector while the bare rows do not.
The exact stock resolver-family strip is boxed in now too. The checked-in
`recovered_source_family_summaries` report shows every `0x00419590` source-family row
(`VictorianStation*`, `TudorStation*`, `SoWestStation*`, `PersianStation*`, `KyotoStation*`,
`ClpBrdStation*`, `Maintenance`, and `ServiceTower`) staying on `type_id = 0x000003ec` with
`dword_0xbb = 0`; almost all of them have no `.bca` pair at all, and the only paired standalone
row `ServiceTower` still has `byte_0xba = 0x00`, `byte_0xbb = 0x00`. So the remaining
load-side question is no longer whether the exact `0x00419590` strip itself carries the seeded
nonzero selector; current evidence says it does not.
The global stock selector report tightens that further: the full `MachineShop.bca` signature
(`0x00/0x80/0x3f/0x00` across `0xb8..0xbb`) is unique across the checked-in stock `.bca`
corpus. So the remaining load-side Tier-2 frontier is one surfaced stock-file outlier plus the

View file

@ -1364,6 +1364,14 @@
all-zero. So the remaining Tier-2 source question is no longer whether the bare `Port` or
`Warehouse` row carries the seeded selector; it is why one warehouse-shaped industrial peer in
that alias family carries the lone seeded selector while the bare rows do not.
The exact stock resolver-family strip is boxed in now too. The checked-in
`recovered_source_family_summaries` report shows every `0x00419590` source-family row
(`VictorianStation*`, `TudorStation*`, `SoWestStation*`, `PersianStation*`, `KyotoStation*`,
`ClpBrdStation*`, `Maintenance`, and `ServiceTower`) stays on `type_id = 0x000003ec` with
`dword_0xbb = 0`, and almost all of them have no `.bca` pair at all; the only paired standalone
row is `ServiceTower`, and it still carries `byte_0xba = 0x00`, `byte_0xbb = 0x00`. So the
remaining Tier-2 source question is no longer whether the exact `0x00419590` strip itself
carries seeded nonzero bank bytes; current evidence says it does not.
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

View file

@ -1323,6 +1323,15 @@ Working rule:
all-zero. So the remaining Tier-2 question is no longer “does the bare `Port` or
`Warehouse` row carry the seeded selector?”; it is “why does one warehouse-shaped industrial
peer in that alias family carry the lone seeded selector while the bare rows do not?”
- the exact stock resolver-family strip is boxed in now too:
the checked-in `recovered_source_family_summaries` report shows every `0x00419590`
source-family row (`VictorianStation*`, `TudorStation*`, `SoWestStation*`,
`PersianStation*`, `KyotoStation*`, `ClpBrdStation*`, `Maintenance`, and `ServiceTower`)
stays on `type_id = 0x000003ec` with `dword_0xbb = 0`, and almost all of them have no `.bca`
pair at all; the only paired standalone row is `ServiceTower`, and it still carries
`byte_0xba = 0x00`, `byte_0xbb = 0x00`. So the remaining Tier-2 question is no longer
whether the exact `0x00419590` source-family strip itself carries the seeded nonzero bank
bytes; current evidence says it does not.
- the global stock `.bca` selector report narrows that one step further still: 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 current Tier-2