Tighten Tier2 checkpoint sequencing order

This commit is contained in:
Jan Petykiewicz 2026-04-21 18:44:10 -07:00
commit 25418c8c42
2 changed files with 29 additions and 2 deletions

View file

@ -10,6 +10,8 @@ The earlier post-load recipe-runtime rebuild call at `0x00443ebc` runs:
- immediately after the named candidate-availability collection at `[world+0x66b2]`
has been restored from fixed `0x22`-byte rows
- by directly calling `0x00435630`
- then calling `0x00412c10` only if live candidate pool `0x0062b268` is non-null
- before the neighboring candidate filter/count rebuilds
`0x00412c10 / 0x00412bd0`
- before the year-derived follow-ons
@ -27,11 +29,13 @@ The later explicit `0x197` checkpoint at `0x00444ac1` sits:
- after the territory-side sweep
`world_region_border_overlay_emit_segment_geometry_from_region_grid`
`0x00487de0`
- and then falls through into
- and then directly reruns `0x00435630`
- then falls through into
`world_preseed_named_candidate_availability_records_from_live_pool`
`0x00437737`
- followed by the later candidate-side availability refresh
- followed by the later unconditional candidate-side availability refresh
`0x00412c10`
- and then `0x00434d40`
So the late Tier 2 strip begins with named-availability preseed and latch refresh, not with the
shell progress or territory overlay helpers that precede it.
@ -70,4 +74,6 @@ The strongest remaining Tier 2 question is sequencing, not naming:
`0x00435630 -> 0x00412d70`
and the broader load-side rebuild owner
`0x00412fb0`,
with the early checkpoint only conditionally refreshing `0x00412c10` but the late checkpoint
always rerunning `0x00435630 -> 0x00437737 -> 0x00412c10`,
rather than on a direct `Warehouse05` availability bit or recipe-book display-name leak.