Know which code will break next, and the fix for it.

Every file gets a single 1 to 10 score computed from 25 deterministic markers: McCabe complexity, deep nesting, brain methods, class cohesion (LCOM4), god classes, Rabin-Karp clone detection, change entropy, co-change scatter, ownership dispersion, prior-defect history, test-quality smells, and more. Lower scores mean the file is more likely to harbor defects.

It is defect-validated. On the same 2,770 files across 9 languages with real defect labels, ranking by repowise health surfaces 2.3x the defects of a leading commercial tool under the same review budget (recall 0.173 vs 0.074, effort-aware Popt 0.607 vs 0.462, ROC AUC 0.731 vs 0.705). Across 21 open-source repos the mean cross-project ROC AUC is 0.74 with a 95% confidence interval of 0.68 to 0.79, ranging from 0.55 to 0.86 across individual repos.

No. Scoring is fully deterministic: 25 markers with weights calibrated offline against a defect corpus. Only the learned constants ship, so the same code always produces the same score, in under 30 seconds on a 3,000-file repo. No cloud, no API calls, no drift.

Both score code health, but repowise is open source so every heuristic is inspectable and reproducible on your own repo, and the score ships inside a broader platform: named refactoring plans your agent can apply, an architecture-aware wiki, git intelligence, architectural decisions, agent provenance, and ten MCP tools for AI agents.

No. The discrimination survives controlling for file size (partial Spearman rho of -0.16) and significantly out-discriminates both recent churn (+0.10 AUC) and prior-defect history (+0.12 AUC), with DeLong p below 1e-9.

Yes. repowise ingests LCOV and Cobertura coverage to compute untested-hotspot risk (the intersection of low coverage and high hotspot score), alerts when a file's health starts declining, and ranks refactoring targets by impact for effort.

Yes, that is the point. Every heuristic is open source under AGPL-3.0, and the validation runs on your own repo. On a typical project, 16 of the 20 lowest-health files had a bug fix in the last 6 months, 3.3x the 24% baseline.

Yes, as a static health pillar, not as an APM or profiler. repowise statically detects performance-risk shapes such as N+1 access and IO-in-loop patterns and scores them as a co-equal third pillar alongside defect risk and maintainability. It is high precision and low recall by design: it raises few findings, but the ones it raises are real. There is no runtime, no agent, and no tracing; it reads your source, like every other signal.

It names the refactor and hands it over. Each of the seven plan types is structured data: what moves where, the helper's signature, what else has to change and the tests to run. Your agent applies it as a recipe, or you ask for the code and get a diff to review. Nothing is ever applied to your repository on its own.

Extract Method, Extract Class, Extract Helper, Move Method, Split File, Break Cycle and Performance Fix. Each detector reports nothing when a signal it needs is missing, so a gap means no suggestion, never a guessed one, and the same commit always gives the same plans.

Every finding carries a confidence from 0 to 1 and the evidence behind it. A finding is marked safe to delete only at high confidence and with no runtime-load risk on its path, such as config, bootstrap or served assets. Entry points, framework routes and registered handlers are never reported.