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

Tighten Tier2 candidate source bounds

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 14:36:16 -07:00
commit ede53efeb9
2 changed files with 51 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1246,15 +1246,23 @@
families. families.
The root scan narrows the real corpus for that question too. `runtime scan-candidate-table-headers The root scan narrows the real corpus for that question too. `runtime scan-candidate-table-headers
rt3_wineprefix/drive_c/rt3/maps` shows `37` probe-bearing shipped maps and `4` skips, while the rt3_wineprefix/drive_c/rt3/maps` shows `37` probe-bearing shipped maps and `4` skips, while the
narrower `runtime scan-candidate-table-named-runs` command confirms that `Louisiana.gmp` and narrower `runtime scan-candidate-table-named-runs` command shows two stable `00`-row families
`Dutchlantis.gmp` share the same split shape: across those `37` probe-bearing maps: `30` maps keep `Port00` / `Warehouse00` at rows `35` /
isolated `Port00` at row `35`, contiguous `Port01..11` at rows `45..55`, isolated `43`, while `7` maps move just those two `00` rows earlier to `10` / `18`; the
`Warehouse00` at row `43`, and contiguous `Warehouse01..11` at rows `56..66`. Raw string `Port01..11` and `Warehouse01..11` runs stay fixed at rows `45..55` and `56..66` in every
presence is broader than that actual fixed-candidate-table seam too: `Port00` appears in all probe-bearing map. Trailer families split independently too: `28` maps keep the numbered rows
`41` shipped `.gmp` files, but `Central Pacific.gmp`, `Italy.gmp`, `Tex-Mex.gmp`, and on trailer `0x00000001`, while `9` maps keep the same row layout but zero the same trailers.
`Texas Tea.gmp` do not expose the fixed candidate-table header at all. So the next Tier-2 Raw string presence is broader than that actual fixed-candidate-table seam too: `Port00`
source pass should target the `37` probe-bearing maps rather than the noisier full appears in all `41` shipped `.gmp` files, but `Central Pacific.gmp`, `Italy.gmp`,
string-bearing map corpus. `Tex-Mex.gmp`, and `Texas Tea.gmp` do not expose the fixed candidate-table header at all. So
the next Tier-2 source pass should target the `37` probe-bearing maps rather than the noisier
full string-bearing map corpus.
The earlier `+0x173` writer census trims several dead ends from that source pass too. Direct
inspection now shows `0x00416ded` is only a collection-local row-id seed via `0x00518380`
before `0x00518900`; `0x004274d8` and `0x0042872d` are object-local rollover/allocator copies;
and `0x005b7a6f` is just a helper-side child allocation. The only candidate-family store in
this strip that still matters to Tier-2 is `0x00419559`, and that one is only the later clone
pass stamping the chosen seed-row id onto the new row.
The direct `+0xba/+0xbb` writer census now rules out a broad false lead too. The obvious new 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 stores at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side
portrait/string refresh helpers over a different id-keyed collection rooted through portrait/string refresh helpers over a different id-keyed collection rooted through
@ -1270,6 +1278,16 @@
naming branch from cloned bit `[candidate+0xba]`. So the unresolved Tier-2 seam is no longer naming branch from cloned bit `[candidate+0xba]`. So the unresolved Tier-2 seam is no longer
“find any direct writer to candidate `+0xba/+0xbb`”; it is “find the earlier seed or projection “find any direct writer to candidate `+0xba/+0xbb`”; it is “find the earlier seed or projection
owner that first makes some source/live rows reach that clone path with nonzero bank bytes.” owner that first makes some source/live rows reach that clone path with nonzero bank bytes.”
The stock owner chain above those parser fields is explicit now too:
`0x00438c8e -> 0x004131f0 -> 0x00412fb0 -> 0x004120b0` constructs root `0x0062b268`, and the
adjacent `.rdata` strings at `0x005c93f4..0x005c940e` prove that `0x00412fb0` is the
`Data\\BuildingTypes\\%1*.bca` / `%1*.bty` loader, not a map-side overlay reader. The immediate
follow-on call at `0x00438ca0 -> 0x00411d90` is a no-op, so there is no hidden world-load
mutation directly after that stock constructor. That leaves the next Tier-2 source question
narrower again: either a later candidate-class serializer/import/export family such as
`0x00414500..0x00414b14` is replaying non-stock bank bytes into live rows, or the qualifying
source rows already live in the stock `BuildingTypes` corpus and only the later clone-choice
logic remains to explain them.
The clone-group seam is tighter now too. Candidate dword `[candidate+0x794]` is not a broader The clone-group seam is tighter now too. Candidate dword `[candidate+0x794]` is not a broader
runtime-owned field with many writers: the current direct write set only initializes it to zero runtime-owned field with many writers: the current direct write set only initializes it to zero
in `0x004120b0` and later assigns it in `0x00412d70` as the selected seed-row index that clones in `0x004120b0` and later assigns it in `0x00412d70` as the selected seed-row index that clones

