--- id: PLN-0107 ticket: multi-frontend-compiler-vs-language-services title: Specify frontend compiler and editorial capability boundary status: done created: 2026-07-15 ref_decisions: [DEC-0041] tags: [compiler, compiler-general, studio, lsp, editor, frontend, multi-frontend] --- ## Briefing `DEC-0041` makes compilation mandatory and editorial language services optional for every frontend. This plan updates the normative compiler-facing documentation so future implementation work has a precise boundary to follow. ## Objective Document the frontend provider contract: compiler capability is required, editorial capabilities are optional, and absent editorial support must not invalidate build, analyze, compile, or backend flows. ## Dependencies - Accepted decision: `DEC-0041`. - Existing `FrontendProvider.compiler()` and `FrontendProvider.languageService()` API shape. - Existing compiler pipeline entrypoint specification. ## Scope - Update compiler specs to state that `FrontendProvider.compiler()` is the required frontend capability. - Define `FrontendProvider.languageService()` as the optional editorial capability boundary. - Document expected fallback behavior for absent editorial capabilities at the compiler/LSP boundary. - Document that build/analyze diagnostics are compiler diagnostics, while editor diagnostics are optional editorial behavior. - Add a short capability vocabulary for completion, hover, definition, signature help, semantic tokens, formatting, rename, and code actions without requiring all of them to exist now. ## Non-Goals - Implement Java API changes. - Migrate PBS editor assistance. - Change LSP behavior. - Split `FrontendLanguageService` into many top-level interfaces. - Choose a plugin or process model for external frontends. ## Execution Method 1. Update `docs/specs/compiler/23. Compiler Pipeline Entry Points Specification.md` with a subsection for frontend provider capability boundaries. 2. State that compiler entrypoints must depend on the compiler capability only and must not require editorial services. 3. Define optional editorial capabilities as host-facing editor assistance, not backend-facing compilation requirements. 4. Record fallback semantics: absent collection-shaped editorial results are empty, absent scalar results are neutral/absent, and protocol unsupported states are explicit where available. 5. Document diagnostics ownership: build/analyze diagnostics are compiler contract output; editor diagnostics may reuse compiler analysis but are not required for frontend validity. 6. Add cross-references to `DEC-0041` and existing frontend provider docs or lessons where appropriate. ## Acceptance Criteria - The compiler spec explicitly separates required compiler capability from optional editorial capability. - The spec states that compile-capable frontends with no language service are valid. - The spec states that absent editorial capability is not a compiler failure. - The spec does not require JSON, RPC, plugin loading, out-of-process frontends, or a wire format. - The spec keeps `FrontendLanguageService` aggregated for now and does not mandate premature feature-interface splitting. ## Tests - Documentation-only plan: run `discussion validate` after updates. - If markdown/spec linting exists locally, run the relevant docs validation task. - Future implementation tests are delegated to `PLN-0110`. ## Affected Artifacts - `docs/specs/compiler/23. Compiler Pipeline Entry Points Specification.md` - `discussion/workflow/decisions/DEC-0041-separate-frontend-compilation-from-editorial-language-services.md` - This plan.