75 lines
3.5 KiB
Markdown
75 lines
3.5 KiB
Markdown
---
|
|
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.
|