Snapshot v3 format

Shape

{
  "version": 3,
  "programPath": "fib.penc",
  "programHash": "sha256:abc...",
  "pausedAtIP": 42,
  "pausedAtMs": 1716480000000,
  "state": {
    "ip": 42,
    "valueStack": [...],
    "frames": [
      { "bindings": { "x": { "tag": "int", "v": 10 } } }
    ],
    "effects": [...],
    "timeOverride": null,
    "noReplay": false
  }
}

Effect entries

{
  "ip": 3,
  "invocationCount": 0,
  "effect": "print",
  "recordedValue": { "tag": "unit" },
  "status": "committed",
  "eventName": "approval"   // only for wait_for,
  "waitUntilMs": 1716480060000  // only for wait_until
}

Migration

Snapshot v3 is NOT migratable from v2. Reasons:

• v2 stored Phase 2 step-machine state (control stack + scope graph). v3 stores Phase 3 VM state (ip + value stack + frame chain).
• v2 effect entries were keyed by AST nodeId; v3 keys by bytecode ip.

If you have a v2 snapshot you need to keep going: re-run from source with Phase 3 binaries (don't try to resume).

Why JSON

JSON is verbose, but it makes snapshots:

• Inspectable: cat foo.penz | jq .
• Diffable: a snapshot's diff is its execution diff
• Forkable: cp foo.penz bar.penz creates a real fork
• Migratable to other runtimes: in principle (not yet implemented)

Hash verification

Every snapshot stores the sha256 of its .penc. On resume, the runtime verifies the bytecode hasn't changed. Mismatched hash → resume refused with a clear error. (Phase 4 "live editing" will lift this restriction in controlled ways.)