prometeu-studio/discussion/workflow/agendas/AGD-0066-multi-frontend-synthetic-test-frontend.md
bQUARKz 35b65bb524
All checks were successful
JaCoCo Coverage #### Project Overview No changes detected, that affect the code coverage. * Line Coverage: 61.37% (17351/28272) * Branch Coverage: 52.31% (6722/12850) * Lines of Code: 28272 * Cyclomatic Complexity: 11325 #### Quality Gates Summary Output truncated.
Test / Build skipped: 15, passed: 601
Intrepid/Prometeu/Studio/pipeline/head This commit looks good
multi FE adjustment agendas
2026-07-15 07:58:23 +01:00

2.4 KiB

id ticket title status created resolved decision tags
AGD-0066 multi-frontend-synthetic-test-frontend Frontend sintetico de teste para provar neutralidade do pipeline open 2026-07-15
compiler
compiler-general
frontend
tests
backend
multi-frontend

Agenda - Criar um frontend sintetico de teste

Objetivo

Domain owner: compiler/general.

Discutir um frontend exclusivo de testes que prove que o pipeline comum nao depende implicitamente do PBS.

Contexto atual

O criterio arquitetural final exige que um frontend sintetico implemente contratos equivalentes a FrontendProvider, FrontendSpec e FrontendCompiler, produza IR comum minima e passe pelo backend ate PBX/verifier.

Escopo

  • Escolher entre frontend totalmente sintetico ou extensao ficticia.
  • Definir fixture de IR minima com frame vazio.
  • Garantir isolamento em testes.

Fora de escopo

  • Expor frontend sintetico no Studio.
  • Criar segunda linguagem real.
  • Criar parser completo ou grammar dummy complexa.

Arquivos e componentes a inspecionar

  • prometeu-compiler/prometeu-frontend-registry/...
  • prometeu-compiler/prometeu-build-pipeline/...
  • testes do build pipeline e backend
  • prometeu-studio/src/main/java/p/studio/projects/... apenas se a selecao por extensao for exercitada

Alteracoes propostas

Opcao A: provider sintetico que ignora arquivos e retorna IR minima diretamente.

Opcao B: extensao .dummy reconhecida em fixture, com conteudo ignorado ou trivial.

Recomendacao inicial: preferir Opcao A para provar neutralidade do pipeline sem criar outra superficie de linguagem.

Estrategia de implementacao

Esperar provider/IR/lifecycle estarem suficientemente definidos, entao adicionar fixture de teste que registra provider sintetico e executa pipeline comum sem PBS.

Testes necessarios

  • Provider registrado e resolvido por languageId.
  • Extensao/source handling testado se a opcao B for escolhida.
  • IR comum produzida, lifecycle montado, IRVM gerado, PBX emitido e verificado.

Criterios de aceitacao

  • Teste falha se pipeline comum instanciar PBS implicitamente.
  • Synthetic frontend existe apenas em test fixtures.
  • PBS nao e afetado.

Riscos

  • Fixture sintetica exercitar caminho feliz pequeno demais e nao proteger acoplamentos reais.
  • Virar uma segunda linguagem informal.

Decisoes que devem ser registradas

  • Forma do frontend sintetico.
  • Escopo minimo da IR fixture.
  • Onde o provider de teste pode ser registrado.