feat: add health dashboard and local ticket archive

docs/OPERATIONS.md

@@ -509,6 +509,14 @@ EOF
 └── db.sqlite3.pre-vacuum-20251209               449MB (antes do primeiro vacuum)
 ```
 
+## 14) Saude e retencao (dashboard interno)
+
+- Dashboard staff: `/admin/health` mostra tickets, cadastros, estado de heartbeat e resumo de retencao. Usa Prisma + Convex; se o Convex nao responder, exibe aviso.
+- Token interno: defina `INTERNAL_HEALTH_TOKEN` (ou reutilize `REPORTS_CRON_SECRET`) no Convex e no Next para a query `ops.healthSnapshot`.
+- Politica alvo: tickets sem expiracao; telemetria inventory/metrics 90 dias; alertas 180 dias; runs/artefatos de export 30 dias. Detalhes em `docs/RETENTION-HEALTH.md`.
+- Sem cron de limpeza ligado. Monitorar tamanho do SQLite e memoria; so limpar/arquivar em janela de manutencao com backup.
+- Backup local de tickets: `POST /api/admin/tickets/archive-local` (staff) exporta tickets resolvidos mais antigos que N dias para JSONL em `ARCHIVE_DIR` (padrao `./archives`). Protegido por `INTERNAL_HEALTH_TOKEN`/`REPORTS_CRON_SECRET`.
+
 ---
 
-Ultima atualizacao: **10/12/2025** — Problema de OOM resolvido definitivamente. Sistema estavel com 395MB de memoria (1.93% do limite de 20GB)
+Ultima atualizacao: **10/12/2025** - Problema de OOM resolvido definitivamente. Sistema estavel com 395MB de memoria (1.93% do limite de 20GB)

docs/RETENTION-HEALTH.md

@@ -0,0 +1,41 @@
+# Retencao, observabilidade e consulta a longo prazo
+
+Este documento resume as decisoes aplicadas agora para manter o sistema saudavel sem perder dados de negocio (tickets).
+
+## Politica de retencao (alvo)
+- Tickets: **sem expiracao automatica**. Antes de mover para storage frio, exportar e manter copia integra; nao apagar tickets direto.
+- Telemetria de maquinas (inventory/metrics): manter 90 dias.
+- Alertas de postura de maquinas: manter 180 dias.
+- Runs/artefatos de export de relatorios: manter 30 dias.
+
+Estrategia: nenhuma limpeza automatica ligada. Usamos apenas monitoramento e, se necessario no futuro, GC preguicoso em handlers de alto volume ou rotinas manuais com janela de manutencao + backup.
+
+## O que foi ajustado no codigo
+- Heartbeat: inventario e metrics agora sao saneados, tem hash estavel e so geram nova versao quando o hash muda (evita JSON.stringify pesado e escrita redundante).
+- Hashes guardados em metadata para comparacao barata; campos volumosos (software/extended) continuam bloqueados.
+- Query interna `ops.healthSnapshot` (Convex) para expor contagem de maquinas/heartbeats por faixa de idade; protegida por `INTERNAL_HEALTH_TOKEN` (cai no `REPORTS_CRON_SECRET` se nao setado).
+- Dashboard `/admin/health` (Next) usa Prisma + Convex para consolidar tickets, cadastros, estado de heartbeat e a politica de retencao.
+- Export/backup local de tickets: endpoint `POST /api/admin/tickets/archive-local` (staff) grava tickets resolvidos mais antigos que N dias em JSONL dentro de `ARCHIVE_DIR` (padrão `./archives`). Usa `exportResolvedTicketsToDisk` com segredo interno (`INTERNAL_HEALTH_TOKEN`/`REPORTS_CRON_SECRET`).
+
+## Como acessar tickets antigos sem perda
+- Base quente: Prisma (SQLite) guarda todos os tickets; nenhuma rotina remove ou trunca tickets.
+- Se um dia for preciso offload (ex.: >50k tickets):
+  - Exportar em lotes (ex.: JSONL mensais) para storage frio (S3/compat).
+  - Gravar um marcador de offload no DB quente (ex.: `ticket_archived_at`, `archive_key`).
+  - Endpoint de leitura pode, ao nao encontrar o ticket no DB quente, baixar/consultar o arquivo frio com base no `archive_key` e exibir em modo somente leitura.
+- Com isso, mesmo tickets muito antigos continuam consultaveis, apenas com caminho de leitura mais lento quando estiverem fora do DB principal.
+
+## Dashboard interno de saude
+- Caminho: `/admin/health` (somente staff).
+- Mostra: contagem total/abertos de tickets, cadastros (usuarios/empresas), conectividade de dispositivos (online/atencao/offline), idade do ultimo e do mais antigo heartbeat, politica de retencao.
+- Protecao da query Convex: defina `INTERNAL_HEALTH_TOKEN` (ou reutilize `REPORTS_CRON_SECRET`) no ambiente do Convex e do Next. Se o token faltar ou o Convex nao responder, o card exibe aviso.
+
+## Checks operacionais sugeridos (manuais)
+- Tamanho do banco do Convex: `ssh -i ~/.ssh/codex_ed25519 root@154.12.253.40 "ls -lh /var/lib/docker/volumes/sistema_convex_data/_data/db.sqlite3"`
+- Memoria do Convex: `ssh -i ~/.ssh/codex_ed25519 root@154.12.253.40 "docker stats --no-stream | grep convex"`
+- Alvos: <100-200 MB para o SQLite e <5 GB de RAM. Acima disso, abrir janela curta, fazer backup e avaliar limpeza ou arquivamento pontual.
+
+## Estado atual e proximos passos
+- Cron de limpeza segue desativado. Prioridade: monitorar 2-4 semanas para validar estabilidade pos-correcoes.
+- Se o volume crescer: habilitar GC preguicoso em handlers de alto volume (ex.: heartbeat) com limites pequenos, ou acionar rotina manual/HTTP para deletar apenas telemetria fora da retenao.
+- Tickets permanecem integrais; qualquer offload futuro deve ser acompanhado de export completo + marcador para leitura em modo arquivo frio.