rrt/docs/rehost-queue.md

Rehost Queue

Working rule:

• Do not stop after commits.
• After each commit, check this queue and continue.
• Only stop if the queue is empty, the remaining work cannot be advanced by any further non-hook work without guessing, or you need approval.
• Before any final response, state which stop condition is true. If none is true, continue.

Next

• Use the higher-layer probes as the standard entry point for the current blocked frontier instead of generic save scans: runtime inspect-periodic-company-service-trace <save.gms>, runtime inspect-region-service-trace <save.gms>, and runtime inspect-infrastructure-asset-trace <save.gms>.

• Follow the new higher-layer probe outputs instead of another blind save scan: runtime inspect-infrastructure-asset-trace <save.gms> now shows that the 0x38a5 infrastructure-asset seam is grounded and the old alias hypothesis is disproved on q.gms, so the next placed-structure slice should target the consumer mapping above that seam rather than more collection discovery; the same trace now also carries atlas-backed candidate consumers (0x0048a1e0, 0x0048dd50, 0x00490a3c, 0x004559d0, 0x00455870, 0x00455930, 0x00448a70/0x00493660/0x0048b660, 0x004133b0) plus bridge/tunnel/track-cap name-family counts, so the next pass can start at those concrete owners instead of the whole placed-structure family.

• Rehost or bound the next concrete Infrastructure consumer above 0x38a5 instead of treating “consumer mapping missing” as a stop: start with the checked-in candidate strip 0x0048a1e0, 0x0048dd50, 0x00490a3c, 0x004559d0, 0x00455870, 0x00455930, 0x00448a70/0x00493660/0x0048b660, 0x004133b0, and narrow that list to the first true shellless owner that consumes the side-buffer seam. The infrastructure trace now ranks the current best hypothesis as the child attach/rebuild strip (0x0048a1e0, 0x0048dd50, 0x00490a3c), with the serializer/load companions next and the route/local-runtime follow-on family explicitly secondary.

• For that top-ranked infrastructure strip, treat the next pass as three exact owner questions rather than a general “map the consumer” task: whether the 0x38a5 compact-prefix/name-pair groups feed the first-child triplet clone lane, the caller-supplied payload-stem lane, or only a later route/local-runtime refresh lane; which child fields or grouped rows absorb the side-buffer payload before 0x00448a70/0x00493660/0x0048b660 become relevant; and, now that the direct route-entry bridge helpers over [this+0x206/+0x20a/+0x20e] are grounded, which later route/local-runtime owner still carries the remaining mixed exact classes once cached primary-child slot [this+0x248] is demoted to child-list cache/cleanup state.

• Targeted disassembly now tightens that strip further: 0x0048a1e0 clones the first child through 0x0052e880/0x0052e720, destroys the prior child, seeds a literal Infrastructure child through 0x00455b70 with payload seed 0x005c87a8, and republishes the two sampled bands through 0x0052e8b0/0x00530720 after attaching through 0x005395d0; the non-clone branch attaches through 0x0053a5d0. So the next unknown is no longer whether this strip owns the child/rebuild seam, but which 0x38a5 compact-prefix groups drive the clone-vs-payload choice.

• The outer rebuild owner is tighter now too: 0x0048dcf0 reads a child count plus optional primary-child ordinal from the tagged stream through 0x00531150, zeroes [this+0x08], dispatches each fresh child through 0x00455a50 -> vtable slot +0x40, culls ordinals above 5, and restores cached primary-child slot [this+0x248] from the saved ordinal. That means the child/rebuild loop is consuming an already-materialized child stream rather than parsing the 0x38a5 compact-prefix seam directly.

• The upstream handoff is grounded now too: 0x00493be0 is the tagged collection load owner over 0x38a5/0x38a6/0x38a7, and it feeds each live infrastructure record straight into 0x0048dcf0 after restoring one shared owner-local dword into the 0x90/0x94 lane. So the remaining infrastructure question is no longer whether 0x38a5 reaches the child-stream restore path at all. Direct disassembly now also shows 0x00518140 resolving a non-direct live entry by tombstone bitset and then returning the first dword of a 12-byte row from [collection+0x3c], while 0x00518680 loads that non-direct table family before 0x00493be0 starts iterating, and 0x00493be0 itself now reads as an ordinal-to-live-id-to-payload-pointer walk through 0x00518380(ordinal, 0) then 0x00518140(live_id). So the next infrastructure question is no longer “which row owns the payload pointer?”. Direct disassembly of 0x005181f0/0x00518260 now also treats those 12-byte rows as a live-entry directory with (payload pointer, previous live id, next live id), so the next infrastructure question is only how those payload streams align with the embedded 0x55f1 name-pair groups and compact-prefix regimes, and which tagged values inside each payload stream become the child count, optional primary-child ordinal, and per-child callback sequence that 0x0048dcf0 consumes. Direct disassembly now also shows the shared child payload callback 0x00455fc0 opening 0x55f1 -> 0x55f2 -> 0x55f3, parsing three 0x55f1 strings through 0x00531380, seeding the child through 0x00455b70, and then dispatching slot +0x48; the widened save-side probe currently sees 0 third 0x55f1 strings on grounded q.gms. That now looks less like a probe failure and more like an ordinary fallback path, because direct disassembly of 0x00455b70 stores the three payload strings into [this+0x206/+0x20a/+0x20e], defaulting the second lane through a fixed literal when absent and defaulting the third lane back to the first string when absent. So the next pass should stay focused on payload-stream grouping and tagged value roles, not on rediscovering a missing third-string encoding.

