feat(fix-record): issue v2 from both producers (2/2)

[arthurpanhku]

Summary

Stacked on #217 — base is claude/fix-record-v2-shape, so review that first. This is where the defect actually closes.

#217 added the shape and the version-aware re-derivation without changing what any command emits. This switches the two producers to supply the regression evidence, so records issued from here on are v2 and a repair that trades one vulnerability for another can no longer be called verified.

What each path was doing

dvalin verify <workflow> was computing the right thing and putting it in the wrong place. gate.blocking holds the original targets still present and the findings the repair introduced, and the whole set went into after.remainingTargets. Now they are separated — targets filtered by the original target keys, introduced derived from the initial scan's fingerprints — with the gate's own threshold and mode recorded beside them.

dvalin . --fix --verify was not computing it for the record at all. It had the baseline in hand and used it in evaluateVerificationGate (which fails on findings scoring ≥ 7 the baseline lacked), but none of that reached buildFixRecord. So:

331  saveFixRecord(record)      ← says VERIFIED, written to --record, printed
340  if (!gate.passed) throw    ← "1 new high/critical finding target(s) appeared"

A record saying verified, on disk and re-deriving cleanly, for a repair the command rejects a moment later — and then collected by the Evidence Pack, the Action's PR comment, and anything else reading the store.

It now records introduced plus a gate of high/new, which is the rule that path already applied — written down rather than implied by which command happened to run.

The ordering dissolves rather than needing a patch. With the regression inside the record, filing before the gate throws is no longer a contradiction: the record already says the repair regressed. That the problem disappears instead of needing its own fix is the sign the shape was the right one.

One extraction, and why it is not tidying

Record assembly on the --fix path moved into buildRunFixRecord. With it inline, I mutated the call site to introduced: null and no test failed — introducedSince was unit-tested, but the call site needs an executor, a worktree, and a git tree to reach. A helper that is tested while its only caller is not is the same shape of gap as the original defect: correct machinery, unverified wiring.

Extracting it makes the wiring assertable. Both mutations now fail tests.

Testing

npm run check — both typechecks and 554 passed (544 on #217 + 10 new). dvalin . --diff over the change: 0 findings.

Mutation-tested. Every switch is pinned by a test that fails when it is undone:

Mutation	Result
workflow path stops supplying regression	3 failed
workflow path puts introduced back into remainingTargets (the original conflation)	1 failed
--fix call site supplies introduced: null	2 failed
--fix records a none threshold, which would block nothing	2 failed

The headline case is asserted directly on both paths: a repair that clears its target, passes the project's checks, and introduces a critical SQL injection now yields verified: false, outcome: 'regressed'.

Security and AI Governance

• This change does not expand file, shell, network, model, or approval permissions. — Set arithmetic over scan results already in memory; no new I/O, subprocess, or egress.
• If it changes agent behavior, prompts, policy, providers, audit logging, or release/build security, I updated the relevant governance evidence in docs/. — No agent, policy, or audit behavior change. The verdict rules are documented in FVP-1 by feat(fix-record): add the v2 shape and version-aware re-derivation (1/2) #217.
• If it introduces a new model/provider/tool or new data flow, I completed docs/governance/AI-CHANGE-IMPACT-ASSESSMENT.md. — Not applicable; no new model, provider, or tool.

Known residual divergence, not fixed here

evaluateVerificationGate also fails a run when the worktree has no code changes, and that condition is still not represented in the verdict. A run where the targets vanished, the checks passed, and nothing was edited would produce verified: true while the command throws. It is far rarer than the regression case and it is a different question — whether a record should have to prove a change happened at all — so it is not folded in here. The record already carries changes (files + diff hash), so the natural fix is a further FVP assertion rather than more producer logic. Say the word and I will file it.

🤖 Generated with Claude Code

https://claude.ai/code/session_0186VyaiQq3MTo4i4mK8P3aW

---

Generated by Claude Code