Design exercise: LSP support via existing extension points (à la Claude Code's lspServers plugins)

Claude Code ships native LSP support and it's worth studying as a design exercise: could mecatl get the same capability purely through its existing extension points — no changes to the core harness kit?

What Claude Code does (read from the shipped binary, 2.1.224)

• The harness embeds a real LSP client. It speaks the protocol directly to a language server: textDocument/didOpen|didChange|didSave, publishDiagnostics, definition, references, implementation, hover, documentSymbol, call hierarchy, semantic tokens.

• Servers are declared, not implemented, by plugins. A plugin manifest carries an lspServers field — inline config or a path to a .lsp.json. The official gopls-lsp plugin is nothing but this (source):

  "lspServers": {
    "gopls": {
      "command": "gopls",
      "extensionToLanguage": { ".go": "go" }
    }
  }
  

  The plugin bundles no binary — gopls must be on PATH. The harness spawns it lazily when a matching file is touched.

• The payoff is zero prompt-context cost: no tool schemas injected. Diagnostics come back attached to edit results; semantic navigation is available without the model asking. Contrast with gopls mcp (the headless MCP server gopls also ships), which exposes explicit tools (go_symbol_references, go_package_api, …) at a per-session context tax.

The design exercise

How close can mecatl get without touching the core?

• Diagnostics after edits looks like a PostToolUse hook on Edit/Write: run gopls check <file> (or a persistent server behind a small shim) and emit findings back into the transcript. Does our hook output channel carry enough to make this useful, or does it only allow/block?
• Navigation/references as tools looks like MCP territory (gopls mcp exists today) — but that reintroduces the context tax the native design avoids. Is there a middle path, e.g. ToolSearch-style progressive disclosure over an LSP-backed toolset?
• Lifecycle is the hard part: a long-lived stateful subprocess per session, lazy spawn on first matching file, didOpen/didChange synchronization with the file tools' writes, workspace-root scoping (our os.Root containment), shutdown on session end. Which of our seams (CommandRunner? hooks? something new) can own a process with that lifecycle?
• If the answer is "none, cleanly" — that's the finding: LSP may be a genuine core capability (a new port, like the provider port), and the exercise tells us where the extension-point boundary actually sits.

Worth noting Claude Code treats it as core too (--bare disables it alongside hooks and plugin sync), while keeping per-language config in plugin space. That split — protocol client in core, server registry in extensions — may be the interesting part to emulate.

Start by tracing the existing PostToolUse hooks around Edit/Write and the CommandRunner, then inspect how os.Root containment and session shutdown are handled. Evaluate whether these extension points can support LSP diagnostics, navigation, and a stateful subprocess lifecycle without core changes. Done means documenting a viable design or clearly identifying where a new core capability is required.