[objectstack-fleet]

Requested by Tesla · project thread

Fixes #25855
Part of #25677 (cutover aftercare, bill item 49).

Clause-②: no
Metadata-protocol: none

What was red

Type Check UI on PR B #25827 head f973a4f3fd (run 40245604632, job 121326496328): the step "Run type-check over the ui packages" took 0 s — its turbo run type-check --filter=...[base] affected scope was empty, so no task ran and nothing under ui/packages/*/dist was built. The next step, pnpm --dir ui run type-check:vitest-setup, then failed: ui/tsconfig.vitest-setup.json maps @object-ui/components, @object-ui/fields, @object-ui/plugin-dashboard, @object-ui/plugin-grid to their package directories and @object-ui/i18n/* to packages/i18n/dist/*, and all of them resolve through built declarations.

The same job is green on a diff that changes ui packages (#25852 head 6015709368, run 40248884869), because there the type-check step's ^build built them first. The red follows the diff, not the tree.

The fix

One step in ci.yml type-check-ui, directly before the vitest-setup step:

- name: Build the ui packages the vitest setup files import
  run: |
    pnpm exec turbo run build --concurrency=4 \
      --filter=@object-ui/components --filter=@object-ui/fields \
      --filter=@object-ui/plugin-dashboard --filter=@object-ui/plugin-grid \
      --filter=@object-ui/i18n

Turbo's build task dependsOn: ["^build"], so their dependencies build too. The step is unconditional. When the type-check step (or main's turbo cache, which the job already restores) has built these packages, turbo replays them from cache.

The job's if: is unchanged, and no step is skipped.

Why not resolve from source instead. The card asked for both routes to be measured. ui/tsconfig.vitest-setup.json's own paths comment already records the measurement: mapping the four packages to src/ gives 484 errors across 318 foreign source files, and mirroring the full 42-entry alias map still leaves 30 errors, 24 of them noImplicitAny residue inside packages/components/src. Fixing that route would mean turning noImplicitAny off for the four files this program exists to check. So the build route is the only one that can be green, and it costs no wall-clock on a cache hit.

Cost

Durations of the Type Check UI job, before this change:

