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

Classify zero-family stock alias clusters

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 15:31:02 -07:00
commit b946e69bd0
4 changed files with 94 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1339,6 +1339,14 @@
stronger stock-family clue than the direct-name lanes, and keep the explicit non-overlap residue
(`MunitionsFactory/MunitionsFactory x1`) separate instead of folding it into the recovered
industrial/commercial subset.
That non-overlap residue is grounded against the wider stock corpus now too. The same checked-in
`name_0x5e` dword-family summary shows `MunitionsFactory` sits in a zero-valued
`WeaponsFactory` alias cluster (`Electric Plant`, `Fertilizer Factory`, `Munitions Factory`,
`Nuclear Power Plant`, `Oil Well`, `Weapons Factory`) rather than outside stock assets
entirely. So the remaining Tier-2 chooser/source-selection frontier is no longer “stock vs
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 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