Intrepid/prometeu-studio
Intrepid/prometeu-studio
4
0
Fork 0
Code Pull Requests Activity
prometeu-studio/discussion/workflow/plans/PLN-0106-migrate-common-consumers-to-provider-lookup.md

3.5 KiB
Raw Blame History

id ticket title status created ref_decisions tags
PLN-0106 multi-frontend-provider-contract Migrate common consumers to provider lookup open 2026-07-15
DEC-0040
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.