Rule out early post-load setup owners

This commit is contained in:
Jan Petykiewicz 2026-04-19 13:56:22 -07:00
commit 25a97d209f
3 changed files with 18 additions and 0 deletions

View file

@ -5919,6 +5919,7 @@ fn build_region_service_trace_report(
evidence: vec![
"the checked-in shell-load subgraph and function map now place world_load_saved_runtime_state_bundle 0x00446d40 directly ahead of world_run_post_load_generation_pipeline 0x004384d0, so the first later non-hook owner family after the ruled-down 0x00444887 continuation is the post-load generation strip rather than another tagged region payload callback".to_string(),
"0x004384d0 already exposes the stage ordering tightly enough to subdivide the next search: id 319 refreshes the route-entry collection, auxiliary route trackers, and then 0x004133b0 placed-structure local-runtime replay; id 320 runs 0x00421c20(1.0, 1) for the region-owned building setup strip; id 321 runs 0x00437b20 and then sweeps regions through 0x00423d30".to_string(),
"direct disassembly now tightens the early 0x004384d0 setup strip too: before the conditional 320/321 gates it always runs 0x0044fb70 transport/pricing-grid setup and 0x0041ea50 candidate-local-service setup, and the extra arg-guarded 0x00421b60 -> 0x004882e0 default-region pair sits beside them as the last pre-320/321 setup branch. Those owners are therefore setup-side world-grid, candidate-table, and border-refresh work rather than the missing [region+0x2a4] / [region+0x310/+0x338/+0x360] republisher".to_string(),
"the 319 placed-structure replay strip is now grounded as more than generic setup glue: 0x004133b0 drains queued site ids through 0x0040e450, sweeps every live placed structure through 0x0040ee10, and then reaches the already-grounded linked-site follow-on 0x00480710, which is a stronger structural bridge into acquisition-side site or peer state than the ruled-down territory/support loaders".to_string(),
"the surrounding 319 helpers are ruled down further now too: 0x00437220 and 0x004377a0 stay on chairman-slot selector/profile materialization over [world+0x69d8/+0x69db] and scenario selector bytes [0x006cec7c+0x87], while 0x00434d40 only seeds the subtype-2 candidate runtime latch [candidate+0x7b0] after the later burst".to_string(),
"the 320 building setup strip is narrower but still relevant: 0x00421c20 dispatches every live region into 0x004235c0, and that worker consults the region profile collection [region+0x37f], the placed-instance registry 0x0062b26c, and demand-balancing helpers like 0x00422900/0x00422be0/0x00422ee0, so current evidence keeps it in the same acquisition-adjacent owner family even though it is not yet a direct writer to [region+0x2a4] or [region+0x310/+0x338/+0x360]".to_string(),

View file

@ -788,6 +788,16 @@ The same brush strip is tighter now too:
way: when startup latch `0x006cd8d8` is clear it stamps `[0x006cec7c+0x79] = 1`, ensures
`[world+0x6a6c] >= 1`, forces chairman-seat byte `[world+0x69db] = 1`, and then re-enters
`0x004377a0` before the later route-entry and placed-structure refresh families. The
early setup strip is explicit now too: before those conditional `320/321` gates,
`0x004384d0` always runs `world_compute_transport_and_pricing_grid` `0x0044fb70` and
`structure_candidate_collection_run_post_load_local_service_setup_phase` `0x0041ea50`, and when
its own entry arg is nonzero it also runs the default-region pair
`world_region_collection_seed_default_regions` `0x00421b60` plus
`world_region_border_overlay_rebuild` `0x004882e0` before any conditional `320/321` branch is
considered. Those owners are therefore setup-side world-grid, candidate-table, and border-refresh
work, not the missing later republisher for `[region+0x2a4]` or
`[region+0x310/+0x338/+0x360]`.
The
region-side setup branches are narrower in the same negative way now too: `0x00421c20` is just
the collection dispatcher, and its worker `0x004235c0` stays inside live region demand and
placement by routing through `0x00422900` cached category accumulation, `0x004234e0` projected

View file

@ -1581,6 +1581,13 @@ Working rule:
chase this `0x004384d0` handoff family directly instead of treating the remaining
`[region+0x2a4]` / `[region+0x310/+0x338/+0x360]` gap as a generic continuation below
`0x00444887`.
- The early `0x004384d0` setup strip is tighter now too: before the conditional `320/321` gates it
always runs `0x0044fb70` transport/pricing-grid setup and `0x0041ea50`
candidate-local-service setup, and the extra arg-guarded `0x00421b60 -> 0x004882e0`
default-region pair sits beside them as the last pre-`320/321` setup branch. Those helpers are
already grounded as world-grid, candidate-table, and border-refresh owners rather than the
missing `[region+0x2a4]` / `[region+0x310/+0x338/+0x360]` republisher, so they drop out of the
remaining region-handoff search too.
- The `319` lane is the strongest bridge inside that family: `0x004133b0` drains queued
placed-structure ids through `0x0040e450`, sweeps every live site through `0x0040ee10`, and then
reaches the already-grounded linked-site follow-on `0x00480710`. The `320` and `321` lanes are