Code Health Score: Repowise coloca números na dívida técnica do seu repositório

Code Health Score: Repowise Coloca Números na Dívida Técnica do Seu Repo

Já mencionamos o Repowise de passagem quando cobrimos a tendência de knowledge graphs para código — apareceu como mais um em uma lista de cinco. Fico pequeno para ele. Repowise não é apenas outra ferramenta que monta um grafo sobre seu repo. É a única dessa lista que faz uma afirmação que as outras nem tentam: que consegue pontuar seu código de 1 a 10 e que essa pontuação realmente prevê onde vão aparecer os bugs.

Vale a pena olhar com detalhes.


O que é Repowise concretamente

pip install repowise, rode repowise init no seu projeto, e constrói cinco coisas ao mesmo tempo:

  • Graph — grafo de dependências via tree-sitter em 15 linguagens, resolução de calls, PageRank/centrality
  • Git — hotspots (churn × complexidade), % de ownership, coupling oculto via co-change pairs, bus factor
  • Docs — uma wiki gerada por LLM por módulo, regenerada incrementalmente em cada commit
  • Decisions — architectural decision records extraídos de oito fontes, etiquetados como verified/fuzzy/unverified
  • Code Health — 25 biomarkers determinísticos, zero chamadas a LLM, menos de 30 segundos em um repo de 3.000 arquivos

Depois expõe tudo isso para Claude Code, Codex ou qualquer cliente MCP através de nove tools. Essa parte — graph, git, docs, decisions — é em espírito bem parecida com o que já vimos com codebase-memory-mcp e Context7. A camada de Code Health é onde Repowise está fazendo algo que ninguém mais nesse espaço está fazendo.


A parte que sim é nova: um score validado contra defeitos reais

A maioria das ferramentas de “code quality score” — e tem muitas — ajustam seus pesos manualmente, conforme o que lhes parece razoável. A proposta do Repowise é distinta: os pesos por trás de seus 25 biomarkers (McCabe complexity, deep nesting, brain methods, coesão LCOM4, god classes, clone detection, untested hotspots, churn, ownership dispersion, e mais) estão calibrados contra um corpus histórico real de defeitos, não escolhidos manualmente.

Para ser claro sobre o que isso significa: é um benchmark próprio do Repowise, publicado em seu repo repowise-bench com metodologia e intervalos de confiança inclusos — não uma auditoria independente de terceiros. Vale a pena testar no seu próprio repo antes de tomar os números como verdade revelada, mas pelo menos a metodologia é transparente o suficiente para poder revisá-la.

Isso é o que reportam, medido sobre os mesmos 2.770 arquivos em 9 linguagens, no mesmo commit, contra as mesmas tags de defeitos, comparado cara a cara contra uma “ferramenta comercial líder” que não nomeiam:

Eixo (paired tests) Repowise Ferramenta comercial
Recall @ 20% do orçamento de linhas 0,173 0,074
Ranking effort-aware (Popt) 0,607 0,462
Densidade de defeitos (ratio Alert:Healthy) 2,18× 0,56×
Discriminação (ROC AUC) 0,731 0,705

Separadamente, em 21 repos open-source que cobrem as nove linguagens “Full tier”, reportam um ROC AUC médio cross-project de 0,74 (IC 95%: 0,68–0,79) para identificar quais arquivos terminam recebendo bug fixes nos seis meses seguintes — sem data leakage, já que os health scores ficam fixados em um commit histórico e os resultados são medidos depois. Também reportam que o score se sustenta mesmo quando controlam por tamanho de arquivo (não é só “marque os arquivos maiores”) e que aguenta em um dataset externo publicado (PROMISE/jEdit) sobre o qual nunca foi ajustado.

Auto-reportado, sim. Mas é o tipo de afirmação auto-reportada que vem com um documento de metodologia em anexo, o que já o coloca um degrau acima do típico gráfico de marketing.


Colocando em funcionamento

pip install repowise          # ou: uv tool install repowise

cd seu-projeto
repowise init        # constrói as cinco camadas — uma única vez
repowise serve       # levanta o MCP server + dashboard local

As camadas de graph, git, dead-code e health são construídas em minutos sem nenhuma chamada a LLM — com repowise init --index-only você tem um índice consultável quase instantaneamente. O único lento é a camada de geração de docs, que você pode deixar rodando em background. Depois do índice inicial, cada atualização disparada por um commit leva menos de 30 segundos.

Se você trabalha especificamente com Claude Code, pode pular a configuração manual:

/plugin marketplace add repowise-dev/repowise
/plugin install repowise@repowise

Isso registra o MCP server, instala o hook, e adiciona os slash commands /repowise:* (init, health, risk, dead-code, decision, …).

Para o health score especificamente, uma vez indexado:

repowise health                       # KPIs + arquivos com pior pontuação
repowise health --coverage cov.lcov   # ingestão LCOV/Cobertura/Clover → detecção de untested-hotspots
repowise health --refactoring-targets # ranking por impacto/esforço
repowise health --trend               # snapshots + alertas de declínio/declínio previsto

As nove MCP tools

A maioria das tools de código para MCP estão montadas em torno de entidades individuais — um arquivo, um símbolo — o que força seu agente a encadear uma dúzia de chamadas. As tools do Repowise estão montadas em torno de tarefas: você passa múltiplos targets e recebe contexto completo em um único round-trip.

Tool Para quê serve
get_overview() Resumo de arquitetura, mapa de módulos, entry points — a primeira chamada em qualquer repo desconhecido
get_answer(question) Retrieval híbrido + expansão de grafo → uma resposta citada com score de confiança
get_context(targets, include?) Ficha de contexto por arquivo/módulo/símbolo — lote de vários targets ao mesmo tempo
get_symbol("file.py::Name") Código-fonte bruto de um símbolo, com limites de linha exatos
search_codebase(query, kind?) Busca semântica filtrável por implementation/test/config/doc
get_risk(targets, changed_files?) Hotspot scores, dependentes, co-change partners — com modo PR incluído
get_why(query?, targets?) Architectural decision records + cadeia de supersession
get_dead_code(...) Código inalcançável por nível de confiança
get_health(targets?, include?) O score de 25 biomarkers, por arquivo ou em nível de dashboard

Seu exemplo de referência — adicionar rate limiting a todos os endpoints de uma API — afirma 5 chamadas de tool em vez de uns 30 greps-e-reads. Isso está alinhado com o padrão geral de “índice estruturado vence a exploração arquivo por arquivo” que vimos em quase todas essas ferramentas, incluindo a redução de ~70% em tool calls e ~89% menos file reads que Repowise reporta em seus próprios benchmarks de eficiência de agente.


Onde fica posicionado frente às alternativas

Repowise é self-hostable (AGPL-3.0), não precisa de nuvem, e é BYOK para as chamadas a LLM que sim faz (a geração de docs). Comparado com DeepWiki, Swimm e CodeScene — os pontos de comparação mais próximos — é o único que combina inteligência de comportamento via git, um health score validado contra defeitos, docs auto-geradas, tools MCP-native e rastreamento de decisões arquitetônicas em um único pacote self-hosted. CodeScene é o análogo mais próximo do lado do health score, mas não é MCP-native e não faz decisões arquitetônicas nem docs auto-geradas.

Também há uma versão hosted (repowise.dev) para times que não querem rodá-lo eles mesmos, mais um PR bot gratuito do GitHub que comenta hotspots e declínio de health por PR sem nenhuma chamada a LLM.


Vale a pena?

Se você já está convencido da proposta de “dar ao seu agente um mapa persistente em vez de fazer com que ele reexplore seu repositório a cada sessão” que vimos com codebase-memory-mcp, o Repowise faz o mesmo e adiciona uma camada genuinamente diferenciada em cima — uma que tenta responder “quais arquivos realmente vão quebrar” em vez de apenas “quais arquivos estão relacionados”. Essa é uma afirmação mais difícil de sustentar e mais difícil de fingir. Vale a pena apontá-lo para seu próprio repositório e comparar os arquivos com pior pontuação de repowise health contra seus últimos seis meses de commits de correções de bugs — esse é o teste que realmente importa aqui, mais do que qualquer gráfico em seu README.

Você já testou no seu próprio repositório, ou fica com o knowledge graph puro por enquanto? Conte-nos como o health score previu bem seus problemas reais :backhand_index_pointing_down: