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

Add hook debug tooling and refine RT3 atlas

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-08 16:31:33 -07:00
commit 57bf0666e0
38 changed files with 14437 additions and 873 deletions
Download patch file Download diff file Expand all files Collapse all files

85
docs/atlas/company-and-ledger.md
View file

@ -64,7 +64,7 @@ Current bounded compatibility impact:
`0x00408f70`, because that target sums raw site cache `+0x12` rather than the weighted `+0x0e`
or promoted `+0x16` lanes
Highest-value open edge:
Latest finance closure:
- The remaining semantic meaning of the annual finance policy branches is now narrower:
stat-family `0x2329/0x1d` is now bounded as current `Book Value Per Share` in the stock-issue
@ -72,27 +72,80 @@ Highest-value open edge:
bond-rate-versus-support ladder, the broader support-adjusted share-price or public-support lane
is now bounded through `company_compute_public_support_adjusted_share_price_scalar` `0x00424fd0`,
and its immediate feeder is now bounded as
`company_compute_cached_recent_per_share_performance_subscore` `0x004248d0`, which weighs recent
`Revenue Per Share`, `Earnings Per Share`, and `Dividend Per Share` lanes `0x1e/0x1f/0x20`
against current `Book Value Per Share`, while `0x21` now routes through
`company_compute_cached_recent_per_share_performance_subscore` `0x004248d0`, which uses an
explicit recent-history ladder: the current partial year is weighted by `(5 * [world+0x0f]) - 5`,
the prior four full years use `48/36/24/12` for `Earnings Per Share` and `Revenue Per Share`
lanes `0x1f/0x1e`, and the adjacent `Dividend Per Share` non-decline trend comparisons on lane
`0x20` use weights `9/8/7/6`, all before the tail folds those lanes against current `Book Value
Per Share`, while `0x21` now routes through
`company_compute_five_year_weighted_shareholder_return` `0x004246b0` and its paired hidden
shareholder-payout lane `0x23`,
raw slot `0x09` aligns with the Income Statement fuel-cost lane surfaced by tooltip `1309`, and
derived slot `0x2b` now reads as the rolling net-profits lane. The main remaining gap is the
exact weight schedule and gate ordering used inside the already-bounded annual bankruptcy,
debt, repurchase, stock-issue, and dividend branches. The current strongest read is now:
derived slot `0x2b` now reads as the rolling net-profits lane. The exact stock-issue cutoff
ordering is now closed, and the current grounded read is:
bankruptcy = first the year, toggle, and cooldown gates, then the three-year scan, then the
revenue-band-selected cash-and-debt ladder, then the support-adjusted share-price threshold,
then the fuel-cost lane and net-profit accumulator; the later deep-distress fallback then
re-checks cash below `-300000` plus the first three recent profit years at or below `-20000`.
Stock issuance = first the bond/stock toggle gates, then the outstanding-share tranche sizing,
then the `55000` proceeds cap, then the support-adjusted price-to-book screen against the
highest live coupon band. Dividend adjustment = first the toggle and age gates, then the
weighted recent-profit-per-share target, then the small-unassigned-share cash supplement, then
the board ceiling clamp. The remaining gap is now mostly the near-cutoff ordering inside the
stock-issue lane, and the current strongest read places the liquidity gate at `0x2329/0x0d`
before the valuation gate at `0x2329/0x1d`. The dividend-ceiling clamp is already separately
bounded on the dividend branch. That is now a final precedence question, not a missing
ownership gap in the annual finance verbs themselves. The debt-news tail is also now explicit:
Stock issuance = first the bond/stock toggles, live-bond count, and founding-age gates, then
tranche sizing from outstanding shares, then the `55000` proceeds-cap trim, then the pressured
support-adjusted share-price recompute and price-to-book derivation, followed by the tested
gates in fixed order: share-price floor `22`, proceeds floor `55000`, current cash
`0x2329/0x0d` against highest-coupon principal plus `5000`, one later stock-issue cooldown gate
driven by the current issue mixed-radix calendar tuple at `[company+0x16b/+0x16f]` versus the
active world absolute calendar counter `[world+0x15]`, and only then the coupon-versus-price-to-book ladder
`0.07/1.3 .. 0.14/0.35`. Dividend
adjustment = first the toggle and age gates, then the weighted recent-profit-per-share target,
then the small-unassigned-share cash supplement, then the board ceiling clamp. The debt-news tail
is also now explicit:
it compares total retired versus newly issued principal to pick `2882..2886`, and the
stock-buyback tail separately publishes `2887` from the accumulated repurchased-share count.
Current finance closure detail:
- The stock-issue cooldown stamp is now structurally closed:
`[company+0x16b/+0x16f]` holds the current issue calendar-point tuple,
`[company+0x173/+0x177]` preserves the prior tuple,
and the cooldown gate converts the current tuple through `0x0051d3c0` before comparing against
the active world absolute calendar counter `[world+0x15]`. The tuple model is no longer just
“calendar-like”: current local arithmetic now bounds it as the same mixed-radix
`12 x 28 x 3 x 60` family unpacked by `0x0051d460`.
- The recent per-share performance feeder `0x004248d0` is now tighter than before:
its four tail lanes are `EPS * 10`, `Revenue Per Share`, a dividend-strength lane derived from
the weighted non-decline ratio on slot `0x20`, and current `Book Value Per Share` from slot
`0x1d`; base lane weights are `40/10/20/30`, startup companies ramp those weights with the
age table `0/0/0/100 -> 25/25/35/100 -> 50/50/65/100 -> 75/75/85/100 -> 100/100/100/100`,
the strongest lane is boosted by `1.25` while the weakest is reduced by `0.8`, the bounded
intermediate `[company+0x0d19]` uses `((difficulty + 1.0) / 2.0)` with a floor at `0.5`,
and the final cached score uses the raw difficulty table
`0.8/0.9/1.0/1.1/1.2/0.9/0.95/1.0` plus the post-bankruptcy smoothing factor.
- The broader support-adjusted share-price consumer `0x00424fd0` is tighter now too:
it starts from that recent per-share feeder, can interpolate it against the older support field
`[company+0x57]` on the young-company path using one capped progress term from
`[world+0x15]`, `[company+0x0d07]`, and founding year `[company+0x157]`, clamps the caller's
share-count pressure term to `[-0.2, 0.2]`, can refresh mutable support field `[company+0x4f]`
from that staged pressure, derives one share-count growth term from `(shares / 20000)^0.33`,
then runs the resulting support scalar through the later threshold ladder
`0.6 / 0.45 / 0.3 / 1.7 / 2.5 / 4.0 / 6.0` before multiplying by scenario issue `0x37` and
rounding into the cached share-price lane `[company+0x0d7b]`.
- The surrounding finance issue split is now much tighter:
`0x00425320` is the bounded company `Credit Rating` score used by the shell debt summary and the
bond-offer rejection path on localized id `974`, with raw issue slot `0x38` folded in at the
tail; `0x00424580` is the explicit `Prime Rate` lane fed by raw issue slot `0x39`; and
`0x00424fd0` then multiplies the equity-side share-price scalar by issue slot `0x37`.
So the strongest current read is:
`0x38 = debt-market / creditworthiness`,
`0x39 = prime-rate / market-rate pressure`,
`0x37 = broader equity-market / investor confidence in company or chairman performance`.
- The raw formula side is now mostly closed, and what remains is mostly whether RT3 exposed one exact
UI caption for issue `0x37` beyond the already-grounded investor-performance strings. The
negative results now sharpen that last edge too: the nearby `0x460a90` / `0x473620`
registration blocks are camera-view and related shell-command families, not finance issue
owners; and the editor-side `Stock Prices` label belongs to a separate float-tuning block
`[state+0x0bde..0x0bf6]`, not the issue table behind `0x37`. The shell-resource side is now
tighter too: extracting `CompanyDetail.win` from `rt3_2WIN.PK4` did not uncover any separate
plain-English finance caption or investor label for this lane, and the recovered shell owner path
already routes section-0 through the dynamic-text widget `0x947f` plus formatter
`shell_format_company_governance_and_economy_status_panel` `0x004e5cf0`. So the strongest
current UI-facing text for issue `0x37` remains the investor-attitude sentence family
`1217` and `3048/3049`, not one standalone caption row like `Credit Rating:` or `Prime Rate:`.

