From 8bec4d1c1b337e9bb081cb8e21b9ea9704f58b9d Mon Sep 17 00:00:00 2001 From: Jan Petykiewicz Date: Sat, 18 Apr 2026 22:36:08 -0700 Subject: [PATCH] Split acquisition replay consumers from rehydrators --- crates/rrt-runtime/src/smp.rs | 21 +++++++++++++++++---- docs/rehost-queue.md | 12 ++++++++---- 2 files changed, 25 insertions(+), 8 deletions(-) diff --git a/crates/rrt-runtime/src/smp.rs b/crates/rrt-runtime/src/smp.rs index 567cbf8..f7bf5f0 100644 --- a/crates/rrt-runtime/src/smp.rs +++ b/crates/rrt-runtime/src/smp.rs @@ -4719,7 +4719,7 @@ fn build_periodic_company_service_trace_report( "0x004269b0 resolves the chosen site id through placed-structure collection 0x0062b26c before mutating the live row, so [site+0x2a4] is reconstructible from collection identity rather than a separate serializer-owned selector".to_string(), "0x00444690 -> 0x004133b0 -> 0x0040ee10 is the current checked-in replay family above live placed structures".to_string(), "0x004133b0 rebuilds cloned local-runtime records through 0x0040e450 and 0x0040ee10 only republishes local position/scalar triplets before 0x0040e360".to_string(), - "direct local replay-strip inspection now tightens that further: 0x0040ee10 only reads cached source lane [site+0x3cc] in the checked range, while the bounded 0x00480710 neighborhood is working from [site+0x04], [site+0x08], and [site+0x3cc] rather than [site+0x276] or [site+0x310/+0x338/+0x360]".to_string(), + "direct local replay-strip inspection now splits that family more precisely: bounded 0x0040ee10 itself only reads cached source lane [site+0x3cc], and the bounded 0x00480710 neighborhood is working from [site+0x04], [site+0x08], and [site+0x3cc]; the broader immediate continuation 0x0040e360..0x0040edf6 still consumes [site+0x2a8], [site+0x2a4], and [site+0x276] around 0x0040d230 / 0x0040d1f0 / 0x00480710 / 0x00426b10 / 0x00455860, but in the checked range those [site+0x276] uses are still reads/queries rather than a direct rehydrating store".to_string(), "direct local writer census now shows the grounded [site+0x276] write side clustering under live mutation families such as 0x004269b0 / 0x00426a10, the create-side 0x0040ef10 / 0x0040f6d0 strip, and the bulk reassignment families 0x00426dce..0x00426ea1 and 0x00430040..0x004300d6 rather than under the known replay strip".to_string(), "direct local control-flow reconstruction now shows those same writer families hanging under the 0x00431b20 opcode dispatcher over 0x0061039c: opcodes 0x04..0x07 dispatch to 0x00430040, opcodes 0x08/0x10..0x13 dispatch to 0x00426d60, and opcodes 0x0d/0x16 dispatch to 0x0042fc90".to_string(), "0x0042fc90 itself iterates the live placed-structure collection 0x0062b26c, filters rows through 0x0040c990 plus optional company match [site+0x276], and then dispatches row vtable slot +0x70, which keeps that branch on the live application side rather than replay".to_string(), @@ -4845,6 +4845,8 @@ fn build_periodic_company_service_trace_report( "0x00444690 late world bring-up caller of 0x004133b0 placed-structure local-runtime replay" .to_string(), "0x004133b0 placed-structure local-runtime replay owner draining queued site ids through 0x0040e450 and sweeping live sites through 0x0040ee10".to_string(), + "0x0040e360..0x0040edf6 broader replay continuation consuming [site+0x2a8/+0x2a4/+0x276] around 0x0040d230 / 0x0040d1f0 / 0x00480710 / 0x00426b10 / 0x00455860" + .to_string(), "0x0040e450 queued site-id cloned local-runtime replay helper".to_string(), "0x0040ee10 live-site position/scalar refresh helper reaching 0x0040edf6 -> 0x00480710 and 0x0040e360".to_string(), "0x00480710 linked-site runtime side-buffer and route-entry-anchor refresh owner" @@ -28110,7 +28112,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(), 9); - assert_eq!(trace.known_bridge_helpers.len(), 68); + assert_eq!(trace.known_bridge_helpers.len(), 69); assert_eq!(trace.next_owner_questions.len(), 5); assert_eq!(trace.companies.len(), 1); assert_eq!( @@ -28284,9 +28286,14 @@ mod tests { .iter() .any(|line| line.contains("0x0040ee10") && line.contains("[site+0x3cc]") + && line.contains("0x0040e360..0x0040edf6") + && line.contains("[site+0x2a8]") + && line.contains("[site+0x2a4]") + && line.contains("[site+0x276]") && line.contains("0x00480710") - && line.contains("[site+0x04]") - && line.contains("[site+0x08]")) + && line.contains("0x00426b10") + && line.contains("0x00455860") + && line.contains("reads/queries")) ); assert!( trace.near_city_acquisition_projection_hypotheses[1] @@ -28867,6 +28874,12 @@ mod tests { .iter() .any(|line| line.contains("0x00444690") && line.contains("0x004133b0")) ); + assert!(trace.known_bridge_helpers.iter().any( + |line| line.contains("0x0040e360..0x0040edf6") + && line.contains("[site+0x2a8/+0x2a4/+0x276]") + && line.contains("0x00426b10") + && line.contains("0x00455860") + )); assert!( trace .known_bridge_helpers diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md index 478be05..666036b 100644 --- a/docs/rehost-queue.md +++ b/docs/rehost-queue.md @@ -108,10 +108,14 @@ Working rule: position/scalar triplets, but current evidence still does not tie that replay family directly to `[site+0x276]` - the same replay strip is narrower than before now: - direct local inspection shows `0x0040ee10` only reading cached source lane `[site+0x3cc]` - in the checked range, while the bounded `0x00480710` neighborhood is working from - `[site+0x04]`, `[site+0x08]`, and `[site+0x3cc]` rather than `[site+0x276]` or the - cached tri-lane + direct local inspection now splits it more precisely: + `0x0040ee10` itself only reads cached source lane `[site+0x3cc]` in the checked range, and + the bounded `0x00480710` neighborhood is working from `[site+0x04]`, `[site+0x08]`, and + `[site+0x3cc]`; but the broader immediate continuation `0x0040e360..0x0040edf6` still + consumes `[site+0x2a8]`, `[site+0x2a4]`, and `[site+0x276]` around + `0x0040d230 / 0x0040d1f0 / 0x00480710 / 0x00426b10 / 0x00455860`, so the replay family is + narrowed rather than ruled out for owner-company rehydration; in the checked range those + `[site+0x276]` uses are still reads/queries rather than a direct rehydrating store - the second is narrower in the same way: the checked-in `0x36b1/0x36b2/0x36b3` triplet seam and the `0x4a9d/0x4a3a/0x4a3b` side-buffer seam still do not serialize `[site+0x310/+0x338/+0x360]`