jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Rule down acquisition replay owner strip

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 22:33:44 -07:00
commit 8e3800bacb
2 changed files with 16 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

11
crates/rrt-runtime/src/smp.rs
View file

@ -4719,6 +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 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(),
@ -28277,6 +28278,16 @@ mod tests {
.iter()
.any(|line| line.contains("0x004133b0"))
);
assert!(
trace.near_city_acquisition_projection_hypotheses[0]
.evidence
.iter()
.any(|line| line.contains("0x0040ee10")
&& line.contains("[site+0x3cc]")
&& line.contains("0x00480710")
&& line.contains("[site+0x04]")
&& line.contains("[site+0x08]"))
);
assert!(
trace.near_city_acquisition_projection_hypotheses[1]
.candidate_consumers

5
docs/rehost-queue.md
View file

@ -107,6 +107,11 @@ Working rule:
`0x004133b0 -> 0x0040e450 / 0x0040ee10` rebuilds cloned local-runtime records and local
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
- 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]`