run	shape	job	type-check step	vitest-setup step
40245604632 (PR B)	empty ui scope	7m22s, red	0 s	2 s, red
40248884869 (#25852)	ui scripts changed	12m20s, green	7m43s	4 s
40247794069 (main push 90a34e2)	full scope, cache hit	3m30s, green	1 s	5 s

After this change: this PR's own run (an empty ui scope by construction) gives the number. It goes into the os-dev report on #25855 once the run completes.

Verification

• Proof run: this PR. It changes no ui/ package, so Type Check UI green here is the fix.
• Local derived gates (node scripts/pm/dispatch-gates.mjs --commands, 56 commands): results are in the os-dev report on ci(ui-merge): Type Check UI is red on every PR whose ui affected-scope is empty — type-check:vitest-setup compiles against unbuilt @object-ui/* dists after turbo built nothing (bill item 49) #25855.

维护者速读(草稿)

• 改了什么:ci.yml 的 Type Check UI 任务里，在 vitest setup 类型检查之前加了一步，用 turbo 构建它依赖的五个 @object-ui 包。
• 为什么改:PR 如果没改 ui/ 包，上一步什么都不构建，这一步就会因为找不到这五个包的类型声明而变红。这个红跟 PR 内容无关，所以 Type Check UI 一直没法加进必需检查。
• 风险与代价(含回滚):有缓存时这一步只是回放，几乎不花时间。没缓存时要多构建五个包和它们的依赖。回滚就是删掉这一步。
• 席位意见:
• 你要做的:批准这个 PR。合并后，在仓库设置里把 Type Check UI 加进必需检查。

---

Generated by Claude Code

[objectstack-fleet]

Test UI (9/16) is red on this PR, and the cause is on main, not in this diff. This PR changes only the root .github/workflows/ci.yml type-check-ui job. The failing test is ui/scripts/__tests__/workflow-cache-save-bound.test.ts: it asserts that ui/.github/workflows/changeset-release.yml defines release: and lane: jobs, and #25745 (2a61f08) deleted that file.

The same shard is red on main: push run 40247794069 (90a34e2) and schedule run 40247421544 (2a61f08) both fail Test UI 3/16, 8/16 and 9/16.

• 3/16 is ui/packages/cli/src/__tests__/app-generator.test.ts (ENOENT on ui/.changeset/config.json). fix(ui-merge): two tests that #25745 broke on main read the merged tree — the Changesets config through changesetConfigPath(), the SDUI html tier by its tags (#25711) #25852 fixes it.
• 8/16 is ui/scripts/__tests__/ci-cd-pipeline-doc.test.ts (ENOENT on ui/.github/workflows/changeset-release.yml).
• 9/16 is the test above.

No open PR fixes 8/16 or 9/16 yet. #25852's own run (6015709) is still red on both. I'm reporting them to the epic PM for a card. They are out of this card's scope, so this PR does not widen to cover them. Test UI is not in the required set. I'm not re-running the job, because the red reproduces deterministically on main.

---

Generated by Claude Code

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 40252576788 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

分类：failure —— 按下面的日志分诊。

失败的 job（日志抽取，best effort）：

• Test UI (9/16) — 失败步骤: Run the ui tests (shard 9/16)

  × bounds the three jobs objectui#7270 found running under the 360-minute default 7ms
  × bounds the four jobs objectui#7956 derived a ceiling for 1ms
  FAIL   unit  scripts/__tests__/workflow-cache-save-bound.test.ts > every workflow cache save is bounded and non-fatal (objectui#7048) > bounds the three jobs objectui#7270 found running under the 360-
    ↳ 失败原因: AssertionError: changeset-release.yml must still define a `release:` job: expected undefined to be defined
  FAIL   unit  scripts/__tests__/workflow-cache-save-bound.test.ts > every workflow cache save is bounded and non-fatal (objectui#7048) > bounds the four jobs objectui#7956 derived a ceiling for
    ↳ 失败原因: AssertionError: changeset-release.yml must still define a `lane:` job: expected undefined to be defined
  

• Test UI (8/16) — 失败步骤: Run the ui tests (shard 8/16)

  × gives every workflow in .github/workflows/ a row in the inventory table — in both directions 23ms
  × never names a workflow file that does not exist 17ms
  × documents every job these four workflows define 2ms
  × names every first-party command the four jobs actually run 2ms
  × names no command outside the declared non-`run:` set 2ms
  × reads one section per workflow — a shrunken enumeration is a broken reader 3ms
  × finds commands on both sides — a silent parser would make every pin below vacuous 10ms
  × names every first-party command every workflow job actually runs 7ms
  × declares every command a section names that its workflow does not run 3ms
  × finds no pre-install gate reaching a package 7ms
  FAIL   unit  scripts/__tests__/check-pre-install-import-graph.test.ts > the real tree — every step objectui#6148 measured is still derived > finds no pre-install gate reaching a package
    ↳ 失败原因: AssertionError: a script this repository runs before `pnpm install` needs `node_modules` to load: expected [ Array(1) ] to deeply equal []
  FAIL   unit  scripts/__tests__/ci-cd-pipeline-doc.test.ts > ci-cd-pipeline.md — workflow inventory > gives every workflow in .github/workflows/ a row in the inventory table — in both directions
    ↳ 失败原因: AssertionError: the "Workflow Inventory" table has rows for workflows that are NOT in .github/workflows/:
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️ 断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• scripts/__tests__/workflow-cache-save-bound.test.ts — 24h 内已弹出 2 个 PR（fix(ui-merge): two tests that #25745 broke on main read the merged tree — the Changesets config through changesetConfigPath(), the SDUI html tier by its tags (#25711) #25852、ci(ui-merge): Type Check UI builds the five vitest-setup packages before that step, so an empty ui scope no longer reds it #25856），但它们同属 1 条投机栈 ⇒ 1 次独立命中。汇总 issue：Queue-flake anchor: scripts/__tests__/workflow-cache-save-bound.test.ts #25862（新建）
• scripts/__tests__/check-pre-install-import-graph.test.ts — 24h 内已弹出 2 个 PR（fix(ui-merge): two tests that #25745 broke on main read the merged tree — the Changesets config through changesetConfigPath(), the SDUI html tier by its tags (#25711) #25852、ci(ui-merge): Type Check UI builds the five vitest-setup packages before that step, so an empty ui scope no longer reds it #25856），但它们同属 1 条投机栈 ⇒ 1 次独立命中。汇总 issue：Queue-flake anchor: scripts/__tests__/check-pre-install-import-graph.test.ts #25863（新建）
• scripts/__tests__/ci-cd-pipeline-doc.test.ts — 24h 内已弹出 2 个 PR（fix(ui-merge): two tests that #25745 broke on main read the merged tree — the Changesets config through changesetConfigPath(), the SDUI html tier by its tags (#25711) #25852、ci(ui-merge): Type Check UI builds the five vitest-setup packages before that step, so an empty ui scope no longer reds it #25856），但它们同属 1 条投机栈 ⇒ 1 次独立命中。汇总 issue：Queue-flake anchor: scripts/__tests__/ci-cd-pipeline-doc.test.ts #25864（新建）

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 4 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)