Add 'fiscal/' from commit '102ba84500dbd9655a0471288c3e278652593ca9'

git-subtree-dir: fiscal
git-subtree-mainline: d95165fc8f
git-subtree-split: 102ba84500

fiscal/docs/VIABILIDADE_CCG_DFE_V1.md

@@ -0,0 +1,85 @@
+# Estudos de viabilidade (Missão 5, Fase 5) — decisão recomendada, sem código
+
+## 5.1 — CCG/SEFAZ (consulta de GTIN com certificado) e Distribuição DF-e (XML de compras)
+
+### O que cada serviço exige
+
+- **CCG (Consulta Cadastro de Contribuintes)/consulta de GTIN via SEFAZ**: exige certificado
+  digital ICP-Brasil **do cliente** (e-CNPJ ou e-CPF do contador/contribuinte) para autenticar a
+  chamada ao webservice estadual/nacional. Não existe uma chave "genérica" do GTI para isso — cada
+  cliente autenticaria com o certificado dele.
+- **Distribuição DF-e** (`NFeDistribuicaoDFe`): mesmo requisito de certificado ICP-Brasil do
+  destinatário (o CNPJ que recebeu a nota), usado para baixar XMLs de compra que o Fisco já sabe
+  que aquele CNPJ recebeu — não depende do fornecedor ter enviado nada manualmente.
+
+### Risco de segurança da chave privada
+
+O desenho atual do projeto é deliberado e documentado (`docs/rtc_auto_apply.md`): **o Hub nunca
+tem acesso a nada local do cliente** (sem chave, sem certificado, sem execução remota). Um
+certificado ICP-Brasil é, na prática, mais sensível que uma senha — normalmente um arquivo `.pfx`
+protegido por senha, ou um token/smartcard físico. Usar isso a partir do Hub (nuvem, fora do
+controle do cliente) exigiria:
+- Ou o cliente **enviar o certificado para o Hub** (nunca deveria acontecer — quebra o modelo de
+  confiança do projeto inteiro, e um vazamento do Hub comprometeria a identidade fiscal de todos
+  os clientes que fizeram isso);
+- Ou o **Agent local** (que já roda na máquina do cliente) fazer a consulta usando o certificado
+  já instalado ali, e devolver ao Hub só o resultado relevante (NCM/GTIN do fornecedor, nunca o
+  XML completo nem o certificado). Isso é tecnicamente viável e é o único desenho que não quebra
+  "o Hub nunca acessa nada local do cliente" — mas ainda é uma consulta à internet **feita pelo
+  Agent**, o que hoje é proibido por regra fixa desta missão ("Só o Hub acessa a internet externa.
+  O Agent não recebe nenhuma chamada externa nova"). Ou seja: **incompatível com o desenho atual
+  sem uma decisão explícita de abrir uma exceção para o Agent**.
+
+### Opt-in por cliente
+
+Mesmo que se decida abrir essa exceção no futuro, o consentimento tem que ser **por instalação**,
+nunca automático — cada cliente tem que decidir explicitamente confiar sua chave/certificado a essa
+finalidade, com escopo claro (o que é consultado, quando, o que é armazenado).
+
+### Esforço estimado (ordem de grandeza, não um cronograma)
+
+- Alto: implica mexer no modelo de segurança do Agent (hoje só lê Firebird local e fala com o Hub),
+  criar um fluxo de configuração de certificado por cliente, tratar renovação/expiração de
+  certificado, e novo tipo de erro/retentativa (SEFAZ indisponível, certificado vencido, etc.).
+  Não é um parser a mais — é uma superfície de segurança nova.
+
+### Decisão recomendada
+
+**Não implementar agora.** O ganho (GTIN/NCM do fornecedor mais confiável) não justifica o
+aumento de superfície de risco e a mudança de desenho ("só o Hub acessa a internet") sem uma
+necessidade concreta e urgente de algum cliente. Reavaliar se/quando um cliente pedir
+explicitamente e aceitar o modelo "o Agent consulta, o Hub nunca vê o certificado".
+
+## 5.2 — XML de NF-e de compra já armazenado nos bancos (evidência declarada)
+
+Como já mapeado (`docs/PISCOFINS_TRANSMITTED_SOURCE_V1.md`), o SGV **não guarda o XML em si** no
+Firebird — só o caminho do arquivo no disco local (`XML_MES.CAMINHO_XML`). Isso muda o desenho
+possível:
+
+- **Viável, com opt-in por cliente**: o Agent (que já roda na máquina, já lê Firebird local) pode
+  ler o arquivo XML autorizado **do disco** (caminho já registrado no banco) — isso não é uma
+  chamada à internet, é leitura de arquivo local, compatível com "o Agent não recebe chamada
+  externa nova" desde que o Hub não peça isso via internet, só o Agent decida ler o que já está
+  no disco dele mesmo.
+- O Agent extrairia **apenas** NCM/CEST/EAN do fornecedor (campos declarados na nota de compra,
+  identificados como DECLARADO — nunca VERIFICADO), agregados, sem dado pessoal (nunca nome do
+  fornecedor, CNPJ, endereço, valores) — um novo "tier" de evidência na KB, mais forte que uma
+  simples observação de cadastro, mas ainda não uma fonte oficial de classificação fiscal:
+  **consenso entre notas de compra não é verdade fiscal** (o fornecedor pode errar o NCM tanto
+  quanto o cliente).
+- Esforço: médio — parser de XML de NF-e (schema já público/estável), sem certificado nem
+  internet nova; o risco real é performance (muitos arquivos por cliente) e tratamento de arquivo
+  ausente/corrompido (comum em bases antigas).
+
+### Decisão recomendada
+
+**Viável como próxima etapa concreta**, com opt-in explícito por instalação (o Agent só lê os XMLs
+se o cliente autorizar), e resultado tratado sempre como evidência DECLARADA (nunca promovida
+automaticamente a VERIFIED_KB). Recomendo priorizar isso sobre CCG/Distribuição DF-e — mesmo
+ganho de evidência, risco de segurança muito menor (sem certificado, sem chamada externa nova).
+
+## 5.3 — Open Food Facts
+
+Confirmado: continua útil **só como identidade de produto** (nome/marca/unidade a partir do GTIN),
+nunca como fonte de classificação fiscal (NCM/CEST/CST) — a base não tem esse dado e não deveria
+ser tratada como se tivesse. Nenhuma mudança de uso recomendada.