• The child loader identity is tighter now too: local .rdata at 0x005cfd00 proves the Infrastructure child vtable uses the shared tagged callback strip directly, with +0x40 = 0x00455fc0, +0x44 = 0x004559d0, +0x48 = 0x00455870, and +0x4c = 0x00455930. Direct disassembly of 0x004559d0 then shows the concrete write-side chain for the child payload: write 0x55f1, serialize string lanes [this+0x206/+0x20a/+0x20e], write 0x55f2, dispatch slot +0x4c, run 0x0052ec50, and close 0x55f3. So the remaining infrastructure frontier is no longer “which slot does 0x00455a40 jump to?”; it is which chooser/seed values reach those string lanes and the trailing footer path.

• That source side is narrower now too: direct disassembly shows the paired chooser siblings calling 0x00490960 directly beside 0x0048a340/0x0048f4c0/0x00490200, and 0x00490960 copies selector fields into the child object ([this+0x219], [this+0x251], bit 0x20 in [this+0x24c], and [this+0x226]), allocates a fresh 0x23a Infrastructure child, seeds it through 0x00455b70 with caller-supplied stem input plus fixed literal Infrastructure at 0x005cfd74, attaches it through 0x005395d0, seeds position lanes through 0x00539530/0x0053a5b0, and can cache it as primary child in [this+0x248]. The remaining problem is no longer “where do the child payload lanes come from?” but “which chooser branches feed 0x00490960 which caller stem and selector tuple for each grounded save-side class?”.

• One direct branch is grounded now too: the repeated chooser calls at 0x004a2eba/0x004a30f9/0x004a339c all feed 0x00490960 with mode arg 0x0a and stem arg 0x005cb138 = BallastCapDT_Cap.3dp, which means they bypass the selector-copy block at 0x004909e2 and go straight into fresh child allocation/seeding. So the remaining source-side mapping problem is no longer generic BallastCap coverage; it is the other constructor branches, especially the ones with mode < 4 that actually populate the selector-byte copy block.

• The broader mode family is grounded now too. A wider static callsite sweep shows:

  • mode 0x0b with fixed TrackCapDT_Cap.3dp / TrackCapST_Cap.3dp
  • mode 0x03 with OverpassST_section.3dp
  • mode 0x02 with decoded tunnel table stems plus zero-stem fallbacks
  • mode 0x01 with decoded bridge table stems plus zero-stem fallbacks

  The current grounded q.gms name corpus now also maps directly onto most of those families: BridgeSTWood_Section.3dp -> mode 0x01, TunnelSTBrick_* -> mode 0x02, BallastCapST_Cap.3dp -> mode 0x0a, and TrackCapST_Cap.3dp -> mode 0x0b, with only Overpass still static-only in the current save corpus.

  So the remaining infrastructure question is no longer “what does 0x00490960 build?” or even “which family is this name row?” but “how do the surviving compact-prefix regimes subdivide those already-mapped families, especially inside bridge mode 0x01 and track-cap mode 0x0b?”.

• The direct route-side bridge is grounded now too: 0x0048e140/0x0048e160/0x0048e180 simply resolve [this+0x206/+0x20a/+0x20e] through live route collection 0x006cfca8, and 0x0048e1a0 compares those resolved peers against [this+0x202]. The neighboring 0x0048ed30 path is now also narrower: it only tears down child list [this+0x08], clearing cached primary-child slot [this+0x248] when needed, so [this+0x248] is no longer the first route bridge to chase.

• The later route/local-runtime follow-on family is tighter now too: 0x00448a70 is a world-overlay helper over [world+0x15e1/+0x162d], 0x00493660 is a counter-plus-companion- region follow-on keyed by [child+0x218], [child+0x226], [child+0x44], and 0x0048dcb0, 0x0048b660 is a presentation-color/style owner over [child+0x216/+0x218/+0x226/+0x44] and bit 0x40 in [child+0x201], and 0x0048e2c0/0x0048e330/0x0048e3c0 now read as flag / route- tracker / region-test helpers rather than hidden payload decoders. So the next infrastructure slice should stay focused on the remaining mixed exact compact-prefix classes and earlier child-stream semantics, not on rediscovering the already-bounded presentation owners.

• The new probe correlation now makes that residual even more concrete: on grounded q.gms, the dominant mixed 0x0001/0xff class splits as bridge:62 / track_cap:21 / tunnel:19, while the pure 0x0002/0xff class is all bridge and the pure 0x0055/0x00 class is all ballast-cap. So the next infrastructure slice should focus on subdividing the mixed one-child 0x0001/0xff class rather than revisiting the already-grounded pure classes.

• The sibling 0x00490200 is tighter now too: it reads the seeded lanes [this+0x206/+0x20a/+0x20e] back through the live route collection at 0x006cfca8, compares them against the current owner using [this+0x216/+0x218/+0x201/+0x202], and behaves like a route/link comparator layered above the same child payload lanes that 0x004559d0 later serializes. So the next infrastructure pass should treat 0x00490960 as the source owner and 0x00490200 as a consumer of the same seeded lanes, not as separate unexplained seams.

• The smaller helper 0x00490a3c is narrower now too: it allocates one literal Infrastructure child, seeds it through 0x00455b70 with caller-provided stem input, attaches it through 0x005395d0, seeds position lanes through 0x00539530/0x0053a5b0, and optionally caches it as the primary child. So the next concrete infrastructure question is which upstream owner maps the direct 0x38a5 rows into the child count, primary-child ordinal, and per-child payload callbacks consumed by 0x0048dcf0, and which restored child fields still retain those embedded name-pair semantics before route/local-runtime follow-ons take over.

