@@ -12,16 +12,24 @@ fixed, on a path #300 did not cover).
 
 `runVale` now excludes a target file over 128KB (`VALE_MAX_FILE_BYTES` in
 `src/rules/vale/run.ts`) before invoking Vale at all, the same preemptive
-treatment already given to a format Vale cannot parse. Excluded files are
-named in a `notices` entry, not reported as a failing finding: unlike an
-unparseable file (where Vale itself proves the file was a real target by
-erroring on it), this exclusion runs from a bare filesystem walk with no way
-to confirm any rule's matcher would have reached the file — reporting it as
-a blocking error produced false failures on files no rule ever touches (a
-lockfile, a generated changelog).
+treatment already given to a format Vale cannot parse — but only when some
+Vale rule's own `.vale.ini` section could actually reach that file.
+`assembleValeConfig` now returns the section patterns it wrote alongside the
+config path, and the size scan globs by those patterns (`findOversizedFiles`
+in `src/rules/vale/formats.ts`) instead of walking every file in the project.
+A first version of this fix scanned the whole tree unconditionally and named
+`pnpm-lock.yaml` and `packages/cli/CHANGELOG.md` as "not checked" on this very
+repository, even though no rule's matcher touches either file — Vale was
+never going to open them, so that was a false positive, not a caught coverage
+hole. Excluded files are named in a `notices` entry rather than a finding:
+unlike an unparseable file (where Vale itself proves the file was a real
+target by erroring on it), this exclusion is a preemptive guess from a
+filesystem walk, and a soft advisory fits an unconfirmed guess better than a
+hard error.
 
 A consumer may now see a `check` that previously counted a large file's
-prose findings instead report a `notices` entry naming that file as skipped.
-128KB is comfortably past hand-written prose (roughly 20,000 words); this
-should only affect generated output, pasted data, or exported notes checked
-directly against a matching rule.
+prose findings instead report a `notices` entry naming that file as skipped
+— but only for a file some rule's own scope actually reaches. 128KB is
+comfortably past hand-written prose (roughly 20,000 words); this should only
+affect generated output, pasted data, or exported notes checked directly
+against a matching rule.
@@ -576,15 +576,22 @@ it.
    large enough document can consume the whole run's time budget on its
    own and cost every other file its findings: the same failure mode as
    the unreadable-file case above, from a different cause. `check`
-   preempts it: a target file over 128KB is skipped, and named in a
-   `notices` entry rather than a finding, since nothing here can confirm
-   whether any matcher would actually have reached it (a large lockfile
-   or a generated file outside every rule's scope is common, and
-   flagging one as a failure would be a false positive). A rule's own
+   preempts it: a target file over 128KB is skipped **only if some
+   matcher's own section would actually reach it**. The scan asks the
+   assembled config's own section patterns, the same ones you write in
+   this file's `.vale.ini`, rather than walking every file in the
+   project. A large lockfile or a generated file no rule's glob names is
+   left alone entirely, not merely reported softly: naming a file no
+   matcher was ever going to check would be a false positive, not a
+   caught coverage hole. A file that IS excluded is named in a `notices`
+   entry rather than a finding: unlike the unreadable-file case above,
+   where Vale's own error proves the file was a real target, this is a
+   preemptive guess from a filesystem walk, and a soft advisory fits an
+   unconfirmed guess better than a hard error does. A rule's own
    fixtures are never this large in practice, so this should not surface
-   while authoring one. It matters when scoping a matcher at a whole
-   project, where a generated changelog or an exported note can cross
-   it.
+   while authoring one. It matters when a matcher's glob is broad, such as
+   `[*.md]` or `[**/README.md]` at the project root, where a generated
+   changelog or an exported note can cross it.
 
    That example changed with Vale v3.18.0, which is the point: the
    dangerous extension is whichever one the list above says needs a
 
@@ -252,7 +252,8 @@ export const checkCommand = defineCommand({
           cwd,
           paths: existingPaths,
           astGrepConfigPath: assembled.sg,
-          valeConfigPath: assembled.vale,
+          valeConfigPath: assembled.vale?.path,
+          valeSections: assembled.vale?.sections,
           runtimeRules: plan.execute,
           runtimeTimeoutMs: parseTimeoutMs(args.timeout),
         });
 
@@ -97,19 +97,59 @@ function valeRuleBlock(ruleId: string, body: string): string {
   return [`# tskl) rule = ${ruleId}`, body, ""].join("\n");
 }
 
