[eslint-refiner] ESLint Refiner — daily report (2026-08-28)

[github-actions[bot]]

Overview: this run surfaced a real backlog problem before it surfaced rule bugs — the rule set has grown 5x since the last recorded run and review cadence needs to change. Two concrete refinement issues were filed against the numeric-parse NaN-check rule family, one of them grounded in a live production file where the guard it's meant to enforce is currently silently bypassable.

Key metrics

Metric	Value
Total rules in eslint-factory	60 (was 12 as of 2026-07-08)
Rules reviewed to date	18 / 60
Rules reviewed this run	6
Issues filed this run	2
Live/grounded findings	1 (HIGH)
Soundness/consistency findings	1 (MED, ungrounded but evidenced by a sibling rule's own fix)

Issues filed

1. Ternary env-presence guards bypass NaN tracking — require-nan-check-after-env-numeric-parse and require-nan-check-after-split-index-parse only track a parsed value when its VariableDeclarator init is literally a CallExpression. The common process.env.X ? parseInt(process.env.X, 10) : default idiom (checks presence, not validity) is invisible to both rules. Grounded live at actions/setup/js/safe_outputs_handlers.cjs:638, where a malformed GH_AW_ASSETS_MAX_SIZE_KB silently produces NaN, which then silently disables the asset size cap (sizeKB > NaN is always false) — with zero warning from either rule.
2. Name-keyed scope-collision risk — require-nan-check-after-env-numeric-parse tracks validated/unvalidated state by variable name (Map/Set<string>) rather than by declaration node identity, so a validated variable in one function scope can silently clear an unvalidated same-named variable in another scope from ever being reported. Its sibling rule, require-nan-check-after-split-index-parse, already fixed this exact failure mode via node-identity-keyed Set<VariableDeclarator> tracking (its own code comment documents the fix). No live collision was found in the current corpus, but the fix is cheap and already proven — porting it closes a real latent gap.

Backlog / cadence note

Why the strategy changed this run

The repo-memory strategy assumed roughly one new custom rule ships per day, so each run would review the single newest one. The gap between this run and the last recorded run (2026-07-08) was about 7 weeks, and in that time eslint-factory/src/index.ts grew from 12 to 60 registered rules — 42 of which have never been reviewed by this process. Reviewing one rule per run is no longer enough to keep pace even at daily cadence, let alone after a multi-week gap.

This run reviewed 6 rules instead of 1, prioritizing the command/exec-interpolation and error-interpolation families for their higher blast radius (shell injection, silent error swallowing) over the more mechanical try/catch-wrapper rules. No defects were found in no-exec-interpolated-command, no-child-process-interpolated-command, or prefer-actions-exec-over-child-process — all three checked out sound against the live actions/setup/js corpus, including a nice confirmation that the digits-only sanitizer pattern (String(x).replace(/[^0-9]/g, "")) is correctly recognized as safe at start_mcp_gateway.cjs:1046. no-caught-error-interpolation has a theoretical blind spot for named (non-inline) error-handler functions passed by reference, but no live unsafe interpolation was found there, so nothing was filed for it.

Repo-memory (state.json) now tracks the full 60-rule inventory, the 18 reviewed so far, and a priority list for the 42 remaining, ordered toward the security-relevant families first (require-fetch-timeout, require-getexecoutput-exitcode-check, require-error-code-for-github-api-throw, interpolation/escaping rules, etc.).

Next actions

• Next run: continue working through the 42 unreviewed rules, security-relevant families first (see state.json priority list).
• Re-verify safe_outputs_handlers.cjs:638 is flagged once the ternary-init fix lands.
• Re-check README rule-documentation coverage (was 2/12 documented as of 2026-07-08; likely much lower now against 60 rules) — raise as a discussion item if still significant.

References:

• §33152652663

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• api.anthropic.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "api.anthropic.com"

See Network Configuration for more information.

Generated by 🤖 ESLint Refiner · claude · agent · 254.9 AIC · ⌖ 7.48 AIC · ⊞ 5.8K · ◷

• expires on Aug 29, 2026, 12:01 AM UTC-08:00