9to5 coverage · Features
Pull request patch coverage checks
Find the relevant changed lines that your tests missed, then verify 100% patch coverage on the uploaded GitHub commit.
What patch coverage measures
Project coverage describes the uploaded codebase. Patch coverage narrows the question to lines added or changed in a pull request. It is useful when a well-tested codebase could otherwise hide an untested change behind a healthy average.
9to5 intersects the PR’s added lines with the line records in your coverage report. A positive hit count means covered; zero means uncovered. The percentage is covered relevant changed lines divided by all relevant changed lines.
A small change with a clear result
| Relevant changed lines | Covered | Patch result |
|---|---|---|
| 10 | 8 | 80% — failing |
| 10 | 10 | 100% — passing |
The patch check currently requires 100%. Configure GitHub branch protection or repository rules to require the check if it should block merging; publishing a failed check alone does not configure your merge policy.
What a green check cannot establish
- Lines absent from the report are outside this calculation. An omitted source file is not automatically counted as uncovered.
- If no relevant changed lines intersect the report, the calculator returns 100%. Inspect the changed-file list and report scope before interpreting that result.
- Line execution does not establish branch coverage or assertion quality. Add tests for meaningful outcomes, errors and boundary conditions.
Give your agent a specific target
Use MCP to resolve the PR and ask for uncovered changed ranges. The agent inspects those source lines locally and writes tests; 9to5 provides the coverage context. Rerun CI and confirm the new head SHA before accepting the result.
Fix a failing patch check · Compare patch and project coverage