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

Split acquisition owner constructor and finalize families

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 22:43:32 -07:00
commit 859c040462
2 changed files with 144 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

18
docs/rehost-queue.md
View file

@ -103,11 +103,13 @@ Working rule:
- `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:
- the first of those is now bounded more tightly:
`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]`
- the same replay strip is narrower than before now:
position/scalar triplets, but direct constructor and caller recovery now shows the
owner-company lane also living under the create-side allocator/finalize family
`0x004134d0 -> 0x0040f6d0 -> 0x0040ef10`, plus data-driven loader callers
`0x0046f073 / 0x004707ff -> 0x0040ef10`
- the checked-in replay strip is narrower than before now:
direct local inspection now splits it more precisely:
`0x0040ee10` itself only reads cached source lane `[site+0x3cc]` in the checked range, and
the bounded `0x00480710` neighborhood is working from `[site+0x04]`, `[site+0x08]`, and
@ -116,6 +118,14 @@ Working rule:
`0x0040d230 / 0x0040d1f0 / 0x00480710 / 0x00426b10 / 0x00455860`, so the replay family is
narrowed rather than ruled out for owner-company rehydration; in the checked range those
`[site+0x276]` uses are still reads/queries rather than a direct rehydrating store
- the create-side owner family is grounded too now:
`0x004134d0` allocates a new row through `0x00518900`, `0x0040f6d0` seeds `[site+0x2a4]`,
copied name bytes, `[site+0x276]`, `[site+0x3d4/+0x3d5]`, and cleared local caches, and the
shared finalize helper `0x0040ef10` has both create-side callers `0x00403ef3 / 0x00404489`
and data-driven loader callers `0x0046f073 / 0x004707ff`
- the remaining owner-company question is therefore narrower than “find any replay seam”:
identify which persisted tuple fields and later restore/finalize calls are sufficient to
repopulate `[site+0x276]` for shellless acquisition
- 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]`