- Keep the periodic-company trace as the main shellless simulation frontier, with the next concrete control-lane pass focused on the ordinary loaded runtime-effect strip `0x00444d92 -> 0x00432f40(kind 8) -> 0x004323a0 -> 0x00431b20`.
The checked `rt3_105/maps` compact-dispatch corpus is now exported directly and partially mirrored into the periodic-company trace: `41` maps scanned, `38` with dispatch-strip rows, `318` nondirect rows total, the add-building subset is only `10` grouped occurrences across `7` descriptor keys, and the strongest broader nondirect families are now bounded too at `36` grouped occurrences across `18` maps for `nondirect-ge1e-h0001-0360-0004-0100-0200-p0000-0000-0000-ffff :: [864:4]` plus `27` across `14` maps for the mixed `[-1:4]` cluster. All of those checked rows still lack recovered trigger kind. The packed-state bridge is narrower than that queue head used to allow too: `0x0042db20/0x00430d70` rebuild and serialize only the fixed text bands plus the standalone and grouped row lists, while the metadata band `+0x7ee..+0x80e` is only mirrored by deep-copy helper `0x0042e050`. The active open question is therefore which ordinary loaded rows acquire or bypass the missing trigger-kind control lane before they can reach placed-structure mutation opcodes.
The dispatcher-side caller census is wider in a way that makes the remaining blocker sharper: `0x00432f40` is already driven shelllessly for kinds `1/0/3/2` and then `5/4` from the recurring simulation-maintenance strip `0x0040a220..0x0040a9ac`, for kind `7` from the grounded company-startup family, and for kind `6` from the placed-structure post-create, startup-refresh, and route-entry post-change tails, while `LoadScreen.win` still owns kind `9`. So the missing piece is no longer “find another shellless dispatcher entrypoint.” It is why ordinary loaded rows still fail to present a matching nonzero `[event+0x7ef]` when the later world-entry one-shot at `0x00444d92` requests kind `8`.
The largest direct writer table is ruled out now too: `0x004d8ea0` is the shell-side `EventConditions.win` commit helper, where controls `0x4e98..0x4ea2` write `[event+0x7ef] = 0..10` on the currently selected live event, so that seed family does not explain shellless post-load bringup.
The broad scenario-name fixup owner is narrower in the same direction: `0x00442c30` really does mutate live event rows after reload, but its grounded trigger-kind writes still only retag `1 -> 5` and `0 -> 2`, while the surrounding event-side branches only patch modifier bytes or nested payload dwords under already-existing kinds. No grounded branch there seeds kind `8`.
The metadata-copy helper is ruled out in the same way: `0x0042e050` really does clone `[event+0x7ef]`, but the current whole-binary caller search still finds only the shell-side selected-event clone path `0x004db8b0`, not any shellless post-load or periodic caller.
The direct write census is tighter in the same direction: the only grounded explicit write of value `8` into `[event+0x7ef]` is `0x004d91b3` inside that same shell helper, while the runtime-side grounded writers still only cover zero-init, copy, `2/3` follow-on seeds, and the later `5` / `2` retags.
Static progress on this head now appears genuinely blocked: the whole-binary `[...+0x7ef]` reference census still collapses to that same grounded writer set plus the already-known compare and copy helpers, so the next honest step likely requires hook-side or runtime tracing between reload `0x00433130` and the world-entry kind-`8` sweep at `0x00444d92`.
The grounded owner strip is `0x004196c0 -> 0x00414490 -> 0x00416ce0 -> 0x00419230`, and the checked candidate-table exports now keep the concrete scenario-side families explicit too: among the `37` probe-bearing maps, `Port00/Warehouse00` stay at `35/43` on `30` maps and shift earlier to `10/18` on `7`, while `Port01..11` / `Warehouse01..11` stay fixed at `45..55` / `56..66` and the numbered trailer family splits independently at `0x00000001 -> 28 maps` versus `0x00000000 -> 9 maps`. The new crossover matrix stays mixed rather than collapsing to one side too: `35/43 :: 0x00000001 -> 25 maps`, `35/43 :: 0x00000000 -> 5 maps`, `10/18 :: 0x00000000 -> 4 maps`, and `10/18 :: 0x00000001 -> 3 maps`. The checked header-cluster export keeps the same root scan bounded to only `3` families: `0x00000000 / 0x00000000 -> 27 maps`, `0xcdcdcdcd / 0xcdcdcdcd -> 9 maps`, and `0x10000000 / 0x00009000 -> 1 map` (`Alternate USA.gmp`). The load-side handoff is narrower now too: `0x004120b0` explicitly reads `[candidate+0xba]` and `[candidate+0xbb]` as one-byte stream fields, and the very next projection owner `0x00412d70` immediately consumes those bytes in two passes, first `+0xba` and then `+0xbb`, to pick one seed row whose full `0x1f2`-dword body will be cloned or reused for each numbered runtime record. The stock decode side is narrower in the same direction: `0x00414490` does not just copy the `0xb8..0xbb` tail, it already derives the optional plane size from `[record+0xb8] * [record+0xb9] << 5` and uses the high nibble of `[record+0xba]` while materializing the four optional plane buffers at `[record+0xcf/+0xd3/+0xd7/+0xdb]`, before `0x00416ce0` remaps only the bare `port` / `warehouse` names and the later `0x00419230` rebank-or-clone pass consumes any bank-qualified owners. The same static pass rules out one lingering false lead too: the earlier suspected `0x00414500..0x00414b14` replay strip is not a separate serializer or import family at all, just the interior plane-decode band of `0x00414490`. The stock `BuildingTypes` corpus is narrower too: across `77` checked `.bca` files only `MachineShop.bca` carries nonzero selector bytes at `0xb8..0xbb`, while the broader nonzero stock signal lives in the `22`-file `.bty` alias-root family with `dword_0xbb = 0x000001f4`, especially the `TextileMill` branch that already covers `Port.bty` and `Warehouse.bty`. The active open question is therefore which later seed or projection seam turns that already-decoded stock-side shape or selector state together with the fixed numbered cluster into nonzero live `[candidate+0xba/+0xbb]` before `0x00412d70` and `0x00419230` consume it.
Static progress on this head is close to the same boundary now: the stock decode chain, the bare-name remap callback, the rebank-or-clone owner, and the earlier suspected mid-range replay strip are all grounded, so the next honest step likely requires runtime tracing of which source rows actually enter the live bank-qualified seed set.
