From 7b80c257337f6dccc3fd479cd342cd12e660ce51 Mon Sep 17 00:00:00 2001
From: Claude <noreply@anthropic.com>
Date: Mon, 10 Aug 2026 20:21:12 +0000
Subject: [PATCH 1/2] ci(turbo): derive the lint and build inputs guards from
 each package's real program (#4184, #4185)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

`lint` and `build` both declared no `inputs` at all, so both ran on turbo's
default — which covers only files inside the package directory. The repo-root
`eslint.config.js` that IS the lint program, and the root tsconfigs plus
`scripts/vite-*.ts` that the build programs read, were unhashed: turbo replayed
the previous verdict instead of re-running.

Adds the third and fourth walkers on the #4176 / #4188 architecture — an ESLint
flat-config program and a build program (a union over tsc / vite / tsup / next /
node / pnpm segments) — plus the family's completeness gate, which asserts every
CACHEABLE turbo task has a guard so a fifth instance cannot arrive quietly.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017Qqyix2QcnpUC9XeYVDzx3
---
 scripts/__tests__/helpers/build-program.ts    | 356 ++++++++++++++++++
 scripts/__tests__/helpers/config-program.ts   | 217 +++++++++++
 .../helpers/eslint-config-program.ts          | 224 +++++++++++
 scripts/__tests__/helpers/tsc-program.ts      | 148 ++++++++
 scripts/__tests__/helpers/turbo-inputs.ts     |  22 +-
 .../helpers/vitest-config-program.ts          | 172 ++-------
 scripts/__tests__/turbo-build-inputs.test.ts  | 233 ++++++++++++
 scripts/__tests__/turbo-lint-inputs.test.ts   | 245 ++++++++++++
 .../turbo-task-guard-coverage.test.ts         |  97 +++++
 .../__tests__/turbo-type-check-inputs.test.ts | 126 +------
 turbo.json                                    |  15 +-
 11 files changed, 1584 insertions(+), 271 deletions(-)
 create mode 100644 scripts/__tests__/helpers/build-program.ts
 create mode 100644 scripts/__tests__/helpers/config-program.ts
 create mode 100644 scripts/__tests__/helpers/eslint-config-program.ts
 create mode 100644 scripts/__tests__/helpers/tsc-program.ts
 create mode 100644 scripts/__tests__/turbo-build-inputs.test.ts
 create mode 100644 scripts/__tests__/turbo-lint-inputs.test.ts
 create mode 100644 scripts/__tests__/turbo-task-guard-coverage.test.ts

