CR-67 archive_reason prefix lint parses the reason by line position and can read a word out of a comment
Hit live on PLUTO-767 (2026-10-06). pluto/.gitpush-pre.sh's CR-67 lint resolves the 3rd argument of a multi-line setArchiveContext( call positionally. Adding an explanatory comment INSIDE the arg list shifted the position and the lint read the word 'trimmed' out of the comment text, reporting src/lib/admin-actions.ts:858 reason='trimmed' and failing the push on a reason literal that was in fact the compliant string admin:user:bulkDeactivate:batch. Worked around by moving the comment above the call. The false POSITIVE is the cheap half; the same positional parse means a comment line can also shift a genuinely non-compliant literal out of the inspected position, which would be a false NEGATIVE on a security-adjacent lint. Fix: match the string-literal argument by syntax (the first string literal in the call) rather than by line offset, and force the check red against a known-bad literal preceded by a comment before accepting it - a control that has not been seen to fail on the case it is for is a green line. Related: PLUTO-767 will add a corpus-wide grammar assert to the same hook and should use the same parse.
Activity
-
FIXED at 576fd50, v2.23.132, live-version MATCH vs remote main (Class-S, tooling-only). MY ORIGINAL DIAGNOSIS ON THIS ROW WAS WRONG IN THE MECHANISM and the real defect is worse. The lint is NOT positional - it paren-matches correctly and scans every string/template literal in the call. It scans RAW TEXT, so a quote or backtick inside a comment opens a PHANTOM literal. My pushed comment contained a backtick-quoted word, which the regex read as a template literal: that is the false positive. The inverse is real and reachable by ordinary prose, measured not theorised: a comment ending on an unbalanced quote whose phantom literals all happen to start with an allowed prefix swallows the real literal's opening delimiter, leaving the real reason unterminated and therefore never matched - a SILENT PASS. Probe case: comment 'was "admin:old" now "admin:new' followed by literal "oops:bad" produced ZERO findings from the old lint. That is exactly the comment someone writes while changing a reason literal, so the exposure is authoring-natural, not contrived. FIX: both the paren walk and the literal scan now run over a comment-blanked copy of the file; regex literals are blanked too because a quote class like /["']/ desynchronises the scan; blanking preserves length so reported line numbers still match the real file. FORCED-RED SUITE 10/10 with both directions seen red - case 3 old=FAIL new=pass (false positive gone), case 4 old=pass new=FAIL (silent pass closed), plus controls for block comments, regex literals, a URL with // inside a REAL literal (must not be blanked), and a shifted argument order. Live-tree measurement: 0 findings before and 0 after, so no verdict on current source changes - this is a pure instrument correction, and no bad literal was hiding behind the silent-pass channel today. Probe suite kept in scratchpad/p768, not committed. Carried with the push: a pre-existing one-line GITPUSH_INFO_VERSION 4.57->4.64 marker bump that was already dirty in that file, not mine.
-
completed