Fingerprints change when a measurement changes and collide for repeated findings — fingerprint v2 #97

Problem

fingerprintIssue (src/issue-fingerprint.ts:16-19) hashes check + rule + normalised path + lower-cased message (:42-48).

1. Unstable across commits. Many messages embed a measurement: "AdminLayout: 65 lines (max 60)" (runners/complexity.ts:43), "~4620 tokens (>4000)" (context), "329 lines — consider splitting" (standards large-file), "imports 12 modules" (architecture), "Barrel file with 5 re-exports" (performance). When the number moves, trend.ts reports one fixed + one new. On a 1,501-issue report (CLI 0.54.4) 600 messages contain digits.
2. Duplication identity includes line numbers. runners/duplication.ts:82 sets file to `${fileA}:${lineA} ↔ ${fileB}:${lineB}` and :81 puts the clone length in the message; any edit above either clone re-identifies it.
3. Not unique within a report. Repeated findings in one file share a fingerprint (on that report: 156 groups covering 529 issues; mostly error-handling, performance, accessibility, type-safety). delta.ts:57-73 already counts them as a multiset, but trend.ts:55-60 collapses them in a Map, so fixing one of two identical findings reports nothing.

What to do (cheapest first)

1. trend.ts multiset — count per fingerprint like delta.ts. Ships alone, no fingerprint change.
2. Per-runner identity (v2):
   • File-scoped measured rules (standards large-file, context high-token-count, architecture high-fan-out, performance barrel-import): key = check + rule + file; message excluded.
   • complexity: key = check + rule + file + function name (f.name).
   • duplication: key = sorted pair of paths without :line + hash of the normalised snippet.
   • Everything else: current key.
     Implemented as an optional per-runner subject (emitted as Issue.subject once schema 0.6.0 declares it); never a global digit regex.
3. Disambiguate repeats with a content anchor: for issues with file + line, add a hash of the whitespace-normalised source line (read from the raw file via FileInventory, not SFC-extracted content); only among identical line contents append an occurrence ordinal. Issues without a line: ordinal by emission order.
4. Versioning: meta.fingerprintVersion = 2. In trend.ts / delta.ts, when the two reports' versions differ (absent = 1), recompute v1 on both sides from check/rule/file/message (available on IssueSnapshot too) so the boundary scan reports no churn. Do not rely on readIssueFingerprint's stored-value preference (:37-40) — that is what would cause the churn.

Rejected

• Global "replace digits with #": dependencies issues have no file/rule and say "95 high vulnerabilities" (runners/dependencies.ts:83-93); 95 → 96 would keep identity and hide a new vulnerability; also collapses version strings and CWE-nn.
• Pure line-order ordinal: inserting an identical finding above existing ones shifts every later ordinal, so the "new" finding reported is the wrong one and any per-fingerprint state attaches to the wrong finding. ~⅓ of issues have no line, so line order is not even total.
• Symbol for type-safety: it is a line regex (runners/type-safety.ts:147) with no AST; its messages carry no measurement anyway. The content anchor covers it.

Acceptance criteria

• Each measured rule above: same finding with a changed number keeps its fingerprint (test per runner).
• Duplication: inserting lines above both clones keeps the fingerprint.
• Two identical findings on different lines get distinct fingerprints; inserting a third identical line above them leaves the first two unchanged; fixing one reports exactly that one fixed.
• dependencies count change still reports a change.
• A trend/delta between a v1 report and a v2 report of unchanged code reports 0 new / 0 fixed.
• CHANGELOG notes the fingerprint version change.

Open question

Project-level aggregate findings ("14 unused files detected by Knip", "Mixed styling approaches: tailwind (1031)…", "Only 20% of exports…") are metrics phrased as findings. Keep the message in their key (churn on every change, today's behaviour) or key by rule (identity stable, count change invisible to identity)? Recommend: keep message for now; per-advisory dependency findings would be the real fix.

Constraints

• mcp's committed fixture changes when its CLI_SPEC next moves to the release containing this; note it in that pin issue.
• Issue.subject / meta.fingerprintVersion are declared in schema 0.6.0 (Reports don't say which commit, branch, CI run or producer they describe — declare scan provenance in VibeReport.meta (0.6.0) schema#6); fingerprint already passes through, so this is not hard-blocked.

Related: #45 (closed, introduced fingerprints), app#27 (fingerprints unread in the monitor).

🤖 Filed with Claude Code