Mapping editor — cards e métricas

O editor de mapeamento é organizado destino-first: o que o cliente recebe (INVOIC, 850, IDoc, NFe etc) vem antes do source SAP.

Os 6 cards do topo

Da esquerda pra direita:

1. Campos Destino (roxo) — total do catálogo destino. Tamanho da mensagem que vai sair.
2. Destino Coberto (verde) — quantos fields do destino já têm rule ativa (não-ignore). Métrica de cobertura.
3. Obrig. Sem Origem (vermelho) — gargalo principal. Quantos fields obrigatórios do destino estão sem source. Mensagem provavelmente não serializa enquanto > 0.
4. Mapeados por IA (cyan) — rules sugeridas pela IA com destino preenchido.
5. Mapeados Manual (verde) — rules criadas/editadas pelo operador.
6. Campos Origem (azul) — total do catálogo source. Sinal secundário (referência).

Clicar em qualquer card filtra a lista de regras abaixo. Card #3 (Obrig. Sem Origem) tem comportamento especial: lista fica vazia, banner aponta pra view Estrutura destino (esses fields vivem no catálogo, não em regras).

Banner de cobertura

• vermelho quando Obrig. Sem Origem > 0: "X campos obrigatórios do destino sem origem (Y/Z destino cobertos)"
• azul quando 0 obrigatórios faltando + cobertura < 100%: "X campos do destino cobertos (Y/Z)"
• some quando 100% coberto

Chips de filtro

Ordem destino-first:

Todos | Mapeados | Obrig. Sem Origem | Destino Sem Cobertura | IA | Manual | Dados Não Usados | [Conflitos]

• Mapeados — rules ativas com source+destino+não-ignore (sinal "está OK")
• Obrig. Sem Origem — filtro de alerta, mesmo comportamento do card vermelho
• Destino Sem Cobertura — fields destino sem rule (mostra rules com source mas sem dest)
• Dados Não Usados — source sem destino (informativo, não bloqueia)
• Conflitos — só aparece quando há 2+ rules pro mesmo destino

View estruturada

A view "Estrutura destino" mostra os fields do destino organizados em árvore (header + loops). A view "Estrutura origem" agora reconhece navs aninhadas corretamente — to_Item.to_PricingElement.X aparece como sub-árvore de to_Item[*], não como sibling top-level.

Por que destino-first

O Lefia entrega destino preenchido pro cliente/parceiro/sistema downstream. As métricas refletem isso: gargalos do destino (campos obrigatórios faltando) são alarmes; sobras do source ("dados não usados") são apenas informação.