Skip to content

[Feature] Filtrar valores irreais de WPM no ranking #68

Closed

Description

@caioross

🚀 Feature

Aplicar um limite máximo de WPM para exibição no ranking público.


📖 Contexto

Durante os testes foram encontrados registros extremamente altos de WPM.

Embora possam ocorrer por bugs, testes internos ou manipulação de dados, esses valores acabam aparecendo no ranking público.

Isso reduz a credibilidade do sistema de classificação.


❌ Problema

Atualmente qualquer valor calculado é exibido.

Isso permite registros como:

  • 1.500 WPM
  • 3.000 WPM
  • 8.000 WPM

Mesmo sendo números claramente impossíveis para um ser humano.

O resultado é um ranking pouco confiável.


💡 Proposta

Aplicar um limite de exibição.

Qualquer jogador com:

WPM > 999

não deverá aparecer no ranking público.

Esses registros ainda podem permanecer armazenados para auditoria ou análise.


🎯 Benefícios

  • ranking mais confiável;
  • melhor competitividade;
  • elimina resultados absurdos;
  • transmite maior credibilidade ao projeto.

✅ Critérios de aceite

  • Jogadores acima de 999 WPM não aparecem no ranking.
  • Os registros permanecem armazenados no banco.
  • Nenhum erro é gerado durante consultas.
  • O restante do ranking permanece inalterado.

🔮 Melhorias futuras

Em vez de utilizar apenas um limite fixo, o sistema poderá futuramente detectar automaticamente resultados suspeitos considerando:

  • precisão;
  • tempo de resposta;
  • quantidade de caracteres;
  • velocidade média histórica do jogador.

Isso permitirá identificar possíveis bots ou exploits de forma mais inteligente.

Activity

  1. added
    enhancementNew feature or request
    em-resolucaoClaim: um Resolvedor está trabalhando nisto
    and removed
    em-resolucaoClaim: um Resolvedor está trabalhando nisto
    on Jul 25, 2026
  2. caioross commented on Jul 26, 2026

    @caioross
    OwnerAuthor

    Resolvido em PR #78 (auto/issue-68-wpm-ranking-filter).

    Filtra as leituras públicas (getLeaderboard + getRecentMatches) pelo teto MAX_PLAUSIBLE_WPM — reusando a mesma constante do guard de escrita (350), por sua decisão, em vez dos 999 originais (350 é mais estrito e evita um segundo limiar). Dados não são apagados: só saem do ranking. Fecha os 4 ACs.

    ⚠ Cobre integralmente o read-filter da PR #30 (issue #28) — sugeri ao PR Doctor mergear este e fechar a #30 como superada; o resto da #28 (limpeza do dado histórico + log) é item do dono. Gate verde: typecheck · build · 34 testes · persistência 49 · métricas 37. Non-draft com quórum (§7.2 — toca supabase.ts).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions