From b937ad7e6e382010f5459c798b91bc0dfe96560b Mon Sep 17 00:00:00 2001 From: Jan Petykiewicz Date: Sat, 18 Apr 2026 23:58:53 -0700 Subject: [PATCH] Order placed-structure restore-side stages --- crates/rrt-runtime/src/smp.rs | 20 ++++++++++++++++++++ docs/rehost-queue.md | 5 +++++ 2 files changed, 25 insertions(+) diff --git a/crates/rrt-runtime/src/smp.rs b/crates/rrt-runtime/src/smp.rs index d1bf0d9..15bef2c 100644 --- a/crates/rrt-runtime/src/smp.rs +++ b/crates/rrt-runtime/src/smp.rs @@ -4757,6 +4757,7 @@ fn build_periodic_company_service_trace_report( "[site+0x2a4] self-id meaning is grounded through 0x0041f7e0 / 0x0041f810 / 0x0041f850".to_string(), "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 ordinary bring-up replay family above live placed structures".to_string(), + "the ordinary restore-side staging order is tighter now too: world bring-up calls 0x00413280 first for tagged 0x36b1/0x36b2/0x36b3 stream load at 0x00444467, refreshes dynamic side buffers through 0x00481210 at 0x004444d8, and only later enters 0x004133b0 at 0x00444690 for queued local-runtime replay plus 0x0040ee10".to_string(), "0x004133b0 rebuilds cloned local-runtime records through 0x0040e450 and 0x0040ee10 only republishes local position/scalar triplets before 0x0040e360".to_string(), "the ordinary bring-up strip stays separate from the constructor/finalize family too: after 0x00444690 -> 0x004133b0 the world restore continues through later route-entry/grid/tagged refresh owners rather than re-entering 0x004134d0 / 0x0040f6d0 / 0x0040ef10 for already-restored rows".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(), @@ -4782,6 +4783,7 @@ fn build_periodic_company_service_trace_report( "the explicit store census now also rules down the remaining obvious non-transport writes, so the missing ordinary restored-row owner seam likely sits outside the currently bounded direct allocator/finalize/store families".to_string(), "the paired collection-side triplet serializer 0x00413440 is ruled down too, so the missing ordinary restored-row owner seam likely sits outside the currently bounded direct allocator/finalize/store families and the tagged 0x36b1/0x36b2/0x36b3 load-save strip".to_string(), "the load-side stream owner 0x00413280 is ruled down to cached-source/candidate replay through vtable slot +0x40 and 0x0040ce60, so the missing ordinary restored-row owner seam still sits beyond the current stream-load bridge too".to_string(), + "the checked ordinary restore ordering is ruled down too: 0x00413280 stream load, 0x00481210 dynamic side-buffer refresh, and 0x004133b0 local-runtime replay all sit on the bring-up strip without re-entering 0x004134d0 / 0x0040f6d0 / 0x0040ef10 for already-restored rows".to_string(), ], }, SmpServiceConsumerHypothesis { @@ -28488,6 +28490,16 @@ mod tests { .any(|line| line.contains("0x00444690 -> 0x004133b0") && line.contains("ordinary bring-up replay family")) ); + assert!( + trace.near_city_acquisition_projection_hypotheses[0] + .evidence + .iter() + .any(|line| line.contains("0x00444467") + && line.contains("0x00413280") + && line.contains("0x004444d8") + && line.contains("0x00481210") + && line.contains("0x00444690")) + ); assert!( trace.near_city_acquisition_projection_hypotheses[0] .evidence @@ -28725,6 +28737,14 @@ mod tests { && line.contains("0x0040ce60") && line.contains("stream-load bridge")) ); + assert!( + trace.near_city_acquisition_projection_hypotheses[0] + .blockers + .iter() + .any(|line| line.contains("0x00481210") + && line.contains("0x004133b0") + && line.contains("0x0040ef10")) + ); assert_eq!( trace .near_city_acquisition_runtime_backed_input_families diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md index 7034410..4754448 100644 --- a/docs/rehost-queue.md +++ b/docs/rehost-queue.md @@ -210,6 +210,11 @@ Working rule: sweeps live rows through `0x0040ee10`; after that, bring-up proceeds into later route-entry, grid, and tagged refresh owners rather than re-entering the constructor/finalize family `0x004134d0 / 0x0040f6d0 / 0x0040ef10` + - the ordinary restore staging order is explicit now too: + world bring-up calls the tagged `0x36b1/0x36b2/0x36b3` stream-load owner `0x00413280` at + `0x00444467`, refreshes the placed-structure dynamic side buffers through `0x00481210` at + `0x004444d8`, and only later enters the queued local-runtime replay owner + `0x00444690 -> 0x004133b0 -> 0x0040ee10` - the broader load-side stream owner is separate too: `0x00413280` is the actual tagged `0x36b1/0x36b2/0x36b3` stream-load owner, dispatching per-entry vtable slot `+0x40`; current local recovery still only grounds that seam through the