Hey James, Right now the action is advisory only. It posts and updates a PR comment, but the check always passes, so it can't gate a merge through branch protection. It would be useful to optionally fail the check (exit non-zero) when specific thresholds are exceeded, so a repo can mark it as a required status check and block risky dependency changes. Some form of granularity would be very nice: block on some checks but only warn on others. For example, block when the dependency-count or install-size threshold is exceeded, but keep duplicates and replacements advisory. A couple of ways that could look: - Per-check boolean inputs, e.g. `fail-on-dependency-count`, `fail-on-size`, `fail-on-duplicates`, all defaulting to `false` so current behaviour is unchanged. - Or a single `fail-on` input taking a list of check names, e.g. `fail-on: dependency-count, size`. Either way, the `scanFor*` functions would need to return a structured result (which check ran, whether it breached, the message) instead of pushing pre-formatted strings into a shared `messages` array, so the fail decision can be made per check. Two open questions: 1. **Granularity model:** per-check booleans, a single `fail-on` list 2. **Fork / artifact mode:** with the `comment` / `artifact` / `comment-from-artifact` split (and the `pull_request_target` direction in #31), which job should carry the failure? Failing the analysis job seems cleanest, but it interacts with how you're thinking about #31.