SonarQube Cloud

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the code quality gate I actually need instead of SonarQube Cloud: analysis on the change, not on the whole repository, blocking a merge when the new code is worse.

Read this first: the free tools here are strong — Semgrep for patterns, the language's own linters and type checker, jscpd for duplication, whatever coverage tool you already run. What the fee buys is rule sets for many languages maintained by people who know them, and the new-code quality gate. The rules you should borrow; the gate you can build in a weekend, and it is the part that changes behaviour.

STACK
- Node 20+ with Fastify for the orchestration and the dashboard
- SQLite through better-sqlite3, WAL mode
- Existing analysers as the engines, each in a container. Do not write a static analyser
- Caddy in front

THE DATA MODEL
- repos: id, name, remote_url, default_branch, config_json, is_active
- analyses: id, repo_id, commit_sha, ref, pull_number, base_sha, started_at, finished_at, status, engine_versions_json
- issues: id, analysis_id, engine, rule_id, severity, kind, file, line, end_line, message, fingerprint, is_new, effort_minutes — kind is bug, vulnerability, smell or duplication
- measures: id, analysis_id, metric, value, scope, scope_path — coverage, duplication, complexity, lines, per file and overall
- gates: id, repo_id, name, conditions_json — the thresholds
- gate_results: id, analysis_id, gate_id, passed, failures_json
- suppressions: id, fingerprint, reason, expires_at, approved_by — always with a reason and an expiry
- Fingerprints stable across analyses, computed from the rule plus a hash of the surrounding code rather than the line number, so a finding survives the file being reformatted

THE NEW-CODE GATE, WHICH IS THE WHOLE IDEA
- Judging a repository as a whole produces a number nobody can move, and a number nobody can move is ignored
- Judging the change is different: this pull request adds twelve lines of uncovered code and two new issues. That is actionable, it is fair to the author, and it is achievable today
- So: compute the diff against the merge base, attribute every issue and every uncovered line to whether it is in the changed lines, and apply the thresholds only to those
- Conditions on new code: no new issues above a severity, coverage on new lines above a percentage, duplication on new lines below a percentage, no new secrets, no security hotspots left unreviewed
- Existing debt is reported separately and never blocks. It goes down over time because every change leaves its own lines clean, which is the whole strategy

RUNNING THE ANALYSIS
- One command in CI: analyse, compare against the base, report, and exit non-zero if the gate fails
- Engines run in containers with a pinned version recorded on the analysis, so a change in results is explicable rather than mysterious
- Coverage read from the file the test run already produces — lcov, Cobertura, whatever the language emits
- Duplication across the whole repository but attributed to the new lines
- Complexity per function, reported when a new or modified function crosses a threshold

THE FEEDBACK
- One comment per pull request, edited in place on every push. A new comment per push is why these tools get muted
- It says: gate passed or failed, and if it failed, exactly which condition and where. Not a link to a dashboard — the specific lines, in the comment
- Inline annotations on the diff through the forge's own check API, which is where a reviewer is already looking
- SARIF output so the forge renders findings natively

HISTORY
- Every measure kept per commit on the default branch, charted as inline SVG
- Coverage, issue count and duplication over time, per directory as well as overall, so a decaying corner is visible
- The debt list ranked by effort, which is the actual to-do list when somebody has a quiet week

CONFIGURATION
- A file in the repository: which engines, which rules, the gate conditions, and the paths to exclude
- Exclusions that actually work: generated code, vendored code, migrations, and test files where the rules do not apply
- Validated by the same code that reads it, with a command to check it locally

RULES
- Start with the recommended set of each engine and remove what does not fit, rather than starting from nothing
- Every rule that fires and is suppressed twice should be reconsidered. A rule nobody agrees with trains people to ignore the tool
- Custom rules for your own patterns, written as engine rules and kept in the repository

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, FORGE_TOKEN, WEBHOOK_SECRET, SESSION_SECRET
- Migrations on boot, each once
- Nightly backup, restore script
- Health endpoint

WHAT MATTERS MOST
Diff attribution and one edited comment. Get the mapping between changed lines and findings right — including for a moved block and a renamed file — and make failing the gate mean something specific and fixable. Whole-repository scores are easy to compute and change nothing.

Give me the repository, the engine wrappers, migrations, .env.example, the CI workflow, and a README naming the free tools it stands on.