Bound startup compact trigger-kind ownership

This commit is contained in:
Jan Petykiewicz 2026-04-19 00:08:58 -07:00
commit 3bac9a0e0a
2 changed files with 30 additions and 8 deletions

View file

@ -226,6 +226,14 @@ Working rule:
called from world bring-up at `0x00444d92` with trigger kind `8` under shell-profile latch
`[0x006cec7c+0x97]`; so `0x0061039c` currently reads as a startup-time live runtime-effect
application lane rather than an ordinary tagged restore owner
- that `kind 8` branch is ordinary in one important way now too:
restore-side loader `0x00433130` repopulates the live event collection `0x0062be18` from packed
chunk family `0x4e21/0x4e22`, and the event-detail editor strip
`0x004d90ba..0x004d91ed` writes trigger field `[event+0x7ef]` across the full `0x00..0x0a`
range through controls `0x4e98..0x4ea2`, including kind `8` at `0x004d91b3`; so the remaining
startup compact-effect question is no longer whether kind `8` is a special synthetic class, but
which loaded kind-`8` rows in `0x0062be18` can actually reach the placed-structure mutation
opcode families under `0x00431b20`
- the `[site+0x27a]` companion lane is grounded now too:
it is a live signed scalar accumulator rather than a second owner-identity seam, with zero-init
at `0x0042125d` and `0x0040f793`, accumulation at `0x0040dfec` and `0x00426ad8`, direct set on
@ -234,9 +242,11 @@ Working rule:
identify which non-transport persisted source family outside the currently bounded direct
allocator/finalize/store families, the save-side `0x00413440` serializer, the load-side
`0x00413280` cached-source bridge, the checked ordinary replay strip
`0x00444690 -> 0x004133b0 -> 0x0040ee10`, and the startup-time runtime-effect dispatcher lane
`0x00444690 -> 0x004133b0 -> 0x0040ee10`, and the already-bounded loaded runtime-effect lane
`0x00444d92 -> 0x00432f40(kind 8) -> 0x004323a0 -> 0x00431b20` feed the tuple or companion
restore calls that are sufficient to repopulate `[site+0x276]` for shellless acquisition
restore calls that are sufficient to repopulate `[site+0x276]` for shellless acquisition; the
remaining runtime-effect subquestion is now which loaded kind-`8` rows can carry the
placed-structure mutation opcodes rather than whether kind `8` is synthetic
- 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]`