GTI_GERENCIADOR_FISCAL/docs/VIABILIDADE_CCG_DFE_V1.md

# 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.