---
id: PLN-0104
ticket: multi-frontend-provider-contract
title: Introduce FrontendProvider registry API
status: open
created: 2026-07-15
ref_decisions: [DEC-0040]
tags: [compiler, compiler-general, studio, frontend, registry, multi-frontend]
---

## Briefing

DEC-0040 requires common code to resolve frontend behavior through a provider. This plan introduces the API surface in the frontend registry without forcing all consumers to migrate in the same change.

Domain owner: `compiler/general`.

## Objective

Introduce `FrontendProvider` and provider-based registry lookup while preserving existing PBS behavior during migration.

## Dependencies

- `PLN-0103` should define the normative spec first.
- Accepted decision: `DEC-0040`.
- Existing registry module: `prometeu-compiler/prometeu-frontend-registry`.

## Scope

- Add the `FrontendProvider` contract in the frontend registry module.
- Add an optional language-service return shape, using an existing interface if one already exists or a minimal neutral placeholder only if required.
- Add provider registration and provider lookup by `languageId`.
- Add `require(languageId)` or equivalent explicit lookup that fails clearly for unknown languages.
- Preserve compatibility methods during migration if existing consumers still call spec or phase lookup.

## Non-Goals

- Do not register PBS in this plan unless needed for API tests with a simple fixture.
- Do not migrate build pipeline or Studio consumers in this plan.
- Do not add plugin discovery, reflection, scanning, external JAR loading, or runtime plugin installation.
- Do not define a broad editor API.

## Execution Method

1. Inspect `FrontendRegistryService`, `FrontendSpec`, and `FrontendPhaseService` to confirm current method names and package ownership.
2. Add `FrontendProvider` to the registry-facing package with `specification()`, `compiler()`, and optional `languageService()`.
3. Update `FrontendRegistryService` so its primary storage is provider keyed by `languageId`.
4. Add `require(languageId)` or the nearest local naming equivalent for provider lookup.
5. Keep old spec/phase accessor methods as provider-derived compatibility wrappers if they are still used.
6. Add registry unit tests for provider registration, provider lookup, duplicate language handling if currently supported, and unknown-language errors.

## Acceptance Criteria

- `FrontendProvider` exists and exposes all responsibilities required by `DEC-0040`.
- `FrontendRegistryService` can resolve a provider by `languageId`.
- Unknown `languageId` lookup fails with a clear exception or diagnostic message.
- Existing callers can still compile until their migration plan runs.

## Tests

- Registry test: registered provider is returned by `languageId`.
- Registry test: unknown `languageId` fails clearly.
- Registry test: provider-derived spec listing remains correct if compatibility methods remain.
- Run the relevant Gradle test task for `prometeu-frontend-registry`.

## Affected Artifacts

- `prometeu-compiler/prometeu-frontend-registry/src/main/java/p/studio/compiler/FrontendRegistryService.java`
- New `FrontendProvider` contract in the same registry API surface.
- Registry tests under `prometeu-compiler/prometeu-frontend-registry/src/test/...`