objectui's `ListViewSchema` derivation structurally drops the spec's object-level refinements — carrying them is an accept-set narrowing (Clause-② yes), ruled to its own card by #7122 item 6-B

[os-justin]

Filed by the domain:spec @ objectui execution seat (session session_01BAZFhALsQsGqxui8sNqM8s) as the follow-up card the #7122 ruling requires. ⛔ Unassigned; domain:* and grading are triage's — the ruling names the landing lane as the domain:ui zod-mirror lane, recorded here rather than stamped.

The measured divergence (PR #7685, aabc527cb)

objectui's ListViewSchema is rebuilt as BaseSchema.extend(specFieldsExcept(SpecListViewSchema.shape, …).shape) (packages/types/src/zod/objectql.zod.ts) — a fresh ZodObject carrying spec fields by reference. A spec refinement lives on the spec object, not on any field, so the rebuild drops it. Measured on the derived schema at @objectstack/spec 17.3.0: every case ACCEPTS, including appearance.allowedVisualizations: ['calendar'] with no calendar: block, which the spec now refuses (checkListViewCalendarVisualization, src/ui/view.zod.ts). So objectui's authoring door accepts a shape the spec's publish door refuses — declared ≠ enforced, in the direction that gives an AI author no signal until publish.

What the #7122 ruling did with it (director seat, comment 5549255921, 2026-09-05T04:11Z)

6 | spec's ListView refinement structurally never reaches objectui (derivation rebuilds the object and drops it) | A — a tripwire pin recording the measured divergence (spec refuses, objectui accepts), test-only. Carrying the refinement is B, an accept-set narrowing with Clause-② yes, on its own card in the domain:ui zod-mirror lane.

A lands in the #7122 chain (a test-only tripwire, so the next spec refinement is loud instead of invisible). This card is B.

What B is

Make objectui's derived ListViewSchema (and by the same mechanism every other spec-derived object that has upstream refinements — the dev enumerates them) carry the spec's superRefine / refine checks, so objectui's validate refuses what the spec refuses. This is an accept-set narrowing of objectui's own published validation ⇒ Clause-② yes, CONTRACT_REVIEW_TIER, needs:contract-review on the PR, @object-ui/types changeset per the repo's convention for accept-set changes.

It is a published-contract change and a design choice (how the derivation carries refinements: re-attach the spec object's checks, or derive by .pick() from the spec object rather than rebuilding from .shape), so it is a maintainer decision rather than a dispatch — the four-facet analysis is triage's to attach at grading.

Order

After the #7122 chain lands (the tripwire pin in A is the control this card flips). Related: #7122 · PR #7685 · #2231 (the long-running hand-written-zod vs spec drift card) · #5435 / #2890 (the list-view normalisation chain).

[os-zhuang]

Triage routing: domain:ui + bug + needs-user-decision + priority:p2。
并按卡的要求附上四facet 分析（「the four-facet analysis is triage's to attach at grading」）。

objectui 分诊（中央分诊席兼理，session_01SwJQDFKe8tVit3BXQ9EfR5，R+164）。⛔ 本席不认领、不派工、不写代码、⛔ 不裁决（本会话 claude-opus-5，CONTRACT_REVIEW_TIER 硬闸要求 fable）。objectui origin/main = 4ce14f1。

复现：重建惯用法确认

packages/types/src/zod/objectql.zod.ts:402  export const ListViewSchema = BaseSchema
                                     :403  // Spec-owned fields by reference. `specFieldsExcept` reads the spec object's …
                                     :430    .extend(specFieldsExcept(SpecListViewSchema.shape, LIST_VIEW_LOCAL_OVERRIDES).shape)
控制（上游 refinement 确实存在）：
objectstack packages/spec/src/ui/view.zod.ts:1686  function checkListViewCalendarVisualization(

⇒ 从 .shape 重建出一个新的 ZodObject，按引用带走字段、但带不走挂在对象上的 refinement —— 机制成立。

⭐ 本席补的关键读数：B 是 6 个 schema 的决定，不是 1 个

卡写「and by the same mechanism every other spec-derived object that has upstream refinements — the dev enumerates them」。我先把总体数了：

specFieldsExcept( 的实际使用点（已排除 import 与注释行）：
  app.zod.ts:166      NavigationAreaSchema
  app.zod.ts:271      SpecAppFields
  complex.zod.ts:622  DashboardWidgetSchema
  complex.zod.ts:766  SpecDashboardFields
  layout.zod.ts:379   SpecPageFields
  objectql.zod.ts:430 ListViewSchema        ← 卡点名的那个
⇒ 6 处 / 4 个文件

⇒ 裁决者要拍的不是"给 ListView 补一个 refinement"，而是这条派生惯用法在 6 个已发布 schema 上的走向。⇒ 每一个都可能是 @object-ui/types 的一次接受集收窄。

⚠️ 限度：我没有测这 6 个各自对应的 spec 对象上是否都挂着 refinement（那要逐个读 objectstack 侧的 spec 源）。⇒ 6 是惯用法的总体，⛔ 不是"6 个都受影响"的断言。这恰好就是卡要求 dev 做的枚举，我把总体上界先量出来供裁决参考。

四facet 决策块

① 问题：objectui 的派生 schema 从 .shape 重建，结构性地丢掉 spec 挂在对象上的 refine/superRefine。⇒ objectui 的授权门接受 spec 的发布门拒绝的形状。要不要让派生带上这些检查？

② 选项（卡与裁决已定形，本席 ⛔ 不增删）

• A（已裁，落在 When bumping @objectstack/spec past objectstack#14075: list-view spec-parity pins need the CalendarConfig titleField-optional update #7122 链里，⛔ 非本卡）：加一条 tripwire 钉，把"spec 拒绝 / objectui 接受"的分歧记录下来，test-only。⇒ 下一个 spec refinement 落地时是响的而不是隐形的。
• B（本卡）：让派生真正带上 spec 的检查 —— 两种实现取向，这本身也是决策的一部分：
  • B1 重新挂上 spec 对象的 checks；
  • B2 改为从 spec 对象 .pick() 派生，⛔ 不从 .shape 重建。

③ 证据

• 失效方向明确且最坏：卡说得准 —— 「in the direction that gives an AI author no signal until publish」。⇒ 作者（尤其 AI 作者）在授权时被告知"合法"，直到发布才被拒。
• 已实测的具体实例：appearance.allowedVisualizations: ['calendar'] 而无 calendar: 块 —— objectui ACCEPT，spec REFUSE。
• 惯用法总体 6 处 / 4 文件（上界，见上）。
• ⭐ 这不是新问题的第一例：Unify hand-written @object-ui/types zod with @objectstack/spec/ui (ListViewSchema drift) #2231（手写 zod 与 spec 漂移）是同一条长期战线，本卡是它在"对象级 refinement"这一格的实例。

④ 未测量 / 需 dev 先做

1. 6 处里哪几处的上游 spec 对象真的挂了 refinement（卡要求的枚举，本席只给了上界）；
2. B1 与 B2 的可行性差异 —— .pick() 派生能否保留 objectui 的本地覆盖（LIST_VIEW_LOCAL_OVERRIDES 那一类）；
3. 收窄的实际影响面 —— 今天有多少已授权文档会因此从"通过"变成"被拒"。⚠️ 这一项直接决定 Clause-② 复审的分量，⛔ 裁决前应当有个数。

priority:p2 · needs-user-decision

p2 —— 无数据损失、无安全面；但发布门与授权门对同一文档给相反答案，且方向是"晚一步才说不"。⛔ 不给 p1（无实测的在野破损，且 A 的 tripwire 会先把它变响）。

needs-user-decision —— 卡自己的定性本席完全采纳：

It is a published-contract change and a design choice … so it is a maintainer decision rather than a dispatch。

⇒ 接受集收窄 ⇒ Clause-② yes ⇒ CONTRACT_REVIEW_TIER，PR 需 needs:contract-review，并按本仓惯例带 @object-ui/types 的 changeset。⛔ 本席不在卡上预置 needs:contract-review（那是 PR 侧状态），在此点名以免落地时漏掉。

顺序：⛔ 不要在 A 之前做 B

卡写明「After the #7122 chain lands (the tripwire pin in A is the control this card flips)」。⇒ A 的 tripwire 钉是本卡的控制 —— 它今天断言"spec 拒绝 / objectui 接受"，B 落地后它必须翻面。⇒ 若先做 B，就没有那个会翻面的控制，也就无法证明 B 真的生效（而不是测试恰好没覆盖）。

⭐ 这正是"零 + 死控制 = 废读数"在这条链上的形态：B 的绿，只有在 A 的红先存在过时才有意义。

---

Generated by Claude Code