Resolvendo rules com ambiguidade V3 (needs_review)

Por que aparece

Mappings criados antes do V3 usavam destination_field plano (ex: C21201). Após migration V3, esses dest plano podem bater com múltiplos qualifiedName no catálogo destino:

• LIN.C212.C21201 (Item identifier no LIN)
• LIN.PIA.C212.C21201 (Additional Product ID no mesmo loop)

Quando o sistema não tem como decidir qual é o correto, marca a rule com flag _needs_review. Nada quebra — engine V3 ainda processa o dest legacy via fallback. Mas o output pode usar contexto errado.

Como resolver

1. Clique em Filtrar no banner azul → lista só as rules ambíguas
2. Em cada rule, na coluna Destino, aparecem chips coloridos V3 candidates: [path1] [path2] ...
3. Clique no chip do path correto → substitui destination_field + remove a flag
4. Alternativa: clique manter legacy se prefere preservar o destino antigo
5. Alternativa: use + Novo campo pra duplicar a rule e mapear o mesmo source pra N dests (1→N é válido)

Quando rolou a migration?

Migration rodada em 2026-05-21. Mappings novos criados depois disso já saem com paths qualificados — sem _needs_review.