[M10] Language services and LSP

[Teakowa]

Goal

Build native language services and an LSP server on top of Wright's proven frontend, compiler/session, and semantic-service layers without coupling editor concerns into compiler core.

Scope

• Define the document/workspace model needed by language services.
• Reuse native .opy parsing, source provenance, semantic indexing, CFG, diagnostics, and toolchain/session APIs.
• Provide diagnostics, completion, hover, references, rename, semantic tokens, and related editor-neutral language services where they provide clear value.
• Support project/include awareness using the same source/project model as the CLI.
• Keep LSP as a protocol adapter over Wright-owned language-service contracts.
• Validate responsiveness, stale-version behavior, project/source correctness, and representative client interoperability.
• Treat true in-flight cancellation according to the evidence-backed contract resolved in [M10 planning] Reconcile cancellation and responsive-analysis contracts #75 rather than assuming historical wording is permanently correct.

M10 baseline sub-issues

• [M10] Define editor-neutral language-service and workspace model #63
• [M10] Add incremental parsing, dependency invalidation, and reanalysis #64
• [M10] Implement diagnostics, hover, definition, and reference language services #65
• [M10] Implement completion, rename, and semantic token services #66
• [M10] Implement LSP server as a thin protocol adapter #67
• [M10] Validate LSP client compatibility, responsiveness, and workspace behavior #68

M10 correctness closure

• [M10 correctness] Make diagnostics source-aware and dependency-reactive #72 — source-aware diagnostics, dependency-reactive refresh, and stale included-source diagnostic retirement
• [M10 correctness] Implement project-wide semantic rename #73 — project-wide semantic rename (identifier-exact semantic occurrences and version-aware LSP edits accepted on 2345536; CI run 31698428421 green)
• [M10 correctness] Harden LSP URI, UTF-16, and document lifecycle boundaries #74 — LSP URI, UTF-16, and lifecycle hardening
• [M10 planning] Reconcile cancellation and responsive-analysis contracts #75 — reconcile cancellation/responsive-analysis contracts
• [M10] Validate language-service milestone and reassess post-M10 roadmap #69 — independent final acceptance and post-M10 reassessment (accepted on f84e43e, CI run 31701527539)

Non-goals

• Shipping a VS Code extension, browser extension, or editor-specific UI.
• Duplicating compiler/session orchestration inside the LSP server.
• Making LSP types part of Wright's compiler or IR contracts.
• Expanding M10 with debugger, CodeLens, inlay hints, formatter, decompiler, or unrelated post-M10 tooling.
• Building sophisticated incrementality/cancellation without measured evidence.

Exit criteria

• Editor-neutral language services provide the declared diagnostics/navigation/refactoring capabilities over Wright's real project model.
• Source identity is preserved correctly across diagnostics, navigation, and multi-document edits.
• Standard LSP clients can consume those capabilities through a thin protocol adapter with correct URI/path, UTF-16, lifecycle, and version semantics.
• Included/open-overlay changes cannot leave dependent semantic results presented as current, including diagnostics previously published for included sources that are no longer diagnostic owners after a project/include change.
• Multi-file rename and diagnostics follow the same Wright-owned source/project semantics as the compiler/toolchain; rename edits target semantic occurrences rather than unrelated same-spelled text.
• Responsive behavior is validated against correctness/performance evidence, and the authoritative cancellation contract is internally consistent.
• No Wright-owned editor extension is required.
• [M10] Validate language-service milestone and reassess post-M10 roadmap #69 performs a fresh independent architecture/roadmap assessment after all correctness closure work is complete and current GitHub CI is green.

Planning note

All bounded M10 correctness issues (#72–#75) are now independently accepted. Do not add new implementation scope unless #69 discovers a concrete acceptance blocker in current repository evidence. The remaining work is #69.

Status

M10 COMPLETE. #69's independent gate accepted the resulting current repository state on f84e43e (green CI run 31701527539, all six jobs executed). #72–#75 correctness closure accepted; language-service/LSP scope delivered with deferred capabilities (true in-flight cancellation, diff-based incremental reanalysis) recorded per #75 and in the #69 gate writeup.

[Teakowa]

Milestone complete: sub-issues #63–#68 and final gate #69 are closed with language-service and LSP-harness evidence (commits 7b0d0f2, c5c8523); gate #69 records the M0–M10 audit, remaining gaps, and post-M10 recommendations.

[Teakowa]

M10 revalidated after remediation: sub-issues #63–#68 and the final gate #69 were reopened, fixed, and re-verified (client document versions, applicable rename edits, cross-file navigation, workspace root + open-document overlays, context-aware completion, semantic-identity tokens, UTF-16 positions, latency/memory evidence). See the #69 gate writeup for the four-way classification and post-M10 recommendations.

[Teakowa]

M10 complete: sub-issues #72–#75 closed and independently audited; #69 independent gate closed with green CI on dc08e12 (run 31680132988).