From 6e46c438374aeca87f9f8c0c9da0e8b30beef942 Mon Sep 17 00:00:00 2001 From: Jan Petykiewicz Date: Sun, 19 Apr 2026 00:02:31 -0700 Subject: [PATCH] Ground placed-structure companion scalar lane --- crates/rrt-runtime/src/smp.rs | 13 +++++++++++++ docs/rehost-queue.md | 4 ++++ 2 files changed, 17 insertions(+) diff --git a/crates/rrt-runtime/src/smp.rs b/crates/rrt-runtime/src/smp.rs index 2a6446e..204d5cc 100644 --- a/crates/rrt-runtime/src/smp.rs +++ b/crates/rrt-runtime/src/smp.rs @@ -4760,6 +4760,7 @@ fn build_periodic_company_service_trace_report( "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(), + "[site+0x27a] is now bounded as a live signed scalar accumulator rather than a second owner-identity mystery: base constructor 0x00421200 zeros it at 0x0042125d, create-side initializer 0x0040f6d0 zeros it again at 0x0040f793, station-detail apply 0x0040dfec accumulates into it before 0x0040d1f0 / 0x00480710, acquisition commit stores it at 0x004269e4, acquisition clear negates and clears it through 0x00426a44..0x00426a90, and acquisition delta helper 0x00426ad8 accumulates into it again".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 constructor control-flow now shows 0x004134d0 allocating a new placed-structure row through 0x00518900 and then calling 0x0040f6d0, which seeds [site+0x2a4], clears broad row state, copies the display name bytes, and writes [site+0x276] from an incoming argument before any later service logic runs".to_string(), "0x0040f6d0 immediately zeroes [site+0x2a8/+0x272/+0x27a/+0x29e], stamps [site+0x3d4/+0x3d5], and seeds further local caches, which makes it a create-side initializer rather than a replay-only refresh".to_string(), @@ -28508,6 +28509,18 @@ mod tests { .any(|line| line.contains("after 0x00444690 -> 0x004133b0") && line.contains("0x004134d0 / 0x0040f6d0 / 0x0040ef10")) ); + assert!( + trace.near_city_acquisition_projection_hypotheses[0] + .evidence + .iter() + .any(|line| line.contains("[site+0x27a]") + && line.contains("0x0042125d") + && line.contains("0x0040f793") + && line.contains("0x0040dfec") + && line.contains("0x004269e4") + && line.contains("0x00426a44..0x00426a90") + && line.contains("0x00426ad8")) + ); assert!( trace.near_city_acquisition_projection_hypotheses[0] .evidence diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md index 282fd65..9bf5c7a 100644 --- a/docs/rehost-queue.md +++ b/docs/rehost-queue.md @@ -225,6 +225,10 @@ Working rule: `0x004323a0 -> 0x00432f40` through direct call `0x00432317`, so `0x0061039c` currently reads as a live runtime-effect application lane rather than the missing persisted restore owner for `[site+0x276]` + - the `[site+0x27a]` companion lane is grounded now too: + it is a live signed scalar accumulator rather than a second owner-identity seam, with zero-init + at `0x0042125d` and `0x0040f793`, accumulation at `0x0040dfec` and `0x00426ad8`, direct set on + acquisition commit at `0x004269e4`, and negated clear at `0x00426a44..0x00426a90` - the remaining owner-company question is therefore narrower than “find any replay seam”: identify which non-transport persisted source family outside the currently bounded direct allocator/finalize/store families, the save-side `0x00413440` serializer, the load-side