[eslint-refiner] Daily ESLint Refiner report — 2026-10-21 (disciplined 0-issue run, 4 new rules reviewed)

[github-actions[bot]]

Overview

First run since 2026-10-05 (16-day gap). eslint-factory's registered rule count grew from 65 → 69. Used the established "ruleCount bump" method to find the never-before-reviewed rules and gave each a first-ever grounded audit against the live actions/setup/js/**/*.cjs corpus. Open eslint-factory issue queue was confirmed at zero both before and after this run — the backlog-clearance milestone from 2026-10-05 has held for over two weeks.

No new issues filed this run. Every rule audited either fired correctly on live code or had zero live misfires; no grounded rule defect was found. This is the 9th disciplined 0-issue run recorded in memory.

Key metrics

Metric	Value
Rules registered	69 (was 65 on 2026-10-05)
Never-before-reviewed rules found via ruleCount diff	4
Rules given first-ever review this run	3 full + 1 lighter pass
Open eslint-factory issues (before / after)	0 / 0
Issues created	0
Chronic theories re-checked	1 (retired this run)

What was reviewed

no-map-parseint-callback (first-ever review) — clean

Flags .map(parseInt) / .map(Number.parseInt) (index becomes radix). Grepped every live parseInt( call site in actions/setup/js/**/*.cjs (~75 sites): every single one passes an explicit radix (parseInt(x, 10) or parseInt(x, 16)) and none is passed bare to .map(). Also checked for a const alias = parseInt; indirection that would escape the rule's direct-identifier check — zero occurrences. Codebase is disciplined here; no gap found.

require-finite-check-before-date-toisostring (first-ever review) — clean

Flags new Date(dynamicArg).toISOString()/.toJSON() when the argument isn't provably finite and there's no Number.isFinite/isNaN guard or try/catch. The rule's own test suite documents a known scope limit: a Date first assigned to a variable (const d = new Date(ms); d.toISOString();) is not flagged, only the inline chained form.

Grepped every live = new Date( assignment in the corpus and traced each to its .toISOString()/.toJSON() use: report_ast.cjs:434/467, check_stop_time.cjs:95, create_project_status_update.cjs:242, expired_entity_cleanup_helpers.cjs:34, and ephemerals.cjs:67/83 are all guarded — either with a direct Number.isNaN(x.getTime()) check right above the call, or (for ephemerals.cjs) because extractExpirationDate() already validates and returns null on failure before any .toISOString() call is reached. The documented scope gap exists but has zero live misses — not filed.

no-split-filter-trim-without-trim-map (first-ever review) — rule confirmed working, 2 structural gaps found but ungrounded

Flags .split(delimiter).filter(x => x.trim()), which drops blank entries but leaves whitespace on the kept ones. Found the rule correctly firing on two live sites:

• redact_secrets.cjs:688 — secretNames.split(",").filter(name => name.trim()), then secretName used un-trimmed in `SECRET_${secretName}` at line 690. A GH_AW_SECRET_NAMES value like "FOO, BAR" produces a lookup for SECRET_ BAR (leading space) that never matches a real env var — the custom secret silently never gets redacted.
• redact_secrets.cjs:778 — same split/filter pattern, though here the value is re-trimmed at point of use (line 782), so no live bug there.

This is a genuine, security-adjacent bug the rule would catch if wired into CI lint — good confirmation the rule has real value. It's an app-code fix, not a rule defect, so no eslint-factory issue was filed for it; flagging here for visibility since redaction correctness is security-relevant.

Two structural gaps were found in the rule itself but not filed (zero live grounding):

1. isSplitSeparator only accepts a string-literal delimiter, not a regex literal (e.g. .split(/,\s*/)) — same whitespace bug would escape detection with a regex separator.
2. isTrimmedNonEmpty unwraps !-negation but not a Boolean(x.trim()) wrapper — grepped for both patterns combined with a non-newline split; no live occurrences of either.

no-ad-hoc-jsonl-parser — lighter pass, deferred

Most complex of the 4 new rules (alias/ESM/destructuring resolution, parser-restart detection). Its own test suite is already unusually thorough (32 cases). 69 files touch jsonl_helpers.cjs. Did not find a fresh angle within this run's budget — carried to next run for a deeper grounded pass.

Rotation/chronic-theory re-checks

• no-core-error-then-process-exit/-exitcode named-constant exit-code theory: re-grepped every process.exit(/process.exitCode= site (~30) for a named-constant argument paired with core.error — 3rd consecutive zero-grounding check. Retiring this theory per the established 2+-check precedent.
• no-unguarded-async-timer-callback leading-guard-clause asymmetry: still exactly 1 live setInterval(async ...) site in the whole corpus (process_runner.cjs:458), still confounded by genuine trailing-code risk in the same callback. No new site appeared; not filed, not retired.

Next actions

• Give no-ad-hoc-jsonl-parser a dedicated, deeper grounded review next run (deferred this run for time budget).
• Watch for a cleaner, non-confounded live site for the no-unguarded-async-timer-callback leading-guard theory before filing.
• No expiry-watch items remain (open-issue queue is empty); next run's dedupe step should still run in case something lands overnight.
• redact_secrets.cjs:688's untrimmed-secret-name lookup bug is noted here for maintainer awareness but is out of this workflow's scope to fix directly (app code, not an eslint-factory rule).

Generated by 🤖 ESLint Refiner · claude · agent · 178.2 AIC · ⌖ 0.835 AIC · ⊞ 6K · ◷
Work c1fb5700d6c671a2c10f1d02bdbd2f5da9ca3729f10302be79c31eead910d85c · Claim c_a8a18a70bc077c66c01f8ce0fe1f7451712502c8c38871b9e4f95b3aa6488599_2

• expires on Oct 21, 2026, 7:57 PM UTC-08:00

[github-actions[bot]]

This discussion has been marked as outdated by ESLint Refiner.

A newer discussion is available at Discussion #71029.