---
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`