Reconstruct acquisition self-id from live row identity

This commit is contained in:
Jan Petykiewicz 2026-04-18 21:57:46 -07:00
commit 6a6f2b4abf
2 changed files with 53 additions and 21 deletions

View file

@ -83,27 +83,30 @@ Working rule:
- `[site+0x2a4]` is already grounded as the record's own placed-structure id lane through the
peer-chain helpers `0x0041f7e0 / 0x0041f810 / 0x0041f850`, and constructor-side `0x00480210`
already seeds that lane for new linked-site rows
- direct disassembly now also shows `0x004269b0` resolving one chosen site id through live
placed-structure collection `0x0062b26c` before mutating `[site+0x276]`, so the
`[site+0x2a4]` self-id lane is reconstructible from collection identity rather than needing a
separate serializer-owned projection
- the subtype byte consumed as `[candidate+0x32] == 4` is already bounded under the
aux-candidate load/stem-policy chain
`0x004131f0 -> 0x00412fb0 -> 0x004120b0 -> 0x00412ab0`
- remaining non-hook gaps are the save or replay projection of `[site+0x276]`, the save or
replay projection of `[site+0x2a4]` into restored rows, and the cached tri-lane
`[site+0x310/+0x338/+0x360]`
- remaining non-hook gaps are the save or replay projection of `[site+0x276]` and the cached
tri-lane `[site+0x310/+0x338/+0x360]`
- the checked-in periodic-company trace now exposes those gaps as structured statuses instead of
only prose:
- site owner-company lane = `live_meaning_grounded_projection_missing`
- site self-id lane = `live_meaning_grounded_projection_missing`
- site self-id lane = `live_meaning_grounded_reconstructible_from_collection_identity`
- site cached tri-lane = `delta_reader_grounded_projection_missing`
- candidate subtype lane = `cached_candidate_id_bridge_grounded_via_stream_load`
- backing-record selector bridge = `stream_load_callback_grounded_via_0x40ce60`
- the same trace now also carries three explicit projection hypotheses for the next pass:
- `site_owner_and_self_id_replay_from_post_load_refresh`
- `site_owner_replay_from_post_load_refresh_self_id_reconstructible`
- `site_cached_tri_lane_payload_or_restore_owner`
- `cached_source_candidate_id_to_subtype_projection`
- the first of those is now partly ruled down by the checked-in atlas:
`0x004133b0 -> 0x0040e450 / 0x0040ee10` rebuilds cloned local-runtime records and local
position/scalar triplets, but current evidence still does not tie that replay family directly
to `[site+0x276]` or `[site+0x2a4]`
to `[site+0x276]`
- the second is narrower in the same way:
the checked-in `0x36b1/0x36b2/0x36b3` triplet seam and the
`0x4a9d/0x4a3a/0x4a3b` side-buffer seam still do not serialize `[site+0x310/+0x338/+0x360]`