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

Add queue exports for Tier-2 and dispatch control lanes

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-21 17:23:17 -07:00
commit 556335238e
8 changed files with 2566 additions and 4 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

@ -1252,6 +1252,12 @@
`Port01..11` and `Warehouse01..11` runs stay fixed at rows `45..55` and `56..66` in every
probe-bearing map. Trailer families split independently too: `28` maps keep the numbered rows
on trailer `0x00000001`, while `9` maps keep the same row layout but zero the same trailers.
The checked-in evidence join is explicit now too:
`artifacts/exports/rt3-1.06/building-type-sources.json` still bounds the stock side to bare
`port` / `warehouse`, `artifacts/exports/rt3-1.06/event-effects-building-bindings.json` keeps
the numbered `Port%02d` / `Warehouse%02d` dispatch family grounded on the event side, and the
new `artifacts/exports/rt3-1.06/candidate-table-named-runs.json` export keeps the scenario-side
row families grounded across the shipped `37`-map probe-bearing corpus.
Raw string presence is broader than that actual fixed-candidate-table seam too: `Port00`
appears in all `41` shipped `.gmp` files, but `Central Pacific.gmp`, `Italy.gmp`,
`Tex-Mex.gmp`, and `Texas Tea.gmp` do not expose the fixed candidate-table header at all. So
@ -1425,6 +1431,10 @@
`0x0050a1cd` keeps the same seeded rows out of one later availability branch. So the remaining
Tier-2 seed question is now sharper: which source/live rows become the first seeded rows that let
`0x00412d70` propagate nonzero bank bytes within that clone family?
The same question can now be stated against the fixed shipped scenario rows too: which earlier
seed/projection seam lets candidate-table rows `35/43/45..66` reach `0x00412d70` with nonzero
`[candidate+0xba/+0xbb]` before the later rebank-or-clone strip `0x00419230` ever consumes
them?
The later rebank-or-clone owner is bounded now too. Direct disassembly of `0x00419230` shows one
outer pass over bank selector `0` then `1`, with an inner `12`-ordinal sweep for each pass. For
each `(bank, ordinal)` pair it scans already-linked aux/source rows by owner candidate id