rrt/artifacts/exports/rt3-1.06/runtime-effect-kind8-late-bringup-note.md

# Runtime Effect Kind-8 Late Bringup Note

This note extracts the current grounded late-bringup facts for the ordinary startup
runtime-effect lane, so the remaining recovery work does not have to keep jumping between the
queue, the large function map note, and the broader subgraph artifacts.

## Grounded Ordering

- `world_load_saved_runtime_state_bundle` `0x00446d40` directly reaches
  `scenario_event_collection_refresh_runtime_records_from_packed_state` `0x00433130`.
- The same loader does **not** directly reach
  `scenario_event_collection_service_runtime_effect_records_for_trigger_kind` `0x00432f40`.
- `world_entry_transition_and_runtime_bringup` `0x00443a50` is the owner above both restore and
  service.
- Current `function-map.csv` notes for `0x00443a50` already state that:
  - the tagged load phase reloads event runtime records through `0x00433130`
  - the one-shot kind-`8` service through `0x00432f40` only runs much later in the final
    reactivation tail
  - shell-profile latch `[0x006cec7c+0x97]` is cleared after that late kind-`8` service

## Late-Tail Candidate Branches

- The remaining unknown is therefore no longer abstract restore-vs-service ordering.
- The remaining unknown is:
  - which late bringup branch or retagger between `0x00433130` reload and final kind-`8`
    `0x00432f40` service materializes the live mutation-capable records

## Checked Corpus Counts

- The checked export
  `artifacts/exports/rt3-1.06/compact-event-dispatch-cluster-counts.json`
  now keeps the ordinary `rt3_105/maps` compact-dispatch corpus grounded without re-running the
  wider inspection command.
- Current corpus totals are:
  - `41` maps scanned
  - `38` maps with dispatch-strip rows
  - `318` nondirect compact dispatch-strip rows total
  - `0` rows with recovered trigger kind
  - `10` add-building grouped occurrences across `7` descriptor keys
    (`Barracks`, `Bauxite Mine`, `FarmGrain`, `Furniture Factory`, `Logging Camp`, `Port01`,
    `Warehouse05`)
- The same export now also carries the concrete carrier-map paths directly through
  `add_building_descriptor_map_paths` and
  `add_building_signature_condition_cluster_map_paths`, including:
  - `Texas Tea.gmp` for `548 Add Building Port01`
  - `Louisiana.gmp` for `563 Add Building Warehouse05`
  - `Alternate USA.gmp` for the repeated `FarmGrain` / `Logging Camp` `ge34` family
  - `Chicago to New York.gmp` and `Pacific Coastal.gmp` for the mixed `[-1:4]` cluster
- The widened counts surface now also keeps the strongest full nondirect families visible beyond
  the add-building subset:
  - `dispatch_signature_condition_cluster_occurrence_counts` now shows the broadest checked family
    is `nondirect-ge1e-h0001-0360-0004-0100-0200-p0000-0000-0000-ffff :: [864:4]` at `36`
    grouped occurrences across `18` maps
  - the next family remains the mixed `[-1:4]` cluster at `27` grouped occurrences across `14`
    maps
  - `dispatch_signature_condition_cluster_descriptor_keys` keeps the first cluster grounded on the
    variable/status descriptor family (`Economic Status`, `Game Variable 1..4`,
    `Company Variable 1..4`) and keeps the second cluster grounded on that same family plus the
    two checked add-building descriptors `Barracks` and `Bauxite Mine`
- That keeps the remaining late-bringup/control-lane question narrow:
  - ordinary loaded nondirect rows already reach the `0x00431b20` mutation strip at scale
  - but the missing trigger-kind lane is still the blocker above the already-grounded descriptor
    bridge

## Direct Trigger-Kind Gate

Fresh direct disassembly now keeps that control lane explicit rather than inferred:

- `0x00444d92`
  - calls `0x00432f40` with trigger kind `8`
  - then clears shell-profile latch `[0x006cec7c+0x97]`
