Every bugweg analysis gets a User Impact Score: LOW, MEDIUM, HIGH or CRITICAL, derived from the highest-severity issue found in the PR. It's a triage signal, meant to help you decide which pull requests a human should read first.
| Score | What it means | Suggested response |
|---|---|---|
| LOW | The most serious finding is low severity | Normal review queue |
| MEDIUM | At least one medium-severity finding | Reviewer reads the flagged lines before approving |
| HIGH | At least one high-severity finding | Review before other open PRs; author responds to each finding |
| CRITICAL | At least one critical finding; the check run is set to action_required | Fix or explicitly dismiss before merge; a branch rule requiring the check blocks it |
What sits alongside the score
Changed files also get a best-effort reachability signal, shown in the check-run comment and in the dashboard's PR detail view: is the file itself entry-point-shaped (routes/, api/, handlers/) or imported by one? That's a static, one-hop heuristic against the repo's entry-point files, not a call graph or a runtime trace, and it doesn't change the score itself. It is also separate from bugweg's per-file code risk score, which tracks risk accumulating in files over time. "No signal found" means unknown, not unreachable.
Repos that install the optional, open-source Express middleware (bugweg-express-telemetry) can also feed real, aggregated route-hit counts into that signal. It only covers repos that opt in, and only Express today; every other repo keeps the static signal.
Why it's still listed as simplified
On bugweg's own feature status page, User Impact Score is marked simplified, and that label is deliberate. The score is a severity rollup, not a model of your product's traffic or business-critical paths; the reachability signal is a heuristic; and the telemetry path is opt-in and Express-only. It's useful for triage, but it shouldn't be the only thing that decides what's safe to skim.
How to test it on your own repo
Take the last month of PRs bugweg has reviewed and look at which ones it scored HIGH or CRITICAL, then compare that list against the incidents and hotfixes your team remembers. Where the two agree, the score is saving you triage time. Where they don't, you've found a concrete blind spot in the current implementation, not a reason to discard the rest of the review pipeline.
See it on your own repo. 3 free PR reviews — card required, never charged.
Install on GitHub