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

Ground acquisition stream-load candidate bridge

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 21:49:35 -07:00
commit bf16237beb
2 changed files with 40 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

11
docs/rehost-queue.md
View file

@ -94,8 +94,8 @@ Working rule:
- site owner-company lane = `live_meaning_grounded_projection_missing`
- site self-id lane = `live_meaning_grounded_projection_missing`
- site cached tri-lane = `delta_reader_grounded_projection_missing`
- candidate subtype lane = `cached_candidate_id_bridge_grounded_projection_missing`
- backing-record selector bridge = `cached_source_candidate_bridge_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_cached_tri_lane_payload_or_restore_owner`
@ -116,14 +116,15 @@ Working rule:
direct local binary inspection shows `0x0040c9a0` folding `[site+0x310/+0x338/+0x360]` into
`[site+0x2b4/+0x2b8/+0x2bc]`, mirroring the nine-dword side array rooted at `[site+0x2e4]`,
and then clearing the tri-lane
- the cached source/candidate bridge is now grounded on stream load too:
direct local binary inspection shows `0x00413280` dispatching per-entry vtable slot `+0x40`
on the `0x005c8c50` specialization table, that slot resolving to `0x0040ce60`, and
`0x0040ce60` immediately re-entering `0x0040cd70` plus `0x0045c150`
- the third hypothesis is now a cached source/candidate bridge question, not just a raw
`[site+0x04]` selector question:
`0x0040cd70` seeds `[site+0x3cc/+0x3d0]` from `0x62b2fc / 0x62b268`,
`0x0040cee0` resolves cached candidate id `[site+0x3d0]` back into the live candidate pool,
and `0x004138f0` already counts live placed structures by that cached candidate id
- that leaves the remaining subtype blocker narrower:
no checked-in replay or restore owner yet guarantees `[site+0x3d0]` is populated for the
acquisition-side rows before `0x0040d360` consumes candidate subtype byte `[candidate+0x32]`
- the checked-in consumer side is tighter too:
`0x0040dc40` already consumes live owner company `[site+0x276]`, company stat-family
`0x2329/0x0d`, candidate field `[candidate+0x22]`, and the projected-cell validation strip