authoring-validation-not-persisted: a flat view body is accepted, published and reported valid, then expands to nothing — the write door judges by the wire union, not the strict ViewSchema

[huangyiirene]

Symptom

A flat view body — a single view's config written where the container belongs — is accepted silently by the runtime metadata door.

• PUT /api/v1/meta/view/<name>?mode=draft with {name, type:'grid', columns:[…], data:{…}} → 200 state:'draft' (and 200 state:'active' on the direct door)
• publish → 200
• read-back carries _diagnostics:{valid:true}

Reproduced on 3 names. The guidance for this exact body exists and fires elsewhere: defineView(body) on the same body throws a located message — "Unrecognized key(s) on this view container: type, columns, data. • type belongs to a single VIEW, not to the container. Wrap it: defineView({ list: { … } })".

Consequence measured: expandViewContainer(...) → [], and GET /meta/view?object=… omits it, while GET /meta/view lists it as a bare unbound row. Registered, reported valid, renders nothing — precisely the outcome the strict container shape was closed to prevent.

Root cause

Two schemas judge the same body, and the write path is on the lenient one.

• getMetadataTypeSchema('view') resolves to ViewMetadataSchema (packages/spec/src/kernel/metadata-type-schemas.ts:102), a 4-member wire union (packages/spec/src/ui/view.zod.ts, ~line 2941 on the run's build). Its precondition assertViewIdentity passes anything that speaksViewVocabulary accepts — and the message it would otherwise emit names "an inline view config (type, columns, sections, filter, …)" as a legitimate arm. A body carrying type + columns therefore never reaches a rejection.
• The guidance-carrying strict ViewSchema (view.zod.ts:2327 on origin/main; line 2358 on the run's build) is only on the defineView/build path.

Verified by hand during the run: ui.ViewSchema.safeParse(body).success = false with the guidance; getMetadataTypeSchema('view').safeParse(body).success = true.

Stale-premise check: re-verified on objectstack origin/main (00e9196). The union, the inline-config arm and the assertViewIdentity precondition are all present; the strict ViewSchema is still build-path only.

⚠️ This needs a direction ruling before implementation

The inline arm looks deliberate — #6391 named the union's members precisely so a consumer could reference them contractually, and #5599 / #5074 sit behind the current shape. The defect as measured is not "the union has four members"; it is that the door accepts a view it then cannot expand, and stamps it valid. Two candidate directions, and picking wrong re-opens a settled contract:

• A — re-word the checklist item / accept the shape as authored. If a bare inline config is a legitimate stored view, then the bug is that it is reported valid:true while being unreachable, and the fix is on the diagnostics/expansion side, not the schema.
• B — make the inline arm require an object binding. An inline config that cannot name the object it attaches to cannot be expanded or served, so requiring the binding turns a silent dead row into a located refusal at the door — at the cost of tightening a published union arm.

Neither is safe to guess. Please rule before this is dispatched.

Related, not duplicate: #5599 (closed) is the ancestor of the current union — it reported that saveMetaItem({item:{nope:1}}) stored a junk active view. That hole was closed by the identity precondition; this card is the residue the precondition deliberately lets through, because a flat view config does speak view vocabulary.

Adjacent and worth reading together: #7736 (this run) — a container body reaches the same door and is stored without ever being expanded either. The two cards meet at the same place: the runtime write door has no expansion step, so neither shape can produce a servable view.

Reproduction

1. Boot the showcase with writable runtime packages.
2. PUT /api/v1/meta/view/<name>?mode=draft with {name:'<name>', type:'grid', columns:[…], data:{…}} → 200 state:'draft'.
3. Publish → 200; GET /api/v1/meta/view/<name> → _diagnostics:{valid:true}.
4. GET /api/v1/meta/view?object=<obj> → the view is absent; GET /api/v1/meta/view lists it as a bare unbound row.
5. Contrast: call defineView(body) on the identical body — it throws the located "Wrap it: defineView({ list: { … } })" guidance.

Routing note

Filed domain:spec rather than domain:metadata: both located files are in packages/spec (ui/view.zod.ts, kernel/metadata-type-schemas.ts), and every candidate fix direction above edits a schema or its diagnostics. If the ruling lands on A and the work turns out to be expansion-side, re-route to domain:metadata at that point.

Source

Extracted from the QA run #7695 (framework 92f26f7, console 09987b680).

[os-zhuang]

Moved pm:queue → needs-user-decision by the spec-lane seat (session session_01JY2Q5Xto1u8YHADgrZDTnk), executing the maintainer's lane-triage authorization (2026-08-11, 「你的车道你可以执行 分类改标」). The card's own text asks for exactly this: "Neither is safe to guess. Please rule before this is dispatched" — a queue label on a card whose body demands a ruling is the #4829 shape in reverse.

Four-lens recommendation (for the ruling; per #7498's decision-card requirement):

1. 实际业务需求 — nobody benefits from a stored view that renders nothing while reporting valid:true; the measured harm is the silent dead row, not the union's arity. Both directions fix that; neither adds capability.
2. 项目长远合理性 — the deeper fact (shared with sibling view-authoring-live: the documented view-container authoring path is inert at runtime — the container is stored but never served #7736) is that the runtime write door has NO expansion step, so no shape it accepts can produce a servable view. A schema-side tightening (B) fixes THIS card's shape but leaves view-authoring-live: the documented view-container authoring path is inert at runtime — the container is stored but never served #7736's container shape dying at the same door. If the door gains an expand-or-refuse step, both cards close structurally.
3. 防 AI 写错 — B (inline arm requires an object binding) turns the silent dead row into a located refusal at the authoring door — the strongest anti-footgun shape. A alone (fix diagnostics/expansion, accept the shape) keeps a lenient wire arm that defineView refuses, i.e. the two doors keep disagreeing in front of the same author.
4. Startup scope — B is a tightening of a published union arm (spec/ui: ViewMetadataSchema 的 union 无判别式且容器成员未导出——消费方做失败诊断只能按成员序索引嵌套 errors #6391 named the members deliberately; view 的 spec 校验闸门形同虚设:saveMetaItem({ item: { nope: 1 } }) 返回 success 并把 {"nope":1} 存成一个 active view #5599/ViewItemSchema 同时是授权形状和 Studio 往返的 wire 成员 —— 拆成两个 schema 还是保持宽松?(挡住 #4001 批 18 最后 2 站点) #5074 behind it) — a contract action needing your word either way.

Recommendation: B, plus the honest half of A — require the object binding on the inline wire arm (located refusal, message mirroring defineView's existing guidance), AND stop stamping valid:true on any stored view that expands to [] (the diagnostics lie is real under every direction). If you'd rather treat the door's missing expansion step as the root fix, rule that instead and this card re-routes to domain:metadata alongside #7736.

Awaiting your ruling — the card dispatches the moment one lands.

---

Generated by Claude Code

[huangyiirene]

Maintainer ruling — 2026-08-12

裁定:方向 B —— inline arm 在运行时写门必须携带 object 绑定,拒绝时给出与 defineView 同款的定位指路。

要点:

• 一个无法展开、无法被任何读路径服务的行,不允许被存储并盖上 valid:true —— 那是给作者(尤其是 AI 作者)的假收据。
• 写门的拒绝复用 build 路径已有的 guidance(「Wrap it: defineView({ list: { … } })」),让作者在犯错现场拿到正确拼法。
• draft 与 active 同样适用;若 Studio 将来出现「先存未绑定草稿」的实测需求,再对 draft 单独放宽 —— 现在没有这个证据,不预留。
• spec/ui: ViewMetadataSchema 的 union 无判别式且容器成员未导出——消费方做失败诊断只能按成员序索引嵌套 errors #6391 的 union 成员契约保持:收紧的是 inline arm 的绑定要求,不是砍掉这个 arm。
• 相邻的 view-authoring-live: the documented view-container authoring path is inert at runtime — the container is stored but never served #7736(container 体同样存而不展开)在实现时一并对照 —— 两卡病灶同源:运行时写门缺展开步骤。

裁定人:维护者 huangyiirene(2026-08-12,接受 PM 综合分析后批准);由 PM 会话 session_01GZKbx4xyF7U5WXj6ch49BM 代笔落卡。转 pm:queue。

---

Generated by Claude Code