• The save-side 0x38a5 probe is now tighter at the payload-envelope level too: grounded q.gms shows all 138 embedded 0x55f1 rows already live inside complete 0x55f1 -> 0x55f2 -> 0x55f3 envelopes before the next name row, every embedded 0x55f2 chunk is the fixed 0x1a bytes that 0x00455fc0 expects, and the dominant embedded 0x55f3 payload-to-next-name span is the short 0x06-byte form across 72 rows. So the next infrastructure pass should stop asking whether the shared tagged callback sequence is present at all and instead decode the short 0x55f3 payload role and its relation to the compact-prefix regimes and primary-child restore path.

• That short trailing lane is tighter now too: direct disassembly of 0x0052ebd0/0x0052ec50 shows the post-+0x48 helper pair loading and serializing two single-byte lanes that fold into bits 0x20 and 0x40 of [this+0x20], and the save-side probe now shows the dominant 0x06-byte rows all carrying the same grounded flag pair 0x00/0x00 on q.gms. So the next concrete infrastructure question is no longer “is there a short trailing flag lane?”; it is how the compact-prefix regimes and those flag-byte pairs feed the child-count / primary-child restore state above 0x0048dcf0.

• The fixed 0x55f2 lane is tighter now too: direct disassembly of 0x00455870/0x00455930 shows the +0x48/+0x4c strip loading and serializing six u32 lanes from the fixed 0x1a chunk, forwarding them through 0x00530720 and 0x0052e8b0. Grounded q.gms probes now show every embedded 0x55f2 row using the same trailing word 0x0101 while those six dword lanes vary by asset row. So the next infrastructure question is no longer whether 0x55f2 is a fixed-format child lane; it is which of those two dword triplets correspond to child-count / primary-child restore state and which only seed published anchor or position bands.

• That split is tighter now too: direct disassembly of 0x00530720/0x0052e8b0 shows the first fixed 0x55f2 triplet landing in [this+0x1e2/+0x1e6/+0x1ea] and the second in [this+0x4b/+0x4f/+0x53], with the companion setter also forcing bit 0x02. So the next infrastructure question is no longer whether the fixed 0x55f2 row hides the child count or primary-child ordinal at all; those outer-header values now have to live outside the fixed row, most likely in the surrounding payload-stream header or compact-prefix regime above 0x0048dcf0.

• The outer prelude itself is tighter now too: direct disassembly of 0x0048dcf0 shows it reading one u16 child count through 0x00531150, zeroing [this+0x08], and conditionally reading one saved primary-child byte before the per-child callback loop runs. Grounded q.gms bytes now also show the first 0x38a6 record starting immediately after the shared owner-local dword with child_count = 1, saved_primary_child_byte = 0xff, and the first child 0x55f1 opening at offset +0x3. So the next infrastructure question is no longer “what kind of values are we looking for above the fixed rows?”; it is the narrower partitioning problem of how the observed 0x55f3-to-next-0x55f1 gaps divide between the two 0x52ebd0 flag bytes and the next record’s u16 + byte prelude.

• The widened prelude correlation closes part of that partitioning too: grounded q.gms rows with a 0x03 post-profile gap now collapse cleanly to the next-record prelude pattern 0x0001 / 0xff across 17/17 rows, while the zero-length class is a separate grounded outlier with dominant pattern 0x0055 / 0x00 across 18/18 rows and the 0x06 class remains the only large mixed frontier. So the next infrastructure slice should focus on classifying the mixed 0x06 rows, not on rediscovering the already-grounded pure-prelude 0x03 rows.

• That 0x06 class is now narrower too: grounded q.gms shows the dominant short-span class as BridgeSTWood_Section.3dp / Infrastructure with compact prefix 0xff000000 / 0x0001 / 0xff across 62/72 rows and dominant prelude candidate 0x0001 / 0xff across 63/72 rows. So the next infrastructure slice should stop treating the 0x06 class as uniformly ambiguous and focus on the smaller outlier families inside that class, especially the zero-like BallastCap-style rows and any remaining non-0x0001 / 0xff prelude candidates.

• The exact compact-prefix classes are explicit across the whole prelude now too: 0xff0000ff / 0x0002 / 0xff is a pure bridge class, 0xff000000 / {0x0001,0x0002} / 0xff are pure bridge classes, 0xf3010100 / 0x0055 / 0x00 is a pure BallastCap class, and 0x0005d368 / 0x0001 / 0xff is a pure one-row TrackCap class.

• That sharpens the remaining infrastructure unknowns considerably: the only mixed exact compact-prefix classes left on grounded q.gms are 0x000055f3 / 0x0001 / 0xff and 0xff0000ff / 0x0001 / 0xff.

• The current 0x000055f3 / 0x0001 / 0xff class is tunnel-dominant: TunnelSTBrick_Section.3dp / Infrastructure:13, TunnelSTBrick_Cap.3dp / Infrastructure:4, TrackCapST_Cap.3dp / Infrastructure:0 in the exact-prefix correlation, with all 17 rows staying on prior profile span 0x03.

• The current 0xff0000ff / 0x0001 / 0xff class is TrackCap-dominant but still carries 4 tunnel rows: TrackCapST_Cap.3dp / Infrastructure:18, TunnelSTBrick_Cap.3dp / Infrastructure:2, TunnelSTBrick_Section.3dp / Infrastructure:2. Its rows are spread across many spans rather than one dominant restore span.

