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

Extract kind-8 late bringup note

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 10:36:27 -07:00
commit 8b89d4717e
2 changed files with 81 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

20
docs/rehost-queue.md
View file

@ -415,6 +415,26 @@ Working rule:
`0x00432f40`. That shifts the remaining ordinary kind-`8` question upward: the unresolved
service-vs-restore ordering is now specifically inside `0x00443a50`, not inside the loader
itself.
- the bringup owner note now supplies the high-level ordering too:
current `function-map.csv` notes for `world_entry_transition_and_runtime_bringup`
`0x00443a50` already state that the tagged load phase reloads event runtime records through
`0x00433130`, while the one-shot kind-`8` runtime-effect service through `0x00432f40` only
runs much later in the final reactivation tail, after the candidate/region/year-band refresh
strip and before shell-profile latch `[0x006cec7c+0x97]` is cleared. That means the remaining
unknown is no longer restore-vs-service ordering in the abstract; it is which late bringup
branch or retagger between those two points materializes the live kind-`8` records that carry
the mutation-capable compact payloads.
- the late retagger remains a prose-first seam:
a direct `0x00442c30` subgraph export currently collapses to the seed node only, because the
grounded function-map note carries the useful scenario-title and collection-mutation detail but
not many mapped-address backrefs. So the post-load scenario-fixup branch should currently be
treated as a manual-note recovery seam rather than one the generic subgraph exporter can answer
by itself.
- the relevant prose is checked in separately now too:
`artifacts/exports/rt3-1.06/runtime-effect-kind8-late-bringup-note.md` extracts the current
late-bringup facts for `0x00446d40`, `0x00443a50`, `0x00442c30`, and the explicit
`SP - GOLD` / `Labor` trigger-kind rewrites, so the next pass can work from one bounded note
instead of stitching the same ordering back together from the queue plus function-map prose.
kinds”; it is the smaller set of scenario-specific records where that sweep explicitly writes
`[event+0x7ef]` itself or a still-later owner does.
- two explicit trigger-kind materializations are now grounded inside that retagger: