Summarize stock alias roots and peer residues

This commit is contained in:
Jan Petykiewicz 2026-04-19 15:28:23 -07:00
commit 9f603ac28e
5 changed files with 261 additions and 51 deletions

View file

@ -1273,6 +1273,18 @@ Working rule:
is `TextileMill`, `Toolndie`, `Brewery`, and `MeatPackingPlant` while
`MunitionsFactory` remains the clear current residue outside the recovered
`0x000001f4` stock header family
- the checked-in building-source summary now says which stock header lane is actually carrying
the shared alias roots too: within that recovered nonzero `0x000001f4` family,
`name_0x40` / `name_0x7c` mostly stay on direct file/display roots (`Warehouse x7` plus
singletons such as `Brewery`, `Port`, and `Toolndie`), while `name_0x5e` is the real
clustered alias-root lane (`TextileMill x10`, `LumberMill x4`, `MeatPackingPlant x4`,
`Distillery x2`, `Toolndie x2`). So the next Tier-2 source-selection pass should treat
`0x5e`-style alias roots as the stronger stock-family clue than the direct-name lanes
- the trace now keeps the explicit non-overlap residue first-class too: the current list outside
that recovered nonzero family is just `MunitionsFactory/MunitionsFactory x1`, so the next
chooser-side/source-selection slice can focus on whether that residue belongs to a zero-valued
stock-header family or to a later live projection seam rather than treating the whole nonzero
post-secondary set as one undifferentiated mystery
- 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,