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

Separate peer-site 0x5dc1 post-secondary byte

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 20:29:58 -07:00
commit a3c867caac
2 changed files with 111 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

22
docs/rehost-queue.md
View file

@ -93,11 +93,13 @@ Working rule:
almost entirely unique while the status kind stays `unset`, and the dominant adjacent payload
delta is `0x00000780` across `1908` steps; grounded `q.gms` shows the same dominant adjacent
delta `0x00000780` across `1868` steps
- the same trace now also promotes the one-byte `0x5dc1` companion lane explicitly: grounded
- the same trace now also promotes the one-byte `0x5dc1` post-secondary discriminator explicitly:
grounded
`p.gms` shows dominant companion byte `0x00` on `2023` rows with only `3` `0x01` rows, and
grounded `q.gms` shows dominant companion byte `0x00` on `2043` rows with only `14` `0x01`
rows; the old “pre-footer padding” hypothesis is now better understood as the probable
`[owner+0x242]` companion lane rather than anonymous slack bytes
rows; the old “pre-footer padding” hypothesis is now better understood as a separate
post-secondary discriminator byte after the repeated secondary payload string, not as the
`[owner+0x242]` field itself
So the next owner question is no longer “what does the acquisition branch do?” or “which post-
load owner replays linked-site refresh?” but “which concrete `0x00455b70` caller family applies
to the live site rows, and which persisted lane becomes the selector bundle that ultimately
@ -128,10 +130,16 @@ Working rule:
(`dominant adjacent delta 0x780` on both `p.gms` and `q.gms`) rather than a compact selector
family, so the next peer-site slice should treat that raw dword as a likely allocator/offset
lane until a stronger selector interpretation appears
- use the new `0x5dc1` companion-byte summary in the same trace as positive evidence:
the probable `[owner+0x242]` lane is overwhelmingly `0x00` with a tiny `0x01` residue on both
grounded saves, so the next peer-site slice should treat that byte as a real typed companion
discriminator and ask which later `0x004014b0` / `0x00406050` predicates actually consume it
- use the new `0x5dc1` post-secondary-byte summary in the same trace as positive evidence:
that byte is overwhelmingly `0x00` with a tiny `0x01` residue on both grounded saves, so the
next peer-site slice should treat it as a real typed discriminator after the restored
`[owner+0x23e]` / `[owner+0x242]` payload strings and ask which later `0x004014b0` /
`0x00406050` predicates actually consume it
- use the new nonzero-companion name-pair summary in the same trace as a narrower acquisition
clue too: grounded `p.gms` exposes only `TextileMill/TextileMill x3`, while grounded `q.gms`
exposes `TextileMill x9`, `Toolndie x2`, and singleton `Brewery`, `MeatPackingPlant`, and
`MunitionsFactory` rows, so the next peer-site slice should treat nonzero post-secondary-byte
rows as a likely industry-like subset rather than a generic placed-structure mode split
- treat the peer-site selector seam itself as grounded enough for planning purposes
- use the new structured restore/runtime field split in the same trace:
restore subset