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

Narrow peer-site replay owner questions

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 18:30:28 -07:00
commit d96bc47a98
2 changed files with 41 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

23
docs/rehost-queue.md
View file

@ -45,8 +45,8 @@ Working rule:
`0x0042b2d0`, the optional company filter through `0x0047efe0`, the station-or-transit gate
`0x0047fd50`, and the status branch `0x0047de00 -> 0x0040c990`
- `0x0047efe0` and `0x0047fd50` both consume `[site+0x04]` as the live backing-record selector
- the subtype-`1` constructor strip `0x0040f6d0 -> 0x00481390 -> 0x00480210` is still the only
grounded writer of linked peer id `[site+0x2a8]`
- `0x00480210` writes linked-peer row `[peer+0x04]` from the anchor-site id argument
- `0x0040f6d0 -> 0x00481390` writes the anchor-site linked peer id back into `[site+0x2a8]`
- `0x0047dda0` consumes `[peer+0x08]` as the linked route-entry anchor id
- `0x00480710 -> 0x0048abc0 / 0x00493cf0` is the linked-site refresh and route-entry rebind or
synthesis strip above that anchor lane
@ -56,16 +56,19 @@ Working rule:
five proximity buckets, and the sampled-cell list
- the winning linked company id comes from `[region+0x2a4]`
So the next owner question is no longer “what does the acquisition branch do?” but “which
rebuild owner repopulates the live peer-site identity lanes `[site+0x04]`, `[site+0x2a8]`, and
`[peer+0x08]` once those two save-owner seams finish?”
post-load owner replays the subtype-`1` constructor or linked-site refresh paths for existing
saves once those two save-owner seams finish?”
- Make the next static/rehost slice the peer-site rebuild seam above persistence, not another save
scan:
- rehost or bound how far `0x0040f6d0 -> 0x00481390 -> 0x00480210` already recreates linked
peer id `[site+0x2a8]` and route-entry anchor `[peer+0x08]`
- rehost or bound how `0x00480710 -> 0x0048abc0 / 0x00493cf0` refreshes or synthesizes the
linked route-entry anchor after load
- find the first upstream non-hook owner that reseeds `[site+0x04]` before
`0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50` consume it
- find which post-load non-hook owner actually replays
`0x0040f6d0 -> 0x00481390 -> 0x00480210` for existing saves, now that the concrete writes to
`[peer+0x04]` and `[site+0x2a8]` are grounded
- bound how far the concrete side-refresh callers
`0x0040df27 / 0x0040e00a / 0x0040edf6 -> 0x00480710 -> 0x0048abc0 / 0x00493cf0`
refresh or synthesize `[peer+0x08]` after load
- find the first upstream post-load owner that reseeds `[site+0x04]` before
`0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50` consume it, if that owner is distinct
from the constructor replay path
- 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>`,