prometeu-studio/discussion/workflow/plans/PLN-0104-introduce-frontendprovider-registry-api.md

id	ticket	title	status	created	ref_decisions	tags
PLN-0104	multi-frontend-provider-contract	Introduce FrontendProvider registry API	open	2026-07-15	DEC-0040	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/...