diff --git a/scripts/__tests__/helpers/build-program.ts b/scripts/__tests__/helpers/build-program.ts
new file mode 100644
index 000000000..52f904798
--- /dev/null
+++ b/scripts/__tests__/helpers/build-program.ts
@@ -0,0 +1,356 @@
+import fs from 'node:fs';
+import path from 'node:path';
+import { outOfPackageProgramFiles } from './config-program';
+import {
+  invocationForCommand,
+  outOfPackageFilesFor,
+  type TscInvocation,
+} from './tsc-program';
+import { rel, repoRoot, type WorkspacePackage } from './turbo-inputs';
+
+/**
+ * Derives a workspace package's **build program** — the set of files the tools
+ * its `build` script drives read in order to know what to produce.
+ *
+ * The fourth instance of the objectui#3514 class (objectui#4185), and the one
+ * with the widest blast radius: `build` declared no `inputs` at all, and `build`
+ * is the task whose `dist/` every other task consumes through
+ * `dependsOn: ["^build"]`. A build replayed from a cache key that ignored a
+ * `strict` flip in the root `tsconfig.json` hands stale `dist/` to everything
+ * downstream.
+ *
+ * ## Why this derivation is a union rather than one walk
+ *
+ * `type-check` scripts are all tsc and `test` scripts are all Vitest, so each of
+ * those guards derives one kind of program. `build` scripts are not uniform —
+ * they are `&&` chains over five tools:
+ *
+ *     tsc                     14 packages      the tsc program (./tsc-program.ts)
+ *     vite build              22 packages      the Vite config program
+ *     tsup                     4 packages      the tsup config program + its tsconfig
+ *     next build               1 app           the Next config program + its tsconfig
+ *     node <script>            2 packages      the script and what it imports
+ *     pnpm <script>            1 app           the same package's other script
+ *
+ * So a segment is classified by the tool it runs, and each tool contributes
+ * whatever IT reads. A segment running a command this module cannot classify
+ * throws rather than being skipped: an unclassified segment is an unswept
+ * program, and this guard's whole value is that it cannot quietly sweep
+ * nothing.
+ *
+ * The relative-import walk over the resolved config files is the shared one in
+ * `./config-program.ts`; the tsc side is the shared walker in `./tsc-program.ts`
+ * that objectui#3514's guard also uses. What lives here is only which file each
+ * tool starts from.
+ *
+ * ## Narrowings specific to this derivation
+ *
+ *  - A BUNDLER PLUGIN'S OWN FILE READS ARE NOT MODELLED. `vite-plugin-dts`
+ *    builds a tsc program from the package's `tsconfig.json`, so a `vite build`
+ *    package does transitively read the root tsconfig that one extends. Chasing
+ *    that would mean reproducing each plugin's version-specific default for
+ *    where its config lives — a derivation that drifts silently the next time a
+ *    plugin changes its defaults, which is the failure mode of the thing being
+ *    guarded. It is left out deliberately, and the cost is measured rather than
+ *    assumed: turbo `inputs` are TASK-wide, not per-package, so an entry earned
+ *    by one package covers the task for all of them — and
+ *    `$TURBO_ROOT$/tsconfig.json` is earned many times over by the 14 packages
+ *    whose build IS a tsc run. The narrowing changes which packages the guard
+ *    NAMES, not which files the task hashes.
+ *  - NO FILE-VALUED OPTIONS. Unlike a Vitest config, nothing in this repo's
+ *    build configs names a program file through a string literal: entries are
+ *    spelled `resolve(__dirname, 'src/index.tsx')`, which is an expression, and
+ *    every out-of-package reach is an `import` instead
+ *    (`apps/console/vite.config.ts` importing the two `scripts/vite-*.ts`
+ *    plugins). Declared explicitly, and empty, so the shared walker's
+ *    key-directed designation rule is visibly a decision here.
+ *  - A `pnpm --filter <pkg> build` SEGMENT IS A TASK-GRAPH FACT, NOT AN INPUTS
+ *    FACT. Two packages have a `prebuild` that builds another workspace package
+ *    (pnpm runs `prebuild` as part of `pnpm run build`, so turbo runs it too).
+ *    The right answer to "this package's build needs that package's dist" is
+ *    turbo's `dependsOn: ["^build"]`, not a `$TURBO_ROOT$` glob over another
+ *    package's source. So delegations are collected and returned rather than
+ *    walked, and `../turbo-build-inputs.test.ts` asserts each delegated package
+ *    is a DECLARED dependency — which is what makes `^build` order it.
+ */
+
+/** Vite's config candidates, in its own precedence order. */
+export const VITE_CONFIG_FILES = [
+  'vite.config.js',
+  'vite.config.mjs',
+  'vite.config.ts',
+  'vite.config.cjs',
+  'vite.config.mts',
+  'vite.config.cts',
+];
+
+/** tsup's config candidates, in its own precedence order. */
+export const TSUP_CONFIG_FILES = [
+  'tsup.config.ts',
+  'tsup.config.cts',
+  'tsup.config.mts',
+  'tsup.config.js',
+  'tsup.config.cjs',
+  'tsup.config.mjs',
+];
+
+/** Next's config candidates. */
+export const NEXT_CONFIG_FILES = [
+  'next.config.js',
+  'next.config.mjs',
+  'next.config.ts',
+  'next.config.cjs',
+  'next.config.mts',
+  'next.config.cts',
+];
+
+/**
+ * Nothing in this repo's build configs designates a program file through a
+ * string literal — see the docblock's second narrowing.
+ */
+export const FILE_VALUED_OPTIONS: ReadonlySet<string> = new Set<string>();
+
+export interface BuildProgram {
+  /** Tool config files the script drives, absolute — the walk's entry points. */
+  readonly configFiles: string[];
+  /** tsc projects the script drives, for the shared tsconfig walker. */
+  readonly tscInvocations: TscInvocation[];
+  /** Workspace packages this build delegates to through `pnpm --filter`. */
+  readonly delegations: string[];
+  /** Files the program reads from outside the package, repo-relative, sorted. */
+  readonly outside: string[];
+}
+
+/** Split a command into tokens, with `--flag=value` kept as one token. */
+function tokenize(command: string): string[] {
+  return command.trim().split(/\s+/);
+}
+
+/** The value of `--flag value` / `--flag=value`, or null. */
+function flagValue(tokens: string[], names: string[]): string | null {
+  for (let i = 0; i < tokens.length; i += 1) {
+    const token = tokens[i];
+    const [flag, inline] = token.includes('=')
+      ? [token.slice(0, token.indexOf('=')), token.slice(token.indexOf('=') + 1)]
+      : [token, null];
+    if (names.includes(flag)) return inline ?? tokens[i + 1] ?? null;
+  }
+  return null;
+}
+
+/**
+ * The first config name in `candidates` that exists in `dir`.
+ *
+ * Vite and Next both resolve their config in the project directory only —
+ * Vite's `loadConfigFromFile` loops `DEFAULT_CONFIG_FILES` over `configRoot`
+ * with no upward step, which is the opposite of Vitest's behaviour and the
+ * reason `packages/components` builds from `vite.config.ts` while its tests run
+ * from `vitest.config.ts`.
+ */
+function firstIn(dir: string, candidates: string[]): string | null {
+  for (const name of candidates) {
+    const candidate = path.join(dir, name);
+    if (fs.existsSync(candidate)) return candidate;
+  }
+  return null;
+}
+
+/**
+ * tsup resolves its config by walking UP from the cwd (joycon, `stopDir` at the
+ * filesystem root), taking the first name in `TSUP_CONFIG_FILES` order in each
+ * directory, and also accepting a `package.json` carrying a `tsup` key. The
+ * walk stops at the repo root here: a config above it is not this repo's.
+ */
+function resolveTsupConfig(fromDir: string): string | null {
+  let dir = fromDir;
+  for (;;) {
+    const found = firstIn(dir, TSUP_CONFIG_FILES);
+    if (found !== null) return found;
+    const manifest = path.join(dir, 'package.json');
+    if (fs.existsSync(manifest)) {
+      const parsed = JSON.parse(fs.readFileSync(manifest, 'utf8')) as { tsup?: unknown };
+      if (parsed.tsup !== undefined) {
+        throw new Error(
+          `${rel(manifest)} configures tsup through a \`tsup\` package.json key. ` +
+            `Teach buildProgramFor() to read it — a JSON config is not walked by the ` +
+            `TypeScript-parser-based import walk.`,
+        );
+      }
+    }
+    if (dir === repoRoot) return null;
+    const parent = path.dirname(dir);
+    if (parent === dir) return null;
+    dir = parent;
+  }
+}
+
+/** The package's own `tsconfig.json`, if it has one — what tsup and Next read. */
+function conventionalTsconfig(pkgDir: string, named: string | null): TscInvocation | null {
+  const project = path.resolve(pkgDir, named ?? 'tsconfig.json');
+  if (!fs.existsSync(project)) return null;
+  return { project, build: false };
+}
+
+interface Accumulator {
+  readonly configFiles: Set<string>;
+  readonly tscInvocations: TscInvocation[];
+  readonly delegations: Set<string>;
+  readonly seenScripts: Set<string>;
+}
+
+/** Classify one `&&` segment of a build script and record what it reads. */
+function collectSegment(pkg: WorkspacePackage, command: string, acc: Accumulator): void {
+  const tokens = tokenize(command);
+  const tool = tokens[0];
+
+  if (tool === 'tsc') {
+    acc.tscInvocations.push(invocationForCommand(pkg.dir, command));
+    return;
+  }
+
+  if (tool === 'vite' && tokens[1] === 'build') {
+    const named = flagValue(tokens, ['--config', '-c']);
+    const root = flagValue(tokens, ['--root', '-r']);
+    const configRoot = path.resolve(pkg.dir, root ?? '.');
+    const config =
+      named !== null ? path.resolve(configRoot, named) : firstIn(configRoot, VITE_CONFIG_FILES);
+    if (config === null) {
+      throw new Error(
+        `${rel(pkg.dir)}: \`${command}\` finds no Vite config in ${rel(configRoot)}. Vite does ` +
+          `not search upward, so this build has no config at all — teach buildProgramFor() if ` +
+          `that is intentional.`,
+      );
+    }
+    if (!fs.existsSync(config)) {
+      throw new Error(`${rel(pkg.dir)}: \`${command}\` names ${rel(config)}, which does not exist.`);
+    }
+    acc.configFiles.add(config);
+    return;
+  }
+
+  if (tool === 'tsup') {
+    const config = resolveTsupConfig(pkg.dir);
+    if (config !== null) acc.configFiles.add(config);
+    // tsup's declaration step compiles with `options.tsconfig || "tsconfig.json"`
+    // resolved from the package directory, so the tsconfig chain is part of the
+    // build program exactly as it is for a bare `tsc`.
+    const tsconfig = conventionalTsconfig(pkg.dir, flagValue(tokens, ['--tsconfig']));
+    if (tsconfig !== null) acc.tscInvocations.push(tsconfig);
+    return;
+  }
+
+  if (tool === 'next' && tokens[1] === 'build') {
+    const config = firstIn(pkg.dir, NEXT_CONFIG_FILES);
+    if (config !== null) acc.configFiles.add(config);
+    const tsconfig = conventionalTsconfig(pkg.dir, null);
+    if (tsconfig !== null) acc.tscInvocations.push(tsconfig);
+    return;
+  }
+
+  if (tool === 'node') {
+    const script = tokens.slice(1).find((token) => !token.startsWith('-'));
+    if (script === undefined) {
+      throw new Error(`${rel(pkg.dir)}: \`${command}\` runs node with no script to walk.`);
+    }
+    const resolved = path.resolve(pkg.dir, script);
+    if (!fs.existsSync(resolved)) {
+      throw new Error(
+        `${rel(pkg.dir)}: \`${command}\` runs ${rel(resolved)}, which does not exist.`,
+      );
+    }
+    acc.configFiles.add(resolved);
+    return;
+  }
+
+  if (tool === 'pnpm') {
+    const filtered = flagValue(tokens, ['--filter', '-F']);
+    if (filtered !== null) {
+      acc.delegations.add(filtered);
+      return;
+    }
+    const name = tokens.slice(1).find((token) => !token.startsWith('-') && token !== 'run');
+    if (name === undefined) {
+      throw new Error(`${rel(pkg.dir)}: \`${command}\` runs pnpm with no script to follow.`);
+    }
+    if (acc.seenScripts.has(name)) return;
+    acc.seenScripts.add(name);
+    const manifest = JSON.parse(
+      fs.readFileSync(path.join(pkg.dir, 'package.json'), 'utf8'),
+    ) as { scripts?: Record<string, string> };
+    const delegated = manifest.scripts?.[name];
+    if (delegated === undefined) {
+      throw new Error(
+        `${rel(pkg.dir)}: \`${command}\` runs the \`${name}\` script, which the package does ` +
+          `not declare.`,
+      );
+    }
+    collectScript(pkg, delegated, acc);
+    return;
+  }
+
+  throw new Error(
+    `${rel(pkg.dir)}: \`${command}\` runs a tool buildProgramFor() cannot classify. Teach it ` +
+      `what that tool reads — an unclassified segment is an unswept program.`,
+  );
+}
+
+/** Walk every `&&` segment of a script. */
+function collectScript(pkg: WorkspacePackage, script: string, acc: Accumulator): void {
+  for (const segment of script.split('&&')) {
+    const command = segment.trim();
+    if (command === '') continue;
+    collectSegment(pkg, command, acc);
+  }
+}
+
+/**
+ * The build program of a package: the tool configs its `build` script reads,
+ * the tsc projects it drives, the workspace packages it delegates to, and the
+ * files all of that reaches outside the package directory.
+ *
+ * `prebuild` and `postbuild` are included when declared, because pnpm runs them
+ * as part of `pnpm run build` and turbo therefore runs them too — leaving them
+ * out would let a build read a file the guard never saw.
+ */
+export function buildProgramFor(pkg: WorkspacePackage): BuildProgram {
+  const manifest = JSON.parse(fs.readFileSync(path.join(pkg.dir, 'package.json'), 'utf8')) as {
+    scripts?: Record<string, string>;
+  };
+  const acc: Accumulator = {
+    configFiles: new Set<string>(),
+    tscInvocations: [],
+    delegations: new Set<string>(),
+    seenScripts: new Set<string>(['build']),
+  };
+
+  for (const name of ['prebuild', 'build', 'postbuild']) {
+    const script = name === 'build' ? pkg.script : manifest.scripts?.[name];
+    if (script !== undefined) collectScript(pkg, script, acc);
+  }
+
+  const configFiles = [...acc.configFiles].sort();
+  const outside = new Set<string>([
+    ...outOfPackageProgramFiles({
+      tool: 'build',
+      entries: configFiles,
+      pkgDir: pkg.dir,
+      fileValuedOptions: FILE_VALUED_OPTIONS,
+    }),
+    ...outOfPackageFilesFor(pkg.dir, acc.tscInvocations),
+  ]);
+
+  return {
+    configFiles,
+    tscInvocations: acc.tscInvocations,
+    delegations: [...acc.delegations].sort(),
+    outside: [...outside].sort(),
+  };
+}
+
+/**
+ * Every file a package's build program reads from outside the package
+ * directory, repo-relative and sorted.
+ */
+export function outOfPackageFiles(pkg: WorkspacePackage): string[] {
+  return buildProgramFor(pkg).outside;
+}
diff --git a/scripts/__tests__/helpers/config-program.ts b/scripts/__tests__/helpers/config-program.ts
new file mode 100644
index 000000000..d413af173
--- /dev/null
+++ b/scripts/__tests__/helpers/config-program.ts
@@ -0,0 +1,217 @@
+import fs from 'node:fs';
+import path from 'node:path';
+import ts from 'typescript';
+import { rel } from './turbo-inputs';
+
+/**
+ * Walking a tool's **configuration program** — the files a build tool reads in
+ * order to know what to do, as opposed to the source it then acts on.
+ *
+ * Four guards now derive one, and they derive it for four different tools:
+ *
+ *  - `../turbo-test-inputs.test.ts` (objectui#4178) walks each package's Vitest
+ *    configuration program.
+ *  - `../turbo-lint-inputs.test.ts` (objectui#4184) walks each package's ESLint
+ *    flat-config program.
+ *  - `../turbo-build-inputs.test.ts` (objectui#4185) walks each package's build
+ *    program, which is a union over the tools its `build` script drives.
+ *  - `../turbo-type-check-inputs.test.ts` (objectui#3514) is the exception: a
+ *    tsc program is assembled by TypeScript's own config parser, so it lives in
+ *    `./tsc-program.ts` instead.
+ *
+ * What differs between the first three is which file a tool starts from and
+ * which of its options name files. What does NOT differ is the walk itself:
+ * parse a config file, follow its relative imports transitively, follow the
+ * paths it designates through file-valued options, and report what lands
+ * outside the package directory. Three hand-written copies of that walk is
+ * three chances for one of them to drift toward resolving FEWER files — and a
+ * derivation that quietly resolves fewer files is a guard that quietly stops
+ * requiring inputs, which is the exact failure all four guards exist to
+ * prevent. One implementation, used by all of them.
+ *
+ * ## Narrowings, shared by every caller
+ *
+ *  - BARE SPECIFIERS ARE NOT FOLLOWED. `eslint.config.js` imports
+ *    `typescript-eslint`, `apps/console/vite.config.ts` imports `vite` — those
+ *    resolve into `node_modules`, which turbo tracks through the lockfile
+ *    rather than through a task's `inputs`. Following them would also drag in
+ *    the alias closure of the workspace, which is most of the repository.
+ *  - DESIGNATION IS KEY-DIRECTED, not every string literal in the file. A
+ *    literal counts as a designated path only under one of the option names the
+ *    caller declares. Globs that SELECT files to act on (`files` / `ignores` in
+ *    an ESLint flat config, `include` in a Vitest project) are not designations:
+ *    the selected files are the tool's subject, not its program, and they live
+ *    inside the package where turbo's `$TURBO_DEFAULT$` already hashes them.
+ *  - A literal under a designating key that LOOKS like a concrete source path
+ *    and resolves to nothing THROWS rather than being skipped, so a renamed
+ *    file cannot quietly leave the program.
+ *
+ * Every narrowing errs the same way: toward requiring MORE files, and toward
+ * throwing on a shape not understood. An approximation that comes out
+ * "covered" is a file waved through while turbo does not hash it —
+ * wrong-and-red is recoverable, wrong-and-green is the bug.
+ */
+
+/** Extensions tried, in order, when a relative specifier carries none. */
+export const RESOLVE_EXTENSIONS = ['.ts', '.tsx', '.mts', '.cts', '.js', '.jsx', '.mjs', '.cjs'];
+
+/** Resolve a relative specifier to a file on disk, trying the extensions above. */
+export function resolveRelative(fromFile: string, specifier: string): string | null {
+  const base = path.resolve(path.dirname(fromFile), specifier);
+  const candidates = [
+    base,
+    ...RESOLVE_EXTENSIONS.map((extension) => base + extension),
+    ...RESOLVE_EXTENSIONS.map((extension) => path.join(base, `index${extension}`)),
+  ];
+  for (const candidate of candidates) {
+    if (fs.existsSync(candidate) && fs.statSync(candidate).isFile()) return candidate;
+  }
+  return null;
+}
+
+/** Does this literal look like a concrete source path rather than a glob or a name? */
+export function looksLikeSourcePath(literal: string): boolean {
+  if (/[*?{}[\]]/.test(literal)) return false;
+  return RESOLVE_EXTENSIONS.some((extension) => literal.endsWith(extension));
+}
+
+/**
+ * Every relative module specifier a source file imports, and every path it
+ * designates through one of `fileValuedOptions`.
+ *
+ * Parsed with TypeScript's own parser rather than regexes — `.mts`, `.tsx`,
+ * `.mjs` and plain `.js` all land here, and a specifier inside a comment or an
+ * unrelated string must not count.
+ */
+export function programEdges(
+  file: string,
+  fileValuedOptions: ReadonlySet<string>,
+): { imports: string[]; designated: string[] } {
+  const source = ts.createSourceFile(
+    file,
+    fs.readFileSync(file, 'utf8'),
+    ts.ScriptTarget.Latest,
+    /* setParentNodes */ true,
+    file.endsWith('x') ? ts.ScriptKind.TSX : undefined,
+  );
+
+  const imports: string[] = [];
+  const designated: string[] = [];
+
+  const literalValue = (node: ts.Node): string | null =>
+    ts.isStringLiteral(node) || ts.isNoSubstitutionTemplateLiteral(node) ? node.text : null;
+
+  /** Collect every literal under a file-valued option's value. */
+  const collectDesignated = (node: ts.Node): void => {
+    const value = literalValue(node);
+    if (value !== null) {
+      designated.push(value);
+      return;
+    }
+    node.forEachChild(collectDesignated);
+  };
+
+  const visit = (node: ts.Node): void => {
+    if (
+      (ts.isImportDeclaration(node) || ts.isExportDeclaration(node)) &&
+      node.moduleSpecifier !== undefined
+    ) {
+      const value = literalValue(node.moduleSpecifier);
+      if (value !== null) imports.push(value);
+    } else if (
+      ts.isCallExpression(node) &&
+      (node.expression.kind === ts.SyntaxKind.ImportKeyword ||
+        (ts.isIdentifier(node.expression) && node.expression.text === 'require')) &&
+      node.arguments.length > 0
+    ) {
+      const value = literalValue(node.arguments[0]);
+      if (value !== null) imports.push(value);
+    } else if (
+      ts.isPropertyAssignment(node) &&
+      (ts.isIdentifier(node.name) || ts.isStringLiteral(node.name)) &&
+      fileValuedOptions.has(node.name.text)
+    ) {
+      collectDesignated(node.initializer);
+    }
+    node.forEachChild(visit);
+  };
+  visit(source);
+
+  return { imports, designated };
+}
+
+export interface ProgramWalk {
+  /** Which tool's program this is, for error messages: `Vitest`, `ESLint`, … */
+  readonly tool: string;
+  /** Where the walk started — the tool's resolved config files, absolute. */
+  readonly entries: readonly string[];
+  /** Package directory the walk is reported relative to. */
+  readonly pkgDir: string;
+  /** Option names whose values name files rather than globs or data. */
+  readonly fileValuedOptions: ReadonlySet<string>;
+}
+
+/**
+ * Every file a configuration program reads, absolute and sorted.
+ *
+ * The entries themselves are part of the program: a config file living outside
+ * the package is exactly as load-bearing as a module it imports, and just as
+ * invisible to `$TURBO_DEFAULT$`.
+ */
+export function programFiles(walk: ProgramWalk): string[] {
+  const seen = new Set<string>();
+  const queue = [...walk.entries];
+
+  while (queue.length > 0) {
+    const file = queue.shift()!;
+    if (seen.has(file)) continue;
+    seen.add(file);
+
+    const { imports, designated } = programEdges(file, walk.fileValuedOptions);
+
+    for (const specifier of imports) {
+      if (!specifier.startsWith('.')) continue;
+      const resolved = resolveRelative(file, specifier);
+      if (resolved === null) {
+        throw new Error(
+          `${rel(file)} imports ${JSON.stringify(specifier)}, which resolves to no file on disk. ` +
+            `Teach resolveRelative() about it rather than letting the ${walk.tool} program shrink ` +
+            `silently.`,
+        );
+      }
+      queue.push(resolved);
+    }
+
+    for (const literal of designated) {
+      // A designated path is spelled either relative to the designating file
+      // (`'../../vitest.setup.tsx'`) or as `path.resolve(<this file's dir>, …)`
+      // — `__dirname` / `import.meta.dirname`, which IS that directory. Both
+      // resolve the same way, so the base is the file, not the cwd.
+      const resolved = resolveRelative(file, literal);
+      if (resolved !== null) {
+        queue.push(resolved);
+        continue;
+      }
+      if (looksLikeSourcePath(literal)) {
+        throw new Error(
+          `${rel(file)} designates ${JSON.stringify(literal)} through a file-valued ${walk.tool} ` +
+            `option, and it resolves to no file on disk. A renamed file must go red here, not ` +
+            `drop out of the program.`,
+        );
+      }
+    }
+  }
+  return [...seen].sort();
+}
+
+/**
+ * Every file a configuration program reads from OUTSIDE the package directory,
+ * repo-relative and sorted. This is the set turbo cannot hash from
+ * `$TURBO_DEFAULT$`, and therefore the set a `$TURBO_ROOT$` input must cover.
+ */
+export function outOfPackageProgramFiles(walk: ProgramWalk): string[] {
+  return programFiles(walk)
+    .filter((file) => path.relative(walk.pkgDir, file).startsWith('..'))
+    .map(rel)
+    .sort();
+}
diff --git a/scripts/__tests__/helpers/eslint-config-program.ts b/scripts/__tests__/helpers/eslint-config-program.ts
new file mode 100644
index 000000000..489da87e3
--- /dev/null
+++ b/scripts/__tests__/helpers/eslint-config-program.ts
@@ -0,0 +1,224 @@
+import fs from 'node:fs';
+import path from 'node:path';
+import { outOfPackageProgramFiles, programFiles } from './config-program';
+import { rel, repoRoot, type WorkspacePackage } from './turbo-inputs';
+
+/**
+ * Derives a workspace package's **ESLint flat-config program** — the set of
+ * files ESLint reads in order to know what linting that package even means.
+ *
+ * The third instance of the objectui#3514 class (objectui#4184), and the
+ * starkest: turbo's `lint` task declared no `inputs` at all, so it ran on
+ * `$TURBO_DEFAULT$`, which covers only files inside the package directory —
+ * while the file that IS the lint program, the repo-root `eslint.config.js`,
+ * lives outside every package. Change a rule there and no package's `lint` hash
+ * moves; turbo replays the previous verdict instead of re-running.
+ *
+ * ## The program
+ *
+ *  1. The flat config ESLint resolves for the package's `lint` script,
+ *     following the script's own `--config` / `--no-config-lookup` and then
+ *     ESLint's upward search.
+ *  2. Every file that config statically imports by RELATIVE specifier,
+ *     transitively. That second step is not a formality here: `eslint.config.js`
+ *     imports `./eslint-rules/index.js`, which imports the four local rule
+ *     implementations, and those rule bodies decide what the ratchets
+ *     (`object-ui/no-synthetic-event-trigger`, `no-try-catch-around-hook`,
+ *     `no-inline-spec-config`, `no-dynamic-import-in-test-hook`) actually
+ *     reject. A rule implementation is as load-bearing as the config line that
+ *     switches it on, and neither was hashed.
+ *
+ * The walk is the shared one in `./config-program.ts`; what lives here is only
+ * which file ESLint starts from.
+ *
+ * ## Narrowings specific to this derivation
+ *
+ *  - `files` / `ignores` ARE NOT PROGRAM FILES. A flat config's `files` and
+ *    `ignores` are globs that SELECT what gets linted; the selected files are
+ *    ESLint's subject, not its program, and they live inside the package where
+ *    `$TURBO_DEFAULT$` already hashes them. The root config's
+ *    `files: ['packages/types/src/objectql.ts']` block looks like a
+ *    counter-example and is not one: when `@object-ui/types` is linted that
+ *    path is inside the package, and when any other package is linted the
+ *    selector simply matches nothing. Treating a selector as a program file
+ *    would make every package's lint program claim to read every other
+ *    package's source — which is the alias-closure mistake the sibling guards
+ *    also decline to make.
+ *  - PLUGINS AND SHAREABLE CONFIGS FROM `node_modules` ARE NOT FOLLOWED
+ *    (`typescript-eslint`, `eslint-plugin-react-hooks`, `@eslint/js`). Those
+ *    are external dependencies, which turbo tracks through the lockfile rather
+ *    than through a task's `inputs`. Only this repo's own files are at stake.
+ *  - TYPE-AWARE LINTING IS NOT MODELLED, because this repo does not use it.
+ *    A `languageOptions.parserOptions.project` (or `projectService`) would put
+ *    tsconfig files into the lint program, and the derivation would have to
+ *    grow a tsc walker to follow them. Rather than leave that as an assumption,
+ *    the guard PINS it: `../turbo-lint-inputs.test.ts` asserts no config in the
+ *    program enables type-aware linting, so switching it on goes red here with
+ *    the instruction, instead of silently under-covering.
+ */
+
+/**
+ * ESLint's flat-config candidates, in its own precedence order.
+ *
+ * Mirrors `FLAT_CONFIG_FILENAMES` in `eslint/lib/config/config-loader.js`
+ * (eslint 10.8.0), which is handed to `find-up` — so the search is
+ * directory-first: walk up from the start directory and, in each directory,
+ * take the first name in THIS order that exists.
+ */
+export const FLAT_CONFIG_FILENAMES = [
+  'eslint.config.js',
+  'eslint.config.mjs',
+  'eslint.config.cjs',
+  'eslint.config.ts',
+  'eslint.config.mts',
+  'eslint.config.cts',
+];
+
+/**
+ * ESLint flat config has no option whose value names a file the config itself
+ * reads — `files` / `ignores` select subjects, and plugins arrive as imported
+ * objects rather than as paths. Declared explicitly, and empty, so that the
+ * shared walker's key-directed designation rule is visibly a decision here
+ * rather than an omission.
+ */
+export const FILE_VALUED_OPTIONS: ReadonlySet<string> = new Set<string>();
+
+export interface EslintInvocation {
+  /** Directories the lint run starts its config search from. */
+  readonly startDirs: readonly string[];
+  /** An explicit `--config`, already resolved; `null` means "search". */
+  readonly config: string | null;
+  /** `--no-config-lookup` disables the search entirely. */
+  readonly lookup: boolean;
+}
+
+/**
+ * The ESLint invocation a package's `lint` script performs.
+ *
+ * Every shape in the repo today is a single `eslint <target>` — `eslint .` for
+ * 44 packages and `eslint src` for `@object-ui/cli`. A script running a lint
+ * command this parser cannot read throws rather than being skipped: an
+ * unparsed script is an unswept program, and this guard's whole value is that
+ * it cannot quietly sweep nothing.
+ */
+export function invocationFor(pkgDir: string, script: string): EslintInvocation {
+  const commands = script
+    .split('&&')
+    .map((segment) => segment.trim())
+    .filter((command) => /(?:^|\s)eslint(?:\s|$)/.test(command));
+
+  if (commands.length !== 1) {
+    throw new Error(
+      `${rel(pkgDir)}: \`${script}\` does not run exactly one \`eslint\` command ` +
+        `(found ${commands.length}). Teach invocationFor() how to read it — do not let the ` +
+        `sweep skip this package.`,
+    );
+  }
+
+  const tokens = commands[0].split(/\s+/);
+  let config: string | null = null;
+  let lookup = true;
+  const targets: string[] = [];
+  for (let i = 1; i < tokens.length; i += 1) {
+    const token = tokens[i];
+    const [flag, inlineValue] = token.includes('=')
+      ? [token.slice(0, token.indexOf('=')), token.slice(token.indexOf('=') + 1)]
+      : [token, null];
+    if (flag === '--config' || flag === '-c') config = inlineValue ?? tokens[++i];
+    else if (flag === '--no-config-lookup') lookup = false;
+    else if (flag.startsWith('-')) {
+      // A flag this parser does not know may or may not take a value, so the
+      // token stream cannot be read past it with confidence.
+      throw new Error(
+        `${rel(pkgDir)}: \`${commands[0]}\` passes ${JSON.stringify(flag)}, a flag ` +
+          `invocationFor() does not know. Teach it rather than letting the targets be misread.`,
+      );
+    } else targets.push(token);
+  }
+
+  // `eslint` with no target lints the cwd, which is the package directory.
+  const startDirs = (targets.length > 0 ? targets : ['.']).map((target) => {
+    const resolved = path.resolve(pkgDir, target);
+    return fs.existsSync(resolved) && fs.statSync(resolved).isDirectory()
+      ? resolved
+      : path.dirname(resolved);
+  });
+
+  return { startDirs, config: config === null ? null : path.resolve(pkgDir, config), lookup };
+}
+
+/**
+ * The flat config ESLint loads for a lint run started in `startDir`.
+ *
+ * Reproduces `findUp(FLAT_CONFIG_FILENAMES, { cwd: fromDirectory })` from
+ * `ConfigLoader.locateConfigFileToUse` — walk UP, and in each directory take
+ * the first name in `FLAT_CONFIG_FILENAMES` order that exists.
+ *
+ * ESLint 10 looks the config up from each LINTED FILE's directory rather than
+ * once from the cwd, so strictly this models the shallowest start point of that
+ * per-file search. The two coincide here because the repo holds exactly one
+ * flat config — a fact `../turbo-lint-inputs.test.ts` asserts rather than
+ * assumes, so a package-local `eslint.config.js` goes red and this derivation
+ * gets taught before it can under-report.
+ *
+ * The walk stops at the repo root: a config above it is not this repo's.
+ */
+export function resolveConfigFile(invocation: EslintInvocation, startDir: string): string | null {
+  if (invocation.config !== null) {
+    if (!fs.existsSync(invocation.config)) {
+      throw new Error(`--config names ${rel(invocation.config)}, which does not exist.`);
+    }
+    return invocation.config;
+  }
+  if (!invocation.lookup) return null;
+
+  let dir = startDir;
+  for (;;) {
+    for (const name of FLAT_CONFIG_FILENAMES) {
+      const candidate = path.join(dir, name);
+      if (fs.existsSync(candidate)) return candidate;
+    }
+    if (dir === repoRoot) return null;
+    const parent = path.dirname(dir);
+    if (parent === dir) return null;
+    dir = parent;
+  }
+}
+
+/** Every flat config file a package's lint run resolves, absolute and sorted. */
+export function configFilesFor(pkg: WorkspacePackage): string[] {
+  const invocation = invocationFor(pkg.dir, pkg.script);
+  const configs = new Set<string>();
+  for (const startDir of invocation.startDirs) {
+    const resolved = resolveConfigFile(invocation, startDir);
+    if (resolved !== null) configs.add(resolved);
+  }
+  return [...configs].sort();
+}
+
+/** Every file a package's ESLint flat-config program reads, absolute and sorted. */
+export function programFilesFor(pkg: WorkspacePackage): string[] {
+  const entries = configFilesFor(pkg);
+  if (entries.length === 0) return [];
+  return programFiles({
+    tool: 'ESLint',
+    entries,
+    pkgDir: pkg.dir,
+    fileValuedOptions: FILE_VALUED_OPTIONS,
+  });
+}
+
+/**
+ * Every file a package's ESLint flat-config program reads from outside the
+ * package directory, repo-relative and sorted.
+ */
+export function outOfPackageFiles(pkg: WorkspacePackage): string[] {
+  const entries = configFilesFor(pkg);
+  if (entries.length === 0) return [];
+  return outOfPackageProgramFiles({
+    tool: 'ESLint',
+    entries,
+    pkgDir: pkg.dir,
+    fileValuedOptions: FILE_VALUED_OPTIONS,
+  });
+}
diff --git a/scripts/__tests__/helpers/tsc-program.ts b/scripts/__tests__/helpers/tsc-program.ts
new file mode 100644
index 000000000..62f620068
--- /dev/null
+++ b/scripts/__tests__/helpers/tsc-program.ts
@@ -0,0 +1,148 @@
+import fs from 'node:fs';
+import path from 'node:path';
+import ts from 'typescript';
+import { rel } from './turbo-inputs';
+
+/**
+ * Derives the **tsc program** a package's script drives — the files TypeScript
+ * is given, as TypeScript itself assembles them.
+ *
+ * Written for objectui#3514 (`type-check`) and lifted out of that guard for
+ * objectui#4185, because `build` drives tsc too: 14 packages build with a bare
+ * `tsc`, `apps/console` adds `tsc -p tsconfig.plugin.json`, and every `tsup`
+ * package's declaration step reads a tsconfig as well. The same derivation,
+ * two tasks — and a second hand-written copy of a tsconfig walker is exactly
+ * the drift neither guard would survive.
+ *
+ * ## Scope, stated so the narrowing is visible rather than assumed
+ *
+ *  - ROOT FILES, not the import closure. This reports the files tsc is GIVEN
+ *    (config `include` / `files` / `extends` / `references`), not every module
+ *    they transitively import. Building 40+ real programs to resolve imports
+ *    needs a built workspace and minutes of CPU per run. The narrowing is sound
+ *    for the failure being guarded: a composite project must list every file in
+ *    its program, which is exactly why both of objectui#3514's known drifts were
+ *    `include` entries in the first place.
+ *  - Cross-package references are still reported. If one package's program
+ *    reaches into another package's directory, that is reported like any other
+ *    out-of-package file rather than waved through on the assumption that
+ *    turbo's `dependsOn: ["^build"]` covers it — `^build` covers declared
+ *    DEPENDENCIES, and a tsconfig reference is not required to be one.
+ */
+
+export interface TscInvocation {
+  /** Absolute path of the tsconfig this segment compiles. */
+  readonly project: string;
+  /** `tsc -b` / `--build`, which also compiles the project's references. */
+  readonly build: boolean;
+}
+
+/**
+ * The tsc projects a `&&` chain of commands drives.
+ *
+ * Every shape in the repo today is a bare `tsc` (the package's own
+ * `tsconfig.json`), `tsc -p <config>` for the `tsconfig.test.json` /
+ * `tsconfig.plugin.json` companions, or `apps/console`'s
+ * `tsc -b tsconfig.node.json --force`. A segment that runs tsc in a shape this
+ * parser cannot read throws rather than being skipped: an unparsed segment is
+ * an unswept program.
+ */
+export function invocationsFor(pkgDir: string, script: string): TscInvocation[] {
+  const invocations: TscInvocation[] = [];
+  for (const segment of script.split('&&')) {
+    const command = segment.trim();
+    if (!/(?:^|\s)tsc(?:\s|$)/.test(command)) continue;
+    invocations.push(invocationForCommand(pkgDir, command));
+  }
+  return invocations;
+}
+
+/** The tsc project a single `tsc …` command drives. */
+export function invocationForCommand(pkgDir: string, command: string): TscInvocation {
+  const build = /(?:^|\s)(?:-b|--build)(?:\s|$)/.test(command);
+  const named = command.match(/(?:^|\s)(?:-p|--project|-b|--build)\s+([^\s]+)/);
+  if (build && !named) {
+    throw new Error(
+      `${rel(pkgDir)}: \`${command}\` builds without naming a project. Teach ` +
+        `invocationsFor() how to resolve it.`,
+    );
+  }
+  const project = path.resolve(pkgDir, named ? named[1] : 'tsconfig.json');
+  if (!fs.existsSync(project)) {
+    throw new Error(`${rel(pkgDir)}: \`${command}\` drives ${rel(project)}, which does not exist.`);
+  }
+  return { project, build };
+}
+
+/**
+ * A tsconfig parsed the way `tsc` parses it, so `fileNames` is the real program
+ * root set rather than a re-implementation of TypeScript's glob semantics.
+ *
+ * `readJsonConfigFile` (not `readConfigFile`) is what makes `extendedSourceFiles`
+ * available — the `extends` chain, which is the half of "the program" that a
+ * file-list-only reading misses.
+ */
+export function parseProject(configPath: string): {
+  parsed: ts.ParsedCommandLine;
+  extended: string[];
+} {
+  const sourceFile = ts.readJsonConfigFile(configPath, ts.sys.readFile);
+  const parsed = ts.parseJsonSourceFileConfigFileContent(
+    sourceFile,
+    ts.sys,
+    path.dirname(configPath),
+    undefined,
+    configPath,
+  );
+  const fatal = parsed.errors.find((e) => e.category === ts.DiagnosticCategory.Error);
+  if (fatal) {
+    throw new Error(
+      `${rel(configPath)} must parse as a tsconfig: ` +
+        ts.flattenDiagnosticMessageText(fatal.messageText, ' '),
+    );
+  }
+  return { parsed, extended: sourceFile.extendedSourceFiles ?? [] };
+}
+
+/**
+ * Every file the given tsc invocations read from outside `pkgDir`,
+ * repo-relative and sorted.
+ */
+export function outOfPackageFilesFor(pkgDir: string, invocations: TscInvocation[]): string[] {
+  const found = new Set<string>();
+  const seen = new Set<string>();
+  const queue = [...invocations];
+
+  while (queue.length > 0) {
+    const { project, build } = queue.shift()!;
+    if (seen.has(project)) continue;
+    seen.add(project);
+
+    const { parsed, extended } = parseProject(project);
+    // The config file itself belongs to the program too — a referenced or
+    // extended config living outside the package is exactly as load-bearing as
+    // a source file, and just as invisible to `$TURBO_DEFAULT$`.
+    for (const file of [project, ...extended, ...parsed.fileNames]) {
+      if (path.relative(pkgDir, file).startsWith('..')) found.add(rel(file));
+    }
+
+    // `tsc -b` compiles referenced projects as well; `tsc -p` does not.
+    if (build) {
+      for (const reference of parsed.projectReferences ?? []) {
+        const target = reference.path.endsWith('.json')
+          ? reference.path
+          : path.join(reference.path, 'tsconfig.json');
+        queue.push({ project: target, build: true });
+      }
+    }
+  }
+  return [...found].sort();
+}
+
+/**
+ * Every file a package's tsc program reads from outside the package directory,
+ * for a script that is a `&&` chain of `tsc` commands.
+ */
+export function outOfPackageFiles(pkgDir: string, script: string): string[] {
+  return outOfPackageFilesFor(pkgDir, invocationsFor(pkgDir, script));
+}
diff --git a/scripts/__tests__/helpers/turbo-inputs.ts b/scripts/__tests__/helpers/turbo-inputs.ts
index f4f69f283..768ba34bc 100644
--- a/scripts/__tests__/helpers/turbo-inputs.ts
+++ b/scripts/__tests__/helpers/turbo-inputs.ts
@@ -109,13 +109,13 @@ export function packagesWithScript(script: string): WorkspacePackage[] {
 }
 
 /**
- * The `$TURBO_ROOT$`-anchored `inputs` of a task, as repo-relative globs.
+ * The declared `inputs` of a task, verbatim.
  *
- * Everything else in the list is package-relative and therefore cannot reach
- * outside the package directory — turbo has no `..` escape, which is why
- * `$TURBO_ROOT$` exists at all.
+ * A task with no `inputs` at all is not "unconfigured" — it is running on
+ * turbo's default, which is the defect all four guards exist to close, so the
+ * absence throws rather than reading as an empty list.
  */
