Why. Incumbents bolt record-replay onto runtimes that never captured nondeterminism (rr = person-decades of ptrace heroics, x86/Linux-only, fragile). Our runtime records every nondet input and top-level assignment delta by design, and replay is byte-identical by contract — so a debugger driving a tape gets time-travel (DAP stepBack/reverseContinue — the greyed-out buttons VS Code already renders) nearly for free, plus something no incumbent debugger can show: each variable's observer trajectory.
Honest scoping (the survey's critic corrected the original pitch). The tape currently records L line events + A top-level assignment deltas + N nondet returns — no function-local frames. A DAP server today would inspect globals only: a tape viewer billed as a debugger. So:
- v1 (this issue): a CLI tape-stepper.
eigenscript --step tape: step forward/back over L records, reconstruct top-level bindings from A records at any point, show each binding's trajectory classification alongside its value, breakpoints as line filters, jump-to-line. Ship with docs/DEBUGGING.md unifying tape + temporal interrogatives + the stepper.
- v2 (blocked): locals on the tape — record function-local A-deltas (measure the cost; the trace compile-gate discipline applies).
- v3 (blocked on v2 + tape versioning): src/eigsdap.c — DAP over stdio reusing eigenlsp's JSON plumbing, stepBack/reverseContinue, variables pane with trajectory child nodes, launch config in the canonical VS Code extension, tests/test_dap.py protocol-pinned like test_lsp.py.
Acceptance (v1). Step back through a failing example and watch the culprit binding's trajectory flip; works on a --trace-on-fail tape from the test runner.
Effort: v1 weeks. Source: 2026-07-04 survey (tooling dimension — the flagship story). Depends on: tape-versioning decision for any persisted-tape workflow.
Why. Incumbents bolt record-replay onto runtimes that never captured nondeterminism (rr = person-decades of ptrace heroics, x86/Linux-only, fragile). Our runtime records every nondet input and top-level assignment delta by design, and replay is byte-identical by contract — so a debugger driving a tape gets time-travel (DAP stepBack/reverseContinue — the greyed-out buttons VS Code already renders) nearly for free, plus something no incumbent debugger can show: each variable's observer trajectory.
Honest scoping (the survey's critic corrected the original pitch). The tape currently records L line events + A top-level assignment deltas + N nondet returns — no function-local frames. A DAP server today would inspect globals only: a tape viewer billed as a debugger. So:
eigenscript --step tape: step forward/back over L records, reconstruct top-level bindings from A records at any point, show each binding's trajectory classification alongside its value, breakpoints as line filters, jump-to-line. Ship with docs/DEBUGGING.md unifying tape + temporal interrogatives + the stepper.Acceptance (v1). Step back through a failing example and watch the culprit binding's trajectory flip; works on a --trace-on-fail tape from the test runner.
Effort: v1 weeks. Source: 2026-07-04 survey (tooling dimension — the flagship story). Depends on: tape-versioning decision for any persisted-tape workflow.