From 58e9effb835ff209b750f917e6f7c1b3f1152609 Mon Sep 17 00:00:00 2001 From: Jan Petykiewicz Date: Sun, 19 Apr 2026 14:45:57 -0700 Subject: [PATCH] Bound Tier2 stock BuildingType remap seam --- ...ntime-roots-camera-and-support-families.md | 19 ++++++++++++++++ docs/rehost-queue.md | 22 +++++++++++++++++++ 2 files changed, 41 insertions(+) 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 3edca9e..871e804 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 @@ -1263,6 +1263,25 @@ 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 `Port00` / `Warehouse00` name seam is narrower than that clone pass now too. Direct + recovery shows `0x00419680` constructing `gpdBuildingTypeDB` at `0x0062b2fc` by storing + vtable `0x005c9718`, and the surrounding `.rdata` descriptor at `0x005c9718` is the `%1*.bty` + table `{ 0x00416950, 0x00416ce0, 0x004168e0, "%1*.bty", ... }`. The ordinary DB load path at + `0x0044431c` calls vtable slot `+0x04 = 0x00416ce0`, while `0x00416950` walks live rows and + calls slot `+0x08 = 0x004168e0` as the per-entry cleanup path. Inside `0x00416ce0`, the stock + building-type loader rewrites only the bare source names `port` (`0x005c8f94`) and `warehouse` + (`0x005c8e4c`) to `Port00` (`0x005c96a0`) and `Warehouse00` (`0x005c9694`) before scanning the + live candidate collection `0x0062b268`; when it finds the matching candidate row, + `0x00416ded` seeds `[row+0x173]` from that live candidate row id before re-entering + `0x00518900`. So the remaining Tier-2 source question is no longer a hidden late writer for the + `00` names themselves. That remap is already owned by the stock `.bty` load callback, leaving + the row-family choice and later bank-selection problem above it as the active frontier. + The checked-in stock source report reinforces that boundary too: + `artifacts/exports/rt3-1.06/building-type-sources.json` still contains only the bare source + stems `port` and `warehouse`, while the numbered `port00..11` and `warehouse00..11` families + stay in `named_binding_comparison.binding_only_canonical_stems`. So the numbered Tier-2 + families no longer belong under stock `BuildingTypes/*.bty` discovery either; they belong under + the scenario/live candidate-table projection seam above the now-grounded bare-name remap. 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 e01f4b9..25cd91c 100644 --- a/docs/rehost-queue.md +++ b/docs/rehost-queue.md @@ -776,6 +776,28 @@ Working rule: 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 `Port00` / `Warehouse00` name mystery is narrower than that bank-byte owner now too. + Direct recovery shows `0x00419680` constructing `gpdBuildingTypeDB` at `0x0062b2fc` by + storing vtable `0x005c9718`, and the surrounding `.rdata` descriptor at `0x005c9718` is the + `%1*.bty` table `{ 0x00416950, 0x00416ce0, 0x004168e0, "%1*.bty", ... }`. That same vtable is + used by the ordinary DB load path at `0x0044431c`, which calls slot `+0x04 = 0x00416ce0`, + while `0x00416950` iterates live rows and calls slot `+0x08 = 0x004168e0` as the per-entry + cleanup path. Inside `0x00416ce0`, the stock building-type loader rewrites only the bare + source names `port` (`0x005c8f94`) and `warehouse` (`0x005c8e4c`) to `Port00` + (`0x005c96a0`) and `Warehouse00` (`0x005c9694`) before scanning the live candidate collection + `0x0062b268`; when it finds the matching candidate row, it seeds `[row+0x173]` from the live + candidate row id at `0x00416ded` and then re-enters `0x00518900`. So the queue no longer + needs a generic hidden late writer for the `00` names themselves: that remap is already owned + by the stock `.bty` load callback. The remaining Tier-2 source question is now the row-family + choice and later bank selection above that remap, especially the shifted `00` families + (`35/43` vs `10/18`) and the still-fixed `01..11` run families (`45..55` / `56..66`). + The checked-in stock source report agrees with that split too: + `artifacts/exports/rt3-1.06/building-type-sources.json` still shows only bare source stems + `port` and `warehouse`, while `port00..11` and `warehouse00..11` stay in + `named_binding_comparison.binding_only_canonical_stems`. So the queue no longer needs more + stock `BuildingTypes/*.bty` discovery for the numbered families either; the remaining `01..11` + source work belongs under scenario/live candidate-table projection and row-family choice above + the already-grounded bare-name remap. 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