💡 Native Code Coverage Merge Protection Ruleset Standard

[github-actions[bot]]

Summary

GitHub shipped code coverage merge protection via branch rulesets on June 30, 2026 (public preview). This platform-native feature can block PRs when test coverage drops below configured thresholds or falls more than N percentage points from the default branch. An org-wide standard should codify coverage thresholds in the existing code-quality ruleset and adopt evaluate mode for safe rollout, replacing ad-hoc CI-check-based coverage enforcement.

Market Signal

GitHub Code Quality launched code coverage merge protection on June 30, 2026 (changelog). Branch rulesets now support two coverage conditions:

• Minimum coverage percentage — the aggregated code coverage for the PR branch must meet a floor
• Maximum coverage drop — coverage cannot drop more than N percentage points relative to the default branch

This is the first platform-native coverage enforcement mechanism. Previously, coverage was only enforceable via CI status checks (which can be re-run, bypassed via admin override, or fail silently). Ruleset enforcement is structurally more reliable: it cannot be circumvented by re-running a job. An evaluate mode allows measuring impact before enforcement.

User Signal

AGENTS.md already mandates: "PRs that reduce coverage below repo-defined thresholds will be rejected." The org's code-quality ruleset in standards/rulesets/ is the single source of truth for quality gates. Issue #593 (SonarCloud org-wide debt reduction) shows active investment in quality tooling. The org recently relocated rulesets to standards/rulesets/ (#575, #577) and added secret-scan + coverage CI jobs to the template (#578), signaling readiness to strengthen coverage enforcement.

Technical Opportunity

The org already manages code-quality and pr-quality rulesets in standards/rulesets/, applied by apply-rulesets.sh. Adding a coverage threshold rule to the existing code-quality ruleset JSON is a natural extension. The evaluate mode mirrors the org's proven informational → blocking promotion pattern (see issues #645-647 for the AGENTS.md linter rollout using the same pattern). The compliance audit can check coverage ruleset status fleet-wide.

Assessment

Dimension	Score	Rationale
Feasibility	high	Feature is in public preview. Integrates into existing apply-rulesets.sh infrastructure. Evaluate mode eliminates rollout risk.
Impact	high	Replaces ad-hoc CI-check enforcement with platform-native rulesets. Structurally prevents coverage regression org-wide.
Urgency	med	Evaluate mode means no rush to enforce. But adopting now builds baseline data for threshold calibration while the feature is fresh.

Adversarial Review

Strongest objection: This requires GitHub Code Quality (Enterprise Cloud/Team). If the org is on a plan that doesn't include Code Quality, this feature is unavailable.

Rebuttal: The org already uses Enterprise-tier features: repository rulesets, custom properties, Advanced Security (CodeQL, secret scanning), SonarCloud. The evaluate-first approach matches the org's demonstrated rollout pattern: measure informational impact first, then promote to blocking after validation (the same pattern used for AGENTS.md validation in #645-647 and compliance checks). Platform-native enforcement is strictly more reliable than CI-check-based enforcement.

Suggested Next Step

1. Verify the org's GitHub plan tier supports Code Quality features.
2. If yes, define initial threshold values (e.g., minimum 70% coverage, max 5% drop) in standards/rulesets/code-quality.json.
3. Deploy in evaluate mode via apply-rulesets.sh to one canary repo (e.g., .github itself) to measure impact before fleet-wide rollout.