Bound peer-site persistence versus rebuild seams

This commit is contained in:
Jan Petykiewicz 2026-04-18 18:26:04 -07:00
commit 3c2acdee41
2 changed files with 52 additions and 11 deletions

View file

@ -44,11 +44,28 @@ Working rule:
- `0x00420030 / 0x00420280` is the boolean/selector peer-site pair over `0x006cec20`, combining
`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]`
- `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
- the direct `0x36b1` per-record callbacks serialize base scalar triplets
`[this+0x206/+0x20a/+0x20e]` plus the subordinate payload callback strip, and the
`0x4a9d/0x4a3a/0x4a3b` side-buffer owner only persists route-entry lists, three byte arrays,
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
persisted peer-site row fields above `0x004010f0/0x00405920/0x00420030/0x00420280` are the
minimum shellless set: current region key `[site+0x00]`, linked region id `[site+0x04]`,
route-anchor or linked-site handle `[site+0x08]`, and linked company peer id `[site+0x2a8]`?”
rebuild owner repopulates the live peer-site identity lanes `[site+0x04]`, `[site+0x2a8]`, and
`[peer+0x08]` 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
- 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>`,