Full 18-field diagnostic (local_completion.py) ran successfully for
Cliente A (CONSTRUCAO) and Cliente B (MMMODAS): zero AUTO_FILL_SAFE
cells in either, so there is nothing for the guarded write cascade to
apply - a correct engine result, not a blocker. Real Agent jobs
completed for all 4 clients (A/B/C/D), confirming the same pattern.
RINCAO/UNIAO snapshot stayed blocked by the session's auto-mode
classifier across two attempts; documented as a known gap instead of
worked around.
Fixed central/tests/test_field_contract.py: its ALLOWED fixture still
pointed at Banco/CONSTRUCAO.FDB from before this mission's allowlist
change to work_copies/; updated it and added the original path as an
explicit must-be-rejected case. Canonical suite: 1191 passed, 1
skipped.
Rewrote the stale "encerrado a pedido do operador" report in
MISSAO_9_LOG.md (written at a premature shutdown) with the real final
report, and updated PROJECT_STATE.md to reflect mission completion.
The machine was shut down and restarted per the operator's earlier request,
then the operator asked to continue instead. On resume, Postgres data
persisted (same volume) and re-checking confirmed CFOP/TIPI_IPI/CEST/
NFE_MOC_TABLES were already ACTIVE (approved in Missão 8) - the earlier
"not found" finding only checked status='DRAFT' and missed that they had
already been promoted. No new approval was needed; register_draft()'s
idempotent lookup just confirmed the existing rows unchanged.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Job 648 (Cliente A/CONSTRUCAO, INITIAL_SYNC, DRY_RUN) completed for real
before the session had to close: 3712/3712 products COMPLETE, 0 blocked,
0 needs-review, 0 writes (as configured). Cliente B (MMMODAS, 20997
products) was still RUNNING when the session ended.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Factual, no client data: Hub 1.3.14 (deployed), Agent published 1.3.8,
Agent 2 1.3.8 (operator-reported, heartbeat not confirmed this session).
Migration heads confirmed via `alembic heads` on both branches: main at
0034_reference_data_registry, feature/cfop-ippt-write at
0033_cfop_ippt_write_mode - both children of 0032, so the two branches'
migration chains diverge and one must be renumbered/rebased before any
merge (flagged as an open risk, not resolved here).
Reference Data Registry status, the 3 pending Contexto Fiscal ADMIN
decisions, what each of Missões 1-5 completed vs. left undone, open risks,
and a docs/ index for the next session to start from.
CLAUDE.md now points to docs/PROJECT_STATE.md as the required first read
before any new fiscal mission.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Missão 5:
Fase 1 (Reference Data Registry): migration 0034 adds licence_terms, valid_from/
valid_to, file_size_bytes, raw_file_path, parse_errors, submitted_by/approved_by/
approved_at to the existing `datasets` table (additive only - the 9 pre-existing
dataset kinds keep their current auto-activate behavior in
central/app/datasets/service.py, completely untouched, so this changes nothing
about the currently-running engine). New central/app/reference_registry.py is a
separate, NEW ingestion workflow: register_draft() always lands as DRAFT (never
auto-activates), diff_against_vigente() summarizes a draft against the current
VIGENTE of the same kind for admin review, approve_draft()/reject_draft() are
the only way to promote a DRAFT (refuses non-DRAFT rows and refuses a draft
with recorded parse_errors). New admin screen "Tabelas oficiais"
(/admin/reference-datasets, ADMIN only, CSRF, every decision audited as
REFERENCE_DATASET_APPROVE/REJECT) lists the registry with a diff view and
approve/reject buttons. New CLI (scripts/ingest_reference_dataset.py) downloads
an official source (currently: NCM/Siscomex, no login/captcha), validates
(minimum row count, a known-sample spot check), and registers a DRAFT - --dry-run
never writes anything.
P1 (NCM) validated for real: downloaded the live official Siscomex NCM JSON
(2026-09-28, sha256 8a3bf89a..., 15,156 entries) with an identifiable User-Agent,
one request. Its hash is IDENTICAL to the NCM dataset already ACTIVE in the Hub -
confirms the currently loaded table is already current against the official
source today. Raw file kept out of git (.gitignore:
sources/raw/reference_registry/); manifest (URL, date, hash, size) recorded in
docs/REFERENCE_DATASET_MANIFEST_V1.md, including P2-P6 sources still pending URL
confirmation.
Fase 5 (feasibility studies, no code): docs/VIABILIDADE_CCG_DFE_V1.md - CCG/SEFAZ
GTIN lookup and Distribuição DF-e both require the client's own ICP-Brasil
certificate; recommendation is NOT to implement now (would require either the
Hub holding a client certificate - breaks the project's core security model - or
the Agent making new outbound internet calls, against this mission's fixed
rules). Reading the already-authorized purchase-NFe XML from disk via the Agent
(path already stored in XML_MES) is recommended as the next concrete step
instead: no certificate, no new internet call, opt-in per installation, result
always tagged DECLARADO (never auto-promoted - consensus across purchase
invoices is not fiscal truth). Open Food Facts stays identity-only, unchanged.
21 new tests, all passing. Full suite: 1147 passed, 1 skipped.
No write to any Firebird database anywhere. No Agent code touched.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Bloco C.1-C.4: searched every BLOB column and every XML/IMPOSTO/TRIBUT-named
table across all 5 databases - no authorized NFC-e/NF-e XML is stored
anywhere (XML_MES only holds a filesystem path on the original machine;
CARTA_CORRECAO/MDFES_XML are for correction letters and cargo manifests;
DEOLHONOIMPOSTO is the national IBPT reference table, not per-item data).
FONTE_ENCONTRADA = NFCE_ITENS's own PIS/COFINS columns (the same values used
to build the XML) - docs/PISCOFINS_TRANSMITTED_SOURCE_V1.md.
Bloco D.1-D.3: the 27 products blocked by NCM on Agent 2, categorized
(4 placeholder 00000000, 3 legacy/vencido, 5 valid-format-but-not-in-the-
active-table, 15 obvious test/garbage values) with a prioritized kb.attest
queue - real products first (Coca-Cola, chicken cuts, pâté, broths), test
cadastro last. All 27 lack a real GTIN, so none can be resolved by barcode
lookup - documented in docs/NCM_27_BLOCKED_PRODUCTS_V1.md.
dossie_contador.md (internal + anonymized) updated with the Bloco C finding.
No schema/migration change. Zero Firebird writes (read-only SQL only).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Documents what the code already does (no behavior change): GTI_FISCAL_VERSION
(Hub) and the Agent's own version are separate numbers with separate release
cycles; central.app.installation_identity.reference_agent_version() already
compares an Agent's heartbeat version against the highest PUBLISHED Windows
AgentRelease, never against the Hub's version - verified against
test_version_reference.py. Also documents that there is no real minimum-
version connection gate today (only SCHEMA_FINGERPRINT is enforced) and where
one would go if ever needed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Missão 4 / Bloco B.2: this repository is local-only (no remote configured,
nothing ever pushed), so moving these files off main is a plain history
edit with no shared-history risk. agent/src/gti_fiscal_agent/cfop_ippt_auto_apply.py,
its tests and docs/CFOP_IPPT_WRITE_CAPABILITY_V1.md now live only on
feature/cfop-ippt-write (created from this same point in history, with one
extra commit adding the Bloco A.3 end-to-end regression test). Nothing on
main imports this code - no behavior changes; this main commit is a pure
file move recorded as a normal new commit, not a rewrite of existing history.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Missão 4 / Bloco A.1 (prioridade máxima): central.app.field_contract.infer_role
treated ANY C000032.TIPO=COMPOSICAO row for a product as proof of own
production, with no ratio check - a beer sold 19 times and used once as a
recipe component (Agent 2, real data) was classified OWN_PRODUCTION from
that single occurrence, proposing to change its CFOP and IPPT.
New deterministic threshold in field_contract.py: COMPOSICAO must be a
majority (>=70%) of that product's own C000032 movement history, with at
least 5 total events, to count as own-production evidence. Below 30% the
evidence is discarded entirely (falls through to other role evidence,
e.g. TIPO=VENDA -> RESALE). Between 30% and 70% (with enough events to be
meaningful) is genuinely conflicting evidence -> UNKNOWN, never guessed
either way. RECEITA_INGREDIENTES/PROD_COZINHA-based evidence (a direct
recipe-table linkage, not a statistical ratio) is untouched.
agent/src/gti_fiscal_agent/firebird_reader.py now counts COMPOSICAO vs other
C000032 rows per product (read_product_evidence: single indexed query;
read_evidence: one grouped query for the whole catalog) into a new
ev["composed_ratio"] key, alongside the existing "composed" set (kept for
other, non-role consumers like coverage.py). central/app/enrichment/api.py's
sanitize_product_evidence and fiscal_completion.py's empty-ev fallback both
carry the new key through.
New tests (central/tests/test_field_contract.py) cover the 5 real cases named
in the mission: the beer (1 vs 19, 5% - discarded), a second beer (3 vs 4,
42.9% - MIXED/UNKNOWN), the liqueur (34 vs 22, 60.7% - still MIXED/UNKNOWN,
below the 70% bar), the juice with PROD_COZINHA=1+RECEITA_INGREDIENTES
(unaffected, stays OWN_PRODUCTION), and the tilapia/corvina fish (no
composed evidence at all, stays RESALE) - plus a strong 90% majority case
and an insufficient-sample (<5 events) case. A new end-to-end test in
agent/tests/test_cfop_ippt_auto_apply.py (committed separately, see the
feature/cfop-ippt-write branch) proves the weak-evidence beer never reaches
select_candidates as a write candidate, independent of any write flag.
Re-running the dry-run over Agent 2's real database (GTI.FDB, 527 products)
after this fix: AUTO_FILL_SAFE CFOP/IPPT cells drop from 12 to 3 (the two
fish CFOP fills + the juice's IPPT, all with strong, non-statistical
evidence) - docs/runs/GTI_dryrun_universe_summary_after_A1.json. This
corrects the Missão 3 report's 12/9(downgraded)/4(sustained) manual
judgment call with a deterministic, tested engine rule.
No schema/migration change. Zero Firebird writes (read-only analysis only).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Missao 3 / Bloco C.1-C.2: new agent/src/gti_fiscal_agent/cfop_ippt_auto_apply.py
mirrors the existing rtc_auto_apply.py safety model for a new, narrower
capability (CFOP_IPPT_WRITE_V1): compare-before-write, stale-write guard
("human override sempre vence" - a value changed since the candidate was
selected is never overwritten), one transaction per cell, readback
verification, and rollback that only restores a value still equal to what
was written. Candidates come exclusively from field_contract.resolve_product's
own AUTO_FILL_SAFE classification for CFOP/IPPT - no new fiscal rule.
14 new tests (agent/tests/test_cfop_ippt_auto_apply.py) prove: flag OFF means
the caller never reaches a write; only CHANGE+write_eligible CFOP/IPPT cells
become candidates; a human edit between decision and write blocks the write;
a second run over an already-applied cell writes zero; a technical failure on
one cell never stops the batch; rollback refuses when the value changed again.
Deliberately NOT wired into agent/scripts/run_agent_service.py::execute_job,
and the Hub-side authorization/audit plumbing (Installation.cfop_ippt_write_mode,
audit table, job-delivered authorization - the same pattern as
central/app/rtc_audit.py) does not exist yet. No currently-published Agent
behavior (1.3.8) changes with this commit - nothing imports this new module.
See docs/CFOP_IPPT_WRITE_CAPABILITY_V1.md for the acceptance roteiro (test
products only, never real ones) and what remains before this can ever be
activated for a real installation - deliberately left for review before any
further step, per this mission's explicit instruction not to publish it active.
Also: dossie_contador.md (internal + anonymized) updated with the Bloco B
finding that the ~9.5% CST=01 anomaly is confined to a single calendar month
(not the whole year), with no fiscal-dimension (NCM/CFOP/CSOSN/ICMS group)
explaining which items got it - consistent with a one-off technical event,
not a deliberate rule.
REAL_PRODUCT_FISCAL_WRITES=0 (no write path exists in this commit).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New script (scripts/blocoB_pis_cofins_source.py) and evidence artifact
(docs/runs/BLOCOB_PIS_COFINS_SOURCE_V1.json): tests whether NCM, CODGRUPO, CFOP,
CSOSN or GRUPO_ICMS determine the CST_PIS_COFINS value emitted in NFCE_ITENS,
across all 5 installations. Read-only; no Firebird write path exists in this script.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Missao 2 (fechamento de lacunas fiscais, read-only + UI/engine gated):
- field_contract: pis_cofins_profile now also accepts the literal sentinels
NOT_APPLICABLE/OPERATION_TIME, resolving to NA only from an audited
FiscalContextEntry - never inferred from emission statistics. CFOP_ENTRADA
under an already-decided entry_scope=MIXED_OR_DYNAMIC now resolves to NA
instead of MANUAL, so it stops blocking product completeness and stops
re-asking an already-answered question. Regression tests prove: no ADMIN
decision => unchanged old behavior; decision present => gated bucket, no write.
- context_keys: validate_entry accepts the two sentinels for pis_cofins_profile.
- Contexto Fiscal UI: PIS/COFINS and CFOP_ENTRADA cards show the Bloco 2
cross-database evidence (5 installations, CRT 1 and 3: emission never reads
the PIS/COFINS cadastral fields anywhere) and a link to an ADMIN-facing,
anonymized dossie-for-the-accountant; entry_scope is now a dropdown.
- release/tests: decoupled the Hub's GTI_FISCAL_VERSION from the Agent's own
version (test_versions_are_coherent_across_hub_and_packages vs the new
test_agent_version_is_internally_coherent) - a Hub-only release must not
require touching, rebuilding or republishing the Agent.
- New read-only evidence: docs/runs/GTI_dryrun_universe_summary.json (527
products, Agent 2's real database), docs/runs/BLOCO2_PIS_COFINS_CROSS_DB_V1.json
(5 installations), docs/fiscal_completeness_matrix.md, docs/dossie_contador.md
(internal, real names) + central/static/docs/dossie_contador.md (public,
anonymized - no CNPJ/razao social/product names), docs/AGENT2_UPGRADE_RUNBOOK_V1.md.
- CLAUDE.md: recorded the permanent fiscal-mission rules (no AI/scraping, no
Firebird schema changes, deploy only via deploy_hub.ps1, never reenroll,
no remote access to client Agent hosts, no client data in unauthenticated
static routes).
No schema/migration change. Zero Firebird writes (new scripts never open a
write connection). Hub only - Agent code untouched.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sandbox test: a 26 s outage exhausted the previous 15 s retry budget and failed a REPROCESS_ALL.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Found by uninstall + fresh install on the clean Windows Sandbox: the old agent_state.sqlite identity conflicted with the new enrollment and the service sat idle.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Found in the clean-Windows recovery test: a single TLS handshake failure mid-job failed a whole sync.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- resolver (rules RTC-R0..R4/A1..A3/G1..G2) over the official cClassTrib table 2026-06-22 and LC 214/2025 annexes; local vs official catalog comparison
- ONE root-cause RTC blocker per product (missing/unresolved/ambiguous/conflict/official mismatch/catalog outdated/evidence missing)
- auto-apply: C000025.CCLASSTRIB only, three switches (FIREBIRD_WRITES + RTC_AUTO_APPLY_ENABLED + Hub authorization), per-product re-read and re-decision, never overwrites, rowcount 1, audit table rtc_write_audits (migration 0027)
- copy-only write E2E (280/280 applied, only CCLASSTRIB changed, 2nd run 0 writes, stale decision 0 writes); real databases untouched
- docs: cclasstrib_resolution, rtc_auto_apply, unified_fiscal_completeness
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- RTC: Agent reads ALL PARAMETROS rows every sync (conflict => off), reports rtc_source/rtc_observed_at/rtc_param_rows; legal_effective_context is informational only
- PIS/COFINS: applicability from CRT + PISCOFINS flag + incidence only (never from empty fields); Simples w/o special treatment NOT_APPLICABLE, taxed regime with explicit N OPTIONAL, unreadable declaration NEEDS_REVIEW
- CST: one digit with an official zero-padded form is VALID_AFTER_NORMALIZATION (non-blocking warning), nothing is written to the ERP
- tests: RTC toggle 0->1->0 across syncs (Agent + Hub stale closing), non-circularity, normalization, panel provenance
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- central/app/unified_fiscal_coverage.py: pure rules (PIS/COFINS NOT_APPLICABLE/REQUIRED/OPTIONAL/NEEDS_REVIEW, RTC only when the ERP switch is on)
- agent: read-only loader (unified_fiscal.py) replaces the legacy/expanded module; findings feed the single operational state, coverage and blocker queue
- hub: BLOCKED_FISCAL_DATA blockers (PIS/COFINS/RTC) share the queue; stale ones close on the next full pass; dashboard breakdown gains CEST/PIS/COFINS/RTC
- panel: legacy/expanded coverage block removed; discreet 'Reforma Tributaria: Ativa/Desativada'
- docs: unified_fiscal_completeness, pis_cofins_applicability, rtc_pis_cofins_model + official source manifests; read-only E2E script
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Hub: installations.processing_enabled / sync_interval_seconds / last_sync_* (migration 0026).
The first heartbeat of an installation without coverage queues exactly one INITIAL_SYNC;
afterwards one SYNC_INCREMENTAL per interval (idempotent, backs off on failure). One fiscal
job at a time per Agent (FIFO, stale RUNNING recovery). Job completion now updates the
coverage snapshot, blockers and JOB_STARTED/COMPLETED/FAILED events. Panel: Sincronizar
agora / Reprocessar tudo / Pausar / Retomar + status; pause is enforced Hub-side.
Agent: local AGENT_JOBS_ENABLED is ignored (central control); SYNC_INCREMENTAL re-classifies
only new/changed products via a per-product fingerprint+decision cache and rebuilds coverage
from it; results carry operational summary and blockers; Firebird credentials come from a
DPAPI firebird.bin. Setup: read-only SGV Firebird discovery (auto-select only when
unambiguous, wizard chooser otherwise), starts the service, waits for the first heartbeat,
upgrade-in-place mode. All jobs stay read-only (FIREBIRD_WRITES=0). Version 1.1.3.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
POST /v1/agents/enroll now returns installation_id; new installs persist it
to agent.env immediately. Runtime recovery precedence: existing SQLite
installation_identity -> configured INSTALLATION_ID -> authenticated
GET /v1/agents/me/identity. Recovery fails closed on missing/malformed/
mismatched identity rather than inventing a UUID (which the Hub would then
reject as a conflicting Installation on an already-enrolled Agent). An
explicit AGENT_JOBS_ENABLED gate stops the service from claiming a job right
after the first heartbeat.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
gti
