Split placed-structure writer families

This commit is contained in:
Jan Petykiewicz 2026-04-19 12:53:28 -07:00
commit 9d9e2965aa
3 changed files with 19 additions and 0 deletions

View file

@ -5603,6 +5603,9 @@ fn build_periodic_company_service_trace_report(
notes.push(
"The base placed-structure load callback is narrower now too: local .rdata at 0x005cb4c0 shows that the shared base table, not the 0x005c8c50 specialization table, owns the 0x0045c150 / 0x0045b560 / 0x00455870 / 0x00455930 load-save quartet. Direct disassembly of 0x0045c150 -> 0x00455fc0 then shows that callback only reloads the generic 0x55f1/0x55f2/0x55f3 triplet/scalar bands and re-enters the same base triplet/scalar slots 0x00455870 / 0x00455930, so the missing placed-structure owner-company lane [site+0x276] still lies outside the checked-in base load path.".to_string(),
);
notes.push(
"The remaining direct [site+0x276] writers are split more cleanly now too: 0x00421200 is the broad late-field constructor/reset zero-fill over the same 0x23a/0x23e/0x25a/0x25e/... row family and clears [+0x276] as part of that initialization; 0x00428270 is a collection-wide live owner remap over 0x0062b26c that rewrites [site+0x276] only for rows matching one caller-supplied old owner id; and 0x00422280 is a subtype-local synthetic scalar writer that buckets float lane [row+0x25e], stores one 100000 * rand(bucket) result into [+0x276], and immediately publishes localized-id 7. Those writes therefore sit under constructor/live mutation or subtype-local scalar families, not the missing restore-time owner-company replay seam.".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(),
);