28
docs/atlas/editor-and-site-service.md
View file

@ -34,7 +34,10 @@ Current grounded runtime chain:
- `placed_structure_refresh_local_service_score_bundle`
- `placed_structure_query_candidate_local_service_metrics`
- `placed_structure_count_candidates_with_local_service_metrics`
- `placed_structure_get_nth_candidate_id_with_local_service_metrics`
- `placed_structure_query_cached_express_service_class_score`
- `placed_structure_refresh_candidate_local_service_comparison_cache_against_peer_site`
- `placed_structure_select_best_candidate_id_by_local_service_score`
Current grounded shell-side consumers:
@ -51,14 +54,19 @@ What this note is for:
- Per-site local service tables and caps
- Station-detail and station-list read-side summaries
Highest-value open edge:
Resolved edge:
- The deeper gameplay meaning of the per-site local service tables is now mostly about whether
those scores stay confined to placement, overlay, and station-summary presentation through the
query helpers, or whether the same query outputs also feed live cargo-economy filter flags,
per-site service-cap rebuilds, or nearby-structure behavior beyond the currently bounded shell
summaries. The grounded chain strongly suggests the read-side path is dominant, the query
helpers themselves still read as read-only consumers, and the only grounded mutation bridge is
the collection-wide cargo-economy filter refresh. The remaining open question is whether that
filter refresh is the full policy sink for the local service tables or whether an additional
mutation-side writer exists outside the local corpus.
- The per-site local service query family is now bounded as predominantly read-side. Above the
mutation and rebuild lane, the grounded helpers are:
`placed_structure_query_candidate_local_service_metrics`,
`placed_structure_count_candidates_with_local_service_metrics`,
`placed_structure_get_nth_candidate_id_with_local_service_metrics`,
`placed_structure_query_cached_express_service_class_score`,
`placed_structure_refresh_candidate_local_service_comparison_cache_against_peer_site`, and
`placed_structure_select_best_candidate_id_by_local_service_score`.
- Their grounded callers are shell summaries, shell detail rows and popups, the world preview
overlay, one company-side autoroute score cache rebuild, and one peer-site comparison cache.
None of the newly closed callers acts as a policy writer back into candidate or site state.
- The only grounded mutation bridge on this edge remains
`structure_candidate_collection_refresh_cargo_economy_filter_flags`, which writes the derived
enabled or filtered state into `[entry+0x56]` before rebuilding the visible counts.

100
docs/atlas/multiplayer.md
View file

@ -31,9 +31,9 @@ What this note is for:
- GameSpy-facing callback and live-route semantics
- Selector-view refresh, retry, and probe state
Highest-value open edge:
Latest local closure:
- The remaining multiplayer edge is narrower now:
- The remaining multiplayer branch is narrower now:
the status-route callback vector is bounded through selector-text or averaged-sample publication,
control-id-list seeding, scalar-query forwarding, and the validated cookie or extended-payload
callbacks. The selector-view sidecar is tighter too: `[entry+0x80]` now reads as the averaged
@ -49,6 +49,10 @@ Highest-value open edge:
`0x5906f0` tears down the decoded schema dictionary rooted at `[this+0x08]`, `0x590540/0x5905a0`
acquire and release refcounted shared schema strings through the global pool, and `0x5908c0`
now reads as the live receive/decode state machine serviced by `0x591290` in table states `2/3`.
The owner-callback mode split above that runtime is tighter now too: mode `0` comes from the
generic append-notify lane `0x590370`, mode `1` from compact upsert `0x590d00`, mode `2` from
generic remove-notify `0x590430`, and modes `6/5/3` from the receive/decode state machine
`0x5908c0`.
The higher transport bring-up split is tighter too: `0x596090` now clearly constructs
`[transport+0xba4]` through `0x5905e0` with owner callback `0x595a40`, then seeds the local
field-cache family `[transport+0x1724]` through `0x5a08f0` with helper `0x595b60`, and then
@ -83,15 +87,31 @@ Highest-value open edge:
`+0x0c/+0x10/+0x18` metadata triplet and the replay modes later consume the pointer through
`0x5933a0`. The negative result is stronger too: local text-side xrefs still show no direct
store to `[transport+0x1778]`, and a wider sweep also failed to show any obvious `lea`-based
replay-band writer. So the sidecar writer remains upstream of this leaf capacity publisher. The
replay-band writer. The owned request lifecycle now tightens that further too:
`0x593330/0x593370/0x593380/0x5934e0/0x5933a0` fully own `[transport+0x1780]`, `0x1784`, and
`0x1788`, while still leaving `[transport+0x1778]` outside that family; the neighboring active
opcode reset path `0x5929a0` also only targets `[transport+0x17fc]`. Constructor and teardown
passes around `0x596090/0x5961b0/0x5962e0` tighten that negative result further: those owners
seed or clear the neighboring replay-band fields while still leaving `[transport+0x1778]`
untouched. A full-binary literal-offset sweep tightens it further still: the only direct
`0x1778` hit in `RT3.exe` is the read in `0x595bc0`. One nearby ambiguity is now closed too: the
mode-`5` mirror path in `0x595a40` and `0x595e10` does not seed `[transport+0x1778]`; it writes
`[transport+0x54]` and mirrors the same staged route companion dword only into queue-side slot
`[transport+0x1724+0x24]` through `0x005a0940`. So the sidecar writer remains upstream of this
leaf capacity publisher. The
payload split is tighter too:
`0x592ae0` now grounds opcode `2` as a seven-dword descriptor payload with an owned string slot
at `+0x08`, so live mode supplies a populated payload while modes `3` and `5` deliberately
enqueue an all-zero payload and reuse only the sidecar metadata in the wrapper. Those two modes
are tighter now too: they are not generic replay guesses, they are the live receive-state owner
callbacks emitted by `0x5911e0 -> 0x5908c0`. So they are best read as delayed metadata replays
over one cached work record, not over a standalone custom cache object. The producer side is
tighter now too: callback-table attach,
over one cached work record, not over a standalone custom cache object. The capacity owner split
itself is tighter now too: `0x595bc0` only does real work for modes
`0`, `3`, and `5`; the upstream table still delivers modes `1`, `2`, and `6`, but those are
explicit no-ops in the capacity leaf. So the callback-owner edge is now effectively closed: the
route-callback table feeds the capacity publisher only through the live append lane and the two
replay lanes, while the remaining missing piece is still the upstream sidecar producer, not the
owner-mode wiring. The producer side is tighter now too: callback-table attach,
bound-route requests, selector-text route requests, and the type-`9` text fastpath all stage
that same `+0x0c/+0x10/+0x18` triplet through `0x5934e0`, so the capacity replay sidecar is
clearly reusing one broader transport work-record family. The generic owner-callback split above that family is tighter now
@ -125,34 +145,52 @@ Highest-value open edge:
`0x5904d0` family, not a vague collection clear.
The callback-table attach side now
constrains the same work-record metadata family a little further too: `0x593650` deliberately
duplicates one caller metadata dword into both work fields `+0x0c` and `+0x18`, while preserving
the remaining caller callback function pointer in `+0x10`. The lower opcode wrappers are tighter
now too: both `0x592a40` and `0x592a70` consume that staged triplet in the order `( callback fn
+0x10, callback companion +0x18, drain context id +0x0c )`. So the replay-side triplet is
clearly a broader transport callback-wrapper family, not one fixed route-only tuple. The type-`9`
text fastpath confirms the same split from the other side too: `0x593d00` only emits the
follow-on callback lane when work field `+0x10` is nonnull, and then forwards `(+0x10, +0x18,
+0x0c)` into `0x593170` as callback function, callback companion, and trailing drain context.
duplicates its first caller metadata dword into both work fields `+0x0c` and `+0x10`, while
carrying the second caller metadata dword in `+0x18`. The lower opcode wrappers are tighter now
too: `0x592a40` turned out not to be the real 0x08-byte binding leaf at all, but the explicit
opcode-`1` trigger wrapper whose constructor is a no-op and whose active-side service is
`0x5913c0`. The real lower binding leaf is `0x592c40`, which builds the local `0x08`-byte
payload later deep-copied by the explicit opcode-`5` family `0x591540/0x591570/0x591580`. The
earlier opcode-`4` reading was just the table-indexing mistake: `0x5928a0` multiplies the pushed
selector by `0x10`, so selector `4` lands on the row at `0x5e2044`, not the row at `0x5e2034`.
So
the replay-side triplet is still a broader transport callback-wrapper family, not one fixed
route-only tuple. The type-`9` text fastpath confirms the same split from the other side too:
`0x593d00` only emits the follow-on callback lane when work field `+0x10` is nonnull, and then
forwards `(+0x10, +0x18, +0x0c)` into `0x593170` as callback function, callback companion, and
trailing drain context.
The nearby field-subscription side is tighter too: `0x592b50` now clearly uses
`[transport+0x1774]` as a cached progress percentage under the `[transport+0xba4]` callback
table, and `0x5962e0` seeds that percentage to `1` just before the first immediate mode-`3`
snapshot. The nearby route-callback-table lifecycle is tighter now too: `0x596090` seeds
`[transport+0xba0]` as the callback-plumbing enable latch, clears staged payload slot
`[transport+0xb50]`, and constructs the three owner branches rooted at `[transport+0xba4]`,
`[transport+0x1164]`, and `[transport+0x18bc]`. The matching local cleanup is tighter too:
`0x5962c0` is the explicit staged route-callback payload clear on `[transport+0xb50]`, while
`0x595ce0` now clearly resets only the capacity-descriptor route callback table at
`[transport+0x1164]`, not the field-subscription table at `[transport+0xba4]`. The only
meaningful gap left on the capacity side is the still-unrecovered writer that stages
`[transport+0x1778]`. The carried sidecar fields are no longer anonymous: current evidence now
says they are just the same cached callback-wrapper triplet reused by other work-record families,
namely drain context id `+0x0c`, callback function `+0x10`, and callback companion `+0x18`.
The negative result is stronger now too: the neighboring replay-band fields
`[transport+0x176c]`, `[transport+0x1770]`, `[transport+0x1774]`, `[transport+0x177c]`,
`[transport+0x1780]`, and `[transport+0x1784]` all have direct local lifecycle owners, but
`[transport+0x1778]` still only appears as the single read in `0x595bc0`. So this is no longer
a local ownership gap: no local writer is grounded, and the remaining staging path is best read
as upstream and indirect rather than one ordinary direct field store in the local text cluster.
`[transport+0x1164]`, and `[transport+0x18bc]`; `0x596210` is the recurring service sweep over
those same three tables plus the local field-cache and queued-descriptor families; `0x596060`
is the explicit `gsi_am_rating` reset; and `0x596530` is the reopen-from-stored-label sibling
above that same am-rating table. The matching local cleanup is tighter too: `0x5962c0` is the
explicit staged route-callback payload clear on `[transport+0xb50]`, while `0x595ce0` now
clearly resets only the capacity-descriptor route callback table at `[transport+0x1164]`, not
the field-subscription table at `[transport+0xba4]`. The only meaningful gap left on the
capacity side is no longer a local writer search. The carried
sidecar fields are no longer anonymous: current evidence now says they are just the same cached
callback-wrapper triplet reused by other work-record families, namely drain context id `+0x0c`,
callback function `+0x10`, and callback companion `+0x18`. The negative result is stronger now
too: the neighboring replay-band fields `[transport+0x176c]`, `[transport+0x1770]`,
`[transport+0x1774]`, `[transport+0x177c]`, `[transport+0x1780]`, and `[transport+0x1784]` all
have direct local lifecycle owners, but `[transport+0x1778]` still only appears as the single
read in `0x595bc0`; even the broader callback-owner lifecycle now skips it while touching those
neighbors, including bring-up `0x596090`, recurring service `0x596210`, am-rating reset/reopen
`0x596060/0x596530`, teardown `0x5961b0`, and field-subscription open `0x5962e0`. The
constructor now closes that negative result further: `0x58dc50` bulk-zeroes the full transport
body and still never seeds `[transport+0x1778]` before later explicit neighbor initialization.
So this edge is now locally closed: no writer is grounded anywhere in `RT3.exe`, and the
remaining staging path is best read as an upstream callback or worker handoff rather than one
missing ordinary field store in the local text cluster. The callback-binding family at
`0x5934e0 -> 0x593650 -> 0x58f2f0` now gives the cleanest local boundary for that claim:
RT3 stages and later consumes the shared work-record metadata triplet, but the sidecar itself
still appears only as a borrowed cached pointer at `0x595bc0`, never as a locally seeded
replay-band field.
One adjacent staged-route callback is
tighter now too: `0x595860` is the submit-result handler below
`0x5958e0`, using the already-grounded third selector-generation counter at `[transport+0xac0]`
@ -212,10 +250,10 @@ Highest-value open edge:
gate and the same queued fallback, mode `2` removes pending descriptors from the queued family,
mode `3` forces mode `2` when the primary-endpoint table is empty, mode `4` updates the deferred
route-status state around `[this+0x1ed4]` and `[this+0x1ed8]`, and mode `5` copies the staged
route companion dword at `[this+0x490]` into `[this+0x54]` while mirroring that value into the
local field-cache family. The route-event dispatcher side is cleaner too:
route companion dword at `[this+0x490]` into `[this+0x54]` while mirroring that value into
queue-side slot `[this+0x1724+0x24]` through `0x005a0940`. The route-event dispatcher side is cleaner too:
the mode-`5` tails in both callback families do not copy a descriptor-local field. They mirror the
transport-staged companion dword at `[this+0x490]` into `[this+0x54]` and the local field-cache
family instead. The `gsi_am_rating` maintenance lane is tighter now too: it sorts the
transport-staged companion dword at `[this+0x490]` into `[this+0x54]` and that same queue-side
slot instead, not into `[this+0x1778]`. The `gsi_am_rating` maintenance lane is tighter now too: it sorts the
primary-endpoint descriptor table through `0x590310` in mode `1` with key `gsi_am_rating`, then
selects the new head through `0x590480` rather than treating the table as pure insertion order.

28
docs/atlas/route-entry-and-trackers.md
View file

@ -125,17 +125,19 @@ What this note is for:
- Route-style peer-link emission and route-link state
- Track-laying-capacity interactions with route synthesis
Highest-value open edge:
Latest local closure:
- The remaining semantic edge here is now mostly about ranking, not company pressure:
the pre-`1.03` versus `1.03+` tracker metric split still looks meaningful for the weighted
linked-transit site-score cache at `company_rebuild_linked_transit_autoroute_site_score_cache`
`0x00407bd0` and the seeded peer-route chooser at `company_build_linked_transit_autoroute_entry`
`0x00408380`, but current evidence says the company train-pressure target still sums raw site
cache `+0x12` rather than the weighted lanes fed by step count and continuity. The lower
route-entry pair metric still has other grounded consumers such as the initial route sweep and
the train route validator through `0x004a6630`, but no downstream consumer of the cached weighted
site lanes `+0x0e/+0x16` is currently grounded beyond the autoroute selector `0x00408280` and
builder `0x00408380`. So the remaining question here is no longer about current local ownership;
it is only whether some still-ungrounded consumer outside the current corpus also reads those
cached weighted lanes.
- The linked-transit cache split is now locally bounded rather than just suggestive:
the pre-`1.03` versus `1.03+` tracker metric dispatcher still matters for the weighted
autoroute cache lanes at `company_rebuild_linked_transit_autoroute_site_score_cache`
`0x00407bd0`, but the grounded downstream chain now stops at route choice rather than company
pressure. Cache lane `+0x16` feeds the owned-site selector
`company_select_best_owned_linked_transit_site_by_autoroute_score` `0x00408280`, and the
weighted peer-side bands then feed `company_build_linked_transit_autoroute_entry`
`0x00408380`; train-side append and add-train helpers `0x00409770` and `0x00409830` only
inherit that weighted choice by calling the builder. By contrast, the company-wide roster target
at `company_compute_owned_linked_transit_site_score_total` `0x00408f70` still sums only raw
cache `+0x12` before `company_balance_linked_transit_train_roster` `0x00409950` reacts. So this
local semantic edge is effectively closed: the compatibility split perturbs ranked site choice
and seeded autoroute peer choice, not the later train-count target, and any further
weighted-lane consumer would have to live outside the currently grounded local chain.

13
docs/atlas/runtime-and-world-tools.md
View file

@ -129,12 +129,11 @@ What this note is for:
- Track-lay and station-placement semantics
- Train detail and trainbuy command ownership
Highest-value open edge:
Current bounded conclusion:
- Whether any later gameplay-owned mode introduces a distinct input or frame owner for ordinary
world interaction, or whether the grounded `shell_controller_window_message_dispatch` plus
- Current evidence points to one stable reading: no later gameplay-owned mode introduces a distinct
outer input or frame owner for ordinary world interaction. The grounded
`shell_controller_window_message_dispatch` plus
`simulation_frame_accumulate_and_step_world` path remains the sole coordinator after world
entry and the first grounded non-camera world-input coordinator. Current evidence now points
strongly to the second reading: the shell-fed input and frame path remains the only grounded
coordinator after world entry, and no separate outer gameplay loop or gameplay-only input object
is grounded in the local corpus.
entry and the first grounded non-camera world-input coordinator, and no separate outer
gameplay loop or gameplay-only input object is grounded in the local corpus.

6
docs/atlas/startup-shell-and-content.md
View file

@ -28,7 +28,7 @@ What this note is for:
- File-flow and content-load boundaries
- World bring-up versus shell-owned cadence questions
Highest-value open edge:
Current bounded conclusion:
- Whether any long-lived gameplay cadence later escapes the bootstrap-owned shell service loop
entirely, or only nests under it.
- No later long-lived gameplay cadence is currently grounded outside the bootstrap-owned shell
service loop; the local evidence still supports the nested-under-shell reading.