Quality gate
- New bugs 0
- Coverage on new code 92.1%
Compare · SonarQube
Proof vs SonarQube
A SonarQube quality gate scores new code against a ruleset. Proof re-reads the shall. Agents can pass the first and still break the second. Semgrep sits on this page.
proof auditNot a SonarQube alternative. Keep the quality gate. Proof does not ship that analyzer.
01 · Answers
How Proof compares to SonarQube
The comparison, as a list. Click the instrument for the same split.
- How does Proof compare to SonarQube? SonarQube is a quality gate on new code. Proof is a requirement gate. Coverage on new code can be green while the shall is red.
- Is Proof a SonarQube alternative? No. Keep SonarQube for smells, duplications, and org-wide dashboards.
- What does SonarQube still win? Thousands of repos, rule packs, a dashboard the org already knows. Semgrep sits here.
- Does a SonarQube quality gate catch a broken requirement? No. The shall was never a Sonar condition. That is the Proof check.
02 · The distinction
A quality gate is a ruleset. A requirement gate is a shall.
SonarQube Server scores new code against the conditions you configured: new bugs, smells, coverage on new code, duplications. That bar is real. It is not the promise the software was supposed to keep.
A quality gate answers: did this patch trip a rule. Agents learn the rules and write the tests that pad coverage on new code. The gate stays green. The shall about refunds was never a Sonar condition.
Signed requirements live in the repo. proof audit re-reads the source. If a shall that held last week does not hold in this commit, CI is red. Semgrep sits with SonarQube here: policy, not a shall.
03 · The exhibit
Same pull request. Two gates. Two answers.
The agent added refunds. Coverage on new code is high. The shall was never a Sonar condition.
The shall
Refunds never exceed capture. Not a Sonar condition.
Not in the rulesetQuality gate
Still green. The tests the agent wrote count as coverage.
PASSEDProof
- STK-REQ-184 refunds never exceed capture
- Verdict not a Sonar condition. CI red.
Same pull request. Two gates. Click the tabs.
| Axis | SonarQube quality gate | Proof requirement gate |
|---|---|---|
| What it reads | New code against a ruleset: bugs, smells, coverage %, duplications. | Signed requirements in the repo against the source that shipped. |
| Pass means | No new issues above the threshold you set. Coverage on new code holds. | Every cited shall still holds. Stale satisfies fails the check. |
| What an agent can do | Satisfy the rules and still break the promise. The tests it wrote count as coverage. | Cannot merge while proof audit is red. The agent gets a reproducer, not a smell. |
| What you keep | The org dashboard, rule packs, and quality-gate UX. Keep them. | Requirements as files, findings with a reproducer, a CI exit code. |
| Where they win | Org-wide static analysis. Thousands of repos. That dashboard is theirs. | One component, held to signed requirements, on every commit. |
Quality Gate: PASSED New Bugs: 0 Coverage on New Code: 92.1% proof audit STK-REQ-184 refunds never exceed capture not a Sonar condition. CI red.
04 · The honest loss
Proof does not replace SonarQube.
SonarQube still wins at the work it was built for: a quality gate across a fleet of repositories, with rule packs and a dashboard a whole org already knows.
Keep SonarQube for smells and new-code coverage. Proof does not ship that analyzer. A green proof audit is not a claim the code is free of smells. A green SonarQube gate is not a claim the software still does what you promised.