fix(engine): precisão honesta — nunca 100% com erro cometido (#20) - #23
Conversation
O painel "// suas estatísticas" mostrava "Precisão 100%" ao lado de "Erros 1": Math.round((1 - 1/200)*100) arredondava 99.5 para 100, contradizendo o cartão de erros e quebrando a honestidade da métrica. - accuracy: 100% agora só com zero erros; com ≥1 erro usa Math.floor e teto de 99%. Não afrouxa anti-cheat (torna a leitura mais rigorosa). - rótulo "Erros" → "Erros (total)" + tooltip explicando que conta teclas erradas já corrigidas (número inalterado, só o significado explícito). - validate-metrics: fórmula espelhada + 3 casos novos (1 erro em 200 e 10000 teclas → 99%; 0 erro → 100%). 27/27 verdes. Closes #20 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@caioross is attempting to deploy a commit to the caioross' projects team on Vercel, but is not a member of this team. To resolve this issue, you can:
To read more about collaboration on Vercel, click here. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request implements an "honest accuracy" calculation (issue #20) in both the Race.tsx component and the validate-metrics.mjs script, ensuring that a 100% accuracy score is only achievable with zero errors, and capping the accuracy at 99% otherwise. It also updates the UI to display "Erros (total)" with an explanatory tooltip. The review feedback correctly suggests using Math.round instead of Math.floor combined with the 99% cap to avoid unfairly penalizing users by rounding down their accuracy scores.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| const accuracy = | ||
| totalKeystrokes === 0 ? 100 : Math.max(0, Math.round((1 - errors / totalKeystrokes) * 100)); | ||
| errors === 0 | ||
| ? 100 | ||
| : Math.max(0, Math.min(99, Math.floor((1 - errors / totalKeystrokes) * 100))); |
There was a problem hiding this comment.
Ao usar Math.floor, a precisão é sempre arredondada para baixo, o que introduz uma penalidade desnecessária para o usuário (por exemplo, uma precisão real de 98.9% seria exibida como 98% em vez de 99%).\n\nPodemos manter o comportamento honesto (nunca exibir 100% se houver erros) usando Math.round em conjunto com o limite máximo de 99 (Math.min(99, ...)). Isso garante que valores como 98.9% sejam arredondados corretamente para 99%, enquanto qualquer valor que arredondaria para 100% (como 99.6%) seja limitado a 99%.
const accuracy =\n errors === 0\n ? 100\n : Math.max(0, Math.min(99, Math.round((1 - errors / totalKeystrokes) * 100)));
| return errors === 0 | ||
| ? 100 | ||
| : Math.max(0, Math.round((1 - errors / totalKeystrokes) * 100)); | ||
| : Math.max(0, Math.min(99, Math.floor((1 - errors / totalKeystrokes) * 100))); |
There was a problem hiding this comment.
Para manter a consistência com a fórmula de precisão no componente Race.tsx, devemos usar Math.round em vez de Math.floor aqui também, mantendo o limite máximo de 99 para evitar que a precisão seja exibida como 100% quando houver erros.
return errors === 0\n ? 100\n : Math.max(0, Math.min(99, Math.round((1 - errors / totalKeystrokes) * 100)));
Parecer PR Doctor — APROVADO (normal §7.3) ✅ · merge aguarda sessão supervisionadaDiff lido inteiro. Correção de honestidade de métrica (issue #20), não maquiagem:
Gate real (verifiquei no branch Área sagrada intocada (só exibição/label; Status: aprovado para squash-merge. O merge (= deploy de produção na Vercel) foi barrado pelo classificador de segurança do harness em modo automático, que exige revisão humana para deploy em |
Parecer PR Doctor — APROVADO (NORMAL, HANDBOOK §7.3)Diff lido inteiro (Race.tsx + validador espelho). Classifiquei como normal: engine de digitação com Corretude verificada:
|
1 participant
Contexto
A persona O Iniciante viu "Precisão 100%" e "Erros 1" ao mesmo tempo (feedback em Discussion #14). Dois números certos pela conta interna, mas incoerentes aos olhos — quebra de honestidade de métrica. Causa-raiz:
Math.round((1 - 1/200)*100)=Math.round(99.5)= 100, coexistindo com o contador cumulativo de erros.O que mudou e por quê
accuracy(Race.tsx):100%agora só com zero erros cometidos. Com ≥1 erro, usaMath.floore teto de99%.errors > 0garantetotalKeystrokes > 0, então não há divisão por zero. Isso não afrouxa anti-cheat — torna a leitura da precisão mais rigorosa (§7.1 não se aplica).title) explicando que conta teclas erradas digitadas incluindo as já corrigidas. Número inalterado; só o significado fica explícito.validate-metrics.mjs: fórmula espelhada + 3 casos novos (1 erro em 200 e em 10 000 teclas → 99%; 0 erro → 100%).Nada toca a área sagrada (latência de input):
handleInpute o caminho de digitação ficam intactos; sem animações novas (reduced-motion preservado).Como foi validado (gate real)
pnpm typecheck✅pnpm build✅node .claude/skills/cr-typing-engine/scripts/validate-metrics.mjs✅ 27/27node scripts/validate-persistence.mjs✅ 33/33pnpm lint: N/A (repo sem config ESLint; CI não roda lint)Acceptance criteria
errors > 0→ Precisão nunca mostra100%(mostra99%ou menos); sóerrors === 0→100%validate-metricsverde com ≥1 caso novoprefers-reduced-motionRiscos
Baixo. Diff de exibição/label (16 linhas em Race.tsx) + validador. Sem Parecer do Conselho nesta issue — segui o plano da própria issue (floor sob
errors > 0), acrescentando o teto de 99% como salvaguarda contra edge de ponto flutuante.Closes #20