From e3c29ae90465eb35ba0c7691c33c3ad382cfc033 Mon Sep 17 00:00:00 2001 From: Jan Petykiewicz Date: Sun, 19 Apr 2026 00:00:37 -0700 Subject: [PATCH] Rule down grouped opcode restore ownership --- crates/rrt-runtime/src/smp.rs | 10 ++++++++++ docs/rehost-queue.md | 12 +++++++++--- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/crates/rrt-runtime/src/smp.rs b/crates/rrt-runtime/src/smp.rs index 15bef2c..2a6446e 100644 --- a/crates/rrt-runtime/src/smp.rs +++ b/crates/rrt-runtime/src/smp.rs @@ -4784,6 +4784,7 @@ fn build_periodic_company_service_trace_report( "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(), + "the grouped opcode dispatcher 0x00431b20 is ruled down too: current direct caller census only reaches it from scenario runtime-effect service 0x004323a0 -> 0x00432f40 via 0x00432317, so 0x0061039c currently reads as a live runtime-effect application lane rather than the missing persisted restore owner for [site+0x276]".to_string(), ], }, SmpServiceConsumerHypothesis { @@ -28745,6 +28746,15 @@ mod tests { && line.contains("0x004133b0") && line.contains("0x0040ef10")) ); + assert!( + trace.near_city_acquisition_projection_hypotheses[0] + .blockers + .iter() + .any(|line| line.contains("0x00431b20") + && line.contains("0x004323a0") + && line.contains("0x00432f40") + && line.contains("0x00432317")) + ); assert_eq!( trace .near_city_acquisition_runtime_backed_input_families diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md index 4754448..282fd65 100644 --- a/docs/rehost-queue.md +++ b/docs/rehost-queue.md @@ -220,12 +220,18 @@ Working rule: per-entry vtable slot `+0x40`; current local recovery still only grounds that seam through the cached-source bridge `0x0040ce60 -> 0x0040cd70 / 0x0045c150`, not through a direct `[site+0x276]` republisher + - the grouped-opcode family is ruled down too: + current direct caller census only reaches `0x00431b20` from scenario runtime-effect service + `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 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 - `0x00413280` cached-source bridge, and the checked ordinary replay strip - `0x00444690 -> 0x004133b0 -> 0x0040ee10` feeds the tuple or companion restore calls that are - sufficient to repopulate `[site+0x276]` for shellless acquisition + `0x00413280` cached-source bridge, the checked ordinary replay strip + `0x00444690 -> 0x004133b0 -> 0x0040ee10`, and the live runtime-effect dispatcher + `0x00431b20` feeds the tuple or companion restore calls that are sufficient to repopulate + `[site+0x276]` for shellless acquisition - 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]`