Follow-up to #182: R-6EA94 still fires on SCREAMING_CASE status-enum references (e.g. 'PENDING') in prose comments

[acknex2]

Follow-up to #182 (thanks for the fix — and for #205). Confirming results from our repo on CLI 0.9.1 (remote scan, 2026-07-22): the narrowing works as designed — our finding count dropped from 27 (R-5EC1A + R-6EA94) to 3, string-literal hits (domain blocklists, UI copy like "Bug report") are gone, lowercase prose words ("later", "temp") no longer match, and R-5EC1A reports zero.

Residual FP class: R-6EA94 still fires when a comment references a status/state enum value in prose. In TypeScript/Prisma codebases these are conventionally SCREAMING_CASE, so they pass the new uppercase + word-boundary checks. Synthetic reproducers (mirror the 3 hits in our private repo):

// A row stays PENDING until a reviewer approves it.
const x = 1;

// PENDING or RUNNING. If the job is just leaving the queue, re-anchor the bar.
const y = 2;

Both are accurate descriptive comments about runtime state — nothing "leftover" to clean up.

Suggestion — either:

1. Drop PENDING from the tag lexicon. Unlike TODO/FIXME/HACK/XXX it's a very common domain/state word (order status, job status, DB enums), and it wasn't part of the conventional tag set; or
2. Keep the word but require tag form, not just the token: comment-leading position and/or colon suffix (// PENDING: migrate this later), the same shape most linters use for TODO detection. Mid-sentence enum references then pass while real leftover tags still match.

Happy to re-test a pre-release build, as before.

[Rome-1]

Thanks for the careful re-test, and for the precise reproducers — the before/after numbers are exactly what we needed to confirm the narrowing behaved as intended.

You're right that this is a residual class rather than a regression. Descriptive comments referencing a status enum are accurate comments, and SCREAMING_CASE is the conventional casing for those values, so they slip past the uppercase and word-boundary checks we added. That's a false positive on our side.

We're going with your second suggestion: requiring tag form rather than just the token — comment-leading position and/or a colon suffix, the shape linters use for TODO detection. That keeps genuine leftover tags like // PENDING: migrate this matching while mid-sentence enum references pass, and it covers the rest of the status vocabulary (RUNNING, FAILED, BLOCKED, ...) instead of just the one word.

We'll follow the same process as last time and confirm here once it's live.

[Rome-1]

Thanks for the precise follow-up — the reproducers made this a five-minute diagnosis.

We went with your option 2. PENDING stays in the lexicon, but the low-priority tags now have to appear in actual tag form: an uppercase low tag has to end the clause right where it appears — colon, dash, owner-paren, or end of line — instead of matching mid-sentence. The high-priority tags (TODO/FIXME/BUG/XXX) are untouched, since those aren't words a comment would use in ordinary prose, so a bare // TODO wire this up still fires as it should.

Re-tested against your two reproducers plus tag-form positive controls:

// A row stays PENDING until a reviewer approves it.                              -> clean
// PENDING or RUNNING. If the job is just leaving the queue, re-anchor the bar.   -> clean (fired before the fix)
// PENDING: re-anchor the bar before the next release                             -> R-6EA94, as intended
// PENDING - waiting on the backfill job                                          -> R-6EA94, as intended
// PENDING (owner) drop this once the migration lands                             -> R-6EA94, as intended

One note worth flagging: of your two reproducers, only the second one fired on the old rule. The first never matched, because the tag has to be comment-leading — so the three hits in your private repo are presumably all shaped like the second. If any of them look more like the first, that's a different rule and we'd want to see it.

The existing #182 shapes (colon / dash / owner-paren, both tag tiers) all still match — no regressions.

This is deployed now, so a fresh remote scan should come back clean on all three. Leaving the issue open until you've confirmed against your own repo — thanks again for the two rounds of re-testing on this.

[acknex2]

Confirmed against our repo — the rule change looks right, but it doesn't appear to be live on our scan path yet.

Shape check first, since you asked: all three hits are comment-leading, i.e. reproducer-2 shaped. One of them is essentially identical to reproducer 2 (PENDING or RUNNING. ...); the other two are the same form — uppercase PENDING opening the comment line, followed immediately by ordinary lowercase prose, with no colon / dash / owner-paren at the tag. So your presumption holds: nothing shaped like reproducer 1, no different rule involved, and under the new tag-form requirement all three should go clean.

But they haven't yet: four fresh scans since your message (spanning roughly 40 minutes) all still returned the same three R-6EA94 notes, including the reproducer-2-identical line:

• fd4cd4a6-ae2e-40ee-8689-5aed01ffd91c and 56667a24-9063-488f-887e-8b98e3c931e9 — both on the same commit
• we then pushed a docs-only commit to change the SHA and got the same result on ee33d171-1e94-4b30-9bdd-d1dd1cd50772 and 9ecb9b01-e8ec-4c16-9555-656b4c8facbe — so per-commit result caching is ruled out from our side

CLI is 0.9.1 (latest published — and as with the #182 rollout, I understand the rules evaluate server-side anyway). Could the deploy still be propagating to whichever pool/tenant serves our account? Happy to re-scan as soon as you can confirm it's live on our path — and thanks for the quick turnaround on the rule change itself, the tag-form behavior in your positive controls is exactly what we suggested.