Ground peer-site backing selector field owner

crates/rrt-runtime/src/smp.rs

@@ -4101,11 +4101,15 @@ fn build_periodic_company_service_trace_report(
         "0x0047dda0 linked-peer route-entry-anchor validator".to_string(),
         "0x00420030 / 0x00420280 peer-site boolean/selector pair over the placed-structure collection".to_string(),
         "0x0047efe0 placed-structure linked-company resolver".to_string(),
+        "0x0052edf0 generic base constructor seeding [this+0x04] from caller arg 1".to_string(),
+        "0x00455c62 concrete placed-structure specialization caller of 0x0052edf0".to_string(),
+        "0x00485819 typed placed-structure caller of 0x0052edf0 via 0x530640-style argument bundle"
+            .to_string(),
         "0x00406050 city-connection bonus/news sibling owner".to_string(),
         "0x00409950 linked-transit roster sibling owner".to_string(),
     ];
     let next_owner_questions = vec![
-        "Which non-hook owner reseeds the live peer-site backing-record selector [site+0x04], now that late world bring-up 0x00444690 -> 0x004133b0 is grounded as the post-load replay owner for queued cloned local-runtime rebuilds and live-site sweeps but still only reaches [site+0x3cc], [site+0x2a8], and [peer+0x08] directly?".to_string(),
+        "Which placed-structure load or bring-up caller feeds caller arg 1 into the generic base constructor 0x0052edf0 so the live backing-record selector [site+0x04] is reseeded before 0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50 consume it?".to_string(),
         "How much of the linked-peer refresh path is strictly post-load versus recurring runtime maintenance now that 0x004133b0 reaches 0x0040ee10 -> 0x0040edf6 -> 0x00480710 during bring-up and 0x004160aa also re-enters 0x0040ee10 later?".to_string(),
         "Which persisted linkage fields behind 0x0047efe0, [region+0x2a4], and [region+0x276] are sufficient to rehost the 0x004014b0 proximity-and-news branch without shell state?".to_string(),
         "Which infrastructure consumer above the grounded 0x38a5 seam actually drives the linked-transit branch that 0x00409950 follows?".to_string(),
@@ -4236,7 +4240,7 @@ fn build_periodic_company_service_trace_report(
                     "0x00406050 city-connection bonus/news sibling owner",
                 ],
                 &[
-                    "Direct disassembly now shows this branch iterating the live class-0 region collection, skipping regions with pending amount [region+0x276], reusing the center-cell token gate 0x0041f6e0 -> 0x0042b2d0, reusing the linked-region status branch 0x0047de00 -> 0x0040c990, checking candidate reachability through 0x004801a0, consulting the placed-structure peer-site boolean/selector pair 0x00420030 / 0x00420280 over 0x006cec20, scoring regions against company proximity and aging through 0x0040d540 and 0x0040cac0, and then publishing the winning linked company id from [region+0x2a4]. The remaining peer-site identity gap is now narrower too: the linked-peer row's [peer+0x04] is written by 0x00480210 as the anchor-site id, the anchor-site row's [site+0x2a8] is written by 0x0040f6d0 after 0x00481390 returns the linked peer id, late world bring-up 0x00444690 -> 0x004133b0 already replays queued clone refresh through 0x0040e450 and live-site sweeps through 0x0040ee10, and [peer+0x08] is refreshed from there through 0x0040edf6 -> 0x00480710 -> 0x0048abc0 / 0x00493cf0.",
+                    "Direct disassembly now shows this branch iterating the live class-0 region collection, skipping regions with pending amount [region+0x276], reusing the center-cell token gate 0x0041f6e0 -> 0x0042b2d0, reusing the linked-region status branch 0x0047de00 -> 0x0040c990, checking candidate reachability through 0x004801a0, consulting the placed-structure peer-site boolean/selector pair 0x00420030 / 0x00420280 over 0x006cec20, scoring regions against company proximity and aging through 0x0040d540 and 0x0040cac0, and then publishing the winning linked company id from [region+0x2a4]. The remaining peer-site identity gap is now narrower too: the linked-peer row's [peer+0x04] is written by 0x00480210 as the anchor-site id, the anchor-site row's [site+0x2a8] is written by 0x0040f6d0 after 0x00481390 returns the linked peer id, the live backing-record selector [site+0x04] is written by the generic base constructor 0x0052edf0 from caller arg 1, late world bring-up 0x00444690 -> 0x004133b0 already replays queued clone refresh through 0x0040e450 and live-site sweeps through 0x0040ee10, and [peer+0x08] is refreshed from there through 0x0040edf6 -> 0x00480710 -> 0x0048abc0 / 0x00493cf0.",
                 ],
             ));
             SmpPeriodicCompanyServiceTraceEntry {
@@ -4270,7 +4274,7 @@ fn build_periodic_company_service_trace_report(
         "Direct disassembly now closes the negative persistence side too: the direct 0x36b1 per-record callbacks serialize the shared base scalar triplets rooted at [this+0x206/+0x20a/+0x20e] plus the subordinate payload callback strip, while the 0x4a9d/0x4a3a/0x4a3b side-buffer owner only persists route-entry lists, three byte arrays, five proximity buckets, and the sampled-cell list. That means neither checked-in save owner seam currently persists the core peer-site identity fields [site+0x04], [site+0x2a8], or [peer+0x08] directly.".to_string(),
     );
     notes.push(
-        "The replay strip is tighter now too. 0x00444690 is the current late world bring-up caller of 0x004133b0, that outer owner drains queued site ids through 0x0040e450 and then sweeps every live placed structure through 0x0040ee10, and 0x0040ee10 itself reaches 0x0040edf6 -> 0x00480710 plus the later 0x0040e360 follow-on. A separate runtime path at 0x004160aa also re-enters 0x0040ee10 later. So [peer+0x08] replay is no longer the open question; the remaining non-hook target is whichever owner reseeds the live backing-record selector [site+0x04] before 0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50 consume it.".to_string(),
+        "The replay strip is tighter now too. 0x00444690 is the current late world bring-up caller of 0x004133b0, that outer owner drains queued site ids through 0x0040e450 and then sweeps every live placed structure through 0x0040ee10, and 0x0040ee10 itself reaches 0x0040edf6 -> 0x00480710 plus the later 0x0040e360 follow-on. A separate runtime path at 0x004160aa also re-enters 0x0040ee10 later. So [peer+0x08] replay is no longer the open question, and [site+0x04] itself is no longer an owner mystery either: the generic base constructor 0x0052edf0 writes [this+0x04] from caller arg 1 after 0x0052ecd0 clears it. The remaining non-hook target is which placed-structure load or bring-up caller supplies that arg-1 selector before 0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50 consume it.".to_string(),
     );
 
     SmpPeriodicCompanyServiceTraceReport {
@@ -25931,7 +25935,7 @@ mod tests {
         let trace = build_periodic_company_service_trace_report(&analysis);
         assert_eq!(trace.selected_company_id, Some(7));
         assert_eq!(trace.atlas_candidate_consumers.len(), 7);
-        assert_eq!(trace.known_bridge_helpers.len(), 27);
+        assert_eq!(trace.known_bridge_helpers.len(), 30);
         assert_eq!(trace.next_owner_questions.len(), 4);
         assert_eq!(trace.companies.len(), 1);
         assert!(trace.atlas_candidate_consumers.iter().any(|line| {
@@ -25940,9 +25944,7 @@ mod tests {
                 && line.contains("peer-site boolean/selector pair")
         }));
         assert!(trace.next_owner_questions.iter().any(|line| {
-            line.contains("[site+0x04]")
+            line.contains("[site+0x04]") && line.contains("0x0052edf0") && line.contains("arg 1")
-                && line.contains("0x00444690 -> 0x004133b0")
-                && line.contains("[peer+0x08]")
         }));
         assert!(trace.next_owner_questions.iter().any(|line| {
             line.contains("0x004160aa")

docs/rehost-queue.md

@@ -62,18 +62,25 @@ Working rule:
     `0x4a9d/0x4a3a/0x4a3b` side-buffer owner only persists route-entry lists, three byte arrays,
     five proximity buckets, and the sampled-cell list
   - the winning linked company id comes from `[region+0x2a4]`
+  - direct disassembly now shows the generic base constructor `0x0052edf0` clearing base state
+    through `0x0052ecd0` and then writing `[this+0x04]` from caller arg `1`
+  - `0x00455c62` is one concrete placed-structure specialization caller of `0x0052edf0`
+  - `0x00485819` is one typed placed-structure caller of `0x0052edf0` through the generic
+    three-arg wrapper `0x00530640`
   So the next owner question is no longer “what does the acquisition branch do?” or “which post-
-  load owner replays linked-site refresh?” but “which remaining owner reseeds the live backing-
+  load owner replays linked-site refresh?” but “which placed-structure load or bring-up caller
-  record selector `[site+0x04]` once the existing bring-up replay finishes?”
+  supplies the `0x0052edf0` arg-1 selector that becomes the live backing-record selector
+  `[site+0x04]` once the existing bring-up replay finishes?”
 - Make the next static/rehost slice the peer-site rebuild seam above persistence, not another save
   scan:
   - treat `0x00444690 -> 0x004133b0 -> 0x0040e450 / 0x0040ee10 -> 0x0040edf6 -> 0x00480710` as
     the checked-in bring-up replay path for existing saves
   - treat `0x004160aa -> 0x0040ee10` as the checked-in recurring runtime maintenance entry into the
     same linked-peer refresh strip
-  - find the remaining owner that reseeds `[site+0x04]` before
+  - treat `0x0052edf0` as the checked-in field owner for `[site+0x04]`
-    `0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50` consume it, if that owner is distinct
+  - map the concrete placed-structure load or bring-up caller that feeds caller arg `1` into
-    from the bring-up replay path
+    `0x0052edf0` before `0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50` consume the
+    resulting selector, if that caller is distinct from the bring-up replay path
 - Use the higher-layer probes as the standard entry point for the current blocked frontier instead
   of generic save scans:
   `runtime inspect-periodic-company-service-trace <save.gms>`,