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

Rule down Tier2 startup availability preseed

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 14:01:47 -07:00
commit e5c4f0b6ac
2 changed files with 18 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1206,6 +1206,16 @@
block is now well grounded as bundled map/save source data, a direct bulk-import path from that
block into the live runtime collection `[state+0x66b2]` is still not grounded by the current
disassembly notes.
The startup-side preseed is narrower in the same negative way now too: direct disassembly of
`0x00437737` shows the branch iterating the live candidate pool `0x0062b268`, reading bank word
`[candidate+0xba]` plus subtype byte `[candidate+0x32]`, and then pushing the candidate stem and
one derived boolean through `0x00434f20` into `[state+0x66b2]`; sibling `0x00436ad7` does the
same after the status gate `0x0040c990`, but only for subtype-`2` candidates whose bank bytes
`[candidate+0xba/+0xbb]` are both zero. The later bring-up caller `0x00444acc` only re-enters
that same `0x00437737 -> 0x00434f20 -> 0x00412c10` strip. So these startup passes still consume
already-materialized bank/template bytes instead of explaining how live candidates diverge from
the all-zero shipped `BuildingTypes/*.bca` corpus before the later `Port%02d` /
`Warehouse%02d` rebuild.
That candidate-side table now has a grounded fixed record layout too: each entry is a `0x22`-byte
blob with a zero-terminated candidate-name slot at `[entry+0x00..+0x1d]` and one trailing
availability dword at `[entry+0x1e]`, read through `0x00434ea0` and mirrored later into

8
docs/rehost-queue.md
View file

@ -715,6 +715,14 @@ Working rule:
candidate pool through `0x004131f0` and the auxiliary/source pool through `0x0041aa50`, and
both constructors tail directly into the same fixed tagged-import families rather than taking a
title-specific source-selection branch in between.
The startup-side availability preseed is negative in the same way now too: direct disassembly
of `0x00437737` and its sibling callsite `0x00436ad7` shows both branches only *reading*
live candidate subtype `[candidate+0x32]` plus bank bytes `[candidate+0xba/+0xbb]` and then
feeding those predicates into the scenario-side availability table at `[state+0x66b2]` through
`0x00434f20`; the later bring-up caller `0x00444acc` simply re-enters that same
`0x00437737 -> 0x00434f20 -> 0x00412c10` strip. So even the visible startup preseed still
consumes already-materialized bank/template bytes rather than explaining how they became
nonzero in the first place.
So the honest next queue head is now one step earlier again:
recover the non-stock writer or restore-time projection owner that makes some live candidates
reach those later consumer strips with nonzero `[candidate+0xba/+0xbb]` despite the observed