view 元数据类型有两种并存形状（ViewItem vs 聚合 container），客户端校验器一直指着不作者的那一个 —— rc.2 收严后暴露 #3312

rc.2 抬 pin（objectui#3235 的 PR）中被 createConformance.test.ts 抓到。该 PR 已做最小修复（按判别式分派，两种形状各自严格校验），但「哪一种才是 view 的唯一 authorable 形状」是个真问题，需要维护者定。

事实

@objectstack/spec/ui 同时导出两个东西，rc.2 里都还在：

本仓两边都在用，而且方向是拧着的：

• 写：packages/app-shell/src/views/metadata-admin/anchors.ts 的 createBuildBody 产出 ViewItem；packages/app-shell/src/views/runtime-metadata-persistence.ts:182 也产出 ViewItem。view-create-body.test.ts 专门拿 ViewItemSchema 守着它。
• 读：MetadataProvider.mergeViewsIntoObjects 两种都认，注释把 ViewItem 称作「the canonical first-class shape (ADR-0017)」、把 container 称作「Legacy aggregated」。
• 校验：packages/app-shell/src/views/metadata-admin/clientValidation.ts 的 view 却指向 ViewSchema（container）。

为什么以前没人发现

rc.1 的 ViewSchema 非 strict。于是 ViewItem 草稿送进去，viewKind / config 被静默 strip，safeParse 返回 success —— 也就是说这个类型的客户端校验从来没有真正校验过任何一个自己的键，是一次「空过」。

rc.2 把 container 收成 strict，空过变成响亮拒绝：

Unrecognized key(s) on this view container: `viewKind`, `config`.
  • `viewKind` belongs to a single VIEW, not to the container. Wrap it:
    defineView({ list: { type, data, columns, … } }), or name it —
    defineView({ listViews: { my_view: { … } } }).
    The container's own keys are `list`, `form`, `listViews`, `formViews`.

与 objectstack#4616 对 email_template 的提醒同型：「If your code registers a client-side or publish-time validator for X, it must point at the schema the metadata kind actually resolves to」。本轮 email_template 那一处已按上游指引改到 EmailTemplateDefinitionSchema。

PR 里的最小修复

clientValidation.ts 按记录自身的判别式分派：带 viewKind 的按 ViewItemSchema 校验，否则按 ViewSchema。判别式取法与读侧 MetadataProvider.isViewItem() 完全一致。

这不是宽容回退 —— 两种形状各自被严格校验，没有任何 coercion，也没有 ?? 兜底；比改之前（container 单挑且静默 strip）严格。选它是因为：

• 只指 ViewItemSchema：会让「打开一条 legacy container 视图记录去编辑」开始报错；
• 只指 ViewSchema（现状）：本仓自己创建的每一条视图都不合法。

需要定的

view 应该只有一种 authorable 形状吗？如果是，哪一种？

• A. ViewItem 为准（本仓写侧现状、ADR-0017「object has-many view」）。则 ObjectStackSchema.views[] 收 container 这件事需要上游解释：published stack 里到底放哪个？container 是否应降级为「只读投影 / 打包产物」？
• B. Container 为准（ObjectStackSchema.views[] 与 clientValidation 原本指的那个）。则本仓写侧要整体迁移：createBuildBody、runtime-metadata-persistence.ts，且 MetadataProvider 的 container 分支要改成按 object 键而非 name 键（现在 objName = view?.name，而 container 的 name 是记录名 <object>.<key>，不是对象名 —— 直接换形状会把视图挂到不存在的对象上）。另外「一个对象一条 container 记录」与「创建表单一次做一个视图」是两种模型，创建流程要重做。
• C. 两者都合法、分层不同（一等记录 vs 聚合投影），那就把这件事写进 spec 文档与 ADR，本仓维持分派。

倾向 C 明确化，其次 A。B 的迁移成本最高且会踩上面那个键名坑。

顺带记录（本轮未改）

• packages/app-shell/src/views/runtime-metadata-persistence.ts:182 同样产出 ViewItem，没有 spec 一致性测试守着 —— 若最终选 B，这里也要一起迁。
• MetadataProvider.tsx 的 docblock 把 container 叫 "Legacy"，而 spec 的 ObjectStackSchema.views[] 恰恰只收 container；无论最终裁决如何，这段措辞都该更新。

相关

• objectui#3235（rc.2 抬 pin PR）
• objectstack#4616（email_template 同型：校验器指错 schema）
• objectui#2323（view-create-body.test.ts 的由来）、ADR-0017

⚠️ 未指派 —— 待裁决。

Generated by Claude Code