28
docs/rehost-queue.md
View file

@ -758,14 +758,24 @@ Working rule:
The new root scan sharpens that boundary further. `runtime scan-candidate-table-headers The new root scan sharpens that boundary further. `runtime scan-candidate-table-headers
rt3_wineprefix/drive_c/rt3/maps` shows `37` probe-bearing shipped maps and `4` skips, while rt3_wineprefix/drive_c/rt3/maps` shows `37` probe-bearing shipped maps and `4` skips, while
the narrower `runtime scan-candidate-table-named-runs` command confirms that the narrower `runtime scan-candidate-table-named-runs` command confirms that
`Louisiana.gmp` and `Dutchlantis.gmp` share the same split shape: the shipped probe-bearing maps split into two stable `00`-row families rather than one:
`Port00` as an isolated run at row `35`, `Port01..11` as one contiguous run at rows `45..55`, `30` maps keep `Port00` / `Warehouse00` at rows `35` / `43`, while `7` maps move just those
`Warehouse00` isolated at row `43`, and `Warehouse01..11` contiguous at rows `56..66`. two `00` rows earlier to `10` / `18`; the `Port01..11` and `Warehouse01..11` runs stay fixed
Raw map-string presence is broader than that actual candidate-table seam too: at `45..55` and `56..66` in all `37` probe-bearing maps. Trailer families split separately
too: `28` maps keep the numbered rows on trailer `0x00000001`, while `9` maps keep the same
row layout but zero those trailers. Raw map-string presence is broader than that actual
candidate-table seam too:
`Port00` appears in all `41` shipped `.gmp` files, but `Central Pacific.gmp`, `Italy.gmp`, `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 `Tex-Mex.gmp`, and `Texas Tea.gmp` do not expose the fixed candidate-table header at all. So
the next Tier-2 source pass should target the `37` probe-bearing maps rather than the noisier the next Tier-2 source pass should target the `37` probe-bearing maps rather than the noisier
full string-bearing map corpus. full string-bearing map corpus.
The earlier `+0x173` writer census now trims several dead ends from that pass. Direct
inspection shows `0x00416ded` is only a collection-local row-id seed via `0x00518380` before
`0x00518900`; `0x004274d8` and `0x0042872d` are object-local rollover/allocator copies; and
`0x005b7a6f` is just a helper-side child allocation. The only candidate-family `+0x173` store
in this strip that still matters to Tier-2 is `0x00419559`, and it is simply the later clone
pass stamping the chosen seed-row id onto the new row. So the queue no longer needs another
generic `+0x173` writer sweep before returning to the actual bank-byte owner.
The direct `+0xba/+0xbb` writer census is narrower now too. The obvious newly surfaced stores The direct `+0xba/+0xbb` writer census is narrower now too. The obvious newly surfaced stores
at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side portrait/string at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side portrait/string
refresh helpers: they walk a separate id-keyed collection through `0x0053f830`, free and refresh helpers: they walk a separate id-keyed collection through `0x0053f830`, free and
@ -782,6 +792,16 @@ Working rule:
divergence frontier is narrower again: not generic direct stores into candidate rows, but the divergence frontier is narrower again: not generic direct stores into candidate rows, but the
earlier seed or projection seam that first makes some source/live rows reach that clone path earlier seed or projection seam that first makes some source/live rows reach that clone path
with nonzero bank bytes. with nonzero bank bytes.
That owner chain is explicit now too: the stock candidate collection root `0x0062b268` is
constructed at `0x00438c8e -> 0x004131f0 -> 0x00412fb0 -> 0x004120b0`, and the adjacent
`.rdata` strings at `0x005c93f4..0x005c940e` prove that `0x00412fb0` is the
`Data\\BuildingTypes\\%1*.bca` / `%1*.bty` loader, not a map-side overlay reader. The
immediate follow-on call at `0x00438ca0 -> 0x00411d90` is a no-op, so there is no hidden
world-load mutation directly after the stock constructor. That narrows the next Tier-2 source
question again: either a later candidate-class serializer/import/export family such as
`0x00414500..0x00414b14` is still replaying non-stock bank bytes into live rows, or the
qualifying source rows already live in the stock `BuildingTypes` corpus and the remaining work
is to explain which rows the later clone path chooses.
The clone-group lane is tighter now too. Candidate dword `[candidate+0x794]` is not a broader The clone-group lane is tighter now too. Candidate dword `[candidate+0x794]` is not a broader
owner-state field written elsewhere; the current direct write set shows it is initialized to owner-state field written elsewhere; the current direct write set shows it is initialized to
zero in `0x004120b0` and then assigned only in `0x00412d70` as the chosen seed-row index that zero in `0x004120b0` and then assigned only in `0x00412d70` as the chosen seed-row index that