[PBI] Fiscal Test Lab com XSD, cobertura e regressão

[elson-vinicius-lopes]

Epic pai

#195

User story

Como Reviewer fiscal, quero executar fixtures e compreender cada divergência antes de aprovar uma transformação.

Aceite

• executar caso individual e suite versionada;
• validar XML contra XSD e regras fiscais retornadas pela API;
• comparar XML canônico com gabarito;
• mostrar cobertura de destinos obrigatórios e não mapeados;
• divergência navega para regra, evidência e campo de origem;
• exibir correlation ID e artefatos permitidos;
• gate quebrado impede aprovação/publicação;
• layout desktop/mobile e navegação por teclado são utilizáveis.

[elson-vinicius-lopes]

Implementação disponível para validação

O PR #211 integra os contratos entregues pelos Slices 3–5 da API:

• Mapping Studio com explicação canônica TCL/XSLT/Sysmiddle;
• revisão human-in-the-loop com ETag/If-Match e conflito 412 fail-safe;
• Sysmiddle estritamente somente leitura, sem controles de mutação;
• compilação assíncrona, release, artefatos e correlation ID;
• Fiscal Test Lab XSLT individual com XSD, diff, cobertura e provenance;
• fixtures limpas após envio e nenhum conteúdo fiscal em localStorage.

Evidência local: npm run quality PASS (299 testes front + 70 BFF) e npm run test:e2e
PASS (22/22 cenários desktop/mobile).

O item permanece em validação, não fechado. Pendências externas/seguintes: API #231 ainda declara
compile=false nos adapters TCL/XSLT, não explica a release XSLT compilada, não lista releases nem
suites versionadas e não possui runner TCL. A resposta livre de needs_input também ainda não é
persistida pela API. O front não simula nenhum desses contratos.

[elson-vinicius-lopes]

Reavaliação 2026-09-16

Revisão de src/components/mapping-studio/MappingTestLabPanel.tsx (668 linhas) e
src/services/api/mappingReleaseService.ts.

Entregue:

• Validar XML contra XSD e regras fiscais retornadas pela API (testRunSummary.xsdValid,
  xsdErrors).
• Comparar XML canônico com gabarito (divergences/divergencesByRuleId).
• Cobertura de destinos obrigatórios exibida (release.requiredCoverage,
  testRunSummary.coveragePercent) — via API#380/#379, ambas CLOSED e consumidas.
• Divergência navega para regra/evidência/origem (agrupamento por ruleId, toggle "Agrupar
  divergências por regra").
• Correlation ID exibido (release.correlationId).
• Gate quebrado impede promoção: diagnóstico bloqueante (error/fatal) impede disparo do
  Test Lab e MappingGovernanceReadiness bloqueia promoção sem regressão aprovada.
• Diff de artefato via MappingArtifactDiffView (A×B entre releases).

Gap real remanescente:

1. "Executar caso individual e suite versionada" — hoje só existe execução de um
   fixture por vez (createTestRun recebe um único inputXml/expectedXml). Não há
   contrato nem UI para rodar uma suíte versionada de múltiplos casos de uma vez. Não
   encontrei em mappingReleaseService.ts/types/mappingRelease.ts nenhum tipo ou endpoint
   de suíte/batch, nem issue aberta na API para isso — é gap real dos dois lados, mas
   sem contrato de API não há o que o front implemente sozinho.
2. Engine TCL: mesma limitação já registrada em [PBI] Mapping Studio: autoria TCL/XSL/XSLT e explicação read-only Sysmiddle #199 — sem runner determinístico, o gate de
   Test Lab não pode ser aprovado para TCL (aviso explícito na UI).
3. "Layout desktop/mobile e navegação por teclado" — não validei manualmente breakpoints
   mobile nesta rodada (fora do escopo desta reavaliação de PM); recomendo QA/UX confirmar
   antes de fechar.

Mantendo em In Validation — Test Lab de caso único está sólido e em produção, mas
"suite versionada" (parte central do título do PBI) não existe ainda em nenhuma camada.

[elson-vinicius-lopes]

Dependência criada na API: LayoutParser/LayoutParserApi#423 — contrato de suíte de teste versionada no Fiscal Test Lab (múltiplas fixtures, histórico entre execuções). Status aqui não muda; aguardando avaliação/priorização do lado da API.