8.6 KiB
Integrated LSP Semantic Read Phase Specification
Status
Active
Applies To
prometeu-studioprometeu-vfsprometeu-lsp- the integrated frontend semantic phase in the Studio
Code Editorworkspace
Purpose
Define the normative Studio contract for the integrated frontend semantic-read phase that arrives before any frontend editing release.
This specification stabilizes:
- the phase boundary between semantic ownership and frontend editing ownership,
- the ownership relationship between
prometeu-vfs,prometeu-lsp, and the Studio editor, - the minimum semantic capability set for frontend documents,
- the dedicated semantic surface used for structural anchors and guide-aware editor structure,
- the packaging expectations for the public
prometeu-lspAPI surface, - and the explicit exclusions that remain outside this phase.
Authority and Precedence
This specification extends:
If this document conflicts with shell-wide Studio rules, shell rules control shell behavior, the Code Editor specification controls workspace-local editor UX, the VFS specification controls document-boundary ownership, and this document controls the integrated semantic-read phase itself.
Normative Inputs
The integrated semantic-read phase must assume:
- frontend-scoped documents may be editable under the controlled write wave exposed by
prometeu-vfs, - editable supported documents remain governed by the controlled write wave,
FrontendSpec.allowedExtensionsremains the source of truth for frontend scope,FrontendSpecis the canonical source of frontend semantic presentation contract data,prometeu-vfsowns document state, snapshots, persistence, and access policy,- and semantic-read over editorial snapshots must remain separate from build-facing ownership.
Phase Boundary
This phase is a semantic phase for frontend documents, not an ownership phase for frontend editing.
Rules:
- no capability in this phase may override
prometeu-vfsaccess policy, save policy, or snapshot ownership; - completion, rename, code actions, and formatting remain outside this phase.
Ownership Rules
prometeu-vfsowns document state, access policy, editorial snapshots, and persistence.prometeu-lspis a semantic consumer aboveprometeu-vfs.- the Studio
Code Editorowns UX surfaces that render semantic-read output. - each frontend owns its semantic vocabulary and semantic presentation resources.
- build-facing document ownership remains outside this phase.
prometeu-lsp must not become the owner of:
- save,
- persistence,
- document access policy,
- frontend semantic presentation assets,
- or frontend edit-right release.
Document Source-of-Truth Rules
- opened frontend documents must be analyzed from the in-memory snapshot exposed by
prometeu-vfs; - unopened frontend documents may be analyzed from filesystem-backed state exposed through the same
prometeu-vfsboundary; - Studio UI code must not bypass
prometeu-vfswith ad hoc file loading for semantic-read behavior; - semantic-read over editorial snapshots must not be treated as canonical build input by implication.
Minimum Capability Set
The minimum semantic capability set of this phase must include:
- diagnostics for frontend documents;
- document symbols for frontend documents;
- workspace symbols for frontend documents;
- outline-facing structural symbol data;
- go-to-definition for frontend documents;
- frontend semantic highlight.
The phase may ship the dedicated structural-anchor surface after the baseline capability set is stable, but Studio and frontend implementations must treat that surface as the canonical source of exact scope-indicator anchoring once it exists.
The phase may also ship a dedicated inline-hint semantic surface.
Once shipped, frontend and Studio implementations must treat that surface as the canonical source of decorative inline hint payloads.
Highlight Ownership Rules
- frontend highlight must come from semantic information provided through
prometeu-lsp; - frontend highlight must use frontend-owned semantic presentation contract data derived from
FrontendSpec; prometeu-lspmust expose a dedicated semantic presentation descriptor derived from the resolvedFrontendSpec;- that descriptor must remain simple and include frontend-owned
semanticKeysplus frontend-ownedresourcesin the same message surface; prometeu-lspmust not collapse frontend semantic keys into host-owned generic categories;- Studio must project semantic keys mechanically to CSS classes without semantic translation;
- frontend semantic presentation resources must remain under frontend
resources/and be resolved like ordinary Java resources; - when semantic presentation descriptor data or usable resources are absent, Studio must continue without semantic highlight;
- this condition must not become a product-facing Studio error and may at most produce normal development logs;
- non-frontend highlight may remain on the existing Studio-local highlighting path in this phase.
Inline Hint Ownership Rules
- frontend inline hints must come from semantic information provided through
prometeu-lsp; - frontend hint existence and hint payload semantics remain frontend-owned;
prometeu-lspmust expose a dedicated transport contract for inline hints rather than relying on Studio-local inference;prometeu-lspmust preserve deterministic anchor information required for host rendering;prometeu-lspmust not invent host-owned hint policy when a frontend does not publish hints;- Studio must render transported hints mechanically as host decorations rather than as document text;
- valid inline hint spans must survive partial degradation when the frontend can still produce them;
- invalid or missing hint spans may be omitted locally;
- Studio must not disable all inline hints for a document solely because some hint spans are unavailable.
Structural Anchor Semantic Surface
Exact structural anchoring for editor scope indicators must not be overloaded into documentSymbols.
documentSymbols remains the outline and navigation surface.
Guide-oriented structure must be exposed through a dedicated semantic surface for structural anchors and related guide metadata.
That dedicated surface must be frontend-owned and language-agnostic.
The contract must describe generic structural positions rather than PBS-specific brace semantics.
The surface must be able to represent structures whose boundaries are expressed by:
- braces;
- keywords;
- indentation-derived blocks;
- or mixed delimiter schemes.
At minimum, the dedicated structural-anchor surface must be able to communicate:
- structural ranges that can participate in active-scope selection;
- immediate parentage or equivalent information needed to recover the nearest ancestor relationship;
- exact structural anchor positions used for guide start and end placement;
- enough structural identity to distinguish the active structural range from its immediate container.
The semantic-read contract must not require Studio to scan source text in order to discover the final structural anchor positions.
Temporary local heuristics may exist only as development aids. They must not become the canonical production contract.
The exact serialized schema of this dedicated surface may evolve in implementation plans, but any accepted schema must preserve the invariants above.
Packaging Rules
The public prometeu-lsp API should follow flat packaging similar to prometeu-packer-api.
Rules:
- public contract surfaces should remain shallow and explicit;
- packages such as
dtos,messages, andeventsare the preferred shape for public API grouping where those surfaces exist; - deep public packaging by internal implementation concern should be avoided;
- runtime or implementation layering may exist internally, but it must not leak into the public contract surface by default.
Non-Goals
- frontend save policy
- completion
- rename
- code actions
- formatting
- build participation inferred from editorial snapshots
- external-editor compatibility requirements
- Studio-owned semantic hint generation
Exit Criteria
This specification is complete enough when:
- the semantic-read versus frontend-editing phase boundary is explicit,
prometeu-vfsandprometeu-lspownership remains unambiguous,- the minimum semantic capability set is explicit,
- frontend and non-frontend highlight ownership is clearly separated,
- and the excluded editing and completion capabilities remain unambiguous.