From 69022731eea263adf4640a33209902bbad9aaaa6 Mon Sep 17 00:00:00 2001
From: Jan Petykiewicz <jan@mpxd.net>
Date: Sat, 18 Apr 2026 20:38:09 -0700
Subject: [PATCH] Narrow region restore continuation candidates

---
 crates/rrt-runtime/src/smp.rs |  3 ++-
 docs/rehost-queue.md          | 13 +++++++++++++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/crates/rrt-runtime/src/smp.rs b/crates/rrt-runtime/src/smp.rs
index f13d050..6aa54d4 100644
--- a/crates/rrt-runtime/src/smp.rs
+++ b/crates/rrt-runtime/src/smp.rs
@@ -5038,13 +5038,14 @@ fn build_region_service_trace_report(
             ],
             evidence: vec![
                 "the checked-in region trace already grounds 0x00444887 as the first caller-side checkpoint above 0x00421510: it refreshes the region collection and then immediately advances into the territory and support collection refresh owners".to_string(),
+                "the neighboring atlas-backed restore symmetry already rules the territory side down somewhat too: 0x00487c20 only restores the live territory collection metadata/id family and its current per-entry slots 0x00487670/0x00487680 are still no-op load/save callbacks, so the territory leg now looks less likely than support or a later region-local rebuild to hide [region+0x2a4] or [region+0x310/+0x338/+0x360]".to_string(),
                 "the same grounded evidence already narrows the later per-region follow-on too: 0x00444b90 dispatches 0x00420560 over each live region after the broader restore continuation has already advanced".to_string(),
                 "direct disassembly already rules that per-region follow-on down as a latch owner: 0x00420560 only zeroes and recomputes [region+0x312] from the embedded profile collection [region+0x37f]/[region+0x383] and lazily seeds the year-driven [region+0x317/+0x31b] band through 0x00420350, not [region+0x276/+0x302/+0x316]".to_string(),
                 "that leaves the broader 0x00444887 continuation as the next structured restore seam above the ruled-down 0x00421510 -> 0x0041f5c0 -> 0x00455fc0 path when chasing acquisition-side lanes [region+0x2a4] and [region+0x310/+0x338/+0x360]".to_string(),
             ],
             blockers: vec![
                 "the concrete later-global restore owner that rehydrates [region+0x2a4] and [region+0x310/+0x338/+0x360] is still not grounded below the 0x00444887 continuation".to_string(),
-                "territory and support collection refresh owners are adjacent in the same continuation and may still carry shared prerequisites before the region-side rebuild resumes".to_string(),
+                "support collection refresh 0x0040b5d0 and the later region-local rebuild remain the strongest adjacent prerequisites now that territory refresh 0x00487c20 is partly ruled down as metadata/id-only".to_string(),
             ],
         },
         SmpServiceConsumerHypothesis {
diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md
index b1834f6..824259c 100644
--- a/docs/rehost-queue.md
+++ b/docs/rehost-queue.md
@@ -608,6 +608,19 @@ Working rule:
   `[this+0x20]`, `[this+0x8d]`, `[this+0x5c..+0x61]`, `[this+0x1ee]`, `[this+0x1fa]`, and
   `[this+0x3e]`, and then it opens `0x55f3` only for span accounting before returning. So the
   missing region latches are not hiding in the remainder of `0x00455fc0` either.
+- The next restore-handoff strip is explicit now too: the region trace now carries a dedicated
+  later-global-restore hypothesis for `0x00444887`, because that continuation is the first caller
+  checkpoint above the ruled-down `0x00421510 -> 0x0041f5c0 -> 0x00455fc0` path. It immediately
+  advances into `0x00487c20` territory refresh and `0x0040b5d0` support refresh, then later
+  re-enters the per-region follow-on loop at `0x00444b90 -> 0x00420560`. Current disassembly keeps
+  `0x00420560` on `[region+0x312]` / `[region+0x317/+0x31b]` only, so the next region pass should
+  treat the broader `0x00444887` continuation as the live handoff seam when chasing
+  `[region+0x2a4]` and `[region+0x310/+0x338/+0x360]`, not as just another generic restore note.
+- That same continuation is slightly less symmetric now too: the atlas-backed territory side at
+  `0x00487c20` currently restores only collection metadata/live ids and still uses no-op per-entry
+  load/save callbacks `0x00487670/0x00487680`, so the next pass should bias more heavily toward
+  support refresh `0x0040b5d0` or the later region-local rebuild than toward territory payload as
+  the hidden source of `[region+0x2a4]` and `[region+0x310/+0x338/+0x360]`.
 - The later restore-side region owners are narrowed further now too: the `0x00421ce0 ->
   0x0041fb00 -> 0x00421730` sweep is class-`0` raster/id rebuild, `0x004881b0` is a companion
   region-set cell-count rebuild over `[region+0x3d/+0x41]`, `0x00487de0` is a border-segment