[eslint-refiner] ESLint Refiner daily report - 2026-09-15

[github-actions[bot]]

ESLint Refiner — daily report (2026-09-15)

One issue filed after grounding five rule investigations against the live actions/setup/js corpus. Scope stayed within eslint-factory/** (62 rules, unchanged since 2026-09-10) targeting actions/setup/js/**.

Key result

Filed: prefer-actions-exec-over-child-process false positive on dual-mode standalone/github-script files.

The rule assumes that any file carrying the /// <reference types="@actions/github-script" /> marker always runs inside the github-script step, where @actions/exec's exec() global is available — so it flags child_process.exec* calls in those files as "prefer @actions/exec." That assumption breaks for files that also require("./shim.cjs"): shim.cjs's own docstring says it exists precisely so github-script-flavored modules can also run as plain standalone Node processes (e.g. inside the safe-outputs / mcp-scripts MCP servers) — and it only polyfills core/context, never exec. Two files hit this live: build_checkout_manifest.cjs (2 sites) and merge_remote_agent_github_folder.cjs (5 sites, and its own header docstring explicitly documents the dual-mode design). A control case, get_current_branch.cjs (marker present, no shim.cjs), correctly remains a true positive, confirming the fix needs to be additive (check for shim.cjs) rather than a blanket loosening.

Other rules reviewed, no issue filed

4 rules investigated with no grounded live defect

• no-unsafe-promise-catch-error-property — has a real architectural gap: its hasGuard flag is set once per enclosing function and then blanket-suppresses all unsafe property accesses in that .catch() callback, unlike its sibling no-unsafe-catch-error-property, which checks guard-vs-access ordering per access. Checked all 26 live .catch((err|error) => {...}) call sites in actions/setup/js — every one either uses getErrorMessage() exclusively or has a single self-contained guard covering its only access. Zero occurrences of the vulnerable shape (an unrelated guard coexisting with a genuinely unguarded separate access), so this doesn't clear the "broadly applicable latent idiom" bar used for structural-only findings in the past. Not filed; flagged in memory as the first thing to re-check if new .catch() sites are added.
• prefer-get-error-message — checks out correctly; no live gap.
• prefer-get-error-message-over-string — correctly scope-gated by hasResolvableLocalBinding; ~15 files use String(err) inside throw new Error(...) template literals but simply don't import getErrorMessage at all, so the rule rightly stays silent. That's a codebase-adoption gap, not a rule defect.
• no-core-exportvariable-non-string — logic mirrors no-core-setoutput-non-string (which had 3 grounded gaps found back in 2026-07-01), but all 22 live core.exportVariable(...) call sites pass string literals or string-typed variables; one site (checkout_pr_branch.cjs:86) already proactively wraps with String(prNumber). No live reproduction of the sibling rule's gaps.

Dedup check

Open eslint-factory issues verified via gh api before filing

60757, 60577, 60196, 59892, 59891, 59647, 59378, 59377 — all reconfirmed open. #59144 (no-misplaced-error-code-definition) has dropped off the open list since 2026-09-14 (fixed or expired via the auto-close TTL) and was not re-investigated this run.

Next actions

• require-error-code-in-thrown-error — deferred two runs in a row now; needs a targeted sampling pass (custom Error subclasses / unusual message-expression shapes across 100+ importing files) rather than exhaustive review. Top priority for next run.
• no-unsafe-promise-catch-error-property — real design gap identified but ungrounded; re-check only if new .catch() call sites appear in the corpus, don't repeat the same 26-site sweep.
• ~25 of 62 rules remain never-reviewed by this memory (fs/exec/fetch try-catch family mostly).

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 · 406 AIC · ⌖ 7.86 AIC · ⊞ 5.8K · ◷

• expires on Sep 15, 2026, 9:40 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-09-16T05:40:24.724Z.

Closed by Workflow