Source-of-truth invariants

These four gates govern the project's OWN quality posture (not the claude ↔ apr code parity). They are the meta-gates that make the rest of the gates trustable.

CCPA-009 — ci_main_branch_green

What it asserts: every commit on main was produced by a PR that had a green CI run.

How it's enforced: GitHub branch protection on main requires the ci/gate check. Direct pushes to main are blocked. Force-pushes to main are blocked. Merges require either fast-forward from a green branch OR squash from an approved + green PR.

What would falsify: a commit on main without a green CI run.

CCPA-010 — pmat_comply_100pct

What it asserts: every commit on main has pmat comply check returning is_compliant=true AND zero Fail-status checks.

How it's enforced: pmat comply check runs in CI on every PR. Any non-compliant artifact (file with disallowed unwrap, complexity > cap, lint violation, etc.) fails the job.

What would falsify: a main-branch commit where pmat comply check reports any Fail-status check.

pmat comply is the project's quality posture meter. It's not just clippy — it's a multi-pass static analyzer with custom rules for the aprender org's conventions (allowed-unwrap categories, complexity caps, doc-coverage minimums, etc.).

CCPA-011 — line_coverage_100pct

What it asserts: 100% function coverage AND ≥99% line coverage across all crates.

How it's enforced: cargo llvm-cov in CI. The threshold was refined in v0.4.0 (M120) from "100% lines" to "100% functions AND ≥99% lines" — the relaxation acknowledges unreachable error-handling branches that are mechanically uncoverable.

What would falsify: a main-branch commit where cargo llvm-cov reports any function with 0% coverage OR line coverage below 99%.

CCPA-012 — pv_contract_gate_on_commit

What it asserts: every commit on main passed pv validate against the pinned contract YAML AND the contracts/pin.lock matches the canonical aprender source.

How it's enforced: a pre-commit hook (scripts/install-pv-hook.sh, hard-installed by make install-hooks) PLUS the CI pv validate job. Both must pass before merge.

What would falsify: a main-branch commit where pv validate rejects the contract YAML OR where contracts/pin.lock's sha256 doesn't match the aprender commit's contract YAML at the pinned commit.

Why these four

These are the trust roots of the rest of the gate hierarchy. If CCPA-009 fails, any other gate could be silently broken on main without notice. If CCPA-010 fails, the project's quality posture has drifted from the org's contract. If CCPA-011 fails, untested code is on main. If CCPA-012 fails, the contract YAML and the code are out of sync.

Per CLAUDE.md, these are the gates that "no code ships without."