docs: Missão 5 addendum (Z.1-Z.6) - correct labels, add tables, adopt VERSIONING.md

Z.1: KB conflict counts were reported as ROW counts (kb_knowledge rows), not
DISTINCT GTIN counts - a single conflicted product with 2 competing NCM
candidates produces 2 rows, doubling the apparent conflict count. Real
number, measured directly in production: 262 distinct GTINs in CONFLICT
(all under knowledge_key=ncm), matching the ~264 baseline closely - no real
growth, just a row-vs-GTIN counting mismatch in the earlier report.

Z.3: corrected the Missão 4 claim that NFCE_ITENS was the "fonte encontrada"
for what PIS/COFINS was actually transmitted - that overstated certainty.
Relabeled PISCOFINS_FONTE_TRANSMITIDA = NÃO_CONCLUSIVO in
docs/PISCOFINS_TRANSMITTED_SOURCE_V1.md and both dossiê copies: a blank
NFCE_ITENS column is equally consistent with "nothing was transmitted" and
"the SGV transmitted a value in the XML but never wrote it back to that
column" - we cannot tell without the actual XML.

Z.4: docs/AUTOFILL_SAFE_3_CELULAS_V1.md - table of the 3 real AUTO_FILL_SAFE
cells (000801/000802 CFOP, 000697 IPPT) with proposed value, field_contract
rule and concrete evidence for each.

Z.5: docs/NCM_27_BLOCKED_PRODUCTS_V1.md now marks the 15 test/garbage-named
products as "produto de teste" in the kb.attest queue (still counted in
coverage, just lower priority); the 3 legacy + 5 out-of-table NCMs are
flagged for reclassification once the official NCM catalog (Fase 2 of this
mission) is loaded and approved.

Z.6: CLAUDE.md records independent Hub/Agent versioning (docs/VERSIONING.md)
as the adopted standard going forward.

No schema/migration change. No Firebird write anywhere.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/AUTOFILL_SAFE_3_CELULAS_V1.md

@@ -0,0 +1,14 @@
+# As 3 células AUTO_FILL_SAFE reais (Agent 2, pós-correção do motor) — Missão 5 / Z.4
+
+Evidência: `docs/runs/GTI_dryrun_universe.ndjson.gz` (dry-run read-only, pós-fix Bloco A.1).
+
+| Produto | Campo | Valor atual | Valor proposto | Regra (`field_contract`) | Evidência concreta |
+|---|---|---|---|---|---|
+| 000801 PEIXE TILAPIA FILE S/ ESPINHAS | CFOP | (em branco) | 5102 | `DERIVED_FROM_ROLE_AND_ST_FILLING_BLANK` | `C000025.TIPO=VENDA` + documento de compra em `C000088`/estoque em `C000100` comprovam papel RESALE; sem substituição tributária (ST) declarada para este item — 5102 é o CFOP de venda de mercadoria de revenda, intra-UF, sem ST. Campo estava vazio (preenche, nunca sobrescreve). |
+| 000802 PEIXE CORVINA POSTA | CFOP | (em branco) | 5102 | `DERIVED_FROM_ROLE_AND_ST_FILLING_BLANK` | Mesma evidência do item acima (RESALE + sem ST), mesmo produto-tipo (peixe fresco vendido a granel). |
+| 000697 SUCO DE GRAVIOLA GTI | IPPT | T (terceiros) | P (própria produção) | `DERIVED_FROM_PRODUCT_ROLE:PROD_COZINHA=1,RECEITA_INGREDIENTES` | Evidência **direta**, não estatística: `C000025.PROD_COZINHA=1` (produto roteado para a cozinha) **e** existe uma linha em `RECEITA_INGREDIENTES` ligando este código a uma receita real — as duas evidências, juntas, não dependem do limiar de maioria de `C000032.TIPO=COMPOSICAO` (que é só para o caso mais fraco, estatístico). |
+
+Nenhuma das 3 depende de interpretação fiscal — são derivações determinísticas de papel do
+produto (revenda/produção própria) já comprovado por dados do próprio ERP (documento de compra,
+estoque, receita), não por regra fiscal inventada. Continuam sujeitas ao roteiro de acceptance com
+produtos de teste antes de qualquer escrita real (`docs/CFOP_IPPT_WRITE_CAPABILITY_V1.md`).

docs/NCM_27_BLOCKED_PRODUCTS_V1.md

@@ -48,6 +48,14 @@ por último):
    prioridade baixa: parecem lixo de cadastro de teste deste ambiente, candidatos a limpeza/
    desativação em vez de correção fiscal (fora do escopo desta missão decidir isso).
 
+**Atualização (Missão 5 / Z.5)**: os 15 produtos de nome/NCM obviamente de teste (item 8 acima +
+000761/762/763) ficam marcados como **"produto de teste"** nesta fila — continuam contados na
+cobertura (não são excluídos automaticamente da métrica de completude), só recebem prioridade mais
+baixa de atestação real. Os 3 vencidos (`02071400`) e os 5 fora da tabela vigente
+(`02071200`/`21069091`/`03061300`) serão reclassificados assim que o catálogo oficial de NCM (P1,
+Fase 2 desta missão) estiver carregado e aprovado — sucessor só será aplicado se a tabela de
+correlação for unívoca; sem isso, continuam bloqueando exatamente como hoje.
+
 ## D.3 — caminho mais curto para o humano, sem GTIN
 
 Como nenhum tem GTIN, o caminho mais curto é sempre o mesmo, em ordem de esforço:

docs/PISCOFINS_TRANSMITTED_SOURCE_V1.md

@@ -15,15 +15,21 @@ nos 5 bancos (GTI/Agent 2, CONSTRUCAO, MMMODAS, RINCAO, UNIAO) — mesmo schema
 - `DEOLHONOIMPOSTO` é a tabela oficial da Lei "De Olho no Imposto" (IBPT) — uma tabela de
   **referência nacional** por NCM (carga tributária aproximada nacional/importada/estadual/
   municipal, para exibir no rodapé do cupom), não o PIS/COFINS realmente aplicado por item.
-- **NFCE_ITENS já é a fonte real**: `CST_PIS_COFINS`, `ALIQUOTA_PIS`, `BASE_CALCULO_PIS`,
-  `VALOR_PIS`, `ALIQUOTA_COFINS`, `BASE_CALCULO_COFINS`, `VALOR_COFINS` são colunas simples
-  (não BLOB) já preenchidas pelo próprio SGV ao montar cada nota — são os mesmos valores que vão
-  para o XML enviado à SEFAZ. Sem o XML em si para conferência cruzada, esta é a melhor evidência
-  disponível do que foi realmente transmitido.
+- `NFCE_ITENS` tem as colunas `CST_PIS_COFINS`, `ALIQUOTA_PIS`, `BASE_CALCULO_PIS`, `VALOR_PIS`,
+  `ALIQUOTA_COFINS`, `BASE_CALCULO_COFINS`, `VALOR_COFINS` — colunas simples (não BLOB),
+  presumivelmente preenchidas pelo SGV ao montar a nota. **Mas isso é uma suposição sobre como o
+  SGV funciona internamente, não uma prova**: essas colunas estão em branco para praticamente
+  todos os itens (exceto o episódio isolado de dezembro/2022 no Agent 2), e sem o XML de verdade
+  para comparar, não sabemos se a coluna em branco significa "nada foi transmitido naquele item"
+  ou "o SGV calculou e transmitiu um valor no XML mas nunca gravou de volta nessa coluna do
+  banco". As duas explicações são compatíveis com os mesmos dados.
 
-**FONTE_ENCONTRADA**: `NFCE_ITENS` (colunas de PIS/COFINS por item), não um XML/BLOB.
-Tabelas inspecionadas e descartadas: `XML_MES` (só caminho de arquivo), `CARTA_CORRECAO`,
-`MDFES`/`MDFES_XML`, `DEOLHONOIMPOSTO` (referência nacional, não por item).
+**PISCOFINS_FONTE_TRANSMITIDA = NÃO_CONCLUSIVO** (corrigido nesta missão — a Missão 4 chamou
+`NFCE_ITENS` de "fonte encontrada", o que superestimava a certeza: é a *melhor evidência
+disponível no banco*, não uma confirmação do que foi de fato transmitido). Tabelas inspecionadas
+e descartadas como fonte de XML: `XML_MES` (só caminho de arquivo), `CARTA_CORRECAO`,
+`MDFES`/`MDFES_XML`, `DEOLHONOIMPOSTO` (referência nacional, não por item). Ver Fase 5 (Missão 5)
+para o estudo de viabilidade de ler o XML autorizado no disco via Agent, com opt-in por cliente.
 
 ## C.3 — cobertura, padrão por CRT, relação com o cadastro
 

docs/dossie_contador.md

@@ -71,14 +71,17 @@ dezembro/2022.
   confirmação do "Tratamento padrão de ICMS" no card correspondente, e mesmo assim o motor consulta
   o tratamento antes de propor o código (nunca aplica 102 cegamente).
 
-## Atualização (Missão 4): onde exatamente está guardado o que foi transmitido
+## Atualização (Missão 5): o que foi realmente transmitido é NÃO_CONCLUSIVO
 
 Procuramos por XML/BLOB armazenado nos 5 bancos: **não existe** — o SGV só guarda o *caminho* do
-arquivo XML no disco da máquina, nunca o conteúdo. A fonte real e mais próxima do que foi
-transmitido são as próprias colunas de PIS/COFINS de `NFCE_ITENS` (CST, base, alíquota, valor por
-item) — os mesmos valores que o SGV usa para montar o XML. Isso não muda a conclusão da pergunta
-(a): mesmo sendo a fonte real, essas colunas confirmam que o cadastro do produto nunca é
-consultado. Ver `docs/PISCOFINS_TRANSMITTED_SOURCE_V1.md`.
+arquivo XML no disco da máquina, nunca o conteúdo. As colunas de PIS/COFINS de `NFCE_ITENS` (CST,
+base, alíquota, valor por item) são a melhor evidência disponível no banco, mas **corrigimos aqui
+uma afirmação forte demais da Missão 4**: essas colunas estão em branco para quase todos os itens,
+e sem o XML de verdade não sabemos se "em branco" significa "nada foi transmitido" ou "o SGV
+transmitiu um valor no XML mas nunca gravou de volta no banco". As duas explicações são compatíveis
+com os mesmos dados — por isso a fonte do que foi *efetivamente* transmitido continua
+**NÃO_CONCLUSIVO**. O que continua de pé, com certeza: o cadastro do produto nunca é consultado
+(branco também). Ver `docs/PISCOFINS_TRANSMITTED_SOURCE_V1.md`.
 
 ## Como usar este dossiê