New-Code Delta

Quality gates enforce standards on new code only by default. This page explains how that distinction is made mechanically so you can debug surprises.

The Problem

If you scan a PR branch and compare raw finding counts to main, you’ll flag every pre-existing issue as “new” — which kills adoption. Developers get blocked on legacy tech debt they didn’t create.

CodeStax fixes this with fingerprint-based new-code delta: only findings introduced in this PR are evaluated against the gate.

Fingerprint

Every finding gets a stable 16-character hash:


fingerprint = sha256(file_path | rule_id | normalize(code_snippet))[:16]

normalize() strips all whitespace, so reformatting churn doesn’t move the hash. Renaming a function from foo to bar will change the hash (the snippet text differs); a pure whitespace reflow will not.

Stored on ScanIssue.fingerprint (indexed).

Baseline

On every scan of the repo’s default branch, fingerprints are upserted into QualityBaseline keyed by (repo_id, branch, fingerprint). This is the “truth” — every finding that exists on main.

On a scan of any non-default branch, each finding is looked up:

If the fingerprint is in the baseline → is_new_in_pr = false (inherited).
If the fingerprint is not in the baseline → is_new_in_pr = true (introduced by this PR).

The quality gate (with applies_to_new_code_only: true) only evaluates findings where is_new_in_pr is true.

First-Scan Semantics

The very first scan of any repo has no baseline. To stay conservative:

If a scan runs before the baseline exists, all findings are flagged is_new_in_pr = true.
This means the very first PR after install may show many “new” findings.
Once the default branch is scanned, the baseline is set. Subsequent PR scans correctly filter.

Recommended bootstrap: trigger a scan on the default branch immediately after repo connection, before any PR scans fire.

Baseline Drift

Over time, fingerprints drift — refactors move code, bulk renames change snippets. What was “inherited” becomes “new”. If you see false spikes of new-in-PR findings after a big merge, that’s the signal to rebuild the baseline:

Settings → Repositories → [Repo] → Rebuild Baseline (admin only)
Or POST /quality/gates/rebuild-baseline/:repo_id via API

Next default-branch scan repopulates fresh fingerprints.

See Baseline Rebuild for the full flow.

Why a fingerprint, not line number?

Line numbers move. Import reshuffling, added comment, extracted helper — all shift line numbers without changing the issue. Using a fingerprint over (file, rule, normalized_code) means:

Adding a comment above the finding → same fingerprint
Reformatting whitespace → same fingerprint
Extract-to-helper where the issue moves to a new file → new fingerprint (intentional — the code moved)

Inspecting Fingerprints

GET /api/quality/gates/status/:scan_id returns new_in_pr counts. GET /api/scans/:id/issues includes is_new_in_pr + fingerprint per finding.