[eslint-refiner] ESLint Refiner - Daily Report (2026-08-03)

[github-actions[bot]]

ESLint Refiner — Daily Report (2026-08-03)

Custom rule factory (eslint-factory/**, targeting actions/setup/js/**) grew significantly since the last run and had a large review backlog. This run caught up on the highest-risk unreviewed rules and filed 2 refinement issues.

Key metrics

Metric	Value
Total rules in factory	37 (was 12 at last run, 2026-07-08 — 26-day gap)
Rules reviewed today	3
Rules reviewed ever	15 / 37
Rules still never reviewed	22
Issues filed today	2

What changed since last run

A 26-day gap opened between runs. In that time the factory grew from 12 to 37 rules — 25 new rules shipped, only 3 of which got reviewed today. Rather than continue the old "pick the single newest rule" cadence against a 22-rule backlog, this run prioritized by risk class: the three command/route-construction rules that guard against shell and GitHub-API injection.

Findings

no-exec-interpolated-command — reviewed, no issue (rule is correct)

Matches exec.exec()/exec.getExecOutput() on the github-script-injected exec global only. Verified this is sufficient: no call site in actions/setup/js imports @actions/exec directly, and all ~150 live exec.exec/getExecOutput call sites already pass a static "git"/"gh"/prefix-var command with arguments in the array parameter. No false negative or false positive found.

no-child-process-interpolated-command — 1 issue filed

Scope resolution (require-destructuring, import specifiers, member-binding aliases) is solid — confirmed it correctly resolves const { spawn, execSync } = require("child_process") in start_mcp_gateway.cjs and would flag the interpolated execSync template literals at lines 741/876/949 (a target-code concern, out of scope for a rule-refinement issue).

Gap: for spawn/spawnSync/execFile/execFileSync, the rule only treats shell: true / shell: "<string>" literal values as shell-enabled. A computed value — shell: process.platform === 'win32' (a standard cross-platform idiom) — silently resolves to "not shell," unlike the adjacent SpreadElement branch which is already conservative. No live occurrence today (grep confirms zero shell: usages in the corpus), but the first computed-shell spawn/execFile call added with an interpolated command would pass review unflagged. Filed with acceptance criteria to treat non-literal shell values conservatively, matching the SpreadElement handling already in the same function.

no-github-request-interpolated-route — 1 issue filed

The rule only inspects the route argument to <client>.request() directly — it never resolves an Identifier argument back to its initializer, unlike its sibling command rules (no-exec-interpolated-command, no-child-process-interpolated-command), which both call resolveWriteOnceInitializerChain for exactly this reason.

Grounded via create_project.cjs:230 / update_project.cjs:919, which already use the const route = <ternary>; client.request(route, ...) idiom (today fully static — a correct true negative). That proves the identifier-bound route shape is a normal pattern in this codebase, and the rule's own opaqueWholeRoute remediation text ("pass a typed route string from the caller") actively steers developers toward exactly the shape the rule can't see through. Filed to bring scope-resolution parity with the sibling command rules.

Strategy notes

• Repo memory (state.json) now tracks two explicit lists — rulesReviewedEver and rulesNeverReviewed — so future runs can resume the backlog sweep without re-deriving rule history. (The repo is a shallow clone, so git log can no longer establish "which rule shipped most recently" — everything attributes to one squash commit.)
• Next run should continue the backlog by risk: require-fetch-timeout/require-fetch-try-catch (network hang/SSRF-adjacent) and require-escaped-regexp-interpolation (ReDoS-adjacent) look like the next highest-value targets, followed by the 5-rule no-core-error-then-* / no-setfailed-then-exit-zero / require-return-after-core-setfailed control-flow family.
• Noted (not filed, since it's a separate mission): a different automation labeled [eslint-monster] also files issues touching actions/setup/js lint findings, but it targets fixing production call sites for already-shipped rules rather than refining rule logic — checked for overlap with today's findings, none found.
• Full findings, prior open issues, and ops notes for future runs are persisted in memory/eslint-refiner repo-memory (state.json, history.jsonl).

References:

• Run §30789584338

Generated by 🤖 ESLint Refiner · agent · 224.3 AIC · ⌖ 28.6 AIC · ⊞ 4.9K · ◷

• expires on Aug 3, 2026, 10:29 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-08-04T06:29:39.146Z.

Closed by Workflow