lsp

The editor spawns `pds lsp` as a child process and drives it over stdio.

• given an editor that speaks the Language Server Protocol
• when it needs language support for a .pds document
• then it spawns `pds lsp` as a child process
• and the server reads requests and writes responses over stdin and stdout

Every change re-checks and republishes diagnostics for the whole workspace.

• given a document open in the editor
• when the editor sends didOpen, didChange, or didClose
• then the store re-converges from the document's current text
• and every module's diagnostics are published against its own file
• but a cross-file issue surfaces in the file that causes it

Full document sync: each change carries the entire new text.

• given the server advertised full text-document sync
• when the editor sends a didChange notification
• then the last content change carries the whole new document text
• and the store replaces the buffer wholesale rather than patching a range

All requests are answered from the document's current source.

• given a document with unsaved edits open in the editor
• when the editor requests hover, definition, completion, or formatting
• then the active buffer's current text is handed to lsp_core
• but the on-disk version is not consulted while a buffer is open

The server owns no language logic — it delegates to lsp_core.

• given a request that needs parsing, checking, resolution, or formatting
• when the server handles it
• then every language answer is computed by the lsp_core handlers
• and checking delegates to the model crate
• but the server adds no language rules of its own — only transport, the disk walk, and URI mapping

Go-to-definition jumps to the declaring span, across files.

• given the cursor on a reference to a node, member, or data type
• when the editor requests go-to-definition
• then lsp_core resolves the reference to its declaring module FQN and span
• and the server maps that FQN back to its file URI, even in another module