usage-monitor: Skill for Claude Code

Usage Monitor — relatório de testes e cobertura

O dono do repositório delega o ciclo inteiro (código, PR, CI, merge) e precisa de uma medida, não de uma impressão, de quanto a suíte protege o produto. Esta skill roda todas as suítes com cobertura e escreve um relatório HTML no design system do app, mais um report.json para leitura por máquina.

O gerador só lê o que as suítes escreveram. Rodar a suíte é responsabilidade desta skill: o mesmo script serve para Windows, Linux e para o artefato baixado do CI.

1. Rodar as suítes

Na raiz do repositório (ou da worktree). Não pare no primeiro vermelho: o relatório existe justamente para mostrar a falha.

Kotlin (domínio, dados, view models, UI, terminal, arquitetura):

# Linux/macOS — `bash ./gradlew`, nunca `chmod +x`: o gradlew está no git sem o bit de execução
bash ./gradlew desktopTest --rerun -Pcoverage -PtestForks=4
bash ./gradlew koverXmlReport -Pcoverage

:: Windows
gradlew.bat desktopTest --rerun -Pcoverage -PtestForks=4
gradlew.bat koverXmlReport -Pcoverage

• desktopTest, e não allTests: no alvo único JVM os dois rodam a mesma suíte, mas --rerun só vale para a tarefa nomeada. Sem ele o build cache (org.gradle.caching=true) devolve XML de uma passada antiga e o relatório descreve outro código.
• -PtestForks=4 só com ~/.skiko já populado (ver CLAUDE.md). Cache frio: -PtestForks=1.
• Sem display (SSH, contêiner): prefixe xvfb-run -a. Parte dos testes consulta o GraphicsEnvironment.
• Medido em 2026-10-22, Linux, 16 processadores, 4 forks: ~55 s de suíte mais ~5 s de Kover.

Servidor de time (server/, vitest + supertest):

cd server && npm ci && npm run test:coverage

test:coverage escreve test-results/junit.xml e coverage/coverage-summary.json (v8 sobre src/).

2. Gerar o relatório

node .claude/skills/usage-monitor-test-report/scripts/build-test-report.mjs

• Saída: build/test-report/index.html e build/test-report/report.json (pasta ignorada pelo git).
• Imprime um resumo no console e sai com 1 quando algum portão bloqueia (suíte não rodou, falha, regra de arquitetura quebrada). Quem automatiza decide pelo código de saída.
• Opções: --root <repo> (padrão: diretório atual) e --out <pasta relativa>.
• --platform win32|linux|darwin troca a plataforma do cabeçalho (padrão: a da máquina que gera).
• --ci só no CI: lá o desktopTest pode vir do build cache (FROM-CACHE) com o carimbo da execução original, e o portão "Resultado do código atual" deixa de comparar horário com o commit.
• Todo run do CI em que a suíte do desktop roda já gera este relatório: job test-report do ci.yml, com a suíte do Windows e a do servidor. O HTML fica no artefato test-report (14 dias) e os portões no resumo do run. Para ler o de um PR sem rodar nada: gh run download <run-id> -n test-report -D build/test-report-ci. Rodar localmente continua valendo antes do push, porque o CI só responde depois dele.