# Verificação — critérios objetivos de sucesso

Spec usada pelo subagente verificador independente. Cada item é **binário (PASS/FAIL)** com evidência.
O verificador escreve um relatório (`docs/VERIFICATION_REPORT.md`) com PASS/FAIL + evidência por item.
Se algo FALHA, corrige (ou devolve feedback ao implementador), re-roda, e só então entrega para
verificação humana.

## Grupo 1 — Dados / SQL (rodar de verdade)
1. `python3 build/build_data.py` roda sem erro e sai com código 0; log mostra `validacao=OK`. **[PASS se exit 0]**
2. As 4 queries `sql/*.sql` rodam isoladas no BQ sem erro de sintaxe. **[testar cada uma]**
3. `data/` contém: segmentos.json, pagamentos.json, faturamento.json, ecommerce.json, combinada.json, meta.json. **[ls]**
4. **Visão 1:** todo segmento do cubo existe em `segmentos.json` (índice válido); somar o cubo por
   (presente)+(não presente) reproduz o total sem filtro de presença (tolerância arredondamento). **[checar via JSON ou SQL]**
5. **Visão 2:** consolidado = normal + Simples (por segmento/ano); a soma dos drills (CNAE) de um
   segmento ≈ a receita consolidada do segmento no último ano (mesmo universo de códigos). **[amostrar 2-3 segmentos]**
6. **Visão 3:** apenas `source_type='csv_archive'`; redacted/`'########'`/`'Erro de Classificação'` excluídos
   (conferir no SQL); soma dos drills NCM-2 ≈ total do segmento. **[ler v3 + JSON]**
7. **Visão 4:** Σ dos 4 trimestres realizados = anual realizado por segmento (tolerância 0,1%); a série
   trimestral termina em `20261` (T1/26) e tem `proj_from_idx` apontando para o 1º trimestre projetado. **[amostrar segmentos]**
8. **Cobertura crosswalk:** segmento "Outros" (423) não concentra > 35% da receita total da RF. **[log do build]**
9. **Nenhum dado inventado:** os números do dashboard são reproduzíveis pelas queries/crosswalks (o
   `export_excel.py` importa o `build_data` e bate com o JSON — conferir uma série). **[cross-check 1 série]**