- `0x00432f40`
  - iterates the live runtime-effect collection
  - calls `0x004323a0` for each row with the requested trigger kind
  - records whether any row fired
  - if collection flag `[this+0x88]` is raised, reruns the same service loop with trigger kind
    `0x0a`
- `0x004323a0`
  - returns immediately unless `[event+0x81f] == 0`
  - returns immediately unless `[event+0x7ef] == trigger_kind`
  - only after that exact compare does it continue into the compact dispatch body

So the active question is no longer whether the trigger kind is a direct row gate. It is where the
ordinary loaded rows get a nonzero `[event+0x7ef]` that matches the later kind-`8` or follow-on
kind-`0x0a` service.

## Reload-Side Boundary

The ordinary reload strip is bounded in the same negative way now:

- `0x00433130`
  - restores tagged record families `0x4e99`, `0x4e9a`, and `0x4e9b`
  - reads one fixed `4`-byte scalar block through `0x00531150`
  - loops live rows through per-record restore helper `0x0042db20`
  - clears collection flag `[this+0x88] = 0` before returning
- that reload path does not pass any trigger-kind argument analogous to the later
  `0x00432f40(kind)` service

So the remaining late-bringup/control-lane frontier stays between reload and service rather than
inside the already-bounded restore loop itself.

## Current Writer Census

The direct writer set for `[event+0x7ef]` is narrower now too:

- `0x0042d5a0`
  - zero-initializes the live runtime-effect record control band
  - clears `[event+0x7ee]`, `[event+0x7ef]`, `[event+0x7f4]`, `[event+0x81f]`, `[event+0x823]`,
    and `[event+0x82b]`
- `0x0042e11a`
  - straight copy helper over the same control band
  - copies `[event+0x7ee/+0x7ef/+0x7f0/+0x7f4...]` from one live row into another
- `0x00430b50`
  - the already-grounded follow-on runtime-effect builder
  - reaches the fresh live row through `0x00432ea0 -> 0x0042d5a0`
  - then seeds `[event+0x7ef]` to `2` or `3` from the current `[world+0x11]` threshold
  - also sets `[event+0x7f5] = 1`
- `0x00443526` and `0x00443601`
  - the already-grounded late retags to `5` and `2`

So the active periodic-company/control-lane question narrows again:

- ordinary reload `0x00433130 -> 0x0042db20` does not itself pass a trigger kind
- the late service strip gates strictly on `[event+0x7ef]`
- and the currently grounded nonzero seed outside the scenario-name retags is the follow-on
  builder reached from the service/dispatch family rather than from the reload loop itself

## Post-Load Scenario Fixup

- `shell_apply_scenario_name_specific_post_load_world_and_object_fixups` `0x00442c30`
  is called from `0x00443a50` at `0x00444b50`.
- This branch is currently **prose-first**, not graph-first:
  - a direct subgraph export on `0x00442c30` collapses to the seed node
  - the useful evidence lives in the grounded function-map note rather than note-reference edges
- The function-map note grounds several concrete mutations across collections rooted at:
  - `0x0062be18`
  - `0x0062bae0`
  - `0x006ada80`
  - `0x0062b268`

## Explicit Trigger-Kind Retags Already Grounded

- `SP - GOLD` branch at `0x00443526`
  - rewrites `[event+0x7ef]` from `1 -> 5`
  - live runtime-event id `1`
  - gated by `[world+0x66de]`
  - checked payload root kind `7` with subtype byte `5`
- `Labor` branch at `0x00443601`
  - rewrites `[event+0x7ef]` from `0 -> 2`
  - live runtime-event id `0x0d`
  - gated by `[world+0x66de]`
  - checked `0x3c -> 0x3d` child payload pair with the matched negative scalar sentinel

## Current Best Next Recovery Question

- Which late bringup branch between:
  - `0x00433130` reload
  - `0x00442c30` scenario-name post-load fixups
  - and final kind-`8` `0x00432f40`
- is responsible for the live kind-`8` records that already carry mutation-capable compact payloads
  in ordinary nondirect bundles.