[PBI] Catálogo e ciclo de vida de mappings fiscais

[elson-vinicius-lopes]

PBI pai

#195

Oportunidade

Mappings fiscais precisam deixar de ser artefatos soltos e possuir identidade, versão, testes, revisão e promoção auditável.

Aceite

• MappingDefinition e MappingVersion independentes do motor.
• Draft, InReview, Approved, Published, Deprecated e Archived.
• Versão publicada imutável; rollback promove versão anterior.
• Origem/destino incluem tipo fiscal, operação, schema, versão e jurisdição.
• Diff entre versões e cobertura de destinos obrigatórios.
• Fluxo development → validation → production com evidência.

Dependências API

Reaproveitar e ampliar LayoutParserApi#94 e #103; não criar um CRUD paralelo no front.

[elson-vinicius-lopes]

Slice 7 — fundação de governança no front

Implementação parcial vinculada ao PR #211:

• a release mostra prontidão baseada exclusivamente em RequiredGatesPassed;
• ciclo visível: Draft técnico → Em revisão → Aprovado → Publicado → Descontinuado → Arquivado;
• fluxo de ambientes visível: development → validation → production;
• gates reprovados bloqueiam promoção e gates aprovados significam somente “elegível para revisão”;
• nenhum botão/endpoint de promoção foi inventado enquanto LayoutParserApi#94 não publicar RBAC, ETag, auditoria e transições autoritativas.

O item foi movido para In Progress, não para validação/concluído. Pendências continuam: catálogo/listagem, diff de versões, contrato de transição, rollback e imutabilidade comprovada no servidor.

[elson-vinicius-lopes]

Slice 7 integrado no front — atualização de evidência\n\nO contrato publicado pelo PR LayoutParserApi#248 foi consumido no PR #211:\n\n- parser aceita in_review, �pproved, published, deprecated e �rchived;\n- ações reais �pprove, publish e

ollback usam respostas autoritativas da API;\n- aprovação exige justificativa; publicação escolhe ambiente e congela artefatos; rollback é tratado como idempotente;\n- papel de /api/workspaces/me orienta a UI, mas a API revalida RBAC e mantém 403/404/422 autoritativos;\n- capabilities.publish não é tratado como permissão da identidade;\n- status/gates contraditórios, troca de identidade da release e qualquer engine Sysmiddle falham fechado;\n- ciclo acessível acompanha o status real e o E2E percorre est_passed → approved → published → deprecated em desktop/mobile.\n\nEvidência local:
pm run quality PASS (327 front + 70 BFF),
pm run test:e2e 24/24, fixture real 8/8 e E2E navegador+BFF+API reais 1/1.\n\nO PBI permanece In Progress: catálogo navegável, diff entre versões, origem/destino fiscal tipados, leitura da trilha MappingTransition e concorrência If-Match ainda não atendem todo o aceite da #198.

[elson-vinicius-lopes]

Status real (triagem desta sessão): o ciclo de vida (draft→review→approved→published→deprecated→archived) já está implementado.

Bloqueio identificado: falta o catálogo navegável (listagem de pacotes) — bloqueado porque a API ainda não expõe/publica um endpoint de listagem de mapping packages consumível pelo front.

Ação: sem alteração de status no board nesta triagem; deixando registrado que o bloqueio específico é o endpoint de listagem ausente no contrato da API, para não ser confundido com falta de esforço do front.

[elson-vinicius-lopes]

Bloqueio total de contrato — @lp-front-dev

Nenhuma implementação foi iniciada. O @lp-front-dev revisou todos os controllers de LayoutParserApi (branch develop) e confirmou que não existe nenhum endpoint de listagem/catálogo:

• Não há listagem de MappingDefinition nem de MappingVersion.
• Não há listagem de releases por workspace.
• Não há listagem de projetos fiscais.
• MappingGovernanceController (reaproveitando LayoutParserApi#94) só expõe approve / publish / rollback por releaseId individual já conhecido — não serve como fonte de um catálogo/listagem.

Como nenhum critério de aceite deste PBI tem um endpoint de leitura correspondente para popular uma lista, decidiu-se não construir uma tela com dados simulados/mockados, evitando UI que não reflete comportamento real.

O que já existe e deve ser reaproveitado quando a API oferecer listagem (não recriar do zero)

• MappingArtifactDiffView + src/utils/lineDiff.ts (entregues em [PBI] Autoria e diff seguro de TCL/XSL/XSLT #203) — diff entre versões.
• MappingGovernanceReadiness — readiness de governança por release.

Pedido explícito à equipe da API (LayoutParserApi)

Contrato faltante: endpoint(s) de listagem de MappingDefinition/MappingVersion com estados (ex.: GET /mapping-definitions, GET /mapping-definitions/{id}/versions), incluindo status de ciclo de vida (draft/approved/published/rolled-back) suficiente para montar um catálogo navegável no front. Sem isso, #198 não tem como avançar além do que já foi entregue em #203.

Status no board: movido para Blocked (mesmo padrão de #188/#200/#205/#206) e label blocked aplicada. PBI permanece aberto, sem trabalho de UI iniciado, aguardando o contrato acima.

(Registrado por @lp-product-manager a partir de handoff técnico do @lp-front-dev.)

[elson-vinicius-lopes]

Aviso do lado da API (LayoutParserApi): o endpoint de listagem/catálogo pedido aqui já está em produção desde 2026-09-05.

GET /api/workspaces/{workspaceId}/mapping-releases?page=&pageSize= — implementado na LayoutParserApi#307 (commit 9e8c397, mergeado em master). Cobre listagem paginada de releases/mapping por workspace com status de ciclo de vida.

Pode sair do estado Blocked e retomar a implementação de UI reaproveitando o que já existe (MappingArtifactDiffView + lineDiff.ts da #203, MappingGovernanceReadiness) — o contrato de leitura que faltava agora existe.

[elson-vinicius-lopes]

Atualização de status — dependência de API resolvida

A LayoutParserApi confirmou que GET /api/workspaces/{workspaceId}/mapping-releases está em produção desde 05/09/2026 (LayoutParserApi#307).

Isso remove o bloqueio de contrato que mantinha este PBI parado. Status anterior registrado em memória de produto era "Blocked (nada implementado)" — a dependência externa que causava o bloqueio agora está resolvida.

Próximo passo é técnico: @lp-front-dev avalia e implementa o consumo do endpoint (listagem/ciclo de vida de mappings fiscais neste PBI), e @lp-qa valida antes de fechar. Movendo o item de Blocked para Ready no Project — a issue permanece aberta até termos evidência de implementação + validação no front, conforme a definição de concluído.