跨分片移交（objectui 分片 PM，会话 session_01NVPjPzmmAJ2Ngtvgg5MSRa；objectui 侧不动 packages/spec/**，按分片协议转入主队列，不指派）。
现场：objectui#3312（含最小修复与实测记录）。在 objectui 抬 pin 到 17.0.0-rc.2 的过程中发现。
需要裁定的
view 元数据存在两种形状：ViewItem（一等记录）与聚合 container。objectui 的写侧（createBuildBody、runtime-metadata-persistence.ts）产出 ViewItem，依据是 ADR-0017「object has-many view」。
但 rc.2 的根 schema 收的似乎是另一种：
packages/spec/src/stack.zod.ts:217
views: z.array(ViewSchema).optional().describe('List Views'),
而 container 的 object 键自述（src/ui/view.zod.ts:1468）：
Object this container binds to — how a stack-level views: [...] entry says which object its views belong to; read by getViewsByObject() / GET /meta/view?object=.
若该观察成立，objectui 正在生产平台根 schema 会拒绝的元数据。
⚠️ 这是 objectui 侧的只读核对，未做端到端写入实测。请以本仓自己的实测为准 —— 我不希望一个未经验证的观察变成裁决依据（这一批已经有三次「前提陈述有误」的先例了，见下）。
为什么现在才浮出来
objectui 的客户端校验器一直指着 container 那一支，而 rc.1 下该 schema 非 strict，未知键被静默 strip —— 也就是说这个类型的客户端校验从来是空过的：写错什么都不报。rc.2 收严之后它才第一次真的开始校验，从而把形状分歧照了出来。
这本身也是一个值得记的样本：一个"存在于磁盘、保护着零"的校验器，只有在被收严的那一刻才会暴露它守护的东西一直是错的。
三个选项（objectui 侧的评估）
| 选项 |
内容 |
objectui 侧成本 |
A ViewItem 为准 |
符合本仓写侧现状与 ADR-0017 |
低；但需上游解释根 schema 只收 container |
| B container 为准 |
本仓写侧整体迁移 |
最高，且实测踩坑：container 的 name 是记录名 <object>.<key> 而非对象名，直接换形状会把视图挂到不存在的对象上（实施侧已实测并回退）；且「一个对象一条 container 记录」与「创建表单一次做一个视图」是两种模型，创建流程要重做 |
| C 两者都合法、分层不同 |
一等记录 vs 聚合投影，写进 spec 文档与 ADR |
低；本仓维持按判别式分派即可 |
objectui 侧倾向 C 明确化，其次 A；不建议 B。
objectui 侧已经做了什么
抬 pin 的 PR 里做了最小修复：客户端校验按记录自身的判别式 viewKind 分派，两种形状各自严格校验（无 coercion、无兜底，判别式取法与读侧 MetadataProvider.isViewItem() 一致）。这不是宽容回退 —— 它把该类型从「从未真正校验」变成「两种形状都真正校验」，严格强于改动前。
本仓不会据此自行选定唯一形状 —— 那是 spec 的建模裁决。
相关
- objectui#3312（本仓承接点，含最小修复说明）
- objectui#3235（rc.2 抬 pin PR）
- ADR-0017（object has-many view）
Generated by Claude Code
跨分片移交（objectui 分片 PM，会话
session_01NVPjPzmmAJ2Ngtvgg5MSRa；objectui 侧不动packages/spec/**，按分片协议转入主队列，不指派）。现场：objectui#3312（含最小修复与实测记录）。在 objectui 抬 pin 到
17.0.0-rc.2的过程中发现。需要裁定的
view元数据存在两种形状：ViewItem（一等记录）与聚合 container。objectui 的写侧（createBuildBody、runtime-metadata-persistence.ts）产出ViewItem，依据是 ADR-0017「object has-many view」。但 rc.2 的根 schema 收的似乎是另一种：
而 container 的
object键自述（src/ui/view.zod.ts:1468）：若该观察成立，objectui 正在生产平台根 schema 会拒绝的元数据。
为什么现在才浮出来
objectui 的客户端校验器一直指着 container 那一支，而 rc.1 下该 schema 非 strict，未知键被静默 strip —— 也就是说这个类型的客户端校验从来是空过的：写错什么都不报。rc.2 收严之后它才第一次真的开始校验，从而把形状分歧照了出来。
这本身也是一个值得记的样本：一个"存在于磁盘、保护着零"的校验器，只有在被收严的那一刻才会暴露它守护的东西一直是错的。
三个选项（objectui 侧的评估）
ViewItem为准name是记录名<object>.<key>而非对象名，直接换形状会把视图挂到不存在的对象上（实施侧已实测并回退）；且「一个对象一条 container 记录」与「创建表单一次做一个视图」是两种模型，创建流程要重做objectui 侧倾向 C 明确化，其次 A；不建议 B。
objectui 侧已经做了什么
抬 pin 的 PR 里做了最小修复：客户端校验按记录自身的判别式
viewKind分派，两种形状各自严格校验（无 coercion、无兜底，判别式取法与读侧MetadataProvider.isViewItem()一致）。这不是宽容回退 —— 它把该类型从「从未真正校验」变成「两种形状都真正校验」，严格强于改动前。本仓不会据此自行选定唯一形状 —— 那是 spec 的建模裁决。
相关
Generated by Claude Code