Repository navigation
spec: view 元数据两种形状并存，且 objectui 写侧产出的可能不是根 schema 收的那一种 —— 需裁定唯一 authorable 形状 #4959
Closed as not planned
Description
Activity
分诊(v17 GA 前排查会话
session_01TuRNZBjTLr2UFH15wivGEe,维护者 2026-08-04 核准):挂domain:spec+target:v17,转 spec 车道。- 落点:裁定对象是
packages/spec的view唯一 authorable 形状(stack.zod.ts:217vsViewItemSchema),按锚定规则归domain:spec。 - 窗口理由:与 spec 车道在队的
target:v17单ViewItemSchema同时是授权形状和 Studio 往返的 wire 成员 —— 拆成两个 schema 还是保持宽松?(挡住 #4001 批 18 最后 2 站点) #5074(ViewItemSchema授权/wire 双角色拆分)同族同文件面 —— 两个裁决拆开做会互相返工,建议同窗合并裁决。objectui 侧最小修复已合(objectui#3312),此单只剩 spec 侧定形状。 - 本单列 GA 排查 B 组(契约裁定类,错过主版本窗口即等 v18)。
Generated by Claude Code
- 落点:裁定对象是
前提实测:端到端不成立,关闭(否决窗口有效)
按移交时的要求,本仓端到端实测已随 #5074(PR #5319 rider)完成,证据:
- schema 层分歧属实:
ObjectStackSchema.views(stack.zod.ts:250)只收容器,对 ViewItem 报unrecognized_keys: ["viewKind","config"];持久化门ViewMetadataSchema接受 ViewItem; - 但本单的核心断言「objectui 正在生产平台根 schema 会拒绝的元数据」不成立:objectui 从不产出栈文档 —— 它逐条走
client.meta.saveItem('view', name, body)→saveMetaItem→ViewMetadataSchema,那正是 ADR-0017 的记录门,接受 ViewItem。不同生产者、不同门,无一处断裂; - 栈级拒绝是带处方的刻意契约(
defineStack({ views: [ViewItem] })报「viewKindbelongs to a single VIEW … Wrap it:defineView({...})」),非疏漏。
裁定:无「唯一 authorable 形状」需要拍板 —— 两个门各司其职且都在正确方向上。原单预期的三选一裁决失去对象,按 premise-refuted 关闭。实测中发现的两条真实残余观察(lint 门映射与栈 schema 不一致、运行时注册循环比 schema 宽)已按 finding 纪律归档为 #5320,待发现分诊轮定级。
维护者或移交方(objectui 分片)如认为余下仍有裁决对象,可重开并以 #5320 的两条为新前提。
Generated by Claude Code
- schema 层分歧属实:
跨分片移交（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