--- id: PLN-0109 ticket: multi-frontend-compiler-vs-language-services title: Make LSP editorial calls capability aware status: done created: 2026-07-15 ref_decisions: [DEC-0041] tags: [compiler, compiler-general, studio, lsp, editor, frontend, multi-frontend] --- ## Briefing `DEC-0041` requires LSP and Studio consumers to query editorial capability availability before invoking editor-specific behavior. The current LSP bridge still contains PBS-specific editorial logic. This plan migrates LSP editorial calls to capability-aware provider lookup and graceful fallbacks. ## Objective Make LSP completion, hover, signature help, semantic tokens, and future editorial calls resolve the active frontend provider, consult optional language-service capabilities, and return deterministic neutral responses when capabilities are absent. ## Dependencies - Accepted decision: `DEC-0041`. - `PLN-0108` should expose PBS editor assistance through `FrontendProvider.languageService()`. - Existing `FrontendRegistryService` frontend lookup. - Existing LSP baseline messages and tests. ## Scope - Update LSP bridge code to resolve frontend providers rather than hard-coding PBS editorial paths. - Add fallback behavior for absent completion, hover, signature help, and semantic token capability. - Preserve compiler-backed diagnostics through analyze/build paths. - Keep PBS editorial behavior stable when its language service is present. - Document or encode unsupported/neutral responses according to existing LSP baseline message shapes. ## Non-Goals - Add new LSP features. - Change VSCode extension behavior beyond consuming existing baseline responses. - Remove all PBS-specific code in one step if adapter compatibility still requires local mapping. - Make semantic presentation metadata optional; only live semantic token production is optional. ## Execution Method 1. Inspect `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/services/compiler/CompilerLanguageServiceBridge.java` and identify all direct PBS editorial calls. 2. Add a provider-resolution path using `FrontendRegistryService` or the existing registry abstraction for `context.languageId()`. 3. For each editorial endpoint, query `provider.languageService()` and then the relevant capability before invoking implementation behavior. 4. Return neutral fallbacks when absent: - completion: incomplete `false` with empty items; - hover: absent/neutral hover content according to current baseline message constraints; - signature help: empty signatures with stable active indices; - semantic tokens: frontend legend/presentation where available and empty token list when live tokenization is absent. 5. Keep `analyzeDocument` compiler-diagnostic behavior on the compiler pipeline and do not require `languageService()`. 6. Update tests to cover both PBS-present and capability-absent frontends. ## Acceptance Criteria - LSP editorial endpoints do not assume every compiler frontend has editor assistance. - Absent editorial capabilities produce deterministic empty or neutral responses, not compiler failures. - Compiler diagnostics still work without a language service. - PBS editor assistance remains unchanged when PBS language service is available. - Any remaining PBS-specific code is adapter-local and documented as temporary if not removed. ## Tests - Add LSP tests for a compile-only frontend or stub provider with no language service. - Preserve existing `CompilerLanguageServiceBridgeTest` coverage for PBS completion, hover, signature help, and semantic tokens. - Add regression coverage that `analyzeDocument` returns compiler diagnostics independently of editorial services. - Run targeted LSP module tests. ## Affected Artifacts - `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/services/compiler/CompilerLanguageServiceBridge.java` - `prometeu-lsp/prometeu-lsp-v1/src/test/java/p/studio/lsp/services/compiler/CompilerLanguageServiceBridgeTest.java` - LSP baseline message types only if neutral response representation is currently insufficient. - Frontend registry integration points used by LSP.