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

Tier2 Rebuild Sequencing (2026-04-21)

This note preserves the currently grounded sequencing around the active Tier-2 queue head, so the short queue does not have to restate the same late bringup strip every time.

Preserved Artifact Notes

• artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-sequencing-note.md
• artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-recipe-runtime-note.md

Coupled Rebuild Strip

The current Tier-2 bringup evidence no longer reads as one isolated helper. The grounded rebuild owners form one coupled strip:

• 0x00435630
  • rebuilds scenario-side port/warehouse recipe runtime tables
  • re-enters 0x00412d70
• 0x00412d70
  • rebuilds candidate runtime records from scenario state
  • runs two explicit bank passes, first on [candidate+0xba] and then on [candidate+0xbb]
  • does not consult the scenario-side recipe-book name at [state+0x0fe8]
  • picks one availability-qualified seed row and either reuses or clones its full 0x1f2-dword body
  • re-enters 0x00435630
  • also re-enters 0x00411ce0 and 0x00411ee0
• 0x00412fb0
  • broader collection-load owner
  • directly loops through the stock/import stream via 0x004120b0
  • 0x004120b0 itself explicitly loads selector bytes [candidate+0xba/+0xbb] from the stream
  • then calls 0x00412d70
  • then calls 0x00412ab0
  • and only after the later catalog rebuild re-enters 0x00412c10
• 0x00437737
  • late preseed of named candidate-availability records from the live pool
  • upserts through 0x00434f20
• 0x00434f20
  • writes the boolean named-availability override bit
  • immediately re-enters 0x00412c10 when the live candidate pool exists
• 0x00412c10
  • refreshes [candidate+0x7ac] from named availability
  • then tails into 0x0041eac0
• 0x00434d40
  • late post-refresh sweep over collection 0x0062b26c
  • sets [entry+0x7b0] = 1 for subtype-2 rows

Late Bringup Placement

The preserved sequencing note keeps the late 0x197 checkpoint concrete too:

• 0x00444ac1 sits after:
  • 0x004354a0
  • territory overlay sweep 0x00487de0
• and then falls through into:
  • 0x00437737
  • followed by the later candidate-side availability refresh 0x00412c10

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, and then runs one final subtype-2 mark pass through 0x00434d40.

Current Reading

This keeps the active Tier-2 owner question on sequencing and data handoff, not on bare naming:

• one side of the strip is the coupled recipe/runtime rebuild family 0x00435630 -> 0x00412d70 -> 0x00412fb0
• the loader edge is explicit now: 0x004120b0 is the stream-side owner that reads [candidate+0xba/+0xbb] as one-byte parser fields before 0x00412fb0 falls into the runtime projection pass
• the projection edge is explicit in the same way: 0x00412d70 does not just “see banked bytes” abstractly, it runs one pass that accepts only nonzero [candidate+0xba] rows and one pass that accepts only nonzero [candidate+0xbb] rows, reusing a matching prior ordinal when available and otherwise cloning the full seed-row body
• 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 same late checkpoint then follows with 0x00434d40, which walks 0x0062b26c and stamps [entry+0x7b0] = 1 on subtype-2 rows
• 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

So the next Tier-2 pass should keep tracing the handoff between those two late rebuild bands, rather than reopening the direct Warehouse05 availability bit or the already-bounded stock asset corpus.