Correction and exact replay

Pre-terminal undo may be an ordinary package command. Repairing an already committed Attempt is different: it crosses a host-owned correction protocol.

Declare correction support

The package declares a bounded correction schema and terminal policy. A player may send a typed correction intent; the host verifies actor authority, revision, idempotency, package support, and policy before replaying.

Immutable revision flow

Attempt revision 1
  + authorized correction intent
  + exact pinned release bytes
        ↓ deterministic replay
Attempt revision 2
  + rebuilt Measurements/progression
  + Story Event additions/retractions

Both revisions remain inspectable. Derived projections point at the current authorized revision.

Replay has fewer capabilities

A historical replay can render the pinned package player against exact recorded state, but it receives no command or correction capability. “Read-only” is enforced by the host bridge rather than entrusted to a disabled-looking button.

Idempotency and conflicts

• Repeating the same correction request returns the same result.
• A correction against an old expected revision fails visibly.
• Concurrent corrections cannot silently overwrite each other.
• Rebuild failure preserves the prior current revision.
• Story retractions are tied to the corrected source evidence.

Darts example

A member may change a wrongly detected single 20 to bull after completion. The package replays the exact throw sequence with the replacement. Around the Clock interprets Bull as a miss for the current target; X01 interprets it as a score. The connector never decides either meaning.