docs(design): legacy-gameboy-v1 16, where the rung slot sits is the whole archive difference

This commit is contained in:
acamilo 2026-09-23 09:33:10 +00:00
parent 4b6624757b
commit bbb25e1afc

View file

@ -408,10 +408,13 @@ export at `Ready(k)`, whether that export is periodic, a milestone archive or th
save. So a checkpoint whose ratchet ledger names `best = r` always carries the slot saved for save. So a checkpoint whose ratchet ledger names `best = r` always carries the slot saved for
rung `r`. This is a **declared difference** from the legacy loop, which archives a milestone rung `r`. This is a **declared difference** from the legacy loop, which archives a milestone
before capturing the ratchet snapshot. A legacy milestone archive holds `best = r-1` and the before capturing the ratchet snapshot. A legacy milestone archive holds `best = r-1` and the
rung `r-1` snapshot; a ported one holds `best = r` and the rung `r` snapshot. After rung `r-1` snapshot; a ported one holds `best = r` and the rung `r` snapshot. In practice the
`fly-reset-to-milestone` onto a ported archive, a stall rollback therefore returns to the two converge: after `fly-reset-to-milestone` onto a legacy archive, the ratchet captures rung
milestone boundary itself rather than to the previous rung's save, and the attempt counter `r` again on the first safe frame (the rung is above the recorded best) and resets the attempt
starts at the new rung. The operator's confirmation of this difference is requested with the counter. The difference is only where the rung `r` slot sits -- on the exact frame of the climb
(ported) or on the first safe frame after the reset (legacy) -- and it is visible only if the
fly stalls or hits game over before any safe frame, when legacy falls back to rung `r-1`'s save
and the ported loop to rung `r`'s (amended 2026-09-23, review round 2). The operator's confirmation of this difference is requested with the
CUT-01 shadow run. The rule is machine-checked in the step trace: `TraceBehaviour.boundaryActions` CUT-01 shadow run. The rule is machine-checked in the step trace: `TraceBehaviour.boundaryActions`
records the saves and the rollback in order, `TraceOperational.captures` records each capture records the saves and the rollback in order, `TraceOperational.captures` records each capture
with the number of boundary actions before it, and a `TransitionTrace` in which a capture with the number of boundary actions before it, and a `TransitionTrace` in which a capture