From ede53efeb9b6eed7d8c3dd805dcbb5be642eebbc Mon Sep 17 00:00:00 2001 From: Jan Petykiewicz Date: Sun, 19 Apr 2026 14:36:16 -0700 Subject: [PATCH] Tighten Tier2 candidate source bounds --- ...ntime-roots-camera-and-support-families.md | 36 ++++++++++++++----- docs/rehost-queue.md | 28 ++++++++++++--- 2 files changed, 51 insertions(+), 13 deletions(-) diff --git a/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md b/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md index 23d74f5..3edca9e 100644 --- a/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md +++ b/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md @@ -1246,15 +1246,23 @@ families. 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 - narrower `runtime scan-candidate-table-named-runs` command confirms that `Louisiana.gmp` and - `Dutchlantis.gmp` share the same split shape: - isolated `Port00` at row `35`, contiguous `Port01..11` at rows `45..55`, isolated - `Warehouse00` at row `43`, and contiguous `Warehouse01..11` at rows `56..66`. 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 the next Tier-2 - source pass should target the `37` probe-bearing maps rather than the noisier full - string-bearing map corpus. + narrower `runtime scan-candidate-table-named-runs` command shows two stable `00`-row families + across those `37` probe-bearing maps: `30` maps keep `Port00` / `Warehouse00` at rows `35` / + `43`, while `7` maps move just those two `00` rows earlier to `10` / `18`; the + `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. + 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 + 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 stores at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side 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 “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.” + 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 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 diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md index 7d7ddc7..e01f4b9 100644 --- a/docs/rehost-queue.md +++ b/docs/rehost-queue.md @@ -758,14 +758,24 @@ Working rule: 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 the narrower `runtime scan-candidate-table-named-runs` command confirms that - `Louisiana.gmp` and `Dutchlantis.gmp` share the same split shape: - `Port00` as an isolated run at row `35`, `Port01..11` as one contiguous run at rows `45..55`, - `Warehouse00` isolated at row `43`, and `Warehouse01..11` contiguous at rows `56..66`. - Raw map-string presence is broader than that actual candidate-table seam too: + the shipped probe-bearing maps split into two stable `00`-row families rather than one: + `30` maps keep `Port00` / `Warehouse00` at rows `35` / `43`, while `7` maps move just those + two `00` rows earlier to `10` / `18`; the `Port01..11` and `Warehouse01..11` runs stay fixed + 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`, `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 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 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 @@ -782,6 +792,16 @@ Working rule: 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 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 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