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>
47 lines
2.6 KiB
Markdown
47 lines
2.6 KiB
Markdown
# 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.
|