Metrics

What it meansA single composite score that rolls bug-fix ratio, churn, and recency-weighted regression density into one number. Recent bug fixes count 2× because last-quarter pain predicts next-quarter pain.

Why it mattersIt's the one number an EM can sort a backlog by. ≥70 is healthy (quietly works — deprioritise), 50–70 is caution (watch list), below 50 is firefighting (actively bleeding velocity). Below 50 sits in the top decile of bug-fix density across every feature we've ever observed.

How it's computedEmpirically calibrated against ~2500 dev features across 17 trained repos. Pure git history — no LLM, no test runs.

What it meansThe fraction of recent commits on a feature classified as fixes — matched by commit-message regex (fix:, bug, hotfix, regression).

Why it mattersUnder 0.15 is normal maintenance noise; 0.15–0.30 means something is structurally off; above 0.30 means most commits here are firefighting. Industry-typical SaaS runs 8–15%, so anything sustained above that is structural, not transient.

How it's computedPure git over the rolling window of recent commits per feature. No LLM.

What it meansHow much engineering attention a feature absorbs, expressed as commits per 100 commits of total repo history scoped to that feature.

Why it mattersUnder 2 is cold (stable or dead code), 2–8 is normal, above 8 is a hotspot — a disproportionate cost centre. The top 10% of features absorb 40%+ of commits, the classic Pareto curve. High churn + low health = split; high churn + high health = freeze the API and protect with contract tests.

How it's computedScale-invariant percentile cut across every corpus repo, so the thresholds hold regardless of repo size.

What it meansHow many other features depend on this one via imports, shared files, and co-change. Touching high-impact code ripples downstream.

Why it matters≥70 is critical (a change here ripples across the product), 40–70 is connective (touches multiple flows), under 40 is a safe-to-refactor leaf. Impact ≥70 + low coverage is the case for mandatory senior review — wire it to CODEOWNERS.

How it's computedGraph-centrality percentiles across the feature dependency graph. The top quartile is the "Stripe webhook handler" shape — touched by everything.

What it meansPer-feature / per-flow test reach. It answers "is this feature tested?" — not "did some line execute?". Most OSS repos ship no lcov report, so we estimate behavioral coverage from git history with zero setup, then merge real lcov line coverage on top if you upload it.

Why it matters≥70 is covered (regressions surface in CI), 40–70 is partial (happy path only — edge cases ship to prod), under 40 is uncovered. Features below 40 correlate with 3× higher post-deploy incident rate. Don't refactor a feature below 40 — write tests first.

How it's computedA 7-signal composite with zero LLM calls: co_change (0.35) + bug_fix_test (0.25) + freshness (0.15) + density (0.10) + co_author (0.10) + ci_workflow (0.05) + commit_msg (0.05). Each signal and the composite are clamped to [0, 1]. Every number carries a confidence band — high (5+ signals fired or lcov merged), medium (3–4), low (≤2) — so a noisy read can't masquerade as ground truth.

What it meansThe count of distinct authors who touched a feature in the last 90 days. Bus factor 1 means one person knows this code — they leave, you bleed.

Why it matters≥3 is resilient (safe to lose any single author), 2 is fragile (pair-program the next change), 1 is critical (single point of failure). Sub-3 ownership correlates with 2–4 week onboarding delays per incident on the affected feature — and "8 critical features owned by one person" is the conversation that gets headcount approved.

How it's computedDerived from git blame / author history over the trailing 90 days, scoped per feature. No LLM.