Files
GTI_GERENCIADOR_FISCAL/docs/AGENT2_UPGRADE_RUNBOOK_V1.md
T
gtiandClaude Sonnet 5 e935ed61d5 feat: audited-decision gate for PIS/COFINS and CFOP_ENTRADA NOT_APPLICABLE/OPERATION_TIME
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>
2026-09-28 09:44:05 -03:00

2.6 KiB

Agent 2 — Roteiro de upgrade manual 1.3.7 → 1.3.8

Self-update: NÃO EXISTE

Evidência no código:

  • deploy/agent-windows/gti-agent.ps1 só aceita install | install-auto | configure | preflight | start | stop | restart | status | uninstall (ValidateSet na linha 20). Não há verbo update/upgrade.
  • install-auto é idempotente e recusa fazer qualquer coisa se .env já tem AGENT_TOKEN e o serviço já existe ("Already enrolled and installed... Nothing to do.") — não reenrola, não atualiza arquivos.
  • O painel do Hub (central/app/control_plane.py:140, compute_version_drift) só calcula e exibe o rótulo "Desatualizada" (version_drift); não existe nenhum código que baixe pacote, copie arquivo ou reinicie o serviço a partir do Hub. O botão "Atualização disponível" é só informativo — não há ação de clique associada.
  • docs/PILOT_DEPLOYMENT.md:367 já documenta isso: "There is no auto-update mechanism yet (deliberately out of scope)".

Conclusão: o upgrade é sempre manual, feito por humano na máquina do cliente.

Roteiro (operador, elevado)

  1. Backup antes de tocar em qualquer arquivo
    • Copie <pasta_instalação>\agent\agent_state.sqlite para um local seguro (ex.: agent_state.sqlite.bak-2026-09-28).
    • Copie também <pasta_instalação>\.env (tem o AGENT_TOKEN permanente — nunca gerar um novo).
  2. gti-agent.ps1 stop (para o serviço GTIFiscalAgent).
  3. Extraia o pacote 1.3.8 publicado sobre a mesma pasta de instalação (sobrescrever arquivos de código), sem apagar a pasta antes e:
    • não sobrescrever .env;
    • não sobrescrever/apagar agent\agent_state.sqlite;
    • não copiar/usar enrollment.json do pacote novo (ele é só para instalação nova; reenrollar geraria outro installation_id/token).
  4. gti-agent.ps1 install (elevado) — reinstala dependências no venv existente e re-registra o serviço com o novo código. Não toca .env nem o SQLite.
  5. Confira que .env continua com o mesmo AGENT_TOKEN/AGENT_ID de antes.
  6. gti-agent.ps1 preflight — deve passar (mesmas credenciais Firebird de antes).
  7. gti-agent.ps1 start.
  8. Verificar (ainda na máquina): gti-agent.ps1 status mostra o serviço rodando.
  9. Confirmar sozinho ou pedir para eu confirmar (somente leitura, pelo Hub): heartbeat com agent_version=1.3.8, installation_id inalterado (bb50884a-5e78-4f26-8cac-804932dae8de), horário do heartbeat novo.

Se algo falhar depois do passo 3, restaurar o backup do agent_state.sqlite e do .env resolve qualquer estado inconsistente sem precisar reenrolar.