---
id: PLN-0106
ticket: multi-frontend-provider-contract
title: Migrate common consumers to provider lookup
status: open
created: 2026-07-15
ref_decisions: [DEC-0040]
tags: [compiler, compiler-general, studio, frontend, registry, multi-frontend]
---

## Briefing

DEC-0040 forbids common compiler, build pipeline, and Studio code from directly instantiating PBS-specific frontend services. After the registry API and PBS provider exist, consumers must move to provider lookup.

Domain owner: `compiler/general`, with impact on `studio`.

## Objective

Migrate common consumers from direct spec/phase/PBS access to provider-based lookup by `languageId`.

## Dependencies

- `PLN-0104` must provide provider lookup.
- `PLN-0105` must register PBS as a provider.
- Accepted decision: `DEC-0040`.

## Scope

- Audit common compiler, build pipeline, Studio, and app code for direct PBS frontend service construction.
- Replace common code service lookup with provider lookup.
- Make build pipeline frontend execution obtain compiler-facing behavior from `provider.compiler()`.
- Make Studio project language catalog list specifications from providers.
- Keep PBS-specific construction inside PBS provider or composition root only.
- Add or update tests that prove common code does not directly instantiate `PBSFrontendPhaseService`.

## Non-Goals

- Do not remove compatibility registry APIs unless all callers have migrated and the removal is local.
- Do not introduce new frontend behavior.
- Do not change backend IR, validation boundaries, or lifecycle semantics beyond provider lookup.
- Do not implement optional Studio language services that do not already exist.

## Execution Method

1. Search for `PBSFrontendPhaseService`, PBS frontend constructors, `getFrontendPhaseService`, and `getFrontendSpec` usage outside PBS and composition-owned code.
2. Classify each usage as composition-owned, PBS-owned, or common consumer.
3. Update common consumers to resolve `FrontendProvider` by `languageId`.
4. Update `FrontendPhasePipelineStage` so it calls provider compiler behavior rather than direct phase lookup.
5. Update `ProjectLanguageCatalogService` so its catalog is provider-derived.
6. Keep compatibility wrappers only where they reduce migration risk and are provider-derived.
7. Add architectural tests or focused unit tests that fail if common modules instantiate `PBSFrontendPhaseService` directly.
8. Run relevant compiler, build pipeline, Studio, and app tests.

## Acceptance Criteria

- Common compiler/build pipeline/Studio code obtains frontend behavior through provider lookup.
- Direct `PBSFrontendPhaseService` instantiation remains only in PBS provider or approved composition code.
- `ProjectLanguageCatalogService` is provider-derived.
- Unknown `languageId` failures remain clear after consumer migration.
- PBS compile/build behavior remains unchanged.

## Tests

- Unit or integration test: build pipeline resolves PBS through provider and compiles an existing PBS fixture.
- Unit test: Studio language catalog lists PBS from provider specs.
- Architecture test or grep-backed test: common modules do not instantiate `PBSFrontendPhaseService`.
- Existing PBS and build pipeline tests pass.

## Affected Artifacts

- `prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/workspaces/stages/FrontendPhasePipelineStage.java`
- `prometeu-studio/src/main/java/p/studio/projects/ProjectLanguageCatalogService.java`
- Common code currently using `FrontendRegistryService.getFrontendSpec` or `getFrontendPhaseService`.
- Tests in compiler, build pipeline, Studio, and app modules.