From 4e1023fb29e9669f9dccf405c2178ee705179204 Mon Sep 17 00:00:00 2001 From: Jan Petykiewicz Date: Sun, 19 Apr 2026 14:13:55 -0700 Subject: [PATCH] Bind Tier2 names to setup payload rows --- .../runtime-roots-camera-and-support-families.md | 6 ++++++ docs/rehost-queue.md | 14 +++++++++++--- 2 files changed, 17 insertions(+), 3 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 0030a0e..759b792 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 @@ -1229,6 +1229,12 @@ every current shipped `.bca` stays zero at `0xb8..0xbb` except `MachineShop.bca`, which carries the lone selector-window exception `(0x00, 0x80, 0x3f, 0x00)` on a `788`-byte row, while the separate `backup/Bldg/*.bca` corpus stays fully zero there. + Direct map-payload inspection sharpens that split further. The current Tier-2 maps + `Louisiana.gmp`, `Dutchlantis.gmp`, and `South East USA.gmp` all already carry the literal + `Port00` / `Warehouse00` / `Port01` / `Warehouse01` names inside the shared setup payload at + stable offsets `0x6f77`, `0x7087`, `0x70cb`, and `0x7241`, while the same map corpus shows no + `MachineShop` string at all. So the live `PortNN` / `WarehouseNN` family now looks more like a + setup-payload candidate-table / source-row projection problem than a hidden alternate BCA stem. 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 diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md index b1bf3fb..4c05979 100644 --- a/docs/rehost-queue.md +++ b/docs/rehost-queue.md @@ -739,6 +739,13 @@ Working rule: `backup/Bldg/*.bca` corpus stays fully zero in that same window. So the queue head is narrower again: explain whether the Machine Shop exception is part of the seeded Tier-2 family at all, or recover the later projection seam that still has to account for the broader live divergence. + Direct map-payload inspection now sharpens that split further. The current Tier-2 maps + `Louisiana.gmp`, `Dutchlantis.gmp`, and `South East USA.gmp` all already carry the literal + `Port00` / `Warehouse00` / `Port01` / `Warehouse01` names inside the shared setup payload at + stable offsets `0x6f77`, `0x7087`, `0x70cb`, and `0x7241` respectively, while the same map + corpus shows no `MachineShop` string at all. That moves the queue head again: the live + `PortNN` / `WarehouseNN` family is now more plausibly a setup-payload candidate-table / source + row projection problem than a hidden stock-BCA stem problem. 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 @@ -765,9 +772,10 @@ Working rule: question is not “who writes the mysterious group id?” but “which source/live rows become the first seeded rows that let `0x00412d70` propagate nonzero bank bytes within that family?” 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]` beyond the lone - `MachineShop.bca` selector-window exception in the shipped `BuildingTypes/*.bca` corpus. + recover the setup-payload or restore-time projection owner that carries those static + `PortNN` / `WarehouseNN` rows into the live candidate clone families with nonzero + `[candidate+0xba/+0xbb]`, beyond the separate `MachineShop.bca` selector-window exception in + the shipped `BuildingTypes/*.bca` corpus. kinds”; it is the smaller set of scenario-specific records where that sweep explicitly writes `[event+0x7ef]` itself or a still-later owner does. - two explicit trigger-kind materializations are now grounded inside that retagger: