From 406668b4d87f4a711893dfaa5b0b0d682fb7fb19 Mon Sep 17 00:00:00 2001 From: Jan Petykiewicz Date: Sun, 19 Apr 2026 12:47:20 -0700 Subject: [PATCH] Bound linked-transit selected-site helper strip --- crates/rrt-runtime/src/smp.rs | 3 +++ .../runtime-roots-camera-and-support-families.md | 8 ++++++++ docs/rehost-queue.md | 5 +++++ 3 files changed, 16 insertions(+) diff --git a/crates/rrt-runtime/src/smp.rs b/crates/rrt-runtime/src/smp.rs index afe87cb..be16ac6 100644 --- a/crates/rrt-runtime/src/smp.rs +++ b/crates/rrt-runtime/src/smp.rs @@ -5597,6 +5597,9 @@ fn build_periodic_company_service_trace_report( notes.push( "The per-company cache-cell layout is bounded now too: 0x004093d0 and 0x00407bd0 use bytes +0x00/+0x01 as the initial participation gates, dword +0x02 as the peer-row count, dword +0x06 as the peer-row pointer, dword +0x0a as the shorter peer-cache refresh stamp, and floats +0x0e/+0x12/+0x16 as the weighted/raw/final linked-transit score lanes. The candidate-table and route-entry-tracker owners are bounded above that too: 0x0062ba8c is constructed through 0x0041f4e0 -> 0x0041ede0 -> 0x0041e970, while 0x004a6360 / 0x004a6630 sit under owner-notify refresh 0x00494fb0. The remaining linked-transit gap is narrower again: subtype-4 follow-on 0x0040eba0 already republishes [site+0x2a4] through 0x004814c0 / 0x00481480 and world-cell chain helpers 0x0042c9f0 / 0x0042c9a0, and direct inspection of 0x0040ea96..0x0040eb65 shows that owner-company branch only consumes [site+0x276] rather than rehydrating it. That pushes the open question one level earlier to whichever restore or service owner feeds [site+0x276] and the live linked-peer rows before this replay continuation runs.".to_string(), ); + notes.push( + "One nearby live helper strip is narrower now too: 0x004337a0 is exactly the raw selected-company getter over [world+0x21], used in the replay-side sibling around 0x0040e775 only to compare the current selection against [site+0x276]. The adjacent world-side helpers 0x00452d80 / 0x00452db0 / 0x00452fa0 are separate live selected-site or active service-state setters/dispatchers over [world+0x217d/+0x2181] gated by mode byte [world+0x2175]; they can clear or republish currently-selected site ids through 0x00413620 / 0x00413750, but they do not repopulate [site+0x276] for already-restored rows.".to_string(), + ); notes.push( "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(), ); diff --git a/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md b/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md index a0d13a6..b92bf1f 100644 --- a/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md +++ b/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md @@ -3704,6 +3704,14 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0` `0x00409720`, strips route lists from company-owned trains in modes `0x0a/0x13`, and then re-enters `train_try_append_linked_transit_autoroute_entry` `0x00409770` only when a train's route list has become empty. + One nearby live helper strip is narrower now too. Direct inspection of the replay-side sibling + around `0x0040e775` shows `0x004337a0` is exactly the raw selected-company getter over + `[world+0x21]`, used there only to compare the current selection against placed-structure lane + `[site+0x276]`. The adjacent world-side helpers `0x00452d80 / 0x00452db0 / 0x00452fa0` are + separate live selected-site or active service-state setters/dispatchers over + `[world+0x217d/+0x2181]` gated by mode byte `[world+0x2175]`; they can clear or republish + currently-selected site ids through `0x00413620 / 0x00413750`, but they do not repopulate + `[site+0x276]` for already-restored rows. On the wider chooser question, the current evidence is also tighter than before: every recovered external owner of `0x00402cb0` is still in the city-connection family, so the two later direct placement lanes currently read as city-connection fallback behavior rather than a broadly shared diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md index 0b7ee0f..2b5cafa 100644 --- a/docs/rehost-queue.md +++ b/docs/rehost-queue.md @@ -62,6 +62,11 @@ Working rule: - the owner-company branch is tighter now too: direct inspection of `0x0040ea96..0x0040eb65` shows that it consumes `[site+0x276]` and branches through owner/company helpers, but does not itself rehydrate `[site+0x276]` + - the nearby selected-company and live-site helper strip is tighter now too: + `0x004337a0` is the raw selected-company getter over `[world+0x21]`, and the adjacent + world-side helpers `0x00452d80 / 0x00452db0 / 0x00452fa0` are live selected-site or active + service-state setters/dispatchers over `[world+0x217d/+0x2181]` gated by mode byte + `[world+0x2175]`, not restore-time republishers for `[site+0x276]` - that makes the next linked-transit question narrower: identify which earlier restore or service owner feeds `[site+0x276]` and the live linked-peer rows before replay continuation `0x0040e360..0x0040edf6`, beyond the already-grounded