packages/lsp/README.md

# lsp/ - LSP capability family

English | [中文](README.zh.md)

The language-server capability seam: an abstract LSP interface, a generic stdio provider, and the model-facing `lsp` tool. All **product** packages.

| Package | Role | ctx key |
|---|---|---|
| `lsp/` | Abstract LSP seam (provider registry by branded id + extension mapping, per-query selection, vocabulary, `LspError`) | `ctx.lsp` |
| `lsp-local/` | Generic multi-server local backend (spawn, JSON-RPC, transient-open queries) | (registers providers on `ctx.lsp`) |
| `tool-lsp/` | Model-facing `lsp` tool (four operations, one-based UTF-16 cursor coordinates) | (registers on `ctx.tools`) |

The interface lives at `lsp/lsp/`. The seam exposes exactly four semantic operations — `goToDefinition`, `findReferences`, `goToImplementation`, `hover` — and no generic JSON-RPC escape hatch, so a provider swap does not change how the model asks for navigation and no protocol payload or unreviewed mutation reaches the model contract. Providers register **capabilities**, not tools; `tool-lsp` is the only owner of the model-facing name, schema, prompt guidance, and presentation.

See the [LSP capability seam Agent Note](../../.agents/notes/implemented/architecture/2026-07-15-lsp-capability-seam.md) for the design rationale, including why documents open transiently per query, why the local host reads through Node APIs rather than `ctx.fs`, and why extension ownership is exclusive within one runtime.
feat(lsp): LSP capability seam, generic stdio provider, and lsp tool 2026-07-16 12:05:35 +08:00			`# lsp/ - LSP capability family`

docs: translate remaining READMEs 2026-07-26 05:03:53 +08:00			`English \| [中文](README.zh.md)`

feat(lsp): LSP capability seam, generic stdio provider, and lsp tool 2026-07-16 12:05:35 +08:00			The language-server capability seam: an abstract LSP interface, a generic stdio provider, and the model-facing `lsp` tool. All product packages.

			`\| Package \| Role \| ctx key \|`
			`\|---\|---\|---\|`
			\| `lsp/` \| Abstract LSP seam (provider registry by branded id + extension mapping, per-query selection, vocabulary, `LspError`) \| `ctx.lsp` \|
refactor(lsp): configure local servers together 2026-07-16 17:31:20 +08:00			\| `lsp-local/` \| Generic multi-server local backend (spawn, JSON-RPC, transient-open queries) \| (registers providers on `ctx.lsp`) \|
feat(lsp): LSP capability seam, generic stdio provider, and lsp tool 2026-07-16 12:05:35 +08:00			\| `tool-lsp/` \| Model-facing `lsp` tool (four operations, one-based UTF-16 cursor coordinates) \| (registers on `ctx.tools`) \|

fix(lsp): align operations and harden lifecycle 2026-07-21 13:29:40 +08:00			The interface lives at `lsp/lsp/`. The seam exposes exactly four semantic operations — `goToDefinition`, `findReferences`, `goToImplementation`, `hover` — and no generic JSON-RPC escape hatch, so a provider swap does not change how the model asks for navigation and no protocol payload or unreviewed mutation reaches the model contract. Providers register capabilities, not tools; `tool-lsp` is the only owner of the model-facing name, schema, prompt guidance, and presentation.
feat(lsp): LSP capability seam, generic stdio provider, and lsp tool 2026-07-16 12:05:35 +08:00
Merge origin/master into lsp 2026-07-20 13:54:38 +08:00			See the [LSP capability seam Agent Note](../../.agents/notes/implemented/architecture/2026-07-15-lsp-capability-seam.md) for the design rationale, including why documents open transiently per query, why the local host reads through Node APIs rather than `ctx.fs`, and why extension ownership is exclusive within one runtime.