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

Compare building source assets to live bindings

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 03:02:11 -07:00
commit 7a26063656
5 changed files with 307 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

23
docs/rehost-queue.md
View file

@ -355,13 +355,22 @@ Working rule:
descriptor-side candidate bridge is now checked in across `503..613`, and the honest remaining
boundary is the missing non-hook name catalog for candidate ids `67..110`
- the new offline `BuildingTypes` source report sharpens that missing name-catalog boundary too:
`runtime inspect-building-type-sources rt3_wineprefix/drive_c/rt3/Data/BuildingTypes`
now reports `77` `.bca` files, `200` `.bty` files, and `208` canonical asset stems, but only
`43` of those canonical stems overlap the live named candidate run `0..66`. The numbered live
`Port00..11` and `Warehouse00..11` names collapse to generic asset stems `Port` and
`Warehouse`, while `165` canonical stems exist only in the broader asset pool. So the
`BuildingTypes` directory is now grounded as a wider offline source catalog, but not yet as a
direct second live candidate-name owner for descriptor-side ids `67..110`
`runtime inspect-building-type-sources rt3_wineprefix/drive_c/rt3/Data/BuildingTypes artifacts/exports/rt3-1.06/event-effects-building-bindings.json`
now reports `77` `.bca` files, `200` `.bty` files, and `208` canonical asset stems. Against
the checked-in named add-building bindings it finds exactly `43` shared canonical stems,
`24` binding-only stems (`Port00..11` and `Warehouse00..11`), and `165` broader asset-only
stems. The numbered live `Port00..11` and `Warehouse00..11` names therefore collapse to
generic asset stems `Port` and `Warehouse` on disk, so the `BuildingTypes` directory is now
grounded as a wider offline source catalog, but not yet as a direct second live candidate-name
owner for descriptor-side ids `67..110`
- the local-runtime builder strip now reinforces that same boundary:
direct disassembly of `0x00418be0` shows the broader placed-structure rebuild lane resolving
its caller-supplied stem only through `0x00416e20 indexed_collection_resolve_live_entry_id_by_stem_string`
against the current live candidate collection, then projecting runtime scratch through
`0x00416ec0` and `0x00418610`. So the broader `BuildingTypes` asset pool is not yet a proven
alternate live owner for descriptor-side add-building candidate ids; current non-hook evidence
still routes stem resolution back through the live candidate collection that tops out at the
contiguous named run `0..66`
- the concrete owner strip above that bundle is grounded now too:
`0x00433060` is the direct non-direct serializer loop that writes `0x4e99/0x4e9a/0x4e9b`,
calls `0x00430d70` per live collection row, and sits beside the sibling `0x00433130` size/load