Exhaust shared region payload reload seam

This commit is contained in:
Jan Petykiewicz 2026-04-18 17:44:40 -07:00
commit 8101e4d122
2 changed files with 6 additions and 0 deletions

View file

@ -4252,6 +4252,7 @@ fn build_region_service_trace_report(
"constructor-side evidence now proves the latches are initialized locally, so the remaining gap can legitimately be framed as post-construction restore or rebuild".to_string(),
"direct disassembly of 0x0041f590/0x0041f5b0 now proves the world-region vtable root is 0x005c9a28, so the 0x00455fc0 dispatch at slot +0x48 lands on 0x00455870 and the serializer sibling at +0x4c lands on 0x00455930".to_string(),
"direct disassembly of 0x00455870/0x00455930 now shows that callback pair only restores and serializes two triplet-like three-lane scalar bands through 0x531150/0x531030 plus 0x530720/0x52e8b0, not [region+0x276/+0x302/+0x316]".to_string(),
"direct disassembly now tightens the rest of 0x00455fc0 too: after the +0x48 callback it only runs 0x0052ebd0 to read two one-byte generic flags through 0x531150 into base object bytes [this+0x20], [this+0x8d], [this+0x5c..+0x61], [this+0x1ee], [this+0x1fa], and [this+0x3e], then opens 0x55f3 only for span accounting before returning, so the missing region latches are not hiding in the remainder of 0x00455fc0 either".to_string(),
"direct disassembly of 0x00421510 now also shows the exact tagged loop shape: it opens 0x5209, reads 0x520a, iterates live entry ordinals through 0x518380/0x518140, seeds a stack-local world-region vtable helper through 0x0041f590/0x0041f5b0, dispatches each loaded record through slot +0x40, and only then closes 0x520b".to_string(),
"direct disassembly of 0x0041f5c0 now also shows its post-0x00455fc0 work is local to the profile collection path: it clamps [region+0x31b] back to 1.0f when needed, zeroes [region+0x317], allocates one 0x88-sized helper through 0x53b070/0x518b90, stores it at [region+0x37f], loads that helper through 0x518680, and clears [region+0x385] before returning".to_string(),
"the first caller-side checkpoint above 0x00421510 is now grounded too: 0x00444887 invokes the region collection refresh inside a broader restore sequence and then immediately advances to territory_collection_refresh_records_from_tagged_bundle 0x00487c20 and support_collection_refresh_records_from_tagged_bundle 0x0040b5d0, which makes the missing latches look like a later global rebuild seam rather than hidden work inside 0x00421510 itself".to_string(),

View file

@ -368,6 +368,11 @@ Working rule:
`0x00531150/0x00531030` plus `0x00530720/0x0052e8b0`; they still do not touch
`[region+0x276/+0x302/+0x316]`. That means the remaining region restore target is now the later
owner that rebuilds those latches or the separate tagged body seam that persists them.
- The rest of `0x00455fc0` is ruled down further now too: after the `+0x48` callback it only runs
`0x0052ebd0`, which reads two one-byte generic flags through `0x531150` into base object bytes
`[this+0x20]`, `[this+0x8d]`, `[this+0x5c..+0x61]`, `[this+0x1ee]`, `[this+0x1fa]`, and
`[this+0x3e]`, and then it opens `0x55f3` only for span accounting before returning. So the
missing region latches are not hiding in the remainder of `0x00455fc0` either.
- The later restore-side region owners are narrowed further now too: the `0x00421ce0 ->
0x0041fb00 -> 0x00421730` sweep is class-`0` raster/id rebuild, `0x004881b0` is a companion
region-set cell-count rebuild over `[region+0x3d/+0x41]`, `0x00487de0` is a border-segment