72 lines
3.1 KiB
Markdown
72 lines
3.1 KiB
Markdown
---
|
|
id: PLN-0103
|
|
ticket: multi-frontend-provider-contract
|
|
title: Specify frontend provider and registry contract
|
|
status: done
|
|
created: 2026-07-15
|
|
ref_decisions: [DEC-0040]
|
|
tags: [compiler, compiler-general, studio, frontend, registry, multi-frontend]
|
|
---
|
|
|
|
## Briefing
|
|
|
|
DEC-0040 locks an explicit `FrontendProvider` contract as the common frontend registration unit. The first implementation step is to make that contract normative in the compiler/general specs before changing code.
|
|
|
|
Domain owner: `compiler/general`, with impact on `studio`.
|
|
|
|
## Objective
|
|
|
|
Specify the frontend provider and registry contract so implementation can introduce the API without relying on implicit behavior or PBS-specific assumptions.
|
|
|
|
## Dependencies
|
|
|
|
- Accepted decision: `DEC-0040`.
|
|
- Existing compiler specs under `docs/specs/compiler/`.
|
|
- Existing Studio/editor references may be linked but must not become the owner of the contract.
|
|
|
|
## Scope
|
|
|
|
- Add or update a compiler/general spec section defining `FrontendProvider`.
|
|
- Define required provider responsibilities:
|
|
- `specification()`;
|
|
- `compiler()`;
|
|
- optional `languageService()`.
|
|
- Define `languageId` as the registry lookup key.
|
|
- Define explicit provider registration as the only supported v1 registration model.
|
|
- Define PBS as the only initial real provider.
|
|
- Define unknown-language failure behavior as explicit and diagnostic-friendly.
|
|
- Define that common code must obtain compiler-facing frontend behavior through provider lookup.
|
|
|
|
## Non-Goals
|
|
|
|
- Do not specify dynamic plugin discovery.
|
|
- Do not specify reflection, classpath scanning, external JAR loading, or runtime plugin installation.
|
|
- Do not introduce a second real frontend.
|
|
- Do not define the full Studio language-service API beyond optional provider capability.
|
|
|
|
## Execution Method
|
|
|
|
1. Inspect existing compiler/general spec organization and choose the nearest owner document for registry and frontend composition.
|
|
2. Add a `FrontendProvider` section with normative `MUST` language for required and optional responsibilities.
|
|
3. Add a registry section stating that providers are resolved by `languageId` and that unknown languages fail clearly.
|
|
4. Add a registration section stating that provider registration is explicit and composition-root-owned.
|
|
5. Add a PBS v1 section stating that PBS is the only initial real provider and no new frontend is introduced by this work.
|
|
6. Cross-reference Studio only as an optional language-service consumer, not as the owner of the provider contract.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- A compiler/general spec defines `FrontendProvider`, registry lookup, explicit registration, and PBS-only initial provider status.
|
|
- The spec prohibits plugin discovery, reflection discovery, scanning, external JAR loading, and runtime plugin installation for this decision.
|
|
- The spec makes `languageService()` optional and does not require editor support for a compilable frontend.
|
|
- The spec is written in English.
|
|
|
|
## Tests
|
|
|
|
- Documentation validation through review against `DEC-0040`.
|
|
- No code tests are required in this plan.
|
|
|
|
## Affected Artifacts
|
|
|
|
- `docs/specs/compiler/...`
|
|
- `discussion/workflow/decisions/DEC-0040-frontendprovider-explicito-como-contrato-de-frontend.md`
|