+/**
+ * A section header (`[pattern]`) from an assembled rule's own body.
+ *
+ * Read from the exact string this module is about to write — never from the
+ * file after writing it. Re-reading the written `.vale.ini` to recover its
+ * own sections would be the mistake `STYLEGUIDE-CODE.md`'s "Verify Build
+ * Output In The Build, Not By Parsing It" warns against: this function
+ * already IS the generator, holding the structured pieces before they are
+ * joined into text, so there is nothing to re-derive.
+ */
+function sectionPatternsOf(body: string): string[] {
+  const patterns: string[] = [];
+  for (const line of body.split("\n")) {
+    const match = /^\[(.+)\]$/.exec(line.trim());
+    if (match?.[1] !== undefined) patterns.push(match[1]);
+  }
+  return patterns;
+}
+
+/**
+ * What `assembleValeConfig` produced: where to point `--config`, and the
+ * section patterns it wrote there.
+ *
+ * `sections` exists so a caller that needs to know what Vale would actually
+ * lint — `findOversizedFiles` in `vale/formats.ts`, scoping its preemptive
+ * size guard to files some rule's matcher could reach — can ask this module
+ * directly instead of re-parsing the config it just wrote.
+ */
+export interface AssembledValeConfig {
+  /** Config path relative to the project root, for `--config`. */
+  path: string;
+  /**
+   * Every section glob pattern written into the config, deduplicated and
+   * sorted for a stable read order. Root-relative, exactly as Vale reads
+   * them — the same strings a `[…]` line in a rule's own `.vale.ini` names.
+   */
+  sections: string[];
+}
+
 /**
  * Assemble `.taskless/.vale.ini` from every Vale rule's own config.
  *
- * Returns the config path relative to the project root, or `undefined` when no
+ * Returns the config path and its section patterns, or `undefined` when no
  * Vale rule declares any config — there is nothing to run, and writing an empty
  * config would invite Vale to lint the project against no rules and report a
  * clean pass.
  */
 export async function assembleValeConfig(
   cwd: string
-): Promise<string | undefined> {
+): Promise<AssembledValeConfig | undefined> {
   const ruleIds = await listRuleIds(cwd, "vale");
   const blocks: string[] = [];
+  const sections = new Set<string>();
 
   for (const ruleId of ruleIds) {
     const configPath = ruleConfigPath(cwd, "vale", ruleId);
@@ -125,6 +165,7 @@ export async function assembleValeConfig(
     }
     const body = ruleConfigBody(source);
     if (body === "") continue;
+    for (const pattern of sectionPatternsOf(body)) sections.add(pattern);
     blocks.push(valeRuleBlock(ruleId, body));
   }
 
@@ -134,7 +175,7 @@ export async function assembleValeConfig(
   const target = join(cwd, ASSEMBLED_VALE_CONFIG);
   await mkdir(dirname(target), { recursive: true });
   await writeFile(target, contents, "utf8");
-  return ASSEMBLED_VALE_CONFIG;
+  return { path: ASSEMBLED_VALE_CONFIG, sections: [...sections].toSorted() };
 }
 
 /**
@@ -193,8 +234,8 @@ export async function assembleSgConfig(
 
 /** Both assembled configs, for a run that needs whichever engines are present. */
 export interface AssembledConfigs {
-  /** `--config` for Vale, or `undefined` when no Vale rule is configured. */
-  vale: string | undefined;
+  /** Vale's config and section patterns, or `undefined` when no Vale rule is configured. */
+  vale: AssembledValeConfig | undefined;
   /** `-c` for ast-grep, or `undefined` when there are no ast-grep rules. */
   sg: string | undefined;
 }
 
@@ -91,6 +91,16 @@ export interface DispatchOptions {
    * written. The config is the only honest signal that there is Vale work.
    */
   valeConfigPath: string | undefined;
+  /**
+   * The section glob patterns `assembleValeConfig` wrote into that config, or
+   * `undefined` when it produced nothing (mirrors `valeConfigPath`).
+   *
+   * Threaded through to `runVale` so its preemptive oversized-file guard can
+   * scope its scan to files some rule's matcher could actually reach, rather
+   * than statting the whole project — see `findOversizedFiles` in
+   * `vale/formats.ts`.
+   */
+  valeSections?: string[] | undefined;
   /** Runtime rules that survived planning. Empty means the harness is skipped. */
   runtimeRules: RuntimeRule[];
   runtimeTimeoutMs?: number;
@@ -177,6 +187,7 @@ async function runValeEngine(options: DispatchOptions): Promise<EngineOutcome> {
     paths: options.paths,
     configPath: options.valeConfigPath,
     timeoutMs: options.valeTimeoutMs,
+    sectionGlobs: options.valeSections,
   });
 
   if (outcome.status === "ok") {
 
@@ -166,6 +166,11 @@ const UNWALKED_DIRECTORIES = new Set([
   TASKLESS_DIRECTORY,
 ]);
 
+/** `glob`'s `exclude` predicate for {@link UNWALKED_DIRECTORIES}. */
+function isUnwalkedEntry(entry: string | Buffer): boolean {
+  return UNWALKED_DIRECTORIES.has(basename(String(entry)));
+}
+
 /**
  * Converter-dependent files inside the run's target set.
  *
@@ -260,18 +265,48 @@ export interface OversizedFile {
  * discover the cost the hard way — is the same trade `converterExclusionGlobs`
  * makes for a format Vale cannot parse at all.
  *
- * Unlike the converter walk, this cannot be scoped by extension: an oversized
- * file can have any extension, or none, so every file under the target roots
- * has to be listed and stat'd. That is a real cost on the happy path, where
- * nothing is oversized and the walk still runs — measured and reported in the
- * PR that introduced this function.
- *
- * A named path is stat'd directly, exactly as `targetFileParseError` does
- * elsewhere in this package: an explicit request is not resolved through the
- * walk that answers a whole-project run. Whether named or discovered by the
- * walk, an oversized file is excluded unconditionally, on every run — the same
- * asymmetry `findConverterDependentFiles` documents, and for the same reason:
- * handing Vale this file does not check it badly, it risks the entire batch's
+ * `sectionGlobs`, when given, is `AssembledValeConfig.sections` from
+ * `assembleValeConfig` — the exact section patterns Vale's own rules are
+ * scoped to. The scan globs those patterns instead of every file in the
+ * tree, exactly as {@link findConverterDependentFiles} globs by its extension
+ * list, and for the same reason precision matters here: a bare `**\/*` walk
+ * finds every file under the target roots regardless of whether any rule
+ * would ever touch it, and reporting one of those as "not checked" is a false
+ * positive, not a caught coverage hole. Measured against this repository:
+ * `pnpm-lock.yaml` and `packages/cli/CHANGELOG.md` are both over the limit,
+ * and neither is named by any `[section]` in any rule's `.vale.ini` — no
+ * rule was ever going to open either one, so the un-scoped walk reported
+ * lost coverage that never existed.
+ *
+ * The patterns are read from `assembleValeConfig`'s own return value, never
+ * by re-parsing the `.vale.ini` it wrote — see the doc on
+ * `sectionPatternsOf` in `assemble.ts` for why that distinction matters.
+ *
+ * `sectionGlobs === undefined` falls back to the previous exhaustive `**\/*`
+ * walk under each target root. That path exists for a caller with no
+ * assembled config to ask — `verifyValeRule`'s isolating config, or a test
+ * that hands `runVale` a hand-written `.vale.ini` directly — and is
+ * unaffected by everything below: same cost, same behavior as before this
+ * parameter existed.
+ *
+ * A named path is stat'd directly when there is no `sectionGlobs` to consult
+ * (the fallback below), exactly as `targetFileParseError` does elsewhere in
+ * this package: an explicit request is not resolved through the walk that
+ * answers a whole-project run. **That changes once `sectionGlobs` is given.**
+ * An explicitly named file is not exempt from scoping either — measured
+ * against the real binary, Vale spends 9ms and reports nothing on a 128KB+
+ * file whose extension no section names, the same as a file it never opened
+ * at all, because no rule is ever assigned to run against it. Checking it
+ * unconditionally would reintroduce the exact false positive this parameter
+ * exists to remove, just reachable via `check some-file.yaml` instead of a
+ * whole-project run. So when sections are known, a named file is a candidate
+ * only if it is also a match for one of them — the same membership test the
+ * walk below already computes.
+ *
+ * Whether named or discovered by the walk, an oversized file is excluded
+ * unconditionally once it qualifies, on every run — the same asymmetry
+ * `findConverterDependentFiles` documents, and for the same reason: handing
+ * Vale this file does not check it badly, it risks the entire batch's
  * timeout.
  *
  * Errors are swallowed the same way as {@link findConverterDependentFiles} and
@@ -283,51 +318,83 @@ export interface OversizedFile {
 export async function findOversizedFiles(
   cwd: string,
   paths: string[],
-  maxBytes: number
+  maxBytes: number,
+  sectionGlobs?: string[]
 ): Promise<OversizedFile[]> {
-  const named: OversizedFile[] = [];
-  const roots: string[] = [];
-  if (paths.length === 0) {
-    roots.push(".");
-  } else {
-    for (const path of paths) {
+  const roots = paths.length === 0 ? ["."] : paths;
+  const found = new Map<string, OversizedFile>();
+
+  const checkCandidate = async (relative: string): Promise<void> => {
+    if (found.has(relative)) return;
+    try {
+      const stats = await stat(resolvePath(cwd, relative));
+      if (stats.isFile() && stats.size > maxBytes) {
+        found.set(relative, { file: relative, size: stats.size });
+      }
+    } catch {
+      // Gone between listing and stat, or unreadable. Not a reason to drop
+      // the exclusion already computed.
+    }
+  };
+
+  if (sectionGlobs === undefined) {
+    // No assembled config to ask what Vale would actually lint — fall back to
+    // the previous behavior: every named path is a candidate regardless of
+    // scope, and every root is walked exhaustively.
+    for (const path of paths) await checkCandidate(path);
+    for (const root of roots) {
+      const prefix = root === "." || root === "" ? "" : `${root}/`;
       try {
-        const stats = await stat(resolvePath(cwd, path));
-        if (stats.isFile() && stats.size > maxBytes) {
-          named.push({ file: path, size: stats.size });
+        for await (const match of glob(`${prefix}**/*`, {
+          cwd,
+          exclude: isUnwalkedEntry,
+        })) {
+          await checkCandidate(String(match));
         }
       } catch {
-        // Unreadable or missing: not this function's problem. The run itself
-        // will report it if it matters.
+        // A target that is not a directory, an unreadable subtree, a
+        // platform where `glob` rejects the pattern: all of them mean "no
+        // notice, never no fix". The exclusion has already been applied by
+        // the time this runs.
       }
-      roots.push(path);
     }
+    return [...found.values()].toSorted((a, b) => a.file.localeCompare(b.file));
   }
 
-  const found = new Map(named.map((entry) => [entry.file, entry]));
-  for (const root of roots) {
-    const prefix = root === "." || root === "" ? "" : `${root}/`;
+  // Section patterns are root-relative, exactly as Vale reads them — never
+  // prefixed per target root, the way the extension-based fallback above is.
+  // A whole-project run (`roots === ["."]`) needs no further narrowing: every
+  // match is already in scope. An explicit target (`check src/` or
+  // `check src/doc.md`) narrows the matches down to that subtree afterward
+  // instead, because a section like `CLAUDE.md` or `**/README.md` has no
+  // meaningful "under src/" form to prefix onto — Vale itself evaluates every
+  // section against the whole project and only its own target list decides
+  // what it actually visits, so intersecting after the glob mirrors that
+  // rather than guessing at one. This is also what makes a named file's
+  // in-scope test free: it needs no separate membership check, because a
+  // pattern like `**/README.md` already matches a top-level `README.md`
+  // found this way, whether or not the caller named it explicitly.
+  const wholeProject = paths.length === 0;
+  for (const pattern of sectionGlobs) {
     try {
-      for await (const match of glob(`${prefix}**/*`, {
+      for await (const match of glob(pattern, {
         cwd,
-        exclude: (entry) => UNWALKED_DIRECTORIES.has(basename(String(entry))),
+        exclude: isUnwalkedEntry,
       })) {
         const relative = String(match);
-        if (found.has(relative)) continue;
-        try {
-          const stats = await stat(resolvePath(cwd, relative));
-          if (stats.isFile() && stats.size > maxBytes) {
-            found.set(relative, { file: relative, size: stats.size });
-          }
-        } catch {
-          // Same reasoning as above: gone between listing and stat, or
-          // unreadable. Not a reason to drop the exclusion already computed.
+        if (
+          !wholeProject &&
+          !roots.some(
+            (root) => relative === root || relative.startsWith(`${root}/`)
+          )
+        ) {
+          continue;
         }
+        await checkCandidate(relative);
       }
     } catch {
-      // A target that is not a directory, an unreadable subtree, a platform
-      // where `glob` rejects the pattern: all of them mean "no notice, never
-      // no fix". The exclusion has already been applied by the time this runs.
+      // Same reasoning as the fallback walk: a malformed pattern or an
+      // unreadable subtree means "no notice, never no fix".
     }
   }