Narrow peer-site selector caller families

This commit is contained in:
Jan Petykiewicz 2026-04-18 18:45:58 -07:00
commit bd0e2920ee
2 changed files with 33 additions and 12 deletions

View file

@ -4102,14 +4102,22 @@ fn build_periodic_company_service_trace_report(
"0x00420030 / 0x00420280 peer-site boolean/selector pair over the placed-structure collection".to_string(),
"0x0047efe0 placed-structure linked-company resolver".to_string(),
"0x0052edf0 generic base constructor seeding [this+0x04] from caller arg 1".to_string(),
"0x00455b70 placed-structure specialization constructor feeding 0x0052edf0 arg 3 as the primary selector and arg 1 as fallback"
.to_string(),
"0x00455c62 concrete placed-structure specialization caller of 0x0052edf0".to_string(),
"0x00456100 local wrapper duplicating its first incoming arg across the 0x00455b70 selector/fallback bundle"
.to_string(),
"0x00456072 fixed 0x55f2 callback forwarding three local dwords plus unit scalars into 0x00455b70"
.to_string(),
"0x00485819 typed placed-structure caller of 0x0052edf0 via 0x530640-style argument bundle"
.to_string(),
"0x00490a79 chooser-side caller of 0x00455b70 with literal selector 0x005cfd74 and fallback seed 0x005c87a8"
.to_string(),
"0x00406050 city-connection bonus/news sibling owner".to_string(),
"0x00409950 linked-transit roster sibling owner".to_string(),
];
let next_owner_questions = vec![
"Which placed-structure load or bring-up caller feeds caller arg 1 into the generic base constructor 0x0052edf0 so the live backing-record selector [site+0x04] is reseeded before 0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50 consume it?".to_string(),
"Which concrete 0x00455b70 caller shape applies to the live class-0 site rows that 0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50 consume, now that 0x0052edf0 ownership is grounded and the remaining question is the selector-source lane feeding arg 3 (with arg 1 as fallback)?".to_string(),
"How much of the linked-peer refresh path is strictly post-load versus recurring runtime maintenance now that 0x004133b0 reaches 0x0040ee10 -> 0x0040edf6 -> 0x00480710 during bring-up and 0x004160aa also re-enters 0x0040ee10 later?".to_string(),
"Which persisted linkage fields behind 0x0047efe0, [region+0x2a4], and [region+0x276] are sufficient to rehost the 0x004014b0 proximity-and-news branch without shell state?".to_string(),
"Which infrastructure consumer above the grounded 0x38a5 seam actually drives the linked-transit branch that 0x00409950 follows?".to_string(),
@ -4240,7 +4248,7 @@ fn build_periodic_company_service_trace_report(
"0x00406050 city-connection bonus/news sibling owner",
],
&[
"Direct disassembly now shows this branch iterating the live class-0 region collection, skipping regions with pending amount [region+0x276], reusing the center-cell token gate 0x0041f6e0 -> 0x0042b2d0, reusing the linked-region status branch 0x0047de00 -> 0x0040c990, checking candidate reachability through 0x004801a0, consulting the placed-structure peer-site boolean/selector pair 0x00420030 / 0x00420280 over 0x006cec20, scoring regions against company proximity and aging through 0x0040d540 and 0x0040cac0, and then publishing the winning linked company id from [region+0x2a4]. The remaining peer-site identity gap is now narrower too: the linked-peer row's [peer+0x04] is written by 0x00480210 as the anchor-site id, the anchor-site row's [site+0x2a8] is written by 0x0040f6d0 after 0x00481390 returns the linked peer id, the live backing-record selector [site+0x04] is written by the generic base constructor 0x0052edf0 from caller arg 1, late world bring-up 0x00444690 -> 0x004133b0 already replays queued clone refresh through 0x0040e450 and live-site sweeps through 0x0040ee10, and [peer+0x08] is refreshed from there through 0x0040edf6 -> 0x00480710 -> 0x0048abc0 / 0x00493cf0.",
"Direct disassembly now shows this branch iterating the live class-0 region collection, skipping regions with pending amount [region+0x276], reusing the center-cell token gate 0x0041f6e0 -> 0x0042b2d0, reusing the linked-region status branch 0x0047de00 -> 0x0040c990, checking candidate reachability through 0x004801a0, consulting the placed-structure peer-site boolean/selector pair 0x00420030 / 0x00420280 over 0x006cec20, scoring regions against company proximity and aging through 0x0040d540 and 0x0040cac0, and then publishing the winning linked company id from [region+0x2a4]. The remaining peer-site identity gap is now narrower too: the linked-peer row's [peer+0x04] is written by 0x00480210 as the anchor-site id, the anchor-site row's [site+0x2a8] is written by 0x0040f6d0 after 0x00481390 returns the linked peer id, the live backing-record selector [site+0x04] is seeded through 0x00455b70 -> 0x0052edf0 with arg 3 as the primary selector and arg 1 as fallback, late world bring-up 0x00444690 -> 0x004133b0 already replays queued clone refresh through 0x0040e450 and live-site sweeps through 0x0040ee10, and [peer+0x08] is refreshed from there through 0x0040edf6 -> 0x00480710 -> 0x0048abc0 / 0x00493cf0.",
],
));
SmpPeriodicCompanyServiceTraceEntry {
@ -4274,7 +4282,7 @@ fn build_periodic_company_service_trace_report(
"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(),
);
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] itself is no longer an owner mystery either: the generic base constructor 0x0052edf0 writes [this+0x04] from caller arg 1 after 0x0052ecd0 clears it. The remaining non-hook target is which placed-structure load or bring-up caller supplies that arg-1 selector before 0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50 consume it.".to_string(),
"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] itself is no longer an owner mystery either: 0x00455b70 feeds 0x0052edf0 with arg 3 as the primary selector and arg 1 as fallback, while grounded caller shapes now include the local wrapper 0x00456100, the fixed 0x55f2 callback 0x00456072, and the chooser-side path 0x00490a79. The remaining non-hook target is which of those caller families, or which still-unmapped sibling, actually seeds the live site rows that 0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50 consume.".to_string(),
);
SmpPeriodicCompanyServiceTraceReport {
@ -25935,7 +25943,7 @@ mod tests {
let trace = build_periodic_company_service_trace_report(&analysis);
assert_eq!(trace.selected_company_id, Some(7));
assert_eq!(trace.atlas_candidate_consumers.len(), 7);
assert_eq!(trace.known_bridge_helpers.len(), 30);
assert_eq!(trace.known_bridge_helpers.len(), 34);
assert_eq!(trace.next_owner_questions.len(), 4);
assert_eq!(trace.companies.len(), 1);
assert!(trace.atlas_candidate_consumers.iter().any(|line| {
@ -25944,7 +25952,9 @@ mod tests {
&& line.contains("peer-site boolean/selector pair")
}));
assert!(trace.next_owner_questions.iter().any(|line| {
line.contains("[site+0x04]") && line.contains("0x0052edf0") && line.contains("arg 1")
line.contains("0x00455b70")
&& line.contains("live class-0 site rows")
&& line.contains("arg 3")
}));
assert!(trace.next_owner_questions.iter().any(|line| {
line.contains("0x004160aa")

View file

@ -64,13 +64,22 @@ Working rule:
- the winning linked company id comes from `[region+0x2a4]`
- direct disassembly now shows the generic base constructor `0x0052edf0` clearing base state
through `0x0052ecd0` and then writing `[this+0x04]` from caller arg `1`
- `0x00455c62` is one concrete placed-structure specialization caller of `0x0052edf0`
- `0x00455b70` is the concrete placed-structure specialization constructor feeding
`0x0052edf0`, with arg `3` as the primary selector and arg `1` as fallback
- `0x00455c62` is the direct in-body call from that specialization constructor into
`0x0052edf0`
- `0x00456100` is a local wrapper that duplicates its first incoming arg across the
selector/fallback bundle before calling `0x00455b70`
- `0x00456072` is a fixed `0x55f2` callback that forwards three local dwords plus unit scalars
into `0x00455b70`
- `0x00485819` is one typed placed-structure caller of `0x0052edf0` through the generic
three-arg wrapper `0x00530640`
- `0x00490a79` is one chooser-side caller of `0x00455b70`, feeding literal selector
`0x005cfd74` with fallback seed `0x005c87a8`
So the next owner question is no longer “what does the acquisition branch do?” or “which post-
load owner replays linked-site refresh?” but “which placed-structure load or bring-up caller
supplies the `0x0052edf0` arg-1 selector that becomes the live backing-record selector
`[site+0x04]` once the existing bring-up replay finishes?”
load owner replays linked-site refresh?” but “which concrete `0x00455b70` caller family applies
to the live site rows, and which persisted lane becomes the selector bundle that ultimately
seeds `[site+0x04]`?”
- Make the next static/rehost slice the peer-site rebuild seam above persistence, not another save
scan:
- treat `0x00444690 -> 0x004133b0 -> 0x0040e450 / 0x0040ee10 -> 0x0040edf6 -> 0x00480710` as
@ -78,9 +87,11 @@ Working rule:
- treat `0x004160aa -> 0x0040ee10` as the checked-in recurring runtime maintenance entry into the
same linked-peer refresh strip
- treat `0x0052edf0` as the checked-in field owner for `[site+0x04]`
- map the concrete placed-structure load or bring-up caller that feeds caller arg `1` into
`0x0052edf0` before `0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50` consume the
resulting selector, if that caller is distinct from the bring-up replay path
- treat `0x00455b70` as the checked-in specialization constructor that maps selector/fallback
bundle lanes into that field owner
- distinguish which `0x00455b70` caller family actually seeds the live site rows before
`0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50` consume the resulting selector, and name
the persisted lane that reaches its selector arg `3`
- Use the higher-layer probes as the standard entry point for the current blocked frontier instead
of generic save scans:
`runtime inspect-periodic-company-service-trace <save.gms>`,