## Grupo 2 — Design / navegação (conforme design system)
10. App abre servido por HTTP (`python3 -m http.server`); `app/index.html` carrega `../data/*.json` sem erro de console. **[carregar a página]**
11. Tipografia IBM Plex Sans/Mono; paleta e componentes coerentes com `design/ref/` (bg #F5F6F8,
    primary #2F6DF6, cards 10px, light mode); charts com banda de projeção tracejada + hachura. **[inspeção visual/DOM]**
12. **Seleção de segmento sempre por NOME amigável** — zero códigos crus (401–428) renderizados na UI. **[scan DOM]**
13. **Navegação fluida e 100% clicável:** todas as 4 visões abrem; todos os filtros/toggles/checkboxes/
    chips/linhas de drill respondem e recalculam; troca de visão não quebra estado; nenhum controle morto;
    nenhum erro de runtime no console ao percorrer tudo. **[clicar em todos os controles]**
14. `node --check app/js/app.js` passa (sem erro de sintaxe). **[rodar]**

## Grupo 3 — Confidencialidade
15. Nenhuma string proibida renderizada na UI nem em qualquer `.xlsx`: `SEFAZ`, `NF-e`, `NFe`,
    `Receita Federal`, `Banco Central`, `BCB`, `MDIC`, `Olinda`, nem nomes de tabela BQ
    (`mpv_`, `rfb_setoriais`, `mdic_`, `0_bcb`, `aiDataset`). Fonte exibida = "AltWise". **[grep no DOM renderizado + nas células do xlsx]**

## Grupo 1b — Eixo de cadeia (tipo) e modos temporais
17. `faturamento.json` tem `tipos:[varejo,atacado,industria,servicos]` e `series[seg][tipo][regime][metric]`;
    soma sobre os 4 tipos = total do segmento (consolidado). Drill traz `tipo` por código. **[checar JSON]**
18. `combinada.json`: `rf` é dict por tipo (`rf.todos = soma dos elos`); Σ trimestres realizados de
    `rf.todos` 2024 = anual `rf.todos` 2024 (0,1%). **[amostrar]**
19. Crosswalk cadeia plausível: vestuário (416) tem receita em varejo **e** indústria (confecção); alimentos
    tem atacarejo no varejo. "Outros" (423) ≤ 35%. **[log do build + amostra]**

## Grupo 2b — Novas interações da UI
20. Filtro **Cadeia** (Todos/Varejo/Atacado/Indústria/Serviços) presente em Faturamento e Combinada;
    muda séries/KPIs/drill; em Combinada a linha de e-commerce só aparece em Todos/Varejo. **[clicar]**
21. Modo **Trimestral/LTM/Ano fechado** em Meios de pagamento e Combinada; LTM = soma móvel 4 trimestres;
    ticket LTM = valor LTM ÷ qtd LTM; Ano fechado descarta ano incompleto. **[clicar + conferir 1 ponto]**
22. **Quebra por regime** desenha 2 linhas por segmento (cheia=normal, tracejada=Simples) na mesma cor,
    com legenda. **[clicar; contar linhas = 2×segmentos]**
23. **Tooltips** nos charts mostram série+período+valor; altura do chart reduzida (~25%) e eixo X visível;
    **sidebar de filtros recolhível** funciona; **drill mostra código + descrição** (NCM e CNAE). **[clicar]**

## Grupo 1c — Penetração de cartões (Visões 5 e 6)
24. `mercado.json` existe com `anos_total`, `anos_ecom`, `total`, `ecommerce`. Identidades por segmento/ano:
    `credito+debito_outros = card`; `cred_avista+cred_parcelado = credito`; `p1+p23+p46+p7 = credito`
    (tolerância de arredondamento). **[checar JSON + log do build]**
25. Sem projeção. **`anos_total` = apenas anos com granularidade `classe`** (filtro de varejo disponível,
    hoje 2016–2024); denominador da aba mercado = faturamento **de varejo** (`tipo=varejo`), não o total.
    A série de penetração **não tem quebra** na virada 2015→2016 (ex.: vestuário 416 suave ~77–90%).
    `anos_ecom` termina no último ano MDIC. **[checar JSON: anos_total começa em 2016; penetração sem salto]**

## Grupo 2c — UI das Visões 5 e 6
26. Duas abas novas ("Cartões — mercado" e "Cartões — e-commerce") na navegação; seleção de segmento por
    nome; Chart 1 = penetração com 3 linhas (Total/Crédito/Débito+outros) em %. **[clicar]**
27. Sub-seletor "Decomposição do crédito": Premium+Empresarial (1 linha), À vista×Parcelado (2 linhas),
    Nº de parcelas (4 linhas); tooltips mostram série+ano+%. **[clicar; contar linhas]**

## Grupo 4 — Documentação
16. `docs/` tem os 6 arquivos (ENTRYPOINT, PLAYBOOK_OPERACAO, PLAYBOOK_USO_COMBINADO, MODELAGEM,
    PREFLIGHT_NOVA_FONTE, VERIFICATION). ENTRYPOINT direciona corretamente. **[ls + leitura rápida]**

## Como o verificador deve rodar
1. Ler este arquivo e criar um todo por item.
2. Rodar build, queries, abrir o app servido (usar harness headless se não houver navegador — ex.: jsdom —
   para clicar nos controles e ler o DOM), inspecionar JSONs e xlsx.
3. Escrever `docs/VERIFICATION_REPORT.md`: tabela item → PASS/FAIL → evidência (números, trechos, comandos).
4. Para cada FAIL: aplicar correção mínima no arquivo responsável (sem violar as regras invioláveis do
   `PREFLIGHT_NOVA_FONTE.md`), re-rodar o build/checagem, atualizar o relatório.
5. Repetir até 100% PASS; então sinalizar pronto para verificação humana.

## Regras invioláveis durante a correção
- Somente leitura no BQ (sem TRUNCATE/DELETE/WRITE).
- Não inventar dado; métrica inexistente fica de fora.
- Não citar fonte final em nenhum artefato renderizado.
- Manter idempotência do build.