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

Bound external Tier-2 resolver caller

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 16:19:36 -07:00
commit f23a3b3add
3 changed files with 21 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

7
docs/control-loop-atlas/map-and-scenario-content-load.md
View file

@ -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

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

@ -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

7
docs/rehost-queue.md
View file

@ -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