TL;DR: Most teams enforce commit standards in three places — local git hooks, CI checks, and branch protection rules — and assume the three add up to coverage. They usually don't. Hooks are skippable by design, CI often reports without blocking, and branch protection covers a narrower surface than people expect. The gap is invisible until a change that "couldn't happen" reaches production. PainHunt's DevTools category carries 4,033 high-scoring signals, and this cluster is not about better hooks — it's about proving which rules actually hold.
The evidence
PainHunt's DevTools category holds 4,033 high-scoring signals (10+/15), average score 11.5, average intensity 7.2/10 — the largest single category in the dataset, drawn from Substack, Medium, Dev.to, GitHub and BlueSky.
The enforcement cluster inside it describes the same shape repeatedly:
- Rules that feel protected but aren't. Teams believe a standard is enforced; the enforcement is partial and nobody has checked which part.
- Hooks only bind cooperating machines. They are skipped by
--no-verify, absent on a machine where the installer never ran, and structurally not in the path for commits made through a web editor. - CI reports without blocking. Checks surface problems and then leave the decision to a human, which is a different thing from preventing the merge.
- No consolidated view. Nothing shows whether hooks, CI checks and repository rulesets are covering the same rule or three different slices of it.
- Incidents caused by changes that were supposed to be impossible — migrations reaching the wrong environment, unreviewed code landing on a main branch.
The personas are engineering managers and platform engineers — people who own the policy rather than write most of the commits. That matters: the person who believes the rule is enforced is usually not the person who would notice it being bypassed.
Why now
Three shifts made a long-standing weakness expensive.
Commits stopped coming only from laptops. Web editors, GitHub Actions bots, dependency updaters and AI coding agents all produce commits that never pass through a local machine. Every client-side control silently drops out of the path for that traffic, and that traffic is now a meaningful share of it.
Rule surfaces multiplied. A repository today may carry pre-commit hooks, required status checks, branch protection, repository rulesets, CODEOWNERS and an org-level policy — each configured in a different place, by different people, at different times. Coverage becomes an intersection nobody has computed.
The blast radius grew. When a commit can trigger a deployment or a migration, "this shouldn't have merged" stops being a code review complaint and becomes an incident.
The wedge
The narrow, buildable thing is verification, not another enforcement layer. Teams don't need a fourth mechanism; they need to know which of the three is actually load-bearing for each rule.
- An adversarial policy test. On a scratch branch, attempt each documented bypass — commit with
--no-verify, commit via the web editor, push to a path assumed protected, merge without the required check — and report what survived. This is the afternoon of manual work every team means to do once and never repeats. - A coverage matrix, rules × entry points. One grid: rules down the side, commit paths across the top (local CLI, web editor, bot, API), each cell showing which layer catches it. The empty cells are the finding, and they're what no existing tool shows in one place.
- Drift alerts. Enforcement decays quietly — a check is renamed and silently stops being required, a ruleset is scoped to a branch pattern that no longer matches. Alerting on a rule that stopped being enforced is more valuable than the initial audit, because the initial audit is the part teams can do themselves.
- Evidence output for auditors. Regulated teams are already asserting that changes are reviewed and tested. A dated artifact showing the control was tested and held is worth more than a screenshot of a settings page.
Risks and honest caveats
Platforms may close this themselves. GitHub's repository rulesets already consolidate part of the problem, and a native coverage view is an obvious feature. Anything built here should assume the single-platform version gets absorbed, and be worth using because it spans GitHub, GitLab and self-hosted at once.
Adversarial testing needs write access to the thing it tests. A tool that pushes scratch commits to prove a rule fails needs permissions that a security-conscious team will scrutinise. Scoping it to a throwaway branch and deleting after is table stakes, and some organisations will still say no.
The buyer may not want the answer. The person who configured the rules is the person the report embarrasses. This sells better as a pre-audit self-check owned by the platform team than as a compliance tool bought over their heads.
It's a small line item. This is a $20–50/month/repo tool, not a platform. It works as a wedge into developer-experience tooling or as a feature inside an internal developer platform — see the related signal on self-service internal developer platforms — rather than as a standalone company.
Where this came from
This is one cluster inside PainHunt's DevTools category. If you're weighing whether the pain is real enough to build against, the Pain Point Browser shows the underlying signals with their intensity and commercial scoring, and the Idea Validator will score a specific version of this idea against the same dataset. The adjacent cluster on quality gates for AI-generated code covers the same enforcement problem from the code-review side.