Gap
DAP natively specs reverseContinue and stepBack — and nothing else we need. It has no notion of:
- jumping to a timestamp / sequence number
- enumerating checkpoints
- a task timeline, or a logical (task) thread distinct from an OS thread
- reverse-stepping over a goroutine or a future rather than a thread
- retroactive watchpoints and their results
#27 implements listCheckpoints/taskTimeline/jumpToEvent as vendor extensions. Nothing specifies them. Vendor extensions that are merely implemented get reimplemented incompatibly by the next tool; vendor extensions that are specified, versioned, and documented become the thing everyone else adopts. Given there is no open-source competitor in this space, whoever writes this document well defines the interface for native-code time-travel debugging. That is how a tool becomes infrastructure rather than a tool.
Scope
docs/DAP-EXTENSIONS.md: request/response/event schemas, capability negotiation (clients must be able to discover what's supported), versioning policy, and the degradation story for clients that support none of it.
- Cover the full surface, including the ones not yet built: checkpoints, jump-to-sequence, task timeline, logical threads, task-scoped stepping, retroactive watchpoints, waker causality, divergence notification (how does a client render "replay diverged"?).
- Model the logical thread carefully — it is the crux. A DAP
Thread that is actually a task lets unmodified clients (VS Code, nvim-dap) get most of the value with zero changes. Decide whether tasks are threads, or a parallel namespace, and justify it.
- JSON Schema for each request/response so other implementations can validate.
- Reference-client conformance notes: what VS Code does with unknown requests, what nvim-dap does.
Done when
The document is complete enough that a third party could implement a compatible server or client without reading Mirrorscope's source, and #27 is checked against it.
Ref: README §7, §10. Gap: "DAP will need extensions... whoever defines those extensions well becomes the de facto standard."
Gap
DAP natively specs
reverseContinueandstepBack— and nothing else we need. It has no notion of:#27 implements
listCheckpoints/taskTimeline/jumpToEventas vendor extensions. Nothing specifies them. Vendor extensions that are merely implemented get reimplemented incompatibly by the next tool; vendor extensions that are specified, versioned, and documented become the thing everyone else adopts. Given there is no open-source competitor in this space, whoever writes this document well defines the interface for native-code time-travel debugging. That is how a tool becomes infrastructure rather than a tool.Scope
docs/DAP-EXTENSIONS.md: request/response/event schemas, capability negotiation (clients must be able to discover what's supported), versioning policy, and the degradation story for clients that support none of it.Threadthat is actually a task lets unmodified clients (VS Code, nvim-dap) get most of the value with zero changes. Decide whether tasks are threads, or a parallel namespace, and justify it.Done when
The document is complete enough that a third party could implement a compatible server or client without reading Mirrorscope's source, and #27 is checked against it.
Ref: README §7, §10. Gap: "DAP will need extensions... whoever defines those extensions well becomes the de facto standard."