-export function rootAnchoredInputs(task: string): string[] {
+export function taskInputs(task: string): string[] {
   const turbo = JSON.parse(fs.readFileSync(turboConfigPath, 'utf8')) as {
     tasks?: Record<string, { inputs?: string[] }>;
   };
@@ -123,8 +123,18 @@ export function rootAnchoredInputs(task: string): string[] {
   if (!definition) throw new Error(`turbo.json must define a \`${task}\` task`);
   const inputs = definition.inputs ?? [];
   if (inputs.length === 0) throw new Error(`turbo.json \`${task}\` must declare \`inputs\``);
+  return inputs;
+}
 
-  return inputs
+/**
+ * The `$TURBO_ROOT$`-anchored `inputs` of a task, as repo-relative globs.
+ *
+ * Everything else in the list is package-relative and therefore cannot reach
+ * outside the package directory — turbo has no `..` escape, which is why
+ * `$TURBO_ROOT$` exists at all.
+ */
+export function rootAnchoredInputs(task: string): string[] {
+  return taskInputs(task)
     .filter((entry) => entry.startsWith('$TURBO_ROOT$/'))
     .map((entry) => entry.slice('$TURBO_ROOT$/'.length));
 }
diff --git a/scripts/__tests__/helpers/vitest-config-program.ts b/scripts/__tests__/helpers/vitest-config-program.ts
index baa518efd..9b6a8f7ce 100644
--- a/scripts/__tests__/helpers/vitest-config-program.ts
+++ b/scripts/__tests__/helpers/vitest-config-program.ts
@@ -1,6 +1,6 @@
 import fs from 'node:fs';
 import path from 'node:path';
-import ts from 'typescript';
+import { outOfPackageProgramFiles } from './config-program';
 import { rel, repoRoot, type WorkspacePackage } from './turbo-inputs';
 
 /**
@@ -29,7 +29,14 @@ import { rel, repoRoot, type WorkspacePackage } from './turbo-inputs';
  *     entry pulls in `apps/console/vitest.config.ts` and the two
  *     `scripts/vite-*.ts` plugins that one imports.
  *
- * ## Narrowings, stated so they are visible rather than assumed
+ * Steps 2 and 3 are the generic walk, shared with the ESLint and build
+ * derivations since objectui#4184 / objectui#4185: see `./config-program.ts`,
+ * whose docblock carries the narrowings all of them share (bare specifiers not
+ * followed, designation key-directed, unresolvable designated paths throw).
+ * What is specific to Vitest, and lives here, is only which file the walk
+ * STARTS from and which option names designate files.
+ *
+ * ## Narrowings specific to this derivation
  *
  *  - THE CONFIGURATION PROGRAM, not the module closure of the tests. Vitest
  *    resolves `@object-ui/*` through the root config's alias table straight to
@@ -39,22 +46,10 @@ import { rel, repoRoot, type WorkspacePackage } from './turbo-inputs';
  *    `dependsOn: ["^build"]` and per-package `$TURBO_DEFAULT$` already answer
  *    source. The failure being guarded is "change the SHARED TEST HARNESS, get
  *    a stale verdict", and the harness is exactly this program.
- *  - DESIGNATION IS KEY-DIRECTED, not every string in the file. A literal
- *    counts as a designated path only inside one of the file-valued options
- *    above. The root config also holds ~45 concrete test-file paths in
- *    `domTsTests` / `heavyDomTests`; those are `include` / `exclude` inputs to
- *    project definitions, covered by their own packages' inputs — not files
- *    this program reads. A literal under a designating key that LOOKS like a
- *    concrete source path and does not resolve throws rather than being
- *    skipped, so a renamed setup file cannot quietly leave the program.
- *  - BARE SPECIFIERS ARE NOT FOLLOWED. `vitest.setup.dom.tsx` imports
- *    `@object-ui/components` for its registration side effects; that is the
- *    alias closure of the first point, not a config file.
- *
- * Every narrowing errs the same way: toward requiring MORE files, and toward
- * throwing on a shape not understood. An approximation that comes out
- * "covered" is a file waved through while turbo does not hash it —
- * wrong-and-red is recoverable, wrong-and-green is the bug.
+ *  - The root config holds ~45 concrete test-file paths in `domTsTests` /
+ *    `heavyDomTests`; those are `include` / `exclude` inputs to project
+ *    definitions, covered by their own packages' inputs — not files this
+ *    program reads. That is the key-directed rule in action.
  */
 
 // ── Which config file Vitest actually loads ─────────────────────────────────
@@ -74,8 +69,8 @@ export const CONFIG_FILES = CONFIG_NAMES.flatMap((name) =>
   CONFIG_EXTENSIONS.map((extension) => name + extension),
 );
 
-/** Extensions tried, in order, when a relative specifier carries none. */
-export const RESOLVE_EXTENSIONS = ['.ts', '.tsx', '.mts', '.cts', '.js', '.jsx', '.mjs', '.cjs'];
+/** Re-exported for callers that used to import it from here. */
+export { RESOLVE_EXTENSIONS } from './config-program';
 
 /** Vitest options whose value names FILES rather than globs or data. */
 export const FILE_VALUED_OPTIONS = new Set(['setupFiles', 'globalSetup', 'projects', 'workspace']);
@@ -157,90 +152,6 @@ export function resolveConfigFile(invocation: VitestInvocation): string | null {
   }
 }
 
-// ── Walking the configuration program ───────────────────────────────────────
-
-/** Resolve a relative specifier to a file on disk, trying Vitest's extensions. */
-function resolveRelative(fromFile: string, specifier: string): string | null {
-  const base = path.resolve(path.dirname(fromFile), specifier);
-  const candidates = [
-    base,
-    ...RESOLVE_EXTENSIONS.map((extension) => base + extension),
-    ...RESOLVE_EXTENSIONS.map((extension) => path.join(base, `index${extension}`)),
-  ];
-  for (const candidate of candidates) {
-    if (fs.existsSync(candidate) && fs.statSync(candidate).isFile()) return candidate;
-  }
-  return null;
-}
-
-/** Does this literal look like a concrete source path rather than a glob or a name? */
-function looksLikeSourcePath(literal: string): boolean {
-  if (/[*?{}[\]]/.test(literal)) return false;
-  return RESOLVE_EXTENSIONS.some((extension) => literal.endsWith(extension));
-}
-
-/**
- * Every relative module specifier a source file imports, and every path it
- * designates through a file-valued Vitest option.
- *
- * Parsed with TypeScript's own parser rather than regexes — `.mts`, `.tsx` and
- * plain `.mjs` all land here, and a specifier inside a comment or a string must
- * not count.
- */
-export function programEdges(file: string): { imports: string[]; designated: string[] } {
-  const source = ts.createSourceFile(
-    file,
-    fs.readFileSync(file, 'utf8'),
-    ts.ScriptTarget.Latest,
-    /* setParentNodes */ true,
-    file.endsWith('x') ? ts.ScriptKind.TSX : undefined,
-  );
-
-  const imports: string[] = [];
-  const designated: string[] = [];
-
-  const literalValue = (node: ts.Node): string | null =>
-    ts.isStringLiteral(node) || ts.isNoSubstitutionTemplateLiteral(node) ? node.text : null;
-
-  /** Collect every literal under a file-valued option's value. */
-  const collectDesignated = (node: ts.Node): void => {
-    const value = literalValue(node);
-    if (value !== null) {
-      designated.push(value);
-      return;
-    }
-    node.forEachChild(collectDesignated);
-  };
-
-  const visit = (node: ts.Node): void => {
-    if (
-      (ts.isImportDeclaration(node) || ts.isExportDeclaration(node)) &&
-      node.moduleSpecifier !== undefined
-    ) {
-      const value = literalValue(node.moduleSpecifier);
-      if (value !== null) imports.push(value);
-    } else if (
-      ts.isCallExpression(node) &&
-      (node.expression.kind === ts.SyntaxKind.ImportKeyword ||
-        (ts.isIdentifier(node.expression) && node.expression.text === 'require')) &&
-      node.arguments.length > 0
-    ) {
-      const value = literalValue(node.arguments[0]);
-      if (value !== null) imports.push(value);
-    } else if (
-      ts.isPropertyAssignment(node) &&
-      (ts.isIdentifier(node.name) || ts.isStringLiteral(node.name)) &&
-      FILE_VALUED_OPTIONS.has(node.name.text)
-    ) {
-      collectDesignated(node.initializer);
-    }
-    node.forEachChild(visit);
-  };
-  visit(source);
-
-  return { imports, designated };
-}
-
 /**
  * Every file a package's Vitest configuration program reads from outside the
  * package directory, repo-relative and sorted.
@@ -248,51 +159,10 @@ export function programEdges(file: string): { imports: string[]; designated: str
 export function outOfPackageFiles(pkg: WorkspacePackage): string[] {
   const entry = resolveConfigFile(invocationFor(pkg.dir, pkg.script));
   if (entry === null) return [];
-
-  const found = new Set<string>();
-  const seen = new Set<string>();
-  const queue = [entry];
-
-  while (queue.length > 0) {
-    const file = queue.shift()!;
-    if (seen.has(file)) continue;
-    seen.add(file);
-    if (path.relative(pkg.dir, file).startsWith('..')) found.add(rel(file));
-
-    const { imports, designated } = programEdges(file);
-
-    for (const specifier of imports) {
-      // Bare specifiers are node_modules or workspace packages — the alias
-      // closure this guard deliberately does not follow (see the docblock).
-      if (!specifier.startsWith('.')) continue;
-      const resolved = resolveRelative(file, specifier);
-      if (resolved === null) {
-        throw new Error(
-          `${rel(file)} imports ${JSON.stringify(specifier)}, which resolves to no file on disk. ` +
-            `Teach resolveRelative() about it rather than letting the program shrink silently.`,
-        );
-      }
-      queue.push(resolved);
-    }
-
-    for (const literal of designated) {
-      // A designated path is spelled either relative to the designating file
-      // (`'../../vitest.setup.tsx'`) or as `path.resolve(<this file's dir>, …)`
-      // — `__dirname` / `import.meta.dirname`, which IS that directory. Both
-      // resolve the same way, so the base is the file, not the cwd.
-      const resolved = resolveRelative(file, literal);
-      if (resolved !== null) {
-        queue.push(resolved);
-        continue;
-      }
-      if (looksLikeSourcePath(literal)) {
-        throw new Error(
-          `${rel(file)} designates ${JSON.stringify(literal)} through a file-valued Vitest ` +
-            `option, and it resolves to no file on disk. A renamed setup file must go red here, ` +
-            `not drop out of the program.`,
-        );
-      }
-    }
-  }
-  return [...found].sort();
+  return outOfPackageProgramFiles({
+    tool: 'Vitest',
+    entries: [entry],
+    pkgDir: pkg.dir,
+    fileValuedOptions: FILE_VALUED_OPTIONS,
+  });
 }
diff --git a/scripts/__tests__/turbo-build-inputs.test.ts b/scripts/__tests__/turbo-build-inputs.test.ts
new file mode 100644
index 000000000..f057f1d20
--- /dev/null
+++ b/scripts/__tests__/turbo-build-inputs.test.ts
@@ -0,0 +1,233 @@
+import { describe, expect, it } from 'vitest';
+import fs from 'node:fs';
+import path from 'node:path';
+import {
+  globToRegExp,
+  packagesWithScript,
+  rel,
+  repoFilesOnDisk,
+  rootAnchoredInputs,
+  taskInputs,
+} from './helpers/turbo-inputs';
+import { VITE_CONFIG_FILES, buildProgramFor } from './helpers/build-program';
+import { CONFIG_FILES as VITEST_CONFIG_FILES } from './helpers/vitest-config-program';
+
+/**
+ * objectui#4185 — turbo's `build` task has the same out-of-package `inputs`
+ * hole that objectui#3514 closed for `type-check`, objectui#4178 closed for
+ * `test` and objectui#4184 closes for `lint`. This is the fourth instance and
+ * the one with the widest blast radius.
+ *
+ * Turbo hashes a task from its `inputs`. `$TURBO_DEFAULT$` covers only files
+ * inside the package directory, and `globalDependencies` is unset — so any file
+ * the task reads from elsewhere in the repo is invisible to the cache key. When
+ * such a file changes, turbo does not re-run the task; it REPLAYS the previous
+ * verdict. `build` declared no `inputs` AT ALL, so it ran on that default,
+ * while:
+ *
+ *  - 14 packages build with a bare `tsc` whose `tsconfig.json` extends the
+ *    repo-root `tsconfig.json` (and `examples/byo-backend-console` extends the
+ *    root `tsconfig.base.json`). Compiler options are as load-bearing as
+ *    source: flipping `strict` there changes every package's output.
+ *  - `apps/console`'s `vite.config.ts` imports `../../scripts/vite-crypto-stub.ts`
+ *    and `../../scripts/vite-maplibre-worker.ts`. `type-check` covers those;
+ *    `build`, the task that actually RUNS that Vite config, did not.
+ *
+ * Measured on `main` at 2b9428338:
+ *
+ *     @object-ui/core#build      baseline                     3f85d1417964dce6
+ *                                after touching tsconfig.json 3f85d1417964dce6  <- frozen
+ *                                after touching tsconfig.base.json
+ *                                                             3f85d1417964dce6  <- frozen
+ *     @object-ui/console#build   baseline                     a17b12650e52ce28
+ *                                after touching
+ *                                scripts/vite-crypto-stub.ts  a17b12650e52ce28  <- frozen
+ *
+ * `.github/workflows/ci.yml` and `.github/workflows/performance-budget.yml`
+ * both run `turbo run build` with `.turbo/cache` persisted through
+ * `actions/cache`, so the stale verdict travels between runs. And `build` is
+ * the task every other task consumes: `test` and `type-check` both declare
+ * `dependsOn: ["^build"]`, so a `dist/` replayed from a cache key that ignored
+ * a root-tsconfig change is handed to everything downstream.
+ *
+ * The derivation lives in `./helpers/build-program.ts`. Unlike its three
+ * siblings it is a UNION rather than one walk, because `build` scripts are not
+ * uniform — they are `&&` chains over tsc, `vite build`, `tsup`, `next build`,
+ * `node <script>` and `pnpm <script>`, and each tool reads its own config. That
+ * module's docblock carries the mechanism and its stated narrowings; this file
+ * carries only the policy over the result.
+ *
+ * The policy is the family's: every out-of-package file must be matched by a
+ * `$TURBO_ROOT$` input, two assertions police the reverse direction, one pins
+ * the sweep's liveness, one pins that the new explicit list did not narrow what
+ * the old default covered, and two pin premises the sweep rests on.
+ */
+
+/** The turbo task this guard is about. */
+const TASK = 'build';
+
+/**
+ * `$TURBO_ROOT$` inputs for `build` that are deliberately NOT derivable from
+ * any package's build program, each with the reason it cannot be.
+ *
+ * Empty, and worth keeping that way: an entry nothing derives is an entry
+ * nobody can verify, and a glob that matches nothing at all reads as coverage
+ * while providing none.
+ */
+const INPUTS_NOT_DERIVABLE: ReadonlyMap<string, string> = new Map();
+
+// ── The derivation, computed once ───────────────────────────────────────────
+
+const PACKAGES = packagesWithScript(TASK);
+const DERIVED = PACKAGES.map((pkg) => ({ ...pkg, program: buildProgramFor(pkg) }));
+const ROOT_INPUTS = rootAnchoredInputs(TASK);
+const MATCHERS = ROOT_INPUTS.map((glob) => ({ glob, re: globToRegExp(glob) }));
+
+describe('turbo `build` inputs cover every out-of-package file (objectui#4185)', () => {
+  /**
+   * The guard's own liveness. Every assertion below is vacuously true if the
+   * sweep found no packages or no out-of-package files — and a sweep that
+   * silently degrades to nothing is precisely the failure this file exists to
+   * make impossible.
+   */
+  it('sweeps the whole workspace and finds a non-empty out-of-package set', () => {
+    expect(PACKAGES.length).toBeGreaterThan(20);
+    const reaching = DERIVED.filter((pkg) => pkg.program.outside.length > 0);
+    expect(
+      reaching.map((pkg) => pkg.name),
+      'no package build program reaches outside its directory — the derivation has stopped ' +
+        'working, because at minimum packages/core/tsconfig.json extends ../../tsconfig.json',
+    ).not.toHaveLength(0);
+  });
+
+  it.each(
+    DERIVED.filter((pkg) => pkg.program.outside.length > 0).map(
+      (pkg) => [pkg.name, pkg] as const,
+    ),
+  )('%s', (_name, pkg) => {
+    const uncovered = pkg.program.outside.filter(
+      (file) => !MATCHERS.some(({ re }) => re.test(file)),
+    );
+    expect(
+      uncovered,
+      `${pkg.name}'s build program reads ${uncovered.join(', ')} from outside ${rel(pkg.dir)}, ` +
+        `and turbo hashes ${TASK} from ${JSON.stringify(ROOT_INPUTS)} plus the package ` +
+        `directory. Turbo will replay a stale verdict — and hand the stale dist/ to every task ` +
+        `that depends on it — when ${uncovered.length === 1 ? 'that file changes' : 'those files change'}. ` +
+        `Add ${uncovered.map((file) => `"$TURBO_ROOT$/${file}"`).join(', ')} to turbo.json's ` +
+        `\`${TASK}\` inputs.`,
+    ).toEqual([]);
+  });
+
+  /**
+   * The other direction. A `$TURBO_ROOT$` entry matching nothing is not
+   * harmless: it reads as coverage, survives review, and quietly stops covering
+   * the file it was written for the moment that file is renamed.
+   */
+  it('every $TURBO_ROOT$ input matches at least one file on disk', () => {
+    const onDisk = repoFilesOnDisk();
+    for (const { glob, re } of MATCHERS) {
+      expect(
+        [...onDisk].some((file) => re.test(file)),
+        `turbo.json \`${TASK}\` input "$TURBO_ROOT$/${glob}" matches no file in the repo. It is ` +
+          `hashing nothing while reading as coverage — fix the glob or delete the entry.`,
+      ).toBe(true);
+    }
+  });
+
+  /**
+   * And the entry is not merely non-empty but actually earned: some package's
+   * program reads a file it matches. This is what keeps the list SHRINKING —
+   * when a program stops reaching out, its input entry has to go with it.
+   */
+  it('every $TURBO_ROOT$ input is required by some package program', () => {
+    const derivedFiles = [...new Set(DERIVED.flatMap((pkg) => pkg.program.outside))];
+    for (const { glob, re } of MATCHERS) {
+      if (INPUTS_NOT_DERIVABLE.has(glob)) continue;
+      expect(
+        derivedFiles.filter((file) => re.test(file)),
+        `turbo.json \`${TASK}\` input "$TURBO_ROOT$/${glob}" is not required by any package's ` +
+          `build program any more. Delete it, or record why it cannot be derived in ` +
+          `INPUTS_NOT_DERIVABLE.`,
+      ).not.toHaveLength(0);
+    }
+  });
+
+  /**
+   * Declaring `inputs` on a task that had none is itself a behaviour change,
+   * and it can only be a SAFE one if the explicit list still contains the
+   * default it replaced. The card raised exactly this worry; this makes it
+   * mechanical rather than a review note.
+   */
+  it('the explicit inputs list still carries $TURBO_DEFAULT$', () => {
+    expect(
+      taskInputs(TASK),
+      `turbo.json \`${TASK}\` declares an explicit inputs list, so it no longer falls back to ` +
+        `turbo's default. Without "$TURBO_DEFAULT$" in the list the package's OWN source stops ` +
+        `being hashed — which would be a far larger source of stale builds than the hole this ` +
+        `guard closes.`,
+    ).toContain('$TURBO_DEFAULT$');
+  });
+
+  /**
+   * A `pnpm --filter <pkg> build` segment inside a `prebuild` is a task-GRAPH
+   * fact, not an inputs fact: the right answer to "this build needs that
+   * package's dist" is `dependsOn: ["^build"]`, which turbo already declares —
+   * but `^build` only orders DECLARED dependencies. Two packages delegate this
+   * way (`apps/site` to `@object-ui/example-schema-catalog`, `packages/components`
+   * to types/core/react), and the derivation deliberately does not walk into
+   * them. That narrowing is sound only while each delegated package is a real
+   * dependency, so assert it rather than assume it.
+   */
+  it('every delegated build target is a declared dependency', () => {
+    const delegating = DERIVED.filter((pkg) => pkg.program.delegations.length > 0);
+    expect(
+      delegating.map((pkg) => pkg.name),
+      'no package delegates a build any more — drop this assertion with the narrowing it ' +
+        'defends, in helpers/build-program.ts',
+    ).not.toHaveLength(0);
+
+    for (const pkg of delegating) {
+      const manifest = JSON.parse(
+        fs.readFileSync(path.join(pkg.dir, 'package.json'), 'utf8'),
+      ) as { dependencies?: Record<string, string>; devDependencies?: Record<string, string> };
+      const declared = new Set([
+        ...Object.keys(manifest.dependencies ?? {}),
+        ...Object.keys(manifest.devDependencies ?? {}),
+      ]);
+      const undeclared = pkg.program.delegations.filter((name) => !declared.has(name));
+      expect(
+        undeclared,
+        `${pkg.name} builds ${undeclared.join(', ')} through a \`pnpm --filter\` lifecycle ` +
+          `script without declaring ${undeclared.length === 1 ? 'it' : 'them'} as a dependency, ` +
+          `so turbo's \`dependsOn: ["^build"]\` does not order the two. Declare the dependency, ` +
+          `or teach build-program.ts to walk into the delegated package's program.`,
+      ).toEqual([]);
+    }
+  });
+
+  /**
+   * The premise that separates this derivation from its `test` sibling: Vite
+   * resolves its config in the project directory ONLY (`loadConfigFromFile`
+   * loops `DEFAULT_CONFIG_FILES` over `configRoot` with no upward step), and
+   * `vite.config.*` is the only spelling it looks for — whereas Vitest walks UP
+   * and prefers `vitest.config.*`. `packages/components` holds both files, so
+   * it builds from one and tests from the other. If a future Vite started
+   * walking up, a configless package's build program would silently gain files
+   * this derivation never reports; if it started reading `vitest.config.*`,
+   * every dual-config package would derive the wrong program.
+   */
+  it('a package holding both spellings builds from vite.config.*, not vitest.config.*', () => {
+    const both = PACKAGES.find(
+      (pkg) =>
+        VITE_CONFIG_FILES.some((name) => fs.existsSync(path.join(pkg.dir, name))) &&
+        VITEST_CONFIG_FILES.filter((name) => name.startsWith('vitest.')).some((name) =>
+          fs.existsSync(path.join(pkg.dir, name)),
+        ),
+    );
+    expect(both, 'no package holds both config spellings any more').toBeTruthy();
+    expect(buildProgramFor(both!).configFiles.map(rel)).toContain(
+      `${rel(both!.dir)}/vite.config.ts`,
+    );
+  });
+});
diff --git a/scripts/__tests__/turbo-lint-inputs.test.ts b/scripts/__tests__/turbo-lint-inputs.test.ts
new file mode 100644
index 000000000..394297dfd
--- /dev/null
+++ b/scripts/__tests__/turbo-lint-inputs.test.ts
@@ -0,0 +1,245 @@
+import { describe, expect, it } from 'vitest';
+import fs from 'node:fs';
+import path from 'node:path';
+import ts from 'typescript';
+import {
+  globToRegExp,
+  packagesWithScript,
+  rel,
+  repoFilesOnDisk,
+  rootAnchoredInputs,
+  taskInputs,
+} from './helpers/turbo-inputs';
+import {
+  FLAT_CONFIG_FILENAMES,
+  configFilesFor,
+  outOfPackageFiles,
+  programFilesFor,
+} from './helpers/eslint-config-program';
+
+/**
+ * objectui#4184 — turbo's `lint` task has the same out-of-package `inputs` hole
+ * that objectui#3514 closed for `type-check` and objectui#4178 closed for
+ * `test`, and it is the starkest of the three.
+ *
+ * Turbo hashes a task from its `inputs`. `$TURBO_DEFAULT$` covers only files
+ * inside the package directory, and `globalDependencies` is unset — so any file
+ * the task reads from elsewhere in the repo is invisible to the cache key. When
+ * such a file changes, turbo does not re-run the task; it REPLAYS the previous
+ * verdict. `lint` declared no `inputs` AT ALL, so it ran on that default:
+ *
+ *     "lint": { "outputs": [], "cache": true }
+ *
+ * while every package's `lint` script is `eslint .` reading one config that
+ * lives outside every package — the repo-root flat config `eslint.config.js`.
+ * Measured on `main` at 2b9428338, `@object-ui/core#lint`:
+ *
+ *     baseline                                  79872f192ee4828c
+ *     after touching eslint.config.js           79872f192ee4828c   <- frozen
+ *     after touching eslint-rules/index.js      79872f192ee4828c   <- frozen
+ *     after touching packages/core/src/index.ts 5127842ced6c29b3   (control)
+ *
+ * And unlike the `test` instance, this one is live in CI today:
+ * `.github/workflows/lint.yml` runs `turbo run lint` and persists `.turbo/cache`
+ * through `actions/cache`, so one poisoned entry rides into later runs. The
+ * concrete failure is that adding or tightening an ESLint rule can land, go
+ * green on cached verdicts computed BEFORE the rule existed, and never run
+ * against the code it was written for — the repo's four `object-ui/*` ratchets
+ * (objectui#2879, objectui#3010, objectui#3090, ADR-0054 Phase 5) are exactly
+ * the kind of rule that fails this way, silently.
+ *
+ * So this guard DERIVES its requirement rather than restating it, the way both
+ * siblings do. The derivation lives in `./helpers/eslint-config-program.ts`,
+ * which assembles each package's ESLint flat-config program: the config ESLint
+ * resolves for its `lint` script, plus that config's transitive relative
+ * imports — which is how `eslint-rules/index.js` and the four local rule
+ * implementations enter the program. That module's docblock carries the
+ * mechanism and its stated narrowings (`files` / `ignores` select subjects
+ * rather than name program files; `node_modules` plugins are tracked by the
+ * lockfile; type-aware linting is pinned as absent rather than assumed). This
+ * file carries only the policy over the result.
+ *
+ * The policy: every file in that program landing outside the package directory
+ * must be matched by a `$TURBO_ROOT$` input, or this test reds naming the
+ * package, the file, and the entry to add. Two assertions police the reverse
+ * direction, one pins the sweep's liveness, one pins that the new explicit list
+ * did not narrow what the old default covered, and three pin the
+ * config-resolution premises the whole sweep rests on.
+ */
+
+/** The turbo task this guard is about. */
+const TASK = 'lint';
+
+/**
+ * `$TURBO_ROOT$` inputs for `lint` that are deliberately NOT derivable from any
+ * package's ESLint program, each with the reason it cannot be.
+ *
+ * Empty, and worth keeping that way: an entry nothing derives is an entry
+ * nobody can verify, and a glob that matches nothing at all reads as coverage
+ * while providing none.
+ */
+const INPUTS_NOT_DERIVABLE: ReadonlyMap<string, string> = new Map();
+
+// ── The derivation, computed once ───────────────────────────────────────────
+
+const PACKAGES = packagesWithScript(TASK);
+const DERIVED = PACKAGES.map((pkg) => ({ ...pkg, outside: outOfPackageFiles(pkg) }));
+const ROOT_INPUTS = rootAnchoredInputs(TASK);
+const MATCHERS = ROOT_INPUTS.map((glob) => ({ glob, re: globToRegExp(glob) }));
+
+describe('turbo `lint` inputs cover every out-of-package file (objectui#4184)', () => {
+  /**
+   * The guard's own liveness. Every assertion below is vacuously true if the
+   * sweep found no packages or no out-of-package files — and a sweep that
+   * silently degrades to nothing is precisely the failure this file exists to
+   * make impossible.
+   */
+  it('sweeps the whole workspace and finds a non-empty out-of-package set', () => {
+    expect(PACKAGES.length).toBeGreaterThan(20);
+    const reaching = DERIVED.filter((pkg) => pkg.outside.length > 0);
+    expect(
+      reaching.map((pkg) => pkg.name),
+      'no package ESLint program reaches outside its directory — the derivation has stopped ' +
+        'working, because the repo holds exactly one flat config and it is at the root, so ' +
+        'EVERY package must reach it',
+    ).not.toHaveLength(0);
+  });
+
+  it.each(DERIVED.filter((pkg) => pkg.outside.length > 0).map((pkg) => [pkg.name, pkg] as const))(
+    '%s',
+    (_name, pkg) => {
+      const uncovered = pkg.outside.filter((file) => !MATCHERS.some(({ re }) => re.test(file)));
+      expect(
+        uncovered,
+        `${pkg.name}'s ESLint flat-config program reads ${uncovered.join(', ')} from outside ` +
+          `${rel(pkg.dir)}, and turbo hashes ${TASK} from ${JSON.stringify(ROOT_INPUTS)} plus the ` +
+          `package directory. Turbo will replay a stale verdict when ${uncovered.length === 1 ? 'that file changes' : 'those files change'}. ` +
+          `Add ${uncovered.map((file) => `"$TURBO_ROOT$/${file}"`).join(', ')} to turbo.json's ` +
+          `\`${TASK}\` inputs.`,
+      ).toEqual([]);
+    },
+  );
+
+  /**
+   * The other direction. A `$TURBO_ROOT$` entry matching nothing is not
+   * harmless: it reads as coverage, survives review, and quietly stops covering
+   * the file it was written for the moment that file is renamed.
+   */
+  it('every $TURBO_ROOT$ input matches at least one file on disk', () => {
+    const onDisk = repoFilesOnDisk();
+    for (const { glob, re } of MATCHERS) {
+      expect(
+        [...onDisk].some((file) => re.test(file)),
+        `turbo.json \`${TASK}\` input "$TURBO_ROOT$/${glob}" matches no file in the repo. It is ` +
+          `hashing nothing while reading as coverage — fix the glob or delete the entry.`,
+      ).toBe(true);
+    }
+  });
+
+  /**
+   * And the entry is not merely non-empty but actually earned: some package's
+   * program reads a file it matches. This is what keeps the list SHRINKING —
+   * when a program stops reaching out, its input entry has to go with it.
+   */
+  it('every $TURBO_ROOT$ input is required by some package program', () => {
+    const derivedFiles = [...new Set(DERIVED.flatMap((pkg) => pkg.outside))];
+    for (const { glob, re } of MATCHERS) {
+      if (INPUTS_NOT_DERIVABLE.has(glob)) continue;
+      expect(
+        derivedFiles.filter((file) => re.test(file)),
+        `turbo.json \`${TASK}\` input "$TURBO_ROOT$/${glob}" is not required by any package's ` +
+          `ESLint flat-config program any more. Delete it, or record why it cannot be derived ` +
+          `in INPUTS_NOT_DERIVABLE.`,
+      ).not.toHaveLength(0);
+    }
+  });
+
+  /**
+   * Declaring `inputs` on a task that had none is itself a behaviour change,
+   * and it can only be a SAFE one if the explicit list still contains the
+   * default it replaced. Drop `$TURBO_DEFAULT$` and the package's own source
+   * stops being hashed — which would turn a guard against stale greens into a
+   * far larger source of them.
+   */
+  it('the explicit inputs list still carries $TURBO_DEFAULT$', () => {
+    expect(
+      taskInputs(TASK),
+      `turbo.json \`${TASK}\` declares an explicit inputs list, so it no longer falls back to ` +
+        `turbo's default. Without "$TURBO_DEFAULT$" in the list the package's OWN files stop ` +
+        `being hashed.`,
+    ).toContain('$TURBO_DEFAULT$');
+  });
+
+  /**
+   * The derivation's premises, pinned against the real ESLint.
+   *
+   * ESLint 10 looks a config up from each LINTED FILE's directory upward
+   * (`findUp(FLAT_CONFIG_FILENAMES)` in `ConfigLoader.locateConfigFileToUse`),
+   * while this derivation searches once from the lint TARGET's directory. The
+   * two coincide only while the repo holds exactly one flat config, at the
+   * root. Pin that, so a package-local `eslint.config.js` goes red here and the
+   * derivation gets taught, instead of silently under-reporting the program of
+   * every package underneath it.
+   */
+  it('the repo holds exactly one flat config, at the root', () => {
+    const onDisk = [...repoFilesOnDisk()].filter((file) =>
+      FLAT_CONFIG_FILENAMES.includes(path.basename(file)),
+    );
+    expect(
+      onDisk.sort(),
+      'a second flat config exists, so ESLint 10 per-file lookup can pick a config this ' +
+        "derivation's per-target lookup never sees. Teach eslint-config-program.ts to search " +
+        'from each linted file rather than from the lint target.',
+    ).toEqual(['eslint.config.js']);
+
+    const resolved = [...new Set(DERIVED.flatMap((pkg) => configFilesFor(pkg).map(rel)))];
+    expect(resolved, 'every package must resolve that same root config').toEqual([
+      'eslint.config.js',
+    ]);
+  });
+
+  it('resolves a package with no config of its own upward to the repo-root config', () => {
+    const configless = PACKAGES.find(
+      (pkg) => !FLAT_CONFIG_FILENAMES.some((name) => fs.existsSync(path.join(pkg.dir, name))),
+    );
+    expect(configless, 'no configless package left to pin the upward walk with').toBeTruthy();
+    expect(configFilesFor(configless!).map(rel)).toEqual(['eslint.config.js']);
+  });
+
+  /**
+   * Type-aware linting would put tsconfig files into the lint program, and this
+   * derivation does not follow them — see the helper's docblock. Rather than
+   * leave that as an unstated assumption, assert it: switching on
+   * `parserOptions.project` (or `projectService`) reds here with the
+   * instruction, instead of quietly under-covering `lint`'s inputs.
+   */
+  it('no config in the lint program enables type-aware linting', () => {
+    const offenders: string[] = [];
+    for (const file of new Set(DERIVED.flatMap((pkg) => programFilesFor(pkg)))) {
+      const source = ts.createSourceFile(
+        file,
+        fs.readFileSync(file, 'utf8'),
+        ts.ScriptTarget.Latest,
+        /* setParentNodes */ true,
+      );
+      const visit = (node: ts.Node): void => {
+        if (
+          ts.isPropertyAssignment(node) &&
+          (ts.isIdentifier(node.name) || ts.isStringLiteral(node.name)) &&
+          (node.name.text === 'project' || node.name.text === 'projectService')
+        ) {
+          offenders.push(`${rel(file)}: ${node.name.text}`);
+        }
+        node.forEachChild(visit);
+      };
+      visit(source);
+    }
+    expect(
+      offenders,
+      'a config in the lint program sets `project` / `projectService`, which makes ESLint read ' +
+        'tsconfig files as part of the lint program. Teach eslint-config-program.ts to walk the ' +
+        'tsconfig chain (./helpers/tsc-program.ts already does it for `type-check` and `build`) ' +
+        'before turning this on, or those tsconfigs go unhashed exactly as eslint.config.js did.',
+    ).toEqual([]);
+  });
+});
diff --git a/scripts/__tests__/turbo-task-guard-coverage.test.ts b/scripts/__tests__/turbo-task-guard-coverage.test.ts
new file mode 100644
index 000000000..ac3af38e1
--- /dev/null
+++ b/scripts/__tests__/turbo-task-guard-coverage.test.ts
@@ -0,0 +1,97 @@
+import { describe, expect, it } from 'vitest';
+import fs from 'node:fs';
+import path from 'node:path';
+import { repoRoot } from './helpers/turbo-inputs';
+
+/**
+ * The completeness statement of the `turbo.json` inputs-guard family
+ * (objectui#3514 → objectui#4178 → objectui#4184 / objectui#4185).
+ *
+ * Four instances of one defect were found one at a time, each by someone
+ * noticing the previous one and asking "where else?". Three of the four were
+ * found that way; the fourth was found by a sweep the third asked for. That is
+ * a discovery process with a hole in it — it depends on the next reader
+ * repeating the question — and the answer to "where else" is mechanical:
+ *
+ *   a task turbo CACHES has a verdict that can be replayed, so it needs a guard
+ *   deriving what it reads; a task turbo never caches has no verdict to replay,
+ *   so it needs nothing.
+ *
+ * Turbo caches by default — a task with no `cache` key is cacheable — so the
+ * exemption has to be spelled out in `turbo.json` rather than inferred. This
+ * test enumerates the tasks and asserts the partition holds, which means the
+ * next cacheable task added to this repo cannot arrive without a guard: it goes
+ * red here, naming itself.
+ *
+ * As of this test, the partition is:
+ *
+ *     build       cached   guarded by turbo-build-inputs.test.ts       (#4185)
+ *     test        cached   guarded by turbo-test-inputs.test.ts        (#4178)
+ *     lint        cached   guarded by turbo-lint-inputs.test.ts        (#4184)
+ *     type-check  cached   guarded by turbo-type-check-inputs.test.ts  (#3514)
+ *     test:watch  cache: false, persistent   nothing to replay
+ *     clean       cache: false               nothing to replay
+ *     dev         cache: false, persistent   nothing to replay
+ */
+
+interface TurboTask {
+  readonly cache?: boolean;
+  readonly inputs?: string[];
+}
+
+const turbo = JSON.parse(fs.readFileSync(path.join(repoRoot, 'turbo.json'), 'utf8')) as {
+  tasks: Record<string, TurboTask>;
+};
+
+/** Turbo caches unless a task opts out, so a missing `cache` key means cached. */
+const CACHEABLE = Object.entries(turbo.tasks).filter(([, task]) => task.cache !== false);
+const UNCACHED = Object.entries(turbo.tasks).filter(([, task]) => task.cache === false);
+
+/** The guard each cacheable task's out-of-package reads are derived by. */
+const guardFor = (task: string): string => `turbo-${task}-inputs.test.ts`;
+
+describe('every cacheable turbo task has a derived inputs guard', () => {
+  it('finds both a cached and an uncached task, so neither branch is vacuous', () => {
+    expect(CACHEABLE.map(([name]) => name)).not.toHaveLength(0);
+    expect(UNCACHED.map(([name]) => name)).not.toHaveLength(0);
+  });
+
+  it.each(CACHEABLE.map(([name]) => [name] as const))('`%s` is guarded', (task) => {
+    const guard = path.join(repoRoot, 'scripts/__tests__', guardFor(task));
+    expect(
+      fs.existsSync(guard),
+      `turbo.json caches the \`${task}\` task, so turbo can REPLAY its verdict instead of ` +
+        `re-running it — and every file that task reads from outside the package directory is ` +
+        `invisible to the cache key unless a "$TURBO_ROOT$" input covers it. There is no ` +
+        `scripts/__tests__/${guardFor(task)} deriving what \`${task}\` reads. Write one (the ` +
+        `four existing guards share ./helpers/turbo-inputs.ts and ./helpers/config-program.ts), ` +
+        `or set "cache": false on the task if it should never be cached.`,
+    ).toBe(true);
+  });
+
+  it.each(CACHEABLE.map(([name, task]) => [name, task] as const))(
+    '`%s` declares explicit inputs',
+    (name, task) => {
+      expect(
+        task.inputs ?? [],
+        `turbo.json \`${name}\` declares no \`inputs\`, so it runs on turbo's default — which ` +
+          `covers only files inside the package directory. That is the objectui#3514 defect ` +
+          `itself: the task's out-of-package program files are unhashed and its verdict gets ` +
+          `replayed. Declare an inputs list starting with "$TURBO_DEFAULT$".`,
+      ).toContain('$TURBO_DEFAULT$');
+    },
+  );
+
+  /**
+   * The other half of the partition. An uncached task is exempt because there
+   * is no stored verdict to replay — not because nobody got round to it. If a
+   * task ever loses its `cache: false`, the assertion above starts requiring a
+   * guard for it, which is the intended coupling.
+   */
+  it.each(UNCACHED.map(([name, task]) => [name, task] as const))(
+    '`%s` is exempt because turbo never caches it',
+    (_name, task) => {
+      expect(task.cache).toBe(false);
+    },
+  );
+});
diff --git a/scripts/__tests__/turbo-type-check-inputs.test.ts b/scripts/__tests__/turbo-type-check-inputs.test.ts
index df85aec6d..6bbf64c67 100644
--- a/scripts/__tests__/turbo-type-check-inputs.test.ts
+++ b/scripts/__tests__/turbo-type-check-inputs.test.ts
@@ -1,7 +1,4 @@
 import { describe, expect, it } from 'vitest';
-import fs from 'node:fs';
-import path from 'node:path';
-import ts from 'typescript';
 import {
   globToRegExp,
   packagesWithScript,
@@ -9,6 +6,7 @@ import {
   repoFilesOnDisk,
   rootAnchoredInputs,
 } from './helpers/turbo-inputs';
+import { outOfPackageFiles } from './helpers/tsc-program';
 
 /**
  * objectui#3514 — turbo's `type-check` `inputs` list is hand-maintained, and it
@@ -70,11 +68,19 @@ import {
  * The turbo-side plumbing this file used to carry inline — workspace discovery,
  * reading `$TURBO_ROOT$` entries out of `turbo.json`, and matching an input
  * glob — now lives in `./helpers/turbo-inputs.ts`, shared with the sibling
- * guard `turbo-test-inputs.test.ts` (objectui#4178, the same defect on the
- * `test` task). Only the DERIVATION differs between the two, and it differs in
- * kind: tsc programs here, Vitest configuration programs there. Two copies of a
- * glob matcher whose whole doctrine is "never approximate toward a match" is
- * exactly the drift neither guard would survive.
+ * guards `turbo-test-inputs.test.ts` (objectui#4178), `turbo-lint-inputs.test.ts`
+ * (objectui#4184) and `turbo-build-inputs.test.ts` (objectui#4185) — the same
+ * defect on the `test`, `lint` and `build` tasks. Only the DERIVATION differs
+ * between them, and it differs in kind: tsc programs here, Vitest configuration
+ * programs there, an ESLint flat-config program for `lint`, and a union of all
+ * of those for `build`. Two copies of a glob matcher whose whole doctrine is
+ * "never approximate toward a match" is exactly the drift none of them would
+ * survive.
+ *
+ * The tsc derivation itself moved out for the same reason when `build` came to
+ * need it: it is `./helpers/tsc-program.ts` now, and that module's docblock
+ * carries the mechanism and its narrowings. This file carries only the policy
+ * over the result.
  */
 
 /** The turbo task this guard is about. */
@@ -91,110 +97,6 @@ const TASK = 'type-check';
  */
 const INPUTS_NOT_DERIVABLE: ReadonlyMap<string, string> = new Map();
 
-// ── The type-check program, as the scripts actually drive it ─────────────────
-
-interface TscInvocation {
-  /** Absolute path of the tsconfig this segment compiles. */
-  readonly project: string;
-  /** `tsc -b` / `--build`, which also compiles the project's references. */
-  readonly build: boolean;
-}
-
-/**
- * The tsc projects a package's `type-check` script drives.
- *
- * Every shape in the repo today is a `&&` chain of `tsc` calls: a bare
- * `tsc --noEmit` (the package's own `tsconfig.json`), `tsc -p <config>` for the
- * `tsconfig.test.json` / `tsconfig.typetests.json` companions, and
- * `apps/console`'s `tsc -b tsconfig.node.json --force`. A segment that runs tsc
- * in a shape this parser cannot read throws rather than being skipped: an
- * unparsed segment is an unswept program.
- */
-function invocationsFor(pkgDir: string, script: string): TscInvocation[] {
-  const invocations: TscInvocation[] = [];
-  for (const segment of script.split('&&')) {
-    const command = segment.trim();
-    if (!/(?:^|\s)tsc(?:\s|$)/.test(command)) continue;
-
-    const build = /(?:^|\s)(?:-b|--build)(?:\s|$)/.test(command);
-    const named = command.match(/(?:^|\s)(?:-p|--project|-b|--build)\s+([^\s]+)/);
-    if (build && !named) {
-      throw new Error(
-        `${rel(pkgDir)}: \`${command}\` builds without naming a project. Teach ` +
-          `invocationsFor() how to resolve it.`,
-      );
-    }
-    const project = path.resolve(pkgDir, named ? named[1] : 'tsconfig.json');
-    if (!fs.existsSync(project)) {
-      throw new Error(`${rel(pkgDir)}: \`${command}\` drives ${rel(project)}, which does not exist.`);
-    }
-    invocations.push({ project, build });
-  }
-  return invocations;
-}
-
-/**
- * A tsconfig parsed the way `tsc` parses it, so `fileNames` is the real program
- * root set rather than a re-implementation of TypeScript's glob semantics.
- *
- * `readJsonConfigFile` (not `readConfigFile`) is what makes `extendedSourceFiles`
- * available — the `extends` chain, which is the half of "the program" that a
- * file-list-only reading misses.
- */
-function parseProject(configPath: string): { parsed: ts.ParsedCommandLine; extended: string[] } {
-  const sourceFile = ts.readJsonConfigFile(configPath, ts.sys.readFile);
-  const parsed = ts.parseJsonSourceFileConfigFileContent(
-    sourceFile,
-    ts.sys,
-    path.dirname(configPath),
-    undefined,
-    configPath,
-  );
-  const fatal = parsed.errors.find((e) => e.category === ts.DiagnosticCategory.Error);
-  expect(
-    fatal && `${rel(configPath)}: ${ts.flattenDiagnosticMessageText(fatal.messageText, ' ')}`,
-    `${rel(configPath)} must parse as a tsconfig`,
-  ).toBeFalsy();
-  return { parsed, extended: sourceFile.extendedSourceFiles ?? [] };
-}
-
-/**
- * Every file a package's type-check program reads from outside the package
- * directory, repo-relative and sorted.
- */
-function outOfPackageFiles(pkgDir: string, script: string): string[] {
-  const found = new Set<string>();
-  const seen = new Set<string>();
-  const queue = invocationsFor(pkgDir, script);
-
-  while (queue.length > 0) {
-    const { project, build } = queue.shift()!;
-    if (seen.has(project)) continue;
-    seen.add(project);
-
-    const { parsed, extended } = parseProject(project);
-    // The config file itself belongs to the program too — a referenced or
-    // extended config living outside the package is exactly as load-bearing as
-    // a source file, and just as invisible to `$TURBO_DEFAULT$`.
-    for (const file of [project, ...extended, ...parsed.fileNames]) {
-      if (path.relative(pkgDir, file).startsWith('..')) found.add(rel(file));
-    }
-
-    // `tsc -b` compiles referenced projects as well; `tsc -p` does not.
-    if (build) {
-      for (const reference of parsed.projectReferences ?? []) {
-        const target = reference.path.endsWith('.json')
-          ? reference.path
-          : path.join(reference.path, 'tsconfig.json');
-        queue.push({ project: target, build: true });
-      }
-    }
-  }
-  return [...found].sort();
-}
-
-// ── turbo.json inputs ────────────────────────────────────────────────────────
-
 // ── The derivation, computed once ────────────────────────────────────────────
 
 const PACKAGES = packagesWithScript(TASK);
diff --git a/turbo.json b/turbo.json
index eceefbe0c..6930a4726 100644
--- a/turbo.json
+++ b/turbo.json
@@ -11,7 +11,13 @@
         "**/*.tsbuildinfo",
         "!**/node_modules/**"
       ],
-      "env": ["NODE_ENV", "VITE_BASE_PATH", "OBJECTSTACK_CLIENT_DIST"]
+      "env": ["NODE_ENV", "VITE_BASE_PATH", "OBJECTSTACK_CLIENT_DIST"],
+      "inputs": [
+        "$TURBO_DEFAULT$",
+        "$TURBO_ROOT$/tsconfig.json",
+        "$TURBO_ROOT$/tsconfig.base.json",
+        "$TURBO_ROOT$/scripts/vite-*.ts"
+      ]
     },
     "test": {
       "dependsOn": ["^build"],
@@ -42,7 +48,12 @@
     },
     "lint": {
       "outputs": [],
-      "cache": true
+      "cache": true,
+      "inputs": [
+        "$TURBO_DEFAULT$",
+        "$TURBO_ROOT$/eslint.config.js",
+        "$TURBO_ROOT$/eslint-rules/*.js"
+      ]
     },
     "type-check": {
       "dependsOn": ["^build"],

From cf72cbbd52d57e8a1f5975c46c0525e029825a3f Mon Sep 17 00:00:00 2001
From: Claude <noreply@anthropic.com>
Date: Mon, 10 Aug 2026 20:22:22 +0000
Subject: [PATCH 2/2] ci(turbo): record the postcss-config blind spot in the
 build derivation (#4185)

The repo-root postcss.config.mjs is outside every build program today only
because two facts coincide, not by construction. Written down where the
derivation's other narrowings live, so the next reader does not have to
re-measure it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017Qqyix2QcnpUC9XeYVDzx3
---
 scripts/__tests__/helpers/build-program.ts | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/scripts/__tests__/helpers/build-program.ts b/scripts/__tests__/helpers/build-program.ts
index 52f904798..9196489da 100644
--- a/scripts/__tests__/helpers/build-program.ts
+++ b/scripts/__tests__/helpers/build-program.ts
@@ -57,6 +57,24 @@ import { rel, repoRoot, type WorkspacePackage } from './turbo-inputs';
  *    `$TURBO_ROOT$/tsconfig.json` is earned many times over by the 14 packages
  *    whose build IS a tsc run. The narrowing changes which packages the guard
  *    NAMES, not which files the task hashes.
+ *  - POSTCSS CONFIG DISCOVERY IS NOT MODELLED, and this one is a KNOWN BLIND
+ *    SPOT rather than a safe narrowing, so it is written down here and filed
+ *    rather than left for the next reader to rediscover. Vite hands CSS to
+ *    `postcss-load-config`, which searches UPWARD from the Vite root — so a
+ *    package that processes CSS through Vite and has no `postcss.config.*` of
+ *    its own would read the repo-root `postcss.config.mjs`, outside its
+ *    directory and unhashed. Measured: no package does BOTH today. Every
+ *    vite-build package that processes CSS (`apps/console`, `packages/components`,
+ *    `packages/runner`, the two console examples) carries its own postcss
+ *    config, which stops the upward walk; `packages/fields` is the only one
+ *    without a config, and its single `src/index.css` never enters the Vite
+ *    graph — nothing imports it, because `scripts/build-css.mjs` compiles it
+ *    separately with an explicit plugin list. So the root config is genuinely
+ *    outside every build program right now, which is why no input entry is
+ *    owed for it. But that is a COINCIDENCE of two facts, not a structural
+ *    guarantee: adding one `import './index.css'` to `packages/fields/src`
+ *    would pull the root postcss config into the build program, turbo would not
+ *    hash it, and this guard would not notice.
  *  - NO FILE-VALUED OPTIONS. Unlike a Vitest config, nothing in this repo's
  *    build configs names a program file through a string literal: entries are
  *    spelled `resolve(__dirname, 'src/index.tsx')`, which is an expression, and