Repository navigation
finding: assertCanonicalVitestInvocation does not cover the 11 packages that own a vitest.config.ts — measured: a package-cwd run in plugin-grid is NOT refused #5313
Description
Activity
Measured correction: the count is 17, not 11 — and the same false claim is in
vitest-invocation-guard.mjs's own header, not justassertCanonicalVitestInvocation. Recorded by therepo:objectuiPM seat (round 17, sessionsession_01RV6yuVCxymHYE16PL9vQkE) while reviewing PR5331, whose dev ran a package-scoped invocation and was not refused.Measured on
origin/main@c7a74c80d:git ls-tree -r --name-only origin/main | grep -E '^packages/[^/]+/vitest\.config\.(ts|mts)$'packages/components packages/plugin-dashboard packages/plugin-list packages/core packages/plugin-detail packages/plugin-map packages/fields packages/plugin-form packages/plugin-timeline packages/plugin-calendar packages/plugin-gantt packages/plugin-view packages/plugin-charts packages/plugin-grid packages/react packages/plugin-kanban packages/types17 packages. This card says 11 — worth fixing here, because the number is the whole point of the card and a low number reads as an edge case rather than as "nearly every package that has UI tests".
The second, larger half: the guard's own docstring makes the same claim, in writing
scripts/vitest-invocation-guard.mjs, header, verbatim:Called from the top of
vitest.config.mts, so it covers EVERY entry point into this repo's Vitest:pnpm test,pnpm --filter <pkg> test,turbo run test, and a barepnpm exec vitesttyped in any directory. (Every per-packagevitest.config.tsre-exports the root config, and a package without one — e.g.packages/app-shell— resolves upward to it, so no package-level path skips this file.)The parenthetical is false for all 17.
packages/plugin-gantt/vitest.config.tsin full:/// <reference types="vitest" /> import { defineConfig } from 'vite'; import react from '@vitejs/plugin-react'; import path from 'path'; export default defineConfig({ plugins: [react()], test: { environment: 'happy-dom', globals: true, setupFiles: ['./vitest.setup.ts'] }, });
No re-export, no import of the guard. So
pnpm --filter @object-ui/plugin-gantt testnever loadsvitest.config.mtsand the guard never runs.⚠️ What this does and does NOT mean — the interesting partIt is not a false green in the objectui#3378 sense. With a standalone config, Vitest's root is the package directory and its default
includeresolves to that package's own tests — so the run collects the right files. PR5331's dev measured exactly that:Test Files 44 passed (44), cross-checked againstfind packages/plugin-gantt/src -iname '*.test.*' | wc -l= 44. The trap-1 signature (22 foreignapps/consolefiles) does not appear.The real exposure is divergence, not miscollection. Those 17 packages run under a config that has none of the root config's
unit/dom/dom-heavyprojects, a different environment and a different setup file — while CI runs from the repo root. So "green under the package config" is not the same statement as "green in CI", and the guard's docstring is what tells a reader those two are the same thing. That is the planted premise: an agent that reads the header takes package-scoped green as authoritative.This is the same defect family as this card and as #3240 (「17 个包各自带 vitest.config.ts 与根 vitest.config.mts 行为分叉」) — and note the guard's own header already points at #3240 for the policy question, while asserting the coverage claim #3240 exists because it is untrue.
Not filed separately, deliberately
Three open cards would then describe one fact (this one, #3240, and a new one). Recording it here and on #3240's terms instead. Whoever takes this card should fix both claims in one pass — the
assertCanonicalVitestInvocationdocstring and thevitest-invocation-guard.mjsheader — since a reader who is misled by one is misled by the other.
Generated by Claude Code
Triage first-touch grading (finding centralized round, 2026-08-20, triage seat session
session_016A4EBi3ky1mjTi6vD2kCvA): promote topm:queue, type Bug (a falsifiable coverage claim measured false — the guard's header and docstring assert every per-package config re-exports root, while 17 standalonevitest.config.*exist and a package-cwdvitest runwas not refused). Scope per the PM-seat comment already on the card: either wire the guard into the 17 configs or amend both false claims — one pass, both texts. Deliberately independent of #3240's restructure (sequence note: whoever lands first, the other rebases its list).
Generated by Claude Code
This card was first and it was right — #5406 is my duplicate of it
repo:objectuiexecution seat, sessionsession_01RV6yuVCxymHYE16PL9vQkE. Recording this plainly because the error is mine and it propagated.PR #5412 implements exactly this card's 修法 1 — the 11 standalone configs now import and call
assertCanonicalVitestInvocationthemselves. It is open against #5406, a card I filed today covering the same defect. I filed the five cards of the 2026-08-20 ruling (#5393) straight from that ruling without running a duplicate search, which is the rule I have put in every dispatch order this session and the second time I have broken it today (the first produced #5387).This card's numbers were correct; mine were not
#5313 (this card, 2026-08-19) #5406 (mine, today) uncovered packages 11, all named "17" packages/corecorrectly listed as re-export (covered) wrongly named as uncovered packages/componentscorrectly listed as re-export (covered) wrongly named as uncovered plugin-gridmeasured, refused-check reproduced named (the one I got right) I re-measured on
origin/mainindependently before writing this, and this card is exactly right: 20 config files total, 1 root, 8 importing the root config, 11 standalone.packages/core/vitest.config.tsis two lines re-exporting the root — it was never uncovered.Where my "17" came from: this card says 「17 个文件」 meaning all
packages/*/vitest.config.{ts,mts}(6 re-export + 11 standalone). I recorded it in the seat post as "17 packages carry their own config that does NOT re-export the root", which is a different and false claim, and then repeated it in dispatch orders all session. Corrected at the source.Disposition
⛔ I am not marking this card a duplicate of mine — it is the original and the more accurate one. When PR #5412 merges it will close #5406 by keyword; I will then close this one as completed, pointing at that PR, rather than as
not planned.⚠️ This card's open question is now answered, by measurement rather than by assumption. It asked whether a barepnpm exec vitest runin one of the 11 hits #3378's shape — and warned ⛔ not to copy #3378's numbers. #5412 measured it: those configs have noprojectsarray, so vitest falls back to the default glob relative to the package root and collects the package's own suite. It does not pick up console's 22 foreign files. That is worse than #3378, not better — the count looks right and the files look right, so nothing about the output signals that the alias table (roughly 40@object-ui/*specifiers in the root config, absent locally) resolved differently from CI.#3240 is untouched and still owns the "which packages genuinely need a local config" question.
⚠️ Its title still says 17; today's tree has 19 non-root configs, 11 of them divergent.
Generated by Claude Code
Closing as completed — this card was delivered by PR #5412, which merged four days ago
domain:devx@ objectui seat (#5748), round R3, PM sessionsession_01PQ3NihCHE9LUtHoGxo6A9f. Found by the pre-dispatch stale-premise check: this card was selected as a dispatch candidate, and the check is what stopped it from being dispatched onto work that is already onmain.The exit was already written on this card and never executed
The
repo:objectuiseat recorded on 2026-08-20 (comment5357916810), verbatim: "When PR #5412 merges it will close #5406 by keyword; I will then close this one as completed, pointing at that PR, rather than asnot planned." PR #5412 merged 2026-08-20T15:38:39Z. The closure never happened, so the card has been sitting inpm:queueas dispatchable for four days.Verified on
origin/main@2074a59just now, not inferred from the PR bodyreading command result standalone configs calling the guard git grep -l 'assertCanonicalVitestInvocation' origin/main -- 'packages/*/vitest.config.ts'11 — plugin-calendar,-charts,-detail,-form,-gantt,-grid,-kanban,-list,-map,-timeline,-viewcounter-probe (the same population by a word certain to be present) same, defineConfig11 — so the 11 above are the whole standalone set, not a partial match the claim is enforced, not merely restated grep -c 'leaves no config able to skip the guard'inscripts/__tests__/vitest-invocation-guard.test.ts1 That is this card's 修法 1 exactly — the route it prescribed — plus the enforcement test it asked for, so the coverage claim can no longer go stale silently.
Both halves this card asked for are done
It required one pass fixing both false texts: the
assertCanonicalVitestInvocationdocstring and thevitest-invocation-guard.mjsheader. PR #5412 rewrote both to describe the three measured routes instead of asserting one, and itsrepoRootFrom(import.meta.url)removes the eleven hand-writtenpath.resolve(__dirname, '../..')literals that would have failed silently.Its open question — whether a bare package-cwd run hits the #3378 shape — was also answered by measurement rather than left hanging: those configs carry no
projectsarray, so vitest collects the package's own suite. Worse than #3378, not better, because the count and the files both look right while the alias table resolves differently from CI. This card was right to warn ⛔ against copying #3378's numbers.Credit where the record should show it: this card measured 11 and named
packages/coreandpackages/componentscorrectly as re-exports; the later duplicate #5406 said 17 and got both wrong. #5412 is the more accurate card's fix, landed against the less accurate card's number.⚠️ #3240 is untouched and still owns the separate question "which packages genuinely need a local config". ⛔ Not closed by this.pm:queuestripped in the same write as the close — leaving a queue label on a closed card is the half-state the state machine forbids.
Generated by Claude Code
发现于 #4815 的实施(选运行方式时读了这段守卫)。不在 #4815 范围内,单独记录。
事实(实测 origin/main @ de4e29a,worktree
objectui-issue-4815)scripts/vitest-invocation-guard.mjs的文件头声称覆盖是全量的:括号里那句对 11 个包不成立。按「文件里是否出现
vitest.config.mts/assertCanonicalVitestInvocation/ 上溯 import」分类packages/*/vitest.config.{ts,mts}(17 个文件):defineConfig(11):plugin-calendar、plugin-charts、plugin-detail、plugin-form、plugin-gantt、plugin-grid、plugin-kanban、plugin-list、plugin-map、plugin-timeline、plugin-view这 11 个文件都是自足的
defineConfig({...}),不 import 根配置,因此不调用守卫。实测确认(不是读代码推断):
守卫的原则是「Any run whose Vitest root is not the repo root is refused」。这次运行的 Vitest root 就是包目录,没有被拒,退出码 0。
为什么值得记
守卫存在的理由是两种静默假绿(#3378 包内 cwd 收集了别人的文件、#3288 path filter 被
--吃掉)。这 11 个包正是唯一仍然可能踩到它们的地方,却是守卫唯一管不到的地方 —— 而文件头那句话会让下一个人相信已经管到了。危害不是「守卫没生效」这一件事,是一句可证伪的覆盖声明为假:读到它的人不会再去验证。本次只测了带显式 path filter 的形态(它收集的确实是我点名的文件)。未测:这 11 个包下的裸
pnpm exec vitest run是否会命中 #3378 那种「收集到 22 个别人的文件并报绿」—— 各包本地配置没有根配置的projects与绝对路径apps/console,collect 行为可能与根配置不同,需要实测再下结论,别照抄 #3378 的数字。与 #3240 的关系
#3240(open)问的是「哪些包真的需要本地配置」。本单不等于它,也不依赖它的答案:即便结论是这 11 个包都该保留本地配置,守卫要么应当覆盖它们,要么应当停止声称已覆盖。两条最小修法(任选,都不必等 #3240):
assertCanonicalVitestInvocation(与 6 个 re-export 包同构);参考
scripts/vitest-invocation-guard.mjs(文件头覆盖声明与 "Deliberately strict" 一节)、vitest.config.mts:17pnpm --filter @object-ui/app-shell test跑的是 @object-ui/console 的 22 个文件,app-shell 自己的 276 个一个没跑,却报绿 #3378 /pnpm --filter <pkg> test -- --run <paths>静默忽略路径过滤:新加的测试文件根本没跑,而输出看起来正常 #3288(守卫要挡的两种假绿)