ci(code-quality): scope the hardcoded-value guard to changed lines (#13950)

[mrveiss]

Closes #13950

Thinking Path

Four PRs in one session failed code-quality on violations git blame attributes to other commits:

PR	inherited	touched an offending line?
#13924	7	no — its diff covered lines ~1078–1120, violations at 199…2758
#13797	3	no — branch had one commit; none of the three blamed SHAs
#13934	3	no
#13945	1	no

The rule is good and all 14 were worth fixing — they are fixed. The cost is that each occurrence looks like a genuine regression until a per-line blame plus a check of the branch's own commit list proves otherwise, and it recurs on every touch of a large legacy module. It also makes avoiding old files the cheapest way to stay green.

The sharper problem: in two of the four, the constant the guard suggested was the wrong concept.

• fix(agent): bound spill classification by size, and stop the nightly sweep touching operator-chosen roots (#13933) #13934 — "user_role": "user" is an RBAC input that worker_node reads in _validate_user_role; the guard suggested CategoryDefaults.ROLE_USER, the chat vocabulary.
• fix(llc): join memberships into the org chart so people render, not only agents (#13936) #13945 — le=100 is a ceiling; the guard suggested KNOWLEDGE_DEFAULT_LIMIT, a default.

Both hold the same value today, so the mechanical fix the message invites goes green while encoding a different meaning. Advice that is unsafe to follow blind is a reason to give it only where the author is already in the code.

What Changed

--changed-lines-only on the wrapper. It computes the added-line set from git diff -U0, runs the hook unchanged, and partitions its violation blocks by file:line.

Opt-in, not default. Every other hook running through this shared wrapper keeps its behaviour byte for byte; only code-quality's hardcoded-values step passes the flag. Pre-commit and a direct run still scan whole files, so the backlog stays measurable rather than invisible.

Fails closed. If the hook exits non-zero and the filter parses no file:line violations, its output is not one this filter understands — so it prints everything and exits with the hook's status. Suppressing an unparsed failure would turn a real regression green, which is #13880's defect reached from the other direction.

Suppressed violations are still printed under their own heading. The hook's COMMIT BLOCKED trailer is dropped in scoped mode: it counts what the hook found across whole files, not what the wrapper is about to decide, so leaving it would contradict the verdict three lines later.

Verification

pipeline-scripts/check-pre-commit-hook-pr_test.py .... 22 passed

Four new tests, the second being the one that matters — this is a scope change, not an off switch:

test	asserts
test_a_pre_existing_violation_in_a_touched_file_does_not_fail	the reported symptom is gone, and the violation is reported, not hidden
test_a_violation_the_pr_adds_still_fails	a newly added violation still fails
test_a_clean_pr_stays_clean	no false positives
test_the_default_mode_is_unchanged	the blast radius stays at one step

3 mutations applied, 3 killed: filter suppressing everything, filter keeping everything, and the default silently gaining scoping.

One thing the first version got wrong, worth recording: it counted the hook's banner and trailer as violation blocks and reported "6 violation(s) on lines this PR added" for a PR that added one clean line — a summary contradicting the correct suppression printed directly above it. Blocks now only count when they carry a VIOLATION header.

Unblocks

#13946 is currently red on 33 inherited violations in code_sync.py, most of them the /opt/autobot/ literals tracked by #13149. Fixing those inline would mean doing #13149 inside an unrelated PR, against paths that control where deploys write.

Model Used

claude-opus-5[1m]

[github-actions]

✅ SSOT Configuration Compliance: Passing

🎉 No hardcoded values detected that have SSOT config equivalents!