• Source-side constructor analysis is narrower now too. 0x00490960 takes:

  • mode at stack arg 1
  • stem at stack arg 2
  • args 3/4 into 0x539530
  • arg 5 into 0x53a5b0
  • arg 10 as the primary-child cache gate for [this+0x248]
  • args 7/8/9 into the selector-copy block for [this+0x219], [this+0x251], and bit 0x20 in [this+0x24c] when mode < 4

• That already separates the remaining mixed classes:

  • fixed TrackCap mode 0x0b callers at 0x0048ed01/0x0048ed20 push arg7/arg8/arg9 as -1 / -1 / 0 and bypass selector-copy entirely because mode >= 4
  • tunnel mode 0x02 callers at 0x004a17eb / 0x004a1995 / 0x004a1b44 / 0x004a1b7d / 0x004a1b95 necessarily flow through selector-copy because mode < 4, with arg8 fixed at 1, arg9 fixed at 0, and only arg7 varying through a branch-local one-bit register

• So the next infrastructure slice should stop treating the remaining frontier as a generic “mixed 0x06/outlier” problem and instead target the owning constructor/restore semantics for those two exact mixed compact-prefix classes, especially how tunnel arg7 and the fixed TrackCap no-selector bundle both still collapse into the observed mixed save-side prefixes.

• The candidate-pattern classes are now explicit across the whole stream too: 0x0055 / 0x00 is a pure BallastCapST_Cap.3dp / Infrastructure class across 18 rows, always preceded by a zero-length prior profile span, while 0x0002 / 0xff is a pure BridgeSTWood_Section.3dp / Infrastructure class across 18 rows with dominant prior profile span 0x06 (10 rows). So the next infrastructure pass should split its owner questions: treat 0x0055 / 0x00 as a BallastCap-specific boundary artifact class, and treat 0x0002 / 0xff as the grounded save-side bridge-specific two-child candidate class above 0x0048a1e0/0x0048dcf0, with the remaining unknown narrowed to the upstream chooser that emits that class before the attach/rebuild path runs.

• That upstream chooser is grounded now too as paired siblings: direct disassembly shows 0x004a2c80 routing the DT family and 0x004a34e0 routing the ST family, with both repeatedly calling 0x0048a1e0, branching on [this+0x226], selector bytes [this+0x219]/[this+0x251], bit 0x20 in [this+0x24c], and lookup tables 0x621a44..0x621a9c, then routing follow-on through 0x0048a340/0x0048f4c0/0x00490200/0x00490960. So the remaining infrastructure question is no longer “is there an upstream chooser?” but “how do the save-side classes select the DT versus ST chooser sibling, and then which lookup-table families inside that sibling map to the grounded 0x0002 / 0xff bridge class and the 0x0055 / 0x00 BallastCap class?”.

• Those lookup tables are decoded now too: 0x621a44/0x621a54 feed BridgeST caps/sections, 0x621a64 feeds TunnelST cap/section variants, 0x621a74/0x621a84 feed BridgeDT caps/sections, and 0x621a94 feeds TunnelDT variants, while fixed literals 0x5cb138/0x5cb150 are BallastCapDT/ST and 0x5cb168/0x5cb180 are OverpassDT/ST. So the remaining infrastructure question is no longer table discovery; it is the selector-byte mapping from [this+0x219]/[this+0x251]/[this+0x252] onto those decoded families and then onto the grounded 0x38a5 prefix classes.

• The top-level chooser meaning is grounded now too: within those paired DT/ST siblings, [this+0x226]==1 routes the bridge families, [this+0x226]==2 routes the tunnel families, and [this+0x226]==3 routes the overpass/ballast family, while bit 0x20 in [this+0x24c] selects the cap-oriented side over the section-oriented side. So the remaining infrastructure selector problem is below that top-level split: the exact [this+0x219]/[this+0x251] values that choose the decoded family entries and how those values surface in the save-side 0x38a5 classes.

• Those material selectors are grounded now too: within the bridge branch, [this+0x219] selects steel, stone, suspension, or wood, with value 2 taking the special suspension-cap path through [this+0x252]; within the tunnel branch, [this+0x251] selects brick versus concrete, while bit 0x20 chooses cap versus section by switching between the base and +0x8 table entry families. So the remaining infrastructure selector problem is no longer “what do these bytes mean?” but “how do those already-grounded selector values surface in the save-side 0x38a5 classes, especially the 0x0002 / 0xff bridge class and the 0x0055 / 0x00 BallastCap class?”.

• The exact setter seam is grounded now too: direct disassembly of 0x0048a340 shows its dword argument writing [this+0x226], its next two byte arguments writing [this+0x219] and [this+0x251], and its final byte argument toggling bit 0x20 in [this+0x24c]. So the remaining infrastructure selector problem is no longer about hidden intermediate state; it is specifically how those already-grounded setter values are serialized or rebuilt into the save-side 0x38a5 prefix classes.

• One selector byte is partly grounded now too: when [this+0x219]==2, the chooser jump tables stop using the general bridge families and instead route [this+0x252] through fixed BridgeDT/BridgeST suspension-cap literals for R10, L10, 12, 14, 16, and 18. So the remaining infrastructure selector problem is mostly [this+0x219]/[this+0x251] family choice plus the exact save-side class mapping for the BallastCap branch.

• The current real-save corpus also narrows the active side further: grounded q.gms, p.gms, g.gms, and nom.gms only expose ST-family side-buffer names, while classic rt3/ saves in this workspace currently expose no 0x38a5 side-buffer seam at all. So the save-driven part of the next infrastructure slice should assume it is exercising the ST chooser sibling directly, with DT still grounded statically but not yet exercised by the current save corpus.

