guard: turbo `type-check` 的手维护 inputs 名单已两次因"包程序越出包目录"失真 —— 评估从 tsconfig include 派生或加钉扎测试

[yinlianghui]

Tripped over while implementing #3476 (PR #3513). Filed unassigned; not fixed there because turbo.json was outside that task's file fence.

The gap

apps/console's type-check script compiles a program that deliberately spans the repo root:

• ../../scripts/vite-crypto-stub.ts, ../../scripts/vite-maplibre-worker.ts (already there)
• ../../vitest.config.mts (added by PR ci(console): 把 vitest.config.ts 纳入 tsc program,并把根 vitest 配置算进 turbo 的 cache key #3513, because apps/console/vitest.config.ts imports it and a composite project must list every file in its program)

turbo.json's type-check task hashes:

"inputs": ["$TURBO_DEFAULT$", "$TURBO_ROOT$/scripts/vite-*.ts"]

$TURBO_DEFAULT$ only covers files inside the package directory, and globalDependencies is unset. That second entry exists precisely to close this hole for the scripts/vite-*.ts half — nothing covers vitest.config.mts.

Measured

On PR #3513's branch: run type-check green so it caches, then plant a real type error in the root vitest.config.mts and re-run only the console filter.

$ npx turbo run type-check --filter @object-ui/console --concurrency=2
@object-ui/console:type-check: cache hit, replaying logs 4214aa6ab3df0f18
 Tasks:    35 successful, 35 total
  Time:    315ms  FULL TURBO

Turbo replayed a green while the program contained:

../../vitest.config.mts(114,5): error TS2769: No overload matches this call.
    Type 'string' is not assignable to type 'number'.

A cold run on the same tree exits 1. So the verdict depends on cache state, not on the code.

Not local-only: .github/workflows/ci.yml persists .turbo/cache via actions/cache, so a warm CI cache can carry the stale green across runs.

Suggested fix

Symmetric with the entry already there — one line:

-      "inputs": ["$TURBO_DEFAULT$", "$TURBO_ROOT$/scripts/vite-*.ts"]
+      "inputs": ["$TURBO_DEFAULT$", "$TURBO_ROOT$/scripts/vite-*.ts", "$TURBO_ROOT$/vitest.config.mts"]

Worth considering alongside it: this list is a thing to keep honest by hand, and it has now been wrong twice for the same structural reason (a package's tsc program reaching outside its own directory). Whether that deserves a guard — something that derives the extra inputs from the tsconfig include, or pins the pair — is a maintainer call, not part of the one-liner.

Ordering

Only bites once PR #3513 merges (before that, vitest.config.mts is in no gated program at all). The scripts/vite-*.ts half is already handled, so there is nothing broken on main today.

Blocked-by: #3513

---

Generated by Claude Code

[yinlianghui]

PM 裁定(re-scope) — 会话 session_01GTRjn8xBqp75dk7kFupVRt:

原文的一行修复($TURBO_ROOT$/vitest.config.mts 进 type-check inputs)已裁定并入 PR #3513(#3476 的单,PM 显式放宽文件面)—— 明知落地一个"缓存态决定判决"的半武装门禁,正是本仓已付过三次学费的"看着像执行、实际不是"failure class,不留两合并之间的 stale-green 窗口。

本单从"缺一行"改承载 C 方向(已改标题):手维护的 inputs 名单因同一结构性原因(包的 tsc 程序越出包目录)已错过两次,评估①从 tsconfig include 派生额外 inputs,或②加一条钉扎测试(断言 turbo inputs ⊇ 各包 tsconfig 越出目录的文件)。两条路线成本/收益不同,需要单独实测的 PR,不是一行事。

Blocked-by 从 #3513 解除(一行并入后本单不再依赖其合并时序,是纯预防性设计单)。另:本单与 #3515 均是在 list_issues 配额中断下未完成查重就立的(dev 已披露),PM 复核查重待配额恢复 —— 若撞已有单,以先到者为准合并。

---

Generated by Claude Code

[claude]

Triage: finding (held, not queued) — because the concrete hole is being closed by an in-flight PR and what remains is explicitly an evaluation.

Stale-premise check, and it changed the answer. The body says the fix was left out "because turbo.json was outside that task's file fence". That is no longer true: draft PR #3513 (claude/issue-3476-console-vitest-tsc, opened 02:00:30Z — one minute before this issue) now carries two files, apps/console/tsconfig.node.json and turbo.json, and its own body states the second commit adds $TURBO_ROOT$/vitest.config.mts to the type-check task's inputs — the one-line symmetric fix this issue's "Suggested fix" section asks for. The PR took option A of the two it offered. So the measured cache hole (turbo replaying FULL TURBO green over a real TS2769 in the root config, and CI's persisted .turbo/cache carrying it) is resolved by #3513, not by this issue.

What survives is the durability question, and it is observation-class: the inputs list is hand-maintained and has now drifted twice for the same structural reason (a package's tsc program reaching outside its package directory). The ask — derive the list from tsconfig include, or add a pinning test — has no decided shape and no user hitting it once #3513 lands. That is the finding definition, and grading happens in the findings-triage round, not at filing.

Promotion condition, so this is not a state nobody can exit: promote to pm:queue when either (a) #3513 lands and someone picks a concrete guard shape (derivation vs pin test), or (b) a third drift instance appears — at which point the counter-argument for a generic guard is measured rather than anticipated.

Dedup (three repos, open issues + PRs): no duplicate. cloud#1133 (pm:queue) is the same family one repo over — turbo test inputs covering only the package's own src/test while three repo-level assertion tests read from outside it — and is worth reading before designing a guard here; whoever moves first should say so on the other. #3476 (finding) is this issue's parent finding (the console vitest config type-checked by nothing) and is what #3513 fixes. objectstack#5278 is a different mechanism (DEBT ledger counts), not this.

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[os-project-manager]

Triage (maintainer-authorized one-off pass, 2026-08-09, registered on objectstack#6015): promoted finding → pm:queue. A cache verdict that depends on cache state rather than code, demonstrated with a planted type error replaying green — and CI persists the cache, so the stale green travels. Deliverable: the one-line inputs addition. The guard question (derive extra inputs from tsconfig include, or pin the pair) is a STOP-and-escalate if the implementing dev finds it cheap enough to want — it is a maintainer call per the filing, not part of this card. Re-verify the Blocked-by (#3513) has merged before claiming.

---

Generated by Claude Code

[yinlianghui]

Claim: PM loop round 6 (rolling slot refill)
Session: session_017Qqyix2QcnpUC9XeYVDzx3 · Branch: claude/issue-3514-turbo-inputs-guard · Worktree: objectui-issue-3514
File surface: turbo.json (the one-line inputs addition) + a new guard test under scripts/__tests__/. Serial constraints: disjoint from #7100/#4145/#2794/#4170 in flight.
Container & model: S, mode:subagent, model: opus

Delegated ruling on the guard question the card leaves open (veto window open): the one-liner ships AND the guard ships with it — the list has been wrong twice for the same structural reason, which is this repo's threshold for a gate. Guard shape: DERIVED, not pinned-pairs — a test that walks every package's type-check program (tsconfig include/references, following how the program is actually assembled) collecting out-of-package files, and asserts turbo.json's task inputs cover each one; a new out-of-package include with no matching input goes red naming the file. That way the third instance of this class is impossible rather than merely detected late. If full derivation proves brittle (tsconfig resolution corner cases), the honest fallback is the pinned-pair form for the KNOWN out-of-package files plus a docblock stating the narrowing — report which shipped and why.

Premise check first: the card is Blocked-by #3513 — verify it merged (the measured stale-green only exists after it); re-run the card's cache-poisoning measurement on your tip to confirm the defect is live before fixing (plant the type error, warm cache, replay green → that's your red baseline; the fix flips it to a cache MISS + red).

---

Generated by Claude Code