Trends and health score

A single scan tells you what’s broken now. The Trends tab tells you whether things are getting better or worse — which is the question that actually drives decisions.

Health score

The health score condenses a scan into one number, weighted by severity. Critical issues pull it down hardest, Info issues barely move it.

It appears on the welcome dashboard as a large color-coded figure with a sparkline and a delta against the previous scan.

The three weights are configurable in Settings. Defaults suit most projects, but if your team treats warnings as blocking, raise the warning weight so the score reflects that. Because scores are recomputed from stored counts, changing weights re-scores your whole history rather than creating a discontinuity.

Treat it as a trend indicator, not a grade. The useful signal is the direction over weeks, not the absolute value on any given day.

Scan history

Each completed scan is appended to Library/RefSafePro/History.json with its timestamp, issue counts by severity, health score, and duration.

History is local, not committed. It reflects the scans run on your machine.

Trend chart

The issue trend chart renders history three ways:

• Line — total issues over time. Cleanest for spotting direction.
• Stacked Area — severity composition over time. Shows whether a falling total is actually fewer Criticals or just fewer Infos.
• Grouped Bars — per-scan severity comparison. Best for a small number of scans.

Hovering any point shows a preview card with that scan’s exact counts.

Statistics tile

Alongside the chart:

• Activity over the last 7 days
• Total time spent scanning
• Recent-versus-prior trend

Total scanning time is a decent proxy for whether validation has become friction. If it’s climbing, move your routine scans to ChangedOnly scope.

Comparing two scans

Select any two scans from history and compare them directly. The comparison reports issues introduced, issues resolved, and issues unchanged between them.

This is the tab’s most practical feature. Before starting a refactor, run a scan. After finishing, run another and compare the two. You get a concrete answer to “did this break anything?” instead of an impression.

It also works across a longer arc — comparing today against a scan from a month ago shows what a sprint actually did to project health.

Reading a rising issue count

A climbing count isn’t automatically bad. Common benign causes:

• You enabled a rule that was previously off, so an existing backlog surfaced at once
• A snooze expired and several issues returned together
• You widened the scan scope, so more of the project is now covered

The diff between consecutive scans distinguishes these from genuine regressions — new issues from a scope change all appear at once in areas you just started scanning, while real regressions cluster around what you’ve been editing.