• Reconstruct the save-side region record body on top of the newly corrected non-direct tagged region seam (0x5209/0x520a/0x520b, stride hint 0x06, Marker09 record stems) now that the 0x55f3 payload is known to be fully consumed by the embedded profile collection on grounded real saves: the remaining blocker is no longer a hidden trailing payload tail, but finding the separate save-owner seam for the pending bonus lane [region+0x276], completion latch [region+0x302], one-shot notice latch [region+0x316], severity/source lane [region+0x25e], and any stable region-id or class discriminator that can drive shellless city-connection service. The newly grounded queue-node probe for the atlas-backed kind-7 notice records is a negative result on q.gms, p.gms, and Autosave.gms, so the next region pass should not assume that the transient [world+0x66a6] queue family is persisted in ordinary saves; the region trace now also carries the concrete queued/service owners (0x00422100, 0x004337c0, 0x00437c00, 0x004c7520, 0x004358d0, 0x00438710, 0x00420030/0x00420280, 0x0047efe0) so the next pass can focus on the missing saved latches and stable region id/class rather than on rediscovering the outer service family.

• Rehost or bound the next concrete region owner above the missing latches instead of treating the absent persisted queue as a stop: start with the checked-in owner strip 0x00422100, 0x004337c0, 0x00437c00, 0x004c7520, 0x004358d0, 0x00438710, 0x00420030/0x00420280, 0x0047efe0, and reduce it to the first true save-owned or rebuild owner that can explain [region+0x25e/+0x276/+0x302/+0x316] plus a stable region id/class. The region trace now ranks the current best hypothesis as the pending bonus service owner (0x004358d0) plus the peer/linkage strip (0x00420030/0x00420280, 0x0047efe0), with the transient producer/queue family explicitly secondary and the queued kind-7 modal dispatch kept as shell-adjacent reference only.

• For that top-ranked region strip, treat the next pass as three exact owner questions too: which restore seam re-seeds [region+0x25e] and clears [region+0x302/+0x316] before the grounded 0x00422100 -> 0x004358d0 producer/consumer cycle runs again, which stable region id or class discriminator survives save/load strongly enough to drive 0x004358d0, and how far the grounded city-connection peer/linkage helpers (0x00420030/0x00420280, 0x0047efe0) can be reused directly before the transient queued-notice family matters again.

• Targeted disassembly now tightens that strip too: 0x004358d0 calls 0x00420030 twice plus 0x00420280, then resolves the linked company through 0x0047efe0, posts company stat slot 4 on success, and stamps [region+0x302] or [region+0x316] while clearing [region+0x276]. 0x00420030 itself now reads as the real peer gate over collection 0x006cec20, combining 0x0042b2d0, the optional company filter through 0x0047efe0, the station-or-transit gate 0x0047fd50, and the status branch 0x0047de00 -> 0x0040c990; 0x00420280 is the same scan returning the first matching site id. So the remaining unknown is the persisted latch/id seam, not the live peer/service logic.

• The producer half is grounded now too: 0x00422100 filters for class-0 regions with [region+0x276]==0 and [region+0x302]==0, rejects already-connected pairs through 0x00420030(1,1,0,0), chooses one eligible candidate, buckets severity/source lane [region+0x25e] against the three checked thresholds, writes the resulting amount to [region+0x276], and appends the kind-7 queued notice through 0x004337c0. That means the remaining region gap is now explicitly the upstream restore seam for [region+0x25e] and the completion/fallback latch clear, not either side of the producer/consumer service pair.

• The severity/source lane itself is narrower now too: 0x004cc930 is a selected-region editor helper that writes [region+0x25a] and [region+0x25e] together from one integer input, while 0x00438150 and 0x00442cc0 are fixed-region global reseed/clamp owners over collection 0x0062bae0 that adjust the same mirrored pair for hardcoded region ids. So the remaining region restore question is no longer “what does [region+0x25e] mean?” but “which load/reseed seam restores the mirrored severity pair before the producer runs?”

• Two more direct-hit writer bands are now explicitly ruled out too: 0x0043a5a0 is a separate constructor under vtable root 0x005ca078 that zeroes its own [this+0x302/+0x316] fields during local object setup, and 0x0045c460/0x0045c8xx is a separate vtable-0x005cb5e8 helper family whose [this+0x316] is a child-array pointer serialized through 0x61a9/0x61aa/0x61ab. So those offset-collision classes should stay out of the remaining region restore search.

• The direct writer census is tighter now too: the other apparent 0x302/0x316 writer bands (0x0043dd45, 0x0043de19, 0x0043e0a7, 0x0043f5bc) all hang off that same non-region 0x005ca078 family through helpers 0x0043af60 and 0x0043b030. So the only grounded region-owned literal writes left are the constructor 0x00421200 plus the producer/consumer pair 0x00422100 and 0x004358d0, which means the remaining region seam should now be treated as an indirect restore/rebuild path rather than another direct offset writer hunt.

• The later post-load per-region sweep is narrowed too: in the broader 0x00444887 restore strip, the follow-on loop at 0x00444b90 dispatches 0x00420560 over each live region, but that helper only zeroes and recomputes [region+0x312] from the embedded profile collection [region+0x37f]/[region+0x383] and lazily seeds the year-driven [region+0x317/+0x31b] band through 0x00420350. It still does not touch [region+0x276/+0x302/+0x316], so that whole follow-on branch should stay out of the remaining latch-restore search too.

• The checked-in constructor owner 0x00421200 world_region_construct_entry_with_id_class_and_default_marker09_profile_seed now also grounds the initialization side of this family: it clears [region+0x276], [region+0x302], [region+0x316], and neighboring cached bands at construction time while seeding [region+0x25a/+0x25e] = 100.0f and [region+0x31b] = 1.0f. That means the remaining queue item is specifically post-construction restore or rebuild of the same latches, not their basic field identity.

• The next restore-side target is explicit now too: the checked-in function map already grounds 0x00421510 as the tagged region-collection load owner that dispatches each live region through vtable slot +0x40, and 0x0041f5c0 as the per-record load slot that reloads the tagged payload through 0x00455fc0 before rebuilding profile collection [region+0x37f]. So the next region pass should ask whether [region+0x276/+0x302/+0x316] are restored directly inside that payload load or rebuilt immediately after it, rather than treating “restore seam” as a generic unknown.

• Direct disassembly now closes that callback identity too: 0x0041f590/0x0041f5b0 prove the world-region vtable root is 0x005c9a28, so the 0x00455fc0 dispatch at slot +0x48 lands on 0x00455870 and the serializer sibling at +0x4c lands on 0x00455930. Those two callbacks only restore and serialize two triplet-like three-lane scalar bands through 0x00531150/0x00531030 plus 0x00530720/0x0052e8b0; they still do not touch [region+0x276/+0x302/+0x316]. That means the remaining region restore target is now the later owner that rebuilds those latches or the separate tagged body seam that persists them.

• The rest of 0x00455fc0 is ruled down further now too: after the +0x48 callback it only runs 0x0052ebd0, which reads two one-byte generic flags through 0x531150 into base object bytes [this+0x20], [this+0x8d], [this+0x5c..+0x61], [this+0x1ee], [this+0x1fa], and [this+0x3e], and then it opens 0x55f3 only for span accounting before returning. So the missing region latches are not hiding in the remainder of 0x00455fc0 either.

• The later restore-side region owners are narrowed further now too: the 0x00421ce0 -> 0x0041fb00 -> 0x00421730 sweep is class-0 raster/id rebuild, 0x004881b0 is a companion region-set cell-count rebuild over [region+0x3d/+0x41], 0x00487de0 is a border-segment emitter over the world raster, and 0x0044c4b0 is the center-cell bit-0x10 reseed pass. So the next region slice should stop revisiting those later owners and stay focused on the still- missing save-owned latch / severity / stable-id seam.

• The later class-0 batch at 0x00438087 is narrowed now too: it walks live class-0 regions through 0x0062bae0, rescales the mirrored severity/source pair [region+0x25a/+0x25e] from the current value using world-side factors, clamps the result, and then hands the collection to 0x00421c20; it still does not touch [region+0x276/+0x302/+0x316].

• Its follow-on 0x00421c20 is bounded as a parameterized region-collection helper rather than a latch owner: it loops the same collection with caller-supplied scalar arguments, dispatches each record through 0x004235c0, and does not write the pending/completion/one-shot lanes directly.

• The subsequent world follow-ons are narrower too: 0x00437b20 only stages a world-side reentry guard at [world+0x46c38], iterates the live region collection through 0x00423d30, and tails into 0x00434d40, while 0x00437220 rebuilds broader world byte-set state around [world+0x66be/+0x69db] and other global collections. Those later branches should stay out of the remaining region latch-restore search too.

• The widened real-save region trace rules out one more false lead too: on grounded saves the 0x55f2 fixed-policy chunk keeps all three reserved dwords at 0x00000000 and the trailing word at invariant 0x0001, so that fixed chunk is not currently carrying the missing latch or stable region id/class discriminator either.

• Reconstruct the save-side placed-structure collection body on top of the newly grounded 0x36b1/0x36b2/0x36b3 header seam so the blocked city-connection / linked-transit branch can stop depending on atlas-only placed-structure and local-runtime refresh notes, especially the semantics of the now-grounded compact 0x55f3 footer dword/status lane and the newly exposed separate tagged side-buffer seam candidates, especially the exact 0x38a5/0x38a6/0x38a7 family whose compact 6-byte header pattern and embedded placed-structure-style 0x55f1 name rows now make it the grounded placed-structure dynamic side-buffer owner; the remaining blocker is semantic closure of the compact prefix regimes now summarized in real saves as seven stable patterns on q.gms and their relation to the embedded 0x55f1/0x55f2/0x55f3 row subset, especially now that the side-buffer name-pair corpus is proven disjoint from the grounded 0x36b1 triplet name-pair corpus on q.gms; the next pass should treat 0x38a5 as a separate infrastructure-asset owner seam, not a compact alias over the triplet records.

• Extend shellless clock advancement so more periodic-company service branches consume owned runtime time state directly instead of only the explicit periodic service command.

• Keep widening selected-year world-owner state only when a full owning reader/rebuild family is grounded strongly enough to avoid one-off leaf guesses.

In Progress

• Widen shellless simulation from explicit service commands toward “advance the runtime clock and the simulation-owned services advance with it.”

Queued

• Rehost additional periodic finance/service branches that still depend on frozen world restore fields instead of advanced runtime-owned time state.
• Reduce remaining company/chairman save-native gaps that still block standalone simulation quality, especially controller-kind closure and any deeper finance/state fields that still rely on conservative defaults.
• Rehost bounded live economy owner state beyond selector/catalog/override surfaces when a concrete non-shell-owned seam is grounded.
• Keep tightening shell-owned parity families only when that directly supports later rehosting.

Blocked

• Full shell/dialog ownership remains intentionally out of scope.
• Any candidate slice that requires guessing rather than rehosting owning state or real reader/setter families stays blocked until a better owner seam is grounded.
• Missing owner seams or dispatch mappings are not by themselves a stop condition when a targeted static-mapping pass or a higher-layer rehosted trace/evaluator surface can still narrow them further without guessing.
• The city-connection announcement / linked-transit roster-maintenance branch is still blocked at the record-body level, not the collection-identity level: the runtime now has a corrected non-direct tagged region seam, a tagged train header-plus-directory seam, and a tagged placed-structure header seam, but it does not yet reconstruct the live region or placed-structure record bodies those service owners need.

Recently Done

• rrt-runtime now exposes three higher-layer probe surfaces and matching CLI inspectors: runtime inspect-periodic-company-service-trace <save.gms>, runtime inspect-region-service-trace <save.gms>, and runtime inspect-infrastructure-asset-trace <save.gms>. These reports separate grounded outer owner inputs, runnable shellless branches, and explicit missing owner seams instead of leaving the current city-connection / linked-transit frontier as an opaque blocker.
• Those same probes now also sharpen the next queue choice on grounded real saves: the periodic company outer owner shows annual finance and route-preference override as grounded shellless branches while city-connection and linked-transit stay blocked on region/infrastructure owner seams; the region trace keeps the queued kind-7 notice family on the transient side; and the infrastructure trace now makes the 0x38a5 consumer-mapping blocker first-class after disproving any alias to the 0x36b1 placed-structure triplet corpus.
• The infrastructure trace now also carries one small atlas-backed static-analysis layer above that seam: bridge/tunnel/track-cap name-family counts from the real side-buffer corpus plus concrete consumer candidates rooted at the Infrastructure child attach/rebuild/serializer helpers and the later route/local-runtime follow-on owners. That means the next 0x38a5 pass can be targeted static mapping instead of another generic scan.
• The same 0x38a5 probe now also exports payload-envelope summaries directly instead of only flat name rows: policy/profile tag presence, dominant embedded 0x55f2 and 0x55f3 span lengths, and sampled row boundaries. That means the next pass can decode the short embedded 0x55f3 payload lane on top of already grounded row boundaries instead of rediscovering the same envelopes again.
• That same probe now also exports the grounded short trailing flag-byte pair summary for the dominant 0x06-byte rows, while the infrastructure trace carries the matching 0x0052ebd0/0x0052ec50 helper seam. That means the next pass can aim directly at how those flags combine with compact-prefix regimes and primary-child restore state instead of treating the short lane as anonymous payload.
• That same probe now also exports the fixed 0x55f2 six-dword policy samples and the grounded shared trailing word 0x0101 for all embedded rows, while the infrastructure trace carries the matching 0x00455870/0x00455930 helper seam. That means the next pass can focus on which of the two restored dword triplets actually bridge into child-count / primary-child state instead of rediscovering the fixed 0x55f2 row shape.
• The infrastructure trace now also carries the deeper 0x00530720/0x0052e8b0 bridge, so the next pass can focus on the outer payload-stream header and compact-prefix regimes instead of revisiting the fixed 0x55f2 six-dword row.
• That same trace now also ranks those consumers into explicit hypotheses, so the next infrastructure pass should start with the attach/rebuild strip instead of treating all candidate owners as equally likely.
• The region trace now also carries the corresponding atlas-backed candidate owner strip above the unresolved save latches, so the region frontier is now explicitly “missing persisted owner seam for [region+0x25e/+0x276/+0x302/+0x316] and stable region id/class,” not “unknown service family.”
• That same trace now also ranks those owners into explicit hypotheses, so the next region pass should start with the pending bonus service owner and peer/linkage strip rather than the queued modal family.
• Save inspection now splits the shared 0x5209/0x520a/0x520b family correctly: the smaller direct 0x1d5 collection is the live train family and now exposes a live-entry directory rooted at metadata dword 16, while the actual region family is the larger non-direct Marker09 collection with live_id/count 0x96/0x91; the tagged placed-structure header (0x36b1/0x36b2/0x36b3) remains grounded alongside them.
• That same corrected region seam now also exposes repeated 0x55f1/0x55f2/0x55f3 serialized record triplets with len-prefixed names plus fixed policy/profile chunk lengths, so the next city-connection pass can target the real record envelope instead of another blind scan.
• The fixed 0x55f2 row inside each region triplet is now decoded structurally as three leading f32 lanes, three reserved u32 lanes, and a trailing u16 word, so the next save-region slice can focus on the larger 0x55f3 payload where the pending/completion/one-shot latches are most likely to live.
• The larger 0x55f3 payload now also exposes an embedded direct profile collection with grounded live-id/count headers, fixed 0x22-byte rows, profile names, and trailing weight scalars, so the remaining region work is on the unresolved payload fields above that collection rather than on the profile subcollection itself.
• Grounded real saves now also show that the region-side 0x55f3 payload has zero trailing padding beyond that embedded profile collection, so the remaining region blocker has shifted from “find the hidden tail inside this payload” to “find the separate owner seam that backs the runtime latches the city-connection branch still reads.”
• Save inspection now also exports a generic low-tag unclassified collection scan over plausible indexed-collection headers, now through a lightweight CLI path that does not require full bundle inspection and now filters out candidates nested inside already-grounded company/chairman/train/ region/placed-structure spans.
• That lightweight scan now also narrows the real save frontier to a much smaller stable candidate set across p.gms, q.gms, and Autosave.gms, with the exact 0x38a5/0x38a6/0x38a7 family standing out as the strongest current placed-structure dynamic side-buffer candidate.
• The 0x38a5/0x38a6/0x38a7 family now also has a first dedicated parser scaffold in rrt-runtime: its synthetic regression is grounded, its header shape is checked in, and the parser now expects a compact 6-byte prefix plus separator byte before an embedded placed-structure-style dual-name row rather than treating the family as anonymous residue.
• That exact 0x38a5/0x38a6/0x38a7 parser is now also wired through a lightweight CLI inspector and the normal save company/chairman analysis output, and grounded real saves now prove the same seam directly: q.gms exposes live_record_count=3865, prefix 0x0005d368/0x0001/0xff, and first embedded names TrackCapST_Cap.3dp / Infrastructure; p.gms exposes the same structure with live_record_count=2467.
• That same direct 0x38a5 probe now also samples multiple embedded name rows with their preceding compact prefixes, showing that the seam is not a one-off wrapper: grounded q.gms samples include repeated TunnelSTBrick_* names under Infrastructure with compact leading dwords like 0x000055f3 and 0xff0000ff, so the next pass can target the semantics of those compact prefix patterns instead of hunting the owner seam itself.
• The 0x38a5 probe now also summarizes all embedded compact prefix regimes instead of just the first few samples: grounded q.gms currently exposes seven stable pattern groups across 138 embedded rows, with the dominant 0xff000000/0x0001/0xff group carrying 62 bridge-section rows, the 0xff0000ff/0x0001/0xff and 0xf3010100/0x0055/0x00 groups concentrating cap-like rows, and a smaller 0x000055f3/0x0001/0xff group carrying 17 tunnel-section / cap rows whose leading dword matches the embedded placed-structure profile tag directly.
• The save-company/chairman analysis path now also compares that grounded 0x38a5 side-buffer name-pair corpus against the grounded 0x36b1 triplet name-pair corpus directly; on q.gms the overlap is currently zero (0/138 decoded side-buffer rows and 0/5 unique side-buffer name pairs match the 56-triplet corpus), which shifts the remaining placed-structure work away from “prove these are aliases” toward “find how the separate infrastructure-asset owner seam is consumed by city-connection / linked-transit service.”
• Save inspection now also has a dedicated probe for the atlas-backed region queued-notice node shape (payload seed 0x005c87a8, kind 7, zero promotion latch, region id, amount, -1/-1 tails), plus a matching lightweight CLI inspector. Grounded q.gms, p.gms, and Autosave.gms all currently return null, which is useful negative evidence: the transient region notice queue is not obviously persisted in these ordinary saves.
• The placed-structure tagged save stream now also exposes repeated 0x55f1/0x55f2/0x55f3 triplets with dual name stems, a fixed five-f32 policy row, and a compact 0x5dc1...0x5dc2 footer carrying one raw u32 payload lane plus one live i32 status lane, so the remaining placed-structure work is semantic closure of those owned fields rather than envelope discovery.
• That compact placed-structure i32 footer status lane is now partially grounded as owned semantics too: observed non-farm families stay at -1, while farm families use nonnegative 0..11 buckets that are now exported as farm growth-stage indices instead of opaque raw status residue.
• Stepped calendar progression now also refreshes save-world owner time fields, including packed year, packed tuple words, absolute counter, and the derived selected-year gap scalar.
• Automatic year-rollover calendar stepping now invokes periodic-boundary service.
• Save-native world locomotive policy owner state now flows through runtime restore state, summaries, and keyed world-flag execution for the grounded All Steam/Diesel/Electric Locos Avail. descriptor strip plus the cached available-locomotive rating.
• The selected-year bucket ladder rooted in 0x00433bd0 is now checked in as a static artifact, and runtime restore state now derives both the selected-year bucket scalar and the [world+0x0bde] economic-tuning mirror from owner-family inputs instead of preserving stale load-time residue.
• That same selected-year owner family now also rebuilds the direct bucket trio [world+0x65/+0x69/+0x6d], the complement trio [world+0x71/+0x75/+0x79], and the scaled companion trio [world+0x7d/+0x81/+0x85] from the checked-in 0x00433bd0 artifact instead of preserving stale save-time residue.
• The save-native company direct-record seam now also carries the full outer periodic-company side-latch trio rooted at 0x0d17/0x0d18/0x0d56, including the preferred-locomotive engine-type chooser byte beside the city-connection and linked-transit finance gates.
• That same side-latch trio now also has a runtime-owned service-state map and summary surface, so later periodic company-service work can stop reading those lanes directly from imported market/cache residue.
• The periodic-boundary owner now also clears the transient preferred-locomotive side latch every cycle and reseeds the finance latches from market state where present, while preserving side-latch-only company context when no market projection exists.
• The outer periodic-company seam now also has a first-class runtime reader: selected-company summaries and finance readers can resolve the base [world+0x4c74] route-preference byte, the effective electric-only override fed by 0x0d17, and the matching 1.4x versus 1.8x route-quality multiplier through owned periodic-service state instead of leaving that bridge in atlas notes.
• That same periodic-company seam now also owns a first-class route-preference apply/restore mutation lane: runtime service state tracks the active and last electric override, beginning the override rewrites [world+0x4c74] to the effective route preference for the selected company service pass, and ending the override restores the base world byte instead of leaving the seam as a pure reader bridge.
• The same route-preference mutation seam now also carries explicit apply/restore service counters through runtime service state and summaries, so later periodic-company branches can assert that override activity happened even before the missing city-connection / linked-transit service owners are fully rehosted.
• Company cash, confiscation, and major governance effects now write through owner state instead of drifting from market/cache readers.
• Company credit rating, prime rate, book value per share, investor confidence, and management attitude now refresh from grounded owner-state readers.
• Annual finance service persists structured news events and grounded debt/share flow totals.