Note persisted 0x5dc1 selector bundle

This commit is contained in:
Jan Petykiewicz 2026-04-19 03:38:01 -07:00
commit edf6c83d92
2 changed files with 9 additions and 0 deletions

View file

@ -5428,6 +5428,10 @@ fn build_periodic_company_service_trace_report(
notes.push(
"The replay strip is tighter now too. 0x00444690 is the current late world bring-up caller of 0x004133b0, that outer owner drains queued site ids through 0x0040e450 and then sweeps every live placed structure through 0x0040ee10, and 0x0040ee10 itself reaches 0x0040edf6 -> 0x00480710 plus the later 0x0040e360 follow-on. A separate runtime path at 0x004160aa also re-enters 0x0040ee10 later. So [peer+0x08] replay is no longer the open question, and [site+0x04] is no longer an owner mystery either: the local linked-site helper strip seeds [site+0x3cc/+0x3d0] from 0x62b2fc / 0x62b268, reaches the save-backed 0x0045c150 / 0x0045c310 owner directly, that owner fills [owner+0x23e/+0x242] from tagged payload 0x5dc1, and 0x0045c36e then feeds [owner+0x23e] through 0x00456100 -> 0x00455b70 -> 0x0052edf0 into [site+0x04]. The remaining non-hook target is now the smaller shellless-simulation question: which subset of those persisted site/peer fields is actually sufficient to run 0x004014b0 and its city-connection sibling without shell state.".to_string(),
);
notes.push(
"The same persisted selector seam is broader than just the two strings. Atlas-backed recovery now bounds 0x0040c980 -> 0x0045b560 as the derived serializer over [site+0x23e/+0x242/+0x246/+0x24e/+0x252], so the remaining restore-owner search should treat that 0x5dc1/0x5dc2 selector/child/runtime bundle as one persisted field family rather than only [site+0x23e/+0x242]."
.to_string(),
);
SmpPeriodicCompanyServiceTraceReport {
profile_family,