jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Tighten Tier2 checkpoint sequencing order

Browse source
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
Download patch file Download diff file Expand all files Collapse all files

10
artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-sequencing-note.md
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.

21
docs/rehost-queue/tier2-rebuild-sequencing-2026-04-21.md
View file

@ -51,6 +51,25 @@ The preserved sequencing note keeps the late `0x197` checkpoint concrete too:
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.
## Direct Checkpoint Order
Fresh `objdump` over `RT3.exe` now makes the two key bringup checkpoints explicit too:
- early checkpoint `0x00443ebc`
- calls `0x00435630`
- then calls `0x00412c10` only if live candidate pool `0x0062b268` is non-null
- then unconditionally calls `0x00412bd0`
- then follows with `0x00434130` and `0x00436af0`
- late checkpoint `0x00444ac1`
- calls `0x00435630`
- then immediately calls `0x00437737`
- then unconditionally calls `0x00412c10`
- then calls `0x00434d40`
So the late bringup strip is not just “somewhere after `0x004354a0`.” It explicitly reruns the
recipe/runtime rebuild before the named-availability preseed and the later unconditional latch
refresh.
## Current Reading
This keeps the active Tier-2 owner question on sequencing and data handoff, not on bare naming:
@ -59,6 +78,8 @@ This keeps the active Tier-2 owner question on sequencing and data handoff, not
`0x00435630 -> 0x00412d70 -> 0x00412fb0`
- the other side is the later named-availability preseed/latch family
`0x00437737 -> 0x00434f20 -> 0x00412c10`
- the early checkpoint only refreshes `0x00412c10` when the live candidate pool already exists,
while the late checkpoint always reruns `0x00435630 -> 0x00437737 -> 0x00412c10`
- the remaining non-hook question is how that interaction lets candidate-table rows
`35/43/45..66` reach `0x00412d70` with nonzero `[candidate+0xba/+0xbb]` before the later
`0x00419230` rebank-or-clone pass consumes them