From f23a3b3add082ea9e3a2e3e43e137ca538c8162f Mon Sep 17 00:00:00 2001 From: Jan Petykiewicz Date: Sun, 19 Apr 2026 16:19:36 -0700 Subject: [PATCH] Bound external Tier-2 resolver caller --- docs/control-loop-atlas/map-and-scenario-content-load.md | 7 +++++++ .../runtime-roots-camera-and-support-families.md | 7 +++++++ docs/rehost-queue.md | 7 +++++++ 3 files changed, 21 insertions(+) diff --git a/docs/control-loop-atlas/map-and-scenario-content-load.md b/docs/control-loop-atlas/map-and-scenario-content-load.md index aef6dfb..6ba8a63 100644 --- a/docs/control-loop-atlas/map-and-scenario-content-load.md +++ b/docs/control-loop-atlas/map-and-scenario-content-load.md @@ -124,6 +124,13 @@ row `ServiceTower` still has `byte_0xba = 0x00`, `byte_0xbb = 0x00`. So the remaining load-side question is no longer whether the exact `0x00419590` strip itself carries the seeded nonzero selector; current evidence says it does not. + The `0x00419590` caller surface is boxed in further too. Current direct caller recovery still + keeps the actual load-side use under the already-grounded `0x00419230` rebank-or-clone strip, + while the only newly surfaced non-local caller is `0x00506424`, which reaches `0x00419590` from + a live placed-structure consumer path that immediately flows through `0x00402c90` and + `0x0040dc40`. So the remaining load-side question is no longer whether `0x00419590` itself is a + hidden load-side owner; it is still the earlier seed-row or projection seam that makes later + clone/consumer paths see nonzero bank bytes. The global stock selector report tightens that further: the full `MachineShop.bca` signature (`0x00/0x80/0x3f/0x00` across `0xb8..0xbb`) is unique across the checked-in stock `.bca` corpus. So the remaining load-side Tier-2 frontier is one surfaced stock-file outlier plus the 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 4858153..14415ba 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 @@ -1372,6 +1372,13 @@ row is `ServiceTower`, and it still carries `byte_0xba = 0x00`, `byte_0xbb = 0x00`. So the remaining Tier-2 source question is no longer whether the exact `0x00419590` strip itself carries seeded nonzero bank bytes; current evidence says it does not. + The `0x00419590` caller surface is boxed in further too. Current direct caller recovery still + keeps the real load-side use under the already-grounded `0x00419230` rebank-or-clone strip, + while the only newly surfaced non-local caller is `0x00506424`, which reaches `0x00419590` from + a live placed-structure consumer path that immediately flows through `0x00402c90` and + `0x0040dc40`. So the remaining Tier-2 source question is no longer whether `0x00419590` itself + is a hidden load-side owner; it is still the earlier seed-row or projection seam that makes + later clone/consumer paths see nonzero bank bytes. The global stock `.bca` selector report narrows that again: the exact `MachineShop.bca` signature (`byte_0xb8 = 0x00`, `byte_0xb9 = 0x80`, `byte_0xba = 0x3f`, `byte_0xbb = 0x00`) is unique across the checked-in stock corpus. So the remaining Tier-2 source frontier is not a diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md index ff1277c..bf8d393 100644 --- a/docs/rehost-queue.md +++ b/docs/rehost-queue.md @@ -1332,6 +1332,13 @@ Working rule: `byte_0xba = 0x00`, `byte_0xbb = 0x00`. So the remaining Tier-2 question is no longer whether the exact `0x00419590` source-family strip itself carries the seeded nonzero bank bytes; current evidence says it does not. + - the `0x00419590` caller surface is boxed in further too: + current direct caller recovery still keeps the real load-side use under the already-grounded + `0x00419230` rebank-or-clone strip, while the only newly surfaced non-local caller is + `0x00506424`, which reaches `0x00419590` from a live placed-structure consumer path that + immediately flows through `0x00402c90` and `0x0040dc40`. So the remaining Tier-2 question is + no longer whether `0x00419590` itself is a hidden load-side owner; it is still the earlier + seed-row or projection seam that makes later clone/consumer paths see nonzero bank bytes. - the global stock `.bca` selector report narrows that one step further still: the exact `MachineShop.bca` signature (`byte_0xb8 = 0x00`, `byte_0xb9 = 0x80`, `byte_0xba = 0x3f`, `byte_0xbb = 0x00`) is unique across the checked-in stock corpus. So the current Tier-2