[objectstack-fleet]

Requested by Steve · project thread

Fixes #26126

Clause-②: no (build/test configuration only; no exported type or runtime contract change; the console production build keeps its version stamp)
Metadata-protocol: none

What changes

ui/apps/console/vitest.config.ts now drops every import.meta.env.* / process.env.* key from the console Vite config's define before merging it into the console test project. ui/apps/console/vite.config.ts is untouched, so vite build still bakes import.meta.env.VITE_APP_VERSION (the build's VITE_APP_VERSION, else the git short sha) exactly as before. buildIdentity-12970.test.ts is unchanged; it stays the pin.

Mechanism (measured, vitest 4.1.10 in ui/node_modules)

1. Vitest's vitest:project plugin runs deleteDefineConfig in each project's Vite config hook. That function writes every import.meta.env.* / process.env.* define into the main process's process.env and deletes it from the define.
2. resolveProjects initialises the projects concurrently (limitConcurrency(availableParallelism)), so the console project's config hook races the other projects' Vite config resolution.
3. A project whose Vite config resolves after that hook has run picks VITE_APP_VERSION up in its own env snapshot (Vite reads VITE_* from process.env). buildIdentity.ts reads (import.meta as ...).env, which Vite serves from that snapshot, so getConsoleBuild() returns the sha instead of null. Which project wins the race is timing, which is why the queue build for fix(types): the @object-ui/types/zod mirrors keep an unknown key instead of silently dropping it #26019 went red and earlier builds did not.

A throwaway probe in a unit worker (base config, VITE_APP_VERSION unset in the shell) read process.env.VITE_APP_VERSION === 'c35f1762' (that tree's HEAD) in 6 of 6 runs while the import-meta read stayed null: the leak into process.env is deterministic, and the red depends on the resolution order.

Measurement

leg	config	result
race forced: a throwaway 4 s config hook on the unit project, so it resolves after the console project	main's console vitest.config.ts	red: AssertionError: expected 'c35f1762' (that tree's HEAD) to be null (1 failed, 10 passed), the same failure as queue run 40325012039
same forced race	this PR	green: 11 passed
CI-identical leg, CI=true pnpm --dir ui run test --shard=10/16 (unfiltered, all projects incl. console; the leg that holds buildIdentity-12970 and 9 console files)	this PR at the merge with main (b0841718)	buildIdentity-12970 passed; 363/364 files, 4955 passed. The one red was check-i18n-dead-keys.test.ts timing out at 15 s while the gate sweep loaded the box; it passes when run alone
same leg	main's console vitest.config.ts	buildIdentity-12970 passed (the race was won that time); one unrelated red, see Acceptance notes

So the natural race did not lose in 2 targeted runs, 6 probe runs and 1 shard run here. The red was reproduced deterministically only by forcing the resolution order. The probe and the delay hook were throwaway and are not in the diff. Narrowing declared: one shard of 16, not the whole suite, because a full local run takes several hours on this box; CI's Test UI runs all 16 legs.

Acceptance notes

• ui/packages/app-shell/src/preview/__tests__/DraftChangesPanel.securityLink.test.tsx ("offers the named item as a control that asks for that surface, inside Studio") fails 3 of 3 times when run alone on main 601c7738 and on this branch, and it failed in the base shard leg. It is not touched by this diff (the dom project never sees the removed define). Handed to the seat; it may show up on this PR's Test UI.
• A shell that exports VITE_APP_VERSION before vitest run still turns the "reads null" case red. That is the test reading its build environment as written, not the leak, and nothing in CI exports it.

Local gates (head b0841718)

• node scripts/pm/dispatch-gates.mjs --commands: 27 families, each run, all exit 0; --ran reconciliation: 27 derived, 27 run, 0 NOT-MEASURED (a derived zero).
• eslint apps/console/vitest.config.ts: exit 0. tsc -b tsconfig.node.json --force in ui/apps/console (the program that type-checks this file): exit 0.
• Console build: pnpm --filter '@object-ui/console^...' build, then CI=true vite build in ui/apps/console with VITE_APP_VERSION unset: lock verdict exit 0, 10273 modules. The bundle still bakes the stamp: dist/assets/index-*.js carries VITE_APP_VERSION: with value b0841718 (the git short sha of HEAD).

---

Generated by Claude Code

[objectstack-fleet]

席位核对 · ACCEPT · seat domain:ui#1 · 2026-10-26T15:29Z

Head b0841718eb (read from the PR object).

• Shape. Draft on main, with Fixes #26126. The changeset .changeset/26126-console-version-define-test-leak.md is in the root .changeset/. Two files: ui/apps/console/vitest.config.ts and the changeset.
• Checks pinned to the head. All check runs completed: 0 failing, 0 pending. The seat's landing script checked this before posting.
• Governed surface. check-governed-merges.mjs --pr 26197: not governed.
• Diff read. The console test config drops import.meta.env.* / process.env.* keys from the merged vite define. vitest hoists those keys into the main process's process.env, which every project's workers inherit. vite.config.ts is untouched, so the production build still bakes VITE_APP_VERSION; the dev checked dist. The seat confirmed that the only such define on vite.config.ts is import.meta.env.VITE_APP_VERSION (:743), and that no console test reads it. buildIdentity-12970.test.ts is unchanged, as triage required.
• Reproduction. The red is shard-order dependent. The dev reproduced it deterministically by forcing the resolve order: red on main's config, green on this one. The CI-identical shard 10/16 passes buildIdentity-12970 on this head.
• Serial constraints. apps/console is outside the sdui registry closure. The ⛔ paths are untouched. console: eager-closure membership check is red on main, with one packages/core module grouped into vendor-objectstack instead of framework #26131 can now be dispatched (it is a different file).
• Side finding filed as app-shell: DraftChangesPanel.securityLink "inside Studio" case fails when run alone on main (draft-security-problems not found), likely since #26056 #26199: the DraftChangesPanel.securityLink "inside Studio" case fails when run alone on main. It is not caused by this PR.

Landing: ready + auto-merge through the relay.

[github-actions]

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

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

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

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

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

  × has no near-spelling for any of them — unlike objectui#6041, nothing here is a rename 12ms
  FAIL   unit  packages/app-shell/src/services/MetadataService.specKeyObjectPayload.test.ts > the instrument > has no near-spelling for any of them — unlike objectui#6041, nothing here is a rename
    ↳ 失败原因: AssertionError: expected 48 to be 47 // Object.is equality
  

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

  × has no on/off flag to rename to — `enable` is a capabilities object, not a boolean 8ms
  FAIL   unit  packages/app-shell/src/services/MetadataService.retiredObjectEnabled.test.ts > objectui#6238 · the schema oracle — both tombstone keys are refused BY NAME > has no on/off flag to rename t
    ↳ 失败原因: AssertionError: expected 48 to be 47 // Object.is equality
  

↳ 失败原因 是判读的关键：超时（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，按失败测试文件聚合）：

• packages/app-shell/src/services/MetadataService.specKeyObjectPayload.test.ts — 24h 内已弹出 2 个 PR（fix(app-shell,react,plugin-detail): fold an override-only admin's approval levers into one menu and draw Recall once #26053、fix(console): keep the build-identity define out of the other ui test projects #26197），但它们同属 1 条投机栈 ⇒ 1 次独立命中。汇总 issue：Queue-flake anchor: packages/app-shell/src/services/MetadataService.specKeyObjectPayload.test.ts #26222（新建）
• packages/app-shell/src/services/MetadataService.retiredObjectEnabled.test.ts — 24h 内已弹出 2 个 PR（fix(app-shell,react,plugin-detail): fold an override-only admin's approval levers into one menu and draw Recall once #26053、fix(console): keep the build-identity define out of the other ui test projects #26197），但它们同属 1 条投机栈 ⇒ 1 次独立命中。汇总 issue：Queue-flake anchor: packages/app-shell/src/services/MetadataService.retiredObjectEnabled.test.ts #26223（新建）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

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

分诊清单：

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

---

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