[eslint-refiner] ESLint Refiner Daily Report 2026-09-20: 3rd consecutive 0-issue run, all 62 rules reviewed

[github-actions[bot]]

Overview

Day 20 of the ESLint Refiner sweep. No new refinement issues were filed today — the third consecutive 0-issue run — after closing out the two theories carried over from yesterday. All 62 registered gh-aw-custom/* rules have now been reviewed at least once.

Key metrics

• Rules in factory: 62 (unchanged since 2026-09-19)
• Issues filed today: 0 (3rd consecutive disciplined 0-issue run: 09-18, 09-19, 09-20)
• Open eslint-factory issues (still active): 7 — all confirmed still open, zero expiries this cycle
• Theories closed out this run: 2 (both retired, zero live grounding)

What was reviewed

Closed out the two rules carried from yesterday's nextPriorities:

1. no-misplaced-error-code-definition — tested three hypotheses, all zero-grounded against the live actions/setup/js corpus:

   • Naming-pattern gap (_ERROR_CODE/_REASON_CODE suffix-only match missing other *_CODE names) — every other _CODE-suffixed constant found (SIGNAL_TERMINATION_EXIT_CODES, CODE_PUSH_TYPES, etc.) is an unrelated concept, not a misplaced error/reason code.
   • Re-export-alias false positive (a file that legitimately re-exports an already-centralized code via require(...).X member access could be wrongly flagged as a local definition) — zero live occurrences; the only two files destructuring the one existing centralized code (POLICY_FILE_PROTECTION_DENIED_REASON_CODE) consume it internally, never re-export it.
   • Destructuring-import false negative (const { X_ERROR_CODE } = require(...) isn't tracked by the rule's VariableDeclaration visitor, since it only matches simple Identifier bindings) — a real structural gap, but the registry currently has only one code total, so there's no live case of a destructured-then-re-exported code to trigger it.

2. require-error-code-for-github-api-throw — the catchClauseRethrows indirect-rethrow-via-helper-function theory (a catch block that delegates to a throwing helper instead of a literal throw, which the rule's reachability logic can't see into). Sampled roughly ten files that both import error_codes.cjs and use the withRetry wrapper-call shape. Every live catch near a GitHub API call either literally throws (correctly detected) or swallows via core.warning/core.info (correctly excluded) — no helper-mediated rethrow sites found.

Both theories are now retired per the project's established diminishing-returns practice (two dedicated passes each, no fresh angle).

Full investigation notes and grep evidence

no-misplaced-error-code-definition — grepped every top-level ^const [A-Z_]*CODE[A-Z_]* = declaration across actions/setup/js/*.cjs. Candidates like ERROR_CODE_PREFIX_RE, SUMMARY_SAFE_ERROR_CODES, SIGNAL_TERMINATION_EXIT_CODES, CODE_PUSH_TYPES, AGENT_EXECUTION_EXIT_CODE_PATH, and CRASH_SIGNAL_EXIT_CODES were all inspected — none are error/reason codes that should be centralized. The only genuine registry code, POLICY_FILE_PROTECTION_DENIED_REASON_CODE, is destructured from error_codes.cjs in approve_workflow_run.cjs and push_to_pull_request_branch.cjs, both consuming it as an internal reasonCode: property value rather than re-exporting it — so neither the FP nor FN theory has a live trigger today.

require-error-code-for-github-api-throw — sampled create_pull_request.cjs, push_to_pull_request_branch.cjs, and the other files intersecting the withRetry-user set with error_codes.cjs importers. Representative catch shapes found: throw error; (literal, correctly attributed), core.warning(...) swallow-and-continue (correctly excluded — no rethrow), and nested fallback retries via direct recursive calls (also literal throws at the base). No case where a catch handler calls out to a separate named helper function whose body contains the actual throw.

Corpus-change detection revisited — the 2026-09-19 squash commit ff2eccd (#61938) touches nearly all of actions/setup/js but is a shallow-clone base snapshot, not incremental churn, reconfirming that git log/diff cannot be used to detect "what's new since last run" in this repository.

Next actions

• All 62 rules have now been reviewed at least once, and every carried theory from the last three runs has been filed, disproven, or explicitly retired. The next run should prioritize finding genuinely new grounding (new call sites from any newly-added .cjs files) over re-deriving retired theories.
• Chronic try-catch-rule-utils.ts VariableDeclaration-suggestion gap (affects ~14 fs-sync/child-process-family rules, twice filed and expired as eslint-factory: shared try/catch suggestion builder silently skips VariableDeclaration call sites #57868 with no fix uptake) is a source-level fix, not an issue-filing target — but this workflow has no create_pull_request safe-output tool, so it can only be flagged here for a human or a PR-capable workflow to pick up.
• Recalibration worth considering: three consecutive 0-issue runs suggests the broadly-applicable-idiom gaps reachable via static grep-only grounding (no live npm/eslint run available in this sandbox) are largely exhausted. A future run could pivot toward auditing rule test coverage thinness as a distinct angle, or reconsider the filing bar for smaller-blast-radius findings.
• Repo-memory (memory/eslint-refiner branch) updated with this run's findings; validated at 33 KB total / well under the 12 KB patch limit.

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 · 197.2 AIC · ⌖ 7.68 AIC · ⊞ 6K · ◷

• expires on Sep 20, 2026, 9:29 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-09-21T05:29:44.080Z.

Closed by Workflow