[eslint-refiner] ESLint Refiner daily report - 2026-07-30

[github-actions[bot]]

Summary

Major state change since last run (2026-07-08): the eslint-factory rule set jumped from 12 to 33 rules (22 new rules shipped over the last ~3 weeks). This run pivoted strategy from "deep-dive the single newest rule" to "triage across many unreviewed rules, then deep-dive the highest-value security-relevant candidates."

What was reviewed

Deep review (implementation + tests + live-corpus grounding via Grep, since npm/node execution is sandboxed/blocked in this environment) of 9 rules:

• no-exec-interpolated-command, no-child-process-interpolated-command (command-injection sinks)
• no-github-request-interpolated-route (Octokit route-injection)
• require-spawnsync-error-check, require-fetch-try-catch, no-caught-error-interpolation
• no-duplicate-constant-values (newest-shipped, least-tested rule - 87 test lines vs 91-621 for siblings)
• no-setfailed-then-exit-zero, require-return-after-core-setfailed

The live actions/setup/js/**/*.cjs corpus is largely disciplined: many candidate gaps turned out to be true negatives already correctly handled (e.g. all live spawnSync call sites check .error; all github.request() route arguments are static; documented/tested-as-intentional scope decisions like route-variable indirection in no-github-request-interpolated-route).

Issue filed (1)

no-child-process-interpolated-command misses inline require('child_process').<method>() calls. The rule's callee-resolution only recognizes the child_process object when bound to a plain identifier (const cp = require('child_process'); cp.execSync(...)); an inline call with no intermediate variable (require('child_process').execSync(...)) is never matched, so an interpolated command through that call shape would go undetected. This is currently ungrounded (no live occurrence in the corpus) but is a cheap, real soundness gap consistent with the rule's own intent and mirrors a previously-fixed gap shape in require-fs-sync-try-catch (destructured/aliased binding blind spot).

Candidates considered but not filed

• no-github-request-interpolated-route route-variable indirection: confirmed via the rule's own .test.ts (it("valid: intentionally out-of-scope route forms are accepted", ...)) to be a deliberate, already-documented scope decision - not a bug.
• no-duplicate-constant-values boolean-value threshold asymmetry (numeric literals need >=3 duplicates to fire, but booleans/strings need only >=2, and booleans are untested in the rule's own suite): searched the live corpus for module-level const NAME = true/false; duplicate patterns and found zero matches, so this stays ungrounded and unfiled this run - worth re-checking in a future pass if that pattern becomes common.

Next run priorities

13 of the 22 new rules still haven't had a deep review pass: no-core-exportvariable-non-string, no-throw-plain-object, require-mkdirsync-try-catch, require-new-url-try-catch, prefer-core-logging, no-core-error-then-process-exit, no-core-error-then-process-exitcode, require-execsync-try-catch, require-execfilesync-try-catch, require-fs-io-try-catch, no-err-stack-then-string-fallback, no-core-error-then-setfailed, prefer-get-error-message-over-string. Given the volume, future runs should continue triaging a handful of rules per run rather than attempting exhaustive single-pass coverage. README doc debt also persists (only a small fraction of the 33 rules are documented) and remains unfiled.

Full strategy, findings, and operational notes persisted to repo-memory (state.json, history.jsonl) on branch memory/eslint-refiner for continuity.

Generated by 🤖 ESLint Refiner · agent · 236.9 AIC · ⌖ 5.27 AIC · ⊞ 4.9K · ◷

• expires on Jul 30, 2026, 10:18 PM UTC-08:00