[pitangainnovare]

O que esse PR faz?

Ranking e distribuição incluem dados parciais por padrão (coverage_policy=allow_partial): dias confirmados nas consultas mensais e totais disponíveis nas consultas anuais de país/idioma. JSON, CSV e XLSX informam cobertura e avisos. strict exige cobertura completa.

No anual, a cobertura é informativa, não um filtro dos totais; os valores podem mudar com novas cargas. Permanecem os intervalos de anos inteiros e as restrições de métricas. Relatórios padrão COUNTER não mudam.

Onde a revisão poderia começar?

counter_api/extensions/coverage.py, counter_api/painless.py e a integração em ranking.py/distribution.py.

Como este poderia ser testado manualmente?

1. Consultar ranking/distribuição em um período com meses incompletos, omitindo coverage_policy; conferir os valores disponíveis e a cobertura informada.
2. Repetir com strict e conferir a rejeição do período incompleto.
3. Consultar país/idioma em um ano incompleto e conferir os totais disponíveis, coverage.basis=available_annual_totals e o aviso de cobertura informativa.
4. Exportar CSV/XLSX e conferir cobertura e avisos, inclusive quando não houver resultados.

Validação automatizada: 376 testes aprovados, 2 ignorados; estilo, OpenAPI e Gitleaks aprovados.

Algum cenário de contexto que queira dar?

Evita ocultar dados disponíveis por lacunas na carga. Dias sem cobertura não são tratados como uso zero. O desempenho da soma diária foi verificado apenas em consultas limitadas, não em escala de produção.

Screenshots

Não se aplica.

Quais são os tickets relevantes?

Closes #157.

Referências

OpenSearch — acesso a campos em scripts

---

Segurança da informação (NSI.04)

Este PR manipula dados sensíveis ou pessoais (LGPD)?

• Sim — descreva os controles de proteção aplicados (criptografia, mascaramento, anonimização, etc.):
• Não — a mudança consulta métricas agregadas e marcadores de cobertura, sem acrescentar dados pessoais.

Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?

• Sim — descreva o que mudou e por quê:
• Não

Este PR introduz, atualiza ou remove dependências de terceiros?

• Sim — as novas dependências foram verificadas no SBOM/Trivy sem vulnerabilidades críticas/altas em aberto?
  • Verificado e aprovado
  • Pendente / vulnerabilidade aceita com justificativa:
• Não

Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?

• Sim — link do job:
• Não aplicável a este PR (justifique):

Pendente de validação pelo pipeline; Gitleaks local aprovado.

Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?

• Sim — confirme que há sanitização/parametrização (prepared statements, escaping, etc.):
• Não — o script Painless é fixo e recebe parâmetros separados, sem interpolar código externo.

Este PR expõe novos endpoints, telas ou serviços?

• Sim — HTTPS obrigatório está garantido e o acesso segue o princípio de menor privilégio?
• Não — utiliza as rotas existentes.

Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?

• Não, nenhum segredo foi commitado
• Sim (bloquear merge e corrigir antes de prosseguir)