1) Integração dos resultados dos relatórios nos testes de consistência

Status de base: os comparativos já estão prontos nos relatórios gerados pelas issues geotrixapp3d_prod#125 e geotrixMap#52 (3D estável; 2D ajustado no mês anterior).

Justificativa

Integrar os comparativos já existentes à suíte de testes garante regressão contínua e reduz custo operacional.

• Backend (geotrix / geotrix3d): simplificar testes, trocar projetos reais por fixtures menores focados em validar rotinas.
• Pods (jobs com backend + banco): priorizar substituição de arquivos/fixtures e ajuste de chamadas/pipelines; novos testes só se estritamente necessários. Entregar CI 2D/3D com relatório automático de diffs.

Atividades

• Mapear testes existentes que consomem artefatos grandes e trocar por fixtures mínimos (mantendo mesmas rotinas).
• Normalizar outputs (CRS, ordenação, precisão) e aplicar diffs (numérico/geométrico/raster).
• Conectar IDs fixos já usados nos comparativos para execução E2E em pods.
• Adicionar validadores checkmate para os resultados salvos em blob storage.
• Publicar relatório de diffs como artefato do CI.

Cronograma (1 semana por app)

Semana 1 — Minex 2D

• D1: inventário de testes + seleção de fixtures mínimos
• D2: substituição de fixtures + ajuste de chamadas (backend)
• D3: integração E2E (pods) com IDs fixos
• D4: checkmate para os resultados salvos em blob storage
• D5: refinamentos + documentação

Entregáveis (1 por app)

• Backend (geotrix / geotrix3d)

  • tests/backend/cmd_output.txt com redução ≥ 60% no tempo total em relação à execução anterior (fixtures menores).
  • Relatório de cobertura covr ≥ 90%: coverage-backend.xml (anexado no CI) + badge atualizado.

• Pods (E2E: backend + banco, ambiente pré)

  • Execução com IDs fixos dos relatórios (geotrixapp3d_prod#125 e geotrixMap#52) validando 100% dos comparativos.

  • Artefatos anexados no CI:

    • pods/cmd_output.txt com mensagens de discriminação dos comparativos (pass/fail por item).
    • diff_report.html (ou .md) e diff_summary.json com os diffs detalhados.

  • (Se o harness de pods for em R) covr ≥ 90% do código do harness: coverage-pods.xml.
    (Se não houver harness em R, entregar relatório de testes E2E com 100% dos cenários previstos executados.)

• Integridade e rastreabilidade

  • manifest-checksums.json (SHA-256) dos resultados no blob storage + verificação automática no CI (“checksum OK”).
  • tests/README-baseline.md documentando atualização de fixtures, tolerâncias e paths dos artefatos.

Semana 2 — Minex 3D

• Mesma sequência D1–D5, replicando o modelo do 2D

Estimativa de esforço

• 2D (Semana 1): 16–18h
• 3D (Semana 2): 16–18h
• Ajustes CI/relatórios (compartilhado): 10h (distribuídos nas duas semanas)

Critérios de aceite

• Testes (backend + pods) rodando com fixtures mínimos e relatório de diffs no CI para 2D e 3D.
• Falhas acima das tolerâncias quebram o CI.

2) covr e backends (restaurar cobertura com safe_call)

Escopo: corrigir a instrumentação de cobertura para ambos os pacotes geotrix (2D) e geotrix3d (3D), hoje impactada pelo split de funções e safe_call.

Justificativa

Sem cobertura confiável, regressões passam despercebidas. Ajustar safe_call e a configuração do covr restaura visibilidade e dá base para metas de cobertura.

Atividades

• Reproduzir o problema e mapear caminhos encobertos por safe_call.
• Ajustar safe_call para preservar instrumentação (re-lançar erro após log; evitar closures opacas; remover nocov acidental).
• Revisar execução covr::package_coverage() no CI (exclusões, paths, R CMD check).
• Adicionar gate de cobertura mínima (temporário) no CI.

Cronograma (1 semana total para ambos pacotes)

• D1: reproduzir falhas de cobertura nos dois pacotes
• D2–D3: patches em safe_call + validação local (geotrix e geotrix3d)
• D4: ajustar pipeline de cobertura no CI (ambos)
• D5: estabilização + documentação de padrão safe_call

Entregáveis (geotrix(2D) egeotrix3d` (3D))

• Relatórios de cobertura por pacote: coverage-geotrix.xml e coverage-geotrix3d.xml (anexados no CI) + badge atualizado.

• PRs de correção em safe_call (links e changelog), com testes cobrindo rotas de erro e re-lançamento.

• Documento técnico docs/testing/safe_call_guidelines.md descrevendo padrão de uso e implicações para cobertura.

Estimativa de esforço

• Semana única (geotrix + geotrix3d): 22–30h

Critérios de aceite

• Relatórios covr exibem caminhos antes ocultos por safe_call em ambos os pacotes.
• Job de cobertura no CI gerando badge/artefato e gate ativado.