dsh-follow-edits

LIMITATIONS

Known limitations

- **The highlight renderer replaces the built-in code preview.** To overlay diff colours it registers a `priority: extension` renderer, so you lose the built-in Shiki syntax highlighting by default (switch back to "Code" in the preview's renderer dropdown). Folding diff colours onto the built-in highlighter is future work. - **Exact line numbers depend on a non-session map.** The host stores `callId → oldStr start line` in an in-memory map during `tools/pre-execute`, and the projection reads it when folding `tool/result`. This is the "apply that reads torn non-session state" pattern called out in `practices.md` (review-tier, not mechanically detectable). The cost: on a cold read/replay the map is empty and the line falls back to a client-side search. - **Shell following is degraded and depends on a recursive watcher.** Shell changes come from `node:fs.watch({recursive: true})` (Windows/macOS support it; **silently unavailable on Linux**); with no before/after content it can only *open* the file; it follows text/code suffixes only and skips `node_modules` / `.git` / `dist` and friends. - **A shell change is delivered on the next session event.** Filesystem events are async and the projection is only recomputed when a session event drives it, so a shell write usually arrives with the event right after it (often the shell's own `tool/result`), or one hop later. - Follows **all** sessions (including background ones). To restrict it to the session in view, filter with `retainedBy.mainView` in `client.js`. - dsh is a developer preview; APIs drift between rc releases.