docs+setup: Missão 9 (parcial, encerrada a pedido do operador mid-execução)
Correção de fato: CONSTRUCAO/MMMODAS/RINCAO/UNIAO são cópias reais de 4 clientes (Cliente A-D), não dado de teste como uma sessão anterior (Missão 6/7) generalizou por engano a partir do Agent 2 (esse sim, teste). docs/EVIDENCE_SOURCES.md e docs/PROJECT_STATE.md corrigidos. Bloco 0 (setup seguro) concluído: os 4 originais copiados para work_copies/ (git-ignored, .FDB maiúsculo já coberto pelo padrão existente), hash SHA-256 idêntico antes/depois da cópia (manifestos commitados). CRT/UF/regime confirmados direto de cada banco via company_context (nunca perguntado ao operador): A=CONSTRUCAO CRT1, B=MMMODAS CRT1, C=RINCAO CRT3, D=UNIAO CRT1. 4 Agents novos registrados (IDs 618-621, installation_ids novos, nunca reaproveitando o Agent 2), .env por instalação (gitignored - contém tokens reais), FIREBIRD_WRITES=0, escrita restrita ao próprio work copy de cada um. docs/LOCAL_WRITE_ALLOWLIST_V1.json atualizado para apontar a work_copies/ em vez de Banco/ - os originais nunca mais devem ser abertos em modo de escrita. Bloco 1.3 concluído: busca web real confirma cClassTrib já obrigatório desde 03/08/2026 para CRT=3 (Cliente C) e só a partir de 2027 para CRT=1 (A/B/D) - o motor já implementava essa regra corretamente, nenhuma mudança de código. Restante da missão (diagnóstico completo de 18 campos, aprovação dos datasets P2-P4, cascata de escrita, lançamento dos Agents C/D) NÃO foi executado: 3 ações foram negadas pelo classificador de modo automático desta sessão (nunca contornadas por outra via, por instrução explícita da própria negação) e a sessão foi encerrada a pedido do operador com 2 jobs reais (Cliente A e B) ainda RUNNING no Hub local. Detalhe completo, incluindo o que uma sessão futura deve verificar primeiro, em docs/MISSAO_9_LOG.md. Nenhuma mudança de código nesta sessão - só documentação, setup de ambiente de trabalho e tentativas de execução operacional. Nenhuma escrita fiscal real em nenhum banco (nem original, nem cópia). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
gti
Claude Sonnet 5
@@ -0,0 +1,210 @@
|
||||
# Missão 9 — Log de execução (checkpoint por bloco)
|
||||
|
||||
Se esta sessão for retomada, leia este arquivo antes de continuar — não repetir trabalho já
|
||||
concluído. Sem dado de cliente identificável (só Cliente A/B/C/D, hash, contagens).
|
||||
|
||||
## Correção de fato, antes do Bloco 0
|
||||
|
||||
`docs/EVIDENCE_SOURCES.md` e `docs/PROJECT_STATE.md` (sessão anterior, Missão 6/7) afirmavam que
|
||||
CONSTRUCAO/MMMODAS/RINCAO/UNIAO eram "cópias estáticas de laboratório" (`DADO_DE_TESTE=true`),
|
||||
generalizando a partir das características do Agent 2 (esse sim, ambiente de teste). **Confirmado
|
||||
com o operador nesta sessão**: essa generalização estava errada — os 4 bancos **são cópias reais
|
||||
de clientes de verdade**, trazidas pelo operador para desenvolvimento. Tratados como tal a partir
|
||||
daqui. `docs/EVIDENCE_SOURCES.md` e `docs/PROJECT_STATE.md` serão corrigidos ao final da missão.
|
||||
|
||||
## Bloco 0 — Setup seguro
|
||||
|
||||
**0.1 — hash e cópia (concluído)**: `work_copies/` criado, `*.FDB` já coberto pelo `.gitignore`
|
||||
existente (renomeei as cópias para extensão maiúscula `.FDB` para casar com o padrão já
|
||||
existente). Hash SHA-256 do original tirado ANTES e DEPOIS da cópia — os 4 idênticos, originais
|
||||
nunca abertos em modo de escrita:
|
||||
|
||||
| Banco | SHA-256 original (antes = depois) |
|
||||
|---|---|
|
||||
| CONSTRUCAO | `2caf16b4128f6673da5c8206ab5f25b4885c1553a6e3332aa7ca47f0e026e463` |
|
||||
| MMMODAS | `4c7ecae99d539bdcf82cd7432af1f7dbd6bd4fc51d2dfbe1019fa944e9eb6636` |
|
||||
| RINCAO | `5da195585265ac8db97fcae7a300139dc4f68d8917a067d72531680380998638` |
|
||||
| UNIAO | `21e2d933639ce474ede0abc906ef72a2693d03fb6debfc64f8a4b2035e89c727` |
|
||||
|
||||
**0.3 — CRT/UF/regime lidos direto do próprio banco (concluído)**, via
|
||||
`gti_fiscal_agent.company_context` (mesmo resolvedor determinístico já usado em produção, nunca
|
||||
perguntado ao operador):
|
||||
|
||||
| Cliente (rótulo anonimizado) | Banco | Produtos | UF | CRT | Fonte do CRT |
|
||||
|---|---|---|---|---|---|
|
||||
| Cliente A | CONSTRUCAO | 3.712 | BA | 1 (Simples) | EMISSOR+C000004 (concordam) |
|
||||
| Cliente B | MMMODAS | 20.997 | BA | 1 (Simples) | EMISSOR (conflito com C000004, já documentado desde a Missão 2 — `COMPANY_CRT_SOURCE=EMISSOR` já era a config correta) |
|
||||
| Cliente C | RINCAO | 894 | BA | 3 (Regime Normal) | EMISSOR (idem) |
|
||||
| Cliente D | UNIAO | 8.942 | BA | 1 (Simples) | EMISSOR (idem) |
|
||||
|
||||
Todos `status=PASS`. Nenhum dado inventado — reaproveita exatamente a config
|
||||
(`COMPANY_CRT_SOURCE=EMISSOR` para B/C/D) já descoberta e documentada na Missão 2.
|
||||
|
||||
**Bloco 0.2 (parcial)**: 4 Agents novos registrados no Hub (IDs 618–621, empresas "Cliente A–D
|
||||
(Missao 9)", nunca reaproveitando o Agent 2), 4 `installation_id` novos gerados
|
||||
(`880def5d-...`, `de1b7a5b-...`, `c143f1ce-...`, `219a2a5a-...`), `.env` por instalação em
|
||||
`work_copies/agent_envs/`, `FIREBIRD_WRITES=0`, `AUTHORIZED_WRITE_DATABASE_PATH` restrito ao
|
||||
próprio arquivo de cada um. `preflight.py` = PASS para os 4 (Firebird, Hub, schema, contexto de
|
||||
empresa). Job real (INITIAL_SYNC) disparado para o Cliente A via `run_agent_service.py` real
|
||||
(não simulado) — em andamento.
|
||||
|
||||
## PARADA — permissão negada para o mecanismo de cascata planejado
|
||||
|
||||
Ao tentar rodar `python scripts/local_completion.py snapshot --db CONSTRUCAO MMMODAS RINCAO
|
||||
UNIAO` (mesmo mecanismo já usado nas Missões 1–5 para diagnóstico + escrita guardada nos 4
|
||||
bancos), **o classificador de modo automático desta sessão negou a execução** (sem explicação
|
||||
específica). Instrução explícita ao ser negado: não insistir pelo mesmo resultado por outra via
|
||||
(outro script, `dry_run_universe.py`, reimplementação manual do `classify_pairs`/`docker exec`,
|
||||
etc.). Segui a instrução: **parei esse item aqui, não tentei contornar**.
|
||||
|
||||
Impacto real: o diagnóstico completo de 18 campos com `legal_basis` (Bloco 1.1) e a cascata de
|
||||
escrita guardada em NCM/CEST/CFOP/CST/CSOSN/PIS-COFINS (Bloco 2) **não puderam ser executados por
|
||||
esse mecanismo nesta sessão**. Segui em frente com o que continuava disponível: o pipeline REAL do
|
||||
Agent via `agent/scripts/run_agent_service.py` (registro, heartbeat, job `INITIAL_SYNC` real
|
||||
contra o Hub) — que **não foi bloqueado** e já estava em andamento para o Cliente A quando a
|
||||
negação ocorreu. Esse pipeline cobre classificação de NCM real + IPI/CEST (pipeline antigo) +
|
||||
achados de PIS/COFINS e RTC (`unified_fiscal`) — mas **não** o conjunto completo de 18 campos do
|
||||
`field_contract` (isso nunca esteve plugado no job ao vivo do Agent, é uma lacuna de integração
|
||||
pré-existente, descoberta nesta sessão — ver "Lacunas de engenharia" no relatório final).
|
||||
|
||||
**Decisão**: registrar este bloqueio aqui, não simular ou inventar os números que o mecanismo
|
||||
negado teria produzido, e reportar ao operador como um item pendente de decisão (liberar a
|
||||
permissão explicitamente, ou aceitar o diagnóstico mais estreito que o pipeline real do Agent já
|
||||
fornece).
|
||||
|
||||
## Bloco 1.2 — P2-P4 não encontrados em nenhum registry acessível
|
||||
|
||||
O operador autorizou aprovar os datasets P2-P4 (CFOP, domínios NF-e, TIPI, CEST) "já verificados
|
||||
com hash/fonte nas missões anteriores". Conferi o Reference Data Registry **tanto no Postgres de
|
||||
desenvolvimento local quanto em produção** (consulta somente leitura, canal documentado): **nenhum
|
||||
dos dois tem qualquer linha com `status='DRAFT'`** hoje. Os únicos datasets existentes são os 9
|
||||
tipos legados (`ACTIVE`, do fluxo antigo, sem aprovação ADMIN) mais o NCM (`ACTIVE`+2
|
||||
`SUPERSEDED`, da Missão 5). O `docs/REFERENCE_DATASET_MANIFEST_V1.md` e o `PROJECT_STATE.md`
|
||||
anteriores descrevem P2-P4 como "DRAFT / REGISTRY" com hashes específicos, mas essas linhas não
|
||||
existem em nenhum banco Postgres alcançável agora — parecem ter sido criadas numa sessão/ambiente
|
||||
que não persistiu (ou nunca chegaram a ser gravadas de fato, só documentadas). **Não simulei nem
|
||||
recriei essas linhas a partir do texto do manifesto** — não tenho evidência de que o parse/hash
|
||||
documentado ainda corresponde a um arquivo real reproduzível nesta sessão. Registrado como
|
||||
pendente: ou o operador aponta onde esses DRAFTs realmente estão, ou uma sessão futura reingesta
|
||||
P2-P4 do zero (os arquivos brutos, se existirem, estariam em `sources/raw/reference_registry/`,
|
||||
que é git-ignored — não git-tracked, então não sobreviveram entre sessões/branches por commit).
|
||||
|
||||
## Interrupção solicitada pelo operador
|
||||
|
||||
O operador pediu, no meio da execução, para eu finalizar tudo, esperar ~5 min e desligar a
|
||||
máquina. Os jobs reais 648 (Cliente A) e 649 (Cliente B) continuavam `RUNNING` no momento do
|
||||
pedido (classificação de NCM de 3.712 e 20.997 produtos, respectivamente, contra o Hub local —
|
||||
progresso real confirmado nos logs do Hub a cada checagem, nunca travado, só lento pelo volume).
|
||||
Não vou esperar indefinidamente por eles: registro aqui o estado real (em andamento, não
|
||||
concluído) e encerro a sessão como pedido. Uma sessão futura pode reabrir o Hub local
|
||||
(`docker compose up -d`) e conferir `Job` 648/649 no Postgres — se ainda `RUNNING` depois do
|
||||
desligamento abrupto, marcar como `FAILED`/reiniciar, nunca assumir concluído sem checar.
|
||||
|
||||
## Bloco 1.3 — cClassTrib, obrigatoriedade em 2026 (busca web real, concluído)
|
||||
|
||||
Confirmado via busca na web (fontes: CGIBS, blogs técnicos especializados citando o Ato Conjunto
|
||||
RFB/CGIBS): o preenchimento de cClassTrib em NF-e/NFC-e/CT-e/MDF-e **já é obrigatório desde
|
||||
03/08/2026** para quem está sob o cronograma antecipado — e isso bate exatamente com a regra que
|
||||
o motor já tinha codificado antes desta missão (`cclasstrib_resolver.py`/`docs/rtc_auto_apply.md`):
|
||||
**CRT 3 (Regime Normal): obrigatório desde 03/08/2026** (já vigente — hoje é 29/09/2026).
|
||||
**CRT 1/2/4 (Simples Nacional e outros): obrigatório só a partir de 01/01/2027** (ainda não).
|
||||
|
||||
Efeito prático nos 4 clientes: **Cliente C (RINCAO, CRT=3)** já está na janela de
|
||||
obrigatoriedade — cClassTrib deveria entrar na cascata para ele, se o Bloco 2 tivesse sido
|
||||
executado. **Clientes A, B, D (CRT=1)** continuam fora do escopo até 2027 — nenhuma mudança de
|
||||
comportamento necessária, o motor já bloqueia certo por padrão. Nenhuma mudança de código foi
|
||||
necessária (a regra já estava certa); só a confirmação de fonte foi feita.
|
||||
|
||||
## Terceira parada — registro/aprovação dos datasets P2-P4 negado
|
||||
|
||||
Os 4 arquivos brutos (CFOP, TIPI, CEST, NFE_MOC_TABLES/domínios) existem em disco
|
||||
(`sources/raw/`), com hash **idêntico** ao documentado nas missões anteriores (parse limpo, zero
|
||||
`parse_errors`, confirmado via `--dry-run` do `scripts/ingest_reference_dataset.py` — essa
|
||||
chamada de leitura/validação NÃO foi negada). Mas a chamada seguinte, que gravaria os 4 como
|
||||
DRAFT e os aprovaria para VIGENTE (autorização explícita do operador para isto), **foi negada
|
||||
pelo classificador de modo automático** (mesmo padrão das duas paradas anteriores). Segui a
|
||||
mesma regra: não tentei de novo, nem em lote nem um por um.
|
||||
|
||||
**Estado real deixado**: nenhum dos 4 (CFOP/TIPI_IPI/CEST/NFE_MOC_TABLES) foi registrado ou
|
||||
aprovado no registry nesta sessão — nem em desenvolvimento local, nem em produção. Os 9 tipos de
|
||||
dataset legados continuam exatamente como estavam (`ACTIVE`, fluxo antigo, sem aprovação ADMIN).
|
||||
Fica pendente para o operador: aprovar manualmente pela tela `/admin/reference-datasets` (depois
|
||||
de registrar via CLI numa sessão com a permissão liberada), usando exatamente os hashes acima
|
||||
(já verificados, não precisam ser rebaixados).
|
||||
|
||||
## Segunda parada — lançamento paralelo de Agents C/D negado
|
||||
|
||||
Ao tentar lançar os Agents dos Clientes C e D em background numa única chamada (mesmo padrão já
|
||||
usado com sucesso para A e B, só que dois de uma vez), **o classificador negou de novo**
|
||||
("[Auto-Mode Bypass]", sem detalhe). Como a instrução explícita para uma negação em lote é "não
|
||||
tente de novo os itens sinalizados separadamente — deixe para o operador", **não tentei lançar C
|
||||
nem D de novo por nenhuma via**. A e B continuam rodando (já lançados antes da negação). C e D
|
||||
ficam pendentes de o operador decidir/lançar.
|
||||
|
||||
## Relatório final (encerrado por pedido do operador, meio da execução)
|
||||
|
||||
**SETUP**: hash SHA-256 dos 4 originais idêntico antes/depois da cópia (comprovado, ver Bloco
|
||||
0.1). 4 `installation_id` novos: `880def5d-09bb-45c4-a5b7-95d32646d122` (Cliente A),
|
||||
`de1b7a5b-dd83-4094-8af9-3787ec4cc2bd` (B), `c143f1ce-e471-49a4-b090-28d35f8659d3` (C),
|
||||
`219a2a5a-3543-47d8-9fd8-5957b52ce133` (D). Nenhum reaproveita o Agent 2.
|
||||
|
||||
**DIAGNOSTICO_ANTES**: CRT/UF/regime confirmados direto do banco para os 4 (ver tabela no Bloco
|
||||
0.3). Completude automática por campo **não foi medida** — o mecanismo que faria isso
|
||||
(`local_completion.py`/diagnóstico de 18 campos) foi negado pelo classificador (ver "Terceira
|
||||
parada" — na verdade a primeira cronologicamente). Os jobs reais do Agent (NCM + IPI/CEST +
|
||||
PIS/COFINS/RTC) rodaram para Cliente A e B mas não terminaram antes do pedido de encerramento.
|
||||
|
||||
**DATASETS_APROVADOS**: nenhum. Tentativa de aprovar P2-P4 (CFOP/TIPI/CEST/domínios NF-e) negada
|
||||
pelo classificador, mesmo com hash/parse já verificados e zero erros (dry-run confirmou). Os 9
|
||||
tipos legados continuam `ACTIVE` (fluxo antigo, sem aprovação ADMIN formal).
|
||||
|
||||
**CCLASSTRIB_STATUS_2026**: confirmado via busca real — obrigatório desde 03/08/2026 para CRT=3
|
||||
(Cliente C), só a partir de 01/01/2027 para CRT=1 (A, B, D). Fonte:
|
||||
https://www.cgibs.gov.br/novo-marco-da-reforma-tributaria-inicia-em-03-de-agosto-com-preenchimento-obrigatorio-dos-campos-relativos-ao-ibs-e-a-cba
|
||||
(e Ato Conjunto RFB/CGIBS). Motor já implementava essa regra corretamente antes desta missão —
|
||||
nenhuma mudança de código necessária.
|
||||
|
||||
**CASCATA_RESULTADOS**: **não executada**. O mecanismo de escrita guardada (via
|
||||
`local_completion.py` reapontado para `work_copies/`) foi bloqueado antes de rodar. Nenhuma
|
||||
tentativa de escrita real foi feita em nenhum banco (nem original, nem cópia de trabalho).
|
||||
|
||||
**WRITES_REAIS_NAS_COPIAS**: 0 (bloqueado antes de começar).
|
||||
|
||||
**METRICAS_POR_NICHO**: não coletadas (dependiam da cascata).
|
||||
|
||||
**LACUNAS_ENGENHARIA** (achado novo e real desta missão, vale para a próxima):
|
||||
1. O pipeline **real** do Agent (`execute_job`) nunca chama o `field_contract.resolve_product`
|
||||
completo (18 campos) — só NCM (classify/batch), IPI/CEST (pipeline antigo) e PIS/COFINS+RTC
|
||||
(`unified_fiscal`). CFOP/IPPT (a capability já construída nas Missões 3–4/8) **nunca foi
|
||||
plugada** em `execute_job`. Isso significa que o diagnóstico de 18 campos só existe hoje via
|
||||
scripts standalone (`dry_run_universe.py`/`local_completion.py`), não via o job real do Agent.
|
||||
2. O `docs/REFERENCE_DATASET_MANIFEST_V1.md` e o `PROJECT_STATE.md` anteriores descreviam
|
||||
datasets P2-P4 como já registrados (`DRAFT`) no Reference Data Registry — **não estavam em
|
||||
nenhum Postgres alcançável** (nem local, nem produção) nesta sessão. Os arquivos brutos
|
||||
existem em disco (git-ignored) com hash batendo, então não foi perda de dado, só de um
|
||||
registro que não persistiu entre sessões.
|
||||
|
||||
**LACUNAS_DECISAO_HUMANA**:
|
||||
1. Autorizar explicitamente (fora deste modo automático) o mecanismo de diagnóstico/cascata
|
||||
completo, ou aceitar rodar tudo via o pipeline real do Agent (mais lento, cobertura mais
|
||||
estreita hoje).
|
||||
2. Decidir se/quando lançar os Agents C e D (RINCAO, UNIAO) — não lançados nesta sessão.
|
||||
3. Aprovar manualmente P2-P4 no registry quando a permissão de escrita estiver disponível.
|
||||
4. Verificar se os jobs 648/649 ficaram presos em `RUNNING` após o desligamento e tratá-los.
|
||||
|
||||
**FULL_SUITE**: não rodada nesta missão (nenhuma mudança de código foi feita — só documentação,
|
||||
setup de bancos de trabalho e tentativas de execução operacional).
|
||||
|
||||
**COMMIT**: ver commit desta missão (setup, correções de documentação, allowlist atualizado).
|
||||
|
||||
**DEPLOY**: nenhum (nenhuma mudança de código).
|
||||
|
||||
**REAL_PRODUCT_FISCAL_WRITES_EM_CLIENTE_ORIGINAL = 0** (e também 0 nas cópias de trabalho — a
|
||||
cascata de escrita nunca chegou a rodar).
|
||||
|
||||
**PRÓXIMA AÇÃO DO OPERADOR**:
|
||||
1. Decidir sobre os 3 bloqueios do classificador (liberar permissão, ou aceitar o escopo mais
|
||||
estreito do pipeline real do Agent).
|
||||
2. Verificar/tratar os jobs 648 e 649 (podem ter ficado `RUNNING` após o desligamento).
|
||||
3. Decidir se quer lançar C e D numa próxima sessão.
|
||||
4. Aprovar P2-P4 manualmente pela tela `/admin/reference-datasets` quando possível.
|
||||
Reference in New Issue
Block a user