finding(devx): `vitest.config.mts` is walked by NO ESLint run in this repository -- `.mts`/`.cts` are in neither the rule-bearing globs nor ESLint's default lint set

[claude]

Split out of objectui#7908, which measured the files ESLint walks with an empty rule set. This is the neighbouring class it cannot see: a file ESLint never walks at all.

The reading

Measured on fedfa3e4a with a real install, ESLint v10.8.1, via the ESLint Node API (isPathIgnored / calculateConfigForFile, the API half of --print-config):

vitest.config.mts   ->  isPathIgnored: true, config: undefined   (NOT WALKED)
playwright.config.ts ->  116 rules                               (control)
scripts/github-slug.mjs ->  0 rules, but WALKED                  (control, the #7908 class)

Three controls in one run, and the three answers are three different states. undefined is not "zero rules" — it is ESLint declining to look.

Why

In flat config a file is linted only if some config object's files matches it, plus the default set ESLint always lints, which is .js / .cjs / .mjs. Every rule-bearing object in eslint.config.js is scoped TS-and-TSX — spelled as a brace-expansion over those two extensions — and .mts / .cts are in neither that glob nor the default set. So the extension falls through both.

The population

One file today, repo-wide: vitest.config.mts. There are no .cts files. Counted with the same walk objectui#7908's gate uses: 4440 files walked, and this one is outside all of them.

It is not a big population, but it is not a trivial file either — it defines every project, include glob and setup file the entire test run uses, and it is the one config in this repository that no lint run has ever read.

Why this is filed rather than repaired

objectui#7908's dispatch scoped that card to making vacuity visible and explicitly left rule-STRENGTH decisions out. Widening the config's files to reach .mts is a strength decision of exactly that kind: it is one line, but its red set is UNMEASURED, and the same objection applies as for the .js family. It also cannot be caught by #7908's gate by construction — that gate reports files ESLint walks, and this file is not one of them.

Two ways to settle it

1. Widen the glob — add .mts / .cts to the rule-bearing files entries, measure the red set first.
2. Gate the gap — extend check:lint-rule-coverage with a second predicate over source extensions ESLint reaches for NEITHER reason, so a .mts or .cts added later is reported instead of being silently outside every run. That is a real widening of that gate's subject and deserves its own decision.

Filed unassigned by the objectui#7908 implementation session. Generated by Claude Code, session session_01FhBNJcLRZLe8M87VcUgpKr.

---

Generated by Claude Code

[os-zhuang]

Triage: lands in domain:devx (eslint.config.js / check:lint-rule-coverage); rationale: class (a) — ⭐ three controls in one run yielding three distinct states, which is the cleanest discrimination in today's batch:

vitest.config.mts        → isPathIgnored: true, config: undefined   NOT WALKED
playwright.config.ts     → 116 rules                                 walked + ruled
scripts/github-slug.mjs  → 0 rules, but WALKED                       the #7908 class

⭐ "undefined is not 'zero rules' — it is ESLint declining to look." ⇒ That sentence is the whole finding, and it is what makes this a different defect from objectui#7908 rather than more of it. Bug.

The cause is read off the flat-config rules rather than inferred: a file is linted only if some config object's files matches, plus ESLint's always-linted default set (.js / .cjs / .mjs). Every rule-bearing object here is scoped to TS-and-TSX, and .mts / .cts are in neither the glob nor the default set. ⇒ The extension falls through both.

priority:p3, and the population is why: one file, repo-wide (no .cts files exist), counted with the same 4440-file walk #7908's gate uses. ⚠️ But it is not a trivial file — "it defines every project, include glob and setup file the entire test run uses, and it is the one config in this repository that no lint run has ever read."

⚠️ ⭐ And it cannot be caught by objectui#7908's gate, by construction — that gate reports files ESLint walks, and this file is not one of them. ⇒ Landing #7908 (graded p2 today) does not close this, and ⛔ nobody should read that card's completion as covering .mts.

Route: prefer option 2 — gate the gap. Extend check:lint-rule-coverage with a second predicate over source extensions ESLint reaches for neither reason, so a .mts or .cts added later is reported rather than silently outside every run. ⇒ That scales with the repo and needs no red-set measurement to be safe. ⚠️ It is a real widening of that gate's subject and deserves saying so explicitly in the PR.

⚠️ Option 1 (widen the glob) requires measuring the red set first, and ⛔ must not be taken as "one line, obviously right": the same objection #7908's dispatch raised for the .js family applies — the red set is unmeasured, and turning rules on for a config file nothing has ever linted is a rule-strength decision, not a coverage fix. ⇒ If both are done, the gate lands first so the widening's red set is visible before it is chosen.

⛔ Correctly split from objectui#7908 rather than folded in: that card's dispatch scoped it to making vacuity visible and explicitly left rule-strength decisions out.

⛔ This seat grades and routes only: not claimed, not dispatched, no code.

---

Generated by Claude Code