metadata-admin:嵌套 union(`config.columns`)的诊断仍塌成「Invalid input」——创建路/编辑路都中

[yinlianghui]

发现于 #3606 的实施(PR #3624)。#3606 修的是根级 union 塌陷;这条是同族的嵌套残留,先于 #3606 存在,两条路都中,因此单独立单由分诊定级。

事实(实测,@objectstack/spec 17.0.0-rc.5)

body:一份 ViewItem,config.columns 写成 [{ field: 123 }](field 应为 string)。

ViewItemSchema(创建路)      → [invalid_union] path=["config","columns"] msg="Invalid input"
ViewMetadataSchema(编辑路)  → [invalid_union] path=[]                   msg="Invalid input"   ← #3606,PR #3624 已修

PR #3624 之后编辑路收敛到与创建路完全一致的状态,即 config.columns + Invalid input。也就是说:根级塌陷已消,嵌套那层没消,且它在创建路上一直就是这样,不是 #5316/#3607 引入的。

为什么 #3606 没有一并修

config.columns 是 string[] | ColumnDef[] 这类没有判别式的 union。#3606 的解法是「按 body 自身的判别式选成员」,而这里没有判别式可用;把两个成员的错误全展开正是 #3606 明确拒绝的噪音做法。PR #3624 因此只展开根上的 union,并把这条残留写进了正文的「已知残留」。

另一个技术约束:成员 issue 的 path 是相对于 union 节点的,只有在根上它才等于 draft 的绝对路径;要处理嵌套层就得把父 path 前缀正确拼接进去。

影响(比 #3606 轻)

它带着真实 path config.columns,所以 SchemaForm 的内联高亮和 Monaco 的定位都还能工作 —— 用户能被带到出错的字段,只是不知道那个字段哪里错(哪一列、哪个键、期望什么类型)。这与 #3606 的空 path「指向不了任何东西」有本质区别。

可能的方向(未实现)

1. 无判别式 union 的「一致意见」展开:若所有成员在同一 path 上给出同一条 message,那条 message 与选哪个成员无关,可以安全提升上来。是真命题而非启发式,但命中率取决于 schema 写法。
2. spec 侧提供诊断入口(metadata-admin 的 view 编辑路走 union 门后,逐字段诊断塌成一条根级「Invalid input」 #3606 正文的方向 3):让 union 自带 discriminator,或导出「按判别式取成员」的入口,消费方不必猜。契约优先,跨仓,可一并覆盖根级与嵌套。
3. 就这样不动 —— path 可用,message 泛化,判断是否值得。

倾向 2;1 可作为不跨仓的兜底。定级请分诊裁决。

相关:#3606、PR #3624、objectstack#5316、objectstack#5074。

[claude]

Triage: finding (held), cross-linked to the spec-side entry point objectstack#6391.

Why finding and not queue. The filer asks triage to grade it, and the honest grade is observation-class: the diagnostic still carries a real path (config.columns), so inline highlighting and Monaco positioning both work — the user is taken to the offending field and only the message is generic. That is materially weaker than #3606, where the empty path pointed at nothing. On top of that, the card's own preferred direction (2 — a spec-side discriminator or diagnostic entry) is not this repo's to choose, and direction 1 (consensus-expansion for discriminator-less unions) is described as a fallback whose hit rate depends on how each schema happens to be written. Neither has an acceptance criterion a dispatch prompt could carry today.

Convergence — one dispatch entry per thing. objectstack#6391 was filed today from the objectui lane and is the contract-side card for exactly this family (ViewMetadataSchema's union has no discriminant and its container/overlay members are unexported). It has been triaged this round as finding + domain:spec. That is where direction 2 gets priced; this card stays as the consumer-side record so that if the spec lane declines, the objectui-local fallback still has a home. ⛔ Not closed as a duplicate — the two halves are separable, and closing this one would delete the only record of the nested layer's parent-path-prefix constraint.

Not Blocked-by: — direction 1 is implementable inside objectui without waiting on anything upstream, so a blocking line would be false. If the spec lane takes #6391, re-grade this card at that point.

No domain:* — objectui is a whole-repo seat.

Stale-premise check. PR #3624 is merged; the measurement in the body (edit path now collapsing to the same config.columns + Invalid input as the create path) describes current main, not a pre-merge state.

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[yinlianghui]

认领(PM 派发),定级:轻度缺陷(path 真实可定位,message 泛化;两路修后收敛一致 — 本单是 #3606 程序的向下一层延伸)。

• Session: session_01GTRjn8xBqp75dk7kFupVRt
• 分支:claude/issue-3626-nested-union-diag
• 文件面:packages/app-shell/src/views/metadata-admin/clientValidation.ts + 同目录诊断测试(可扩展 fix(app-shell): expand view edit-gate union failures into per-field diagnostics #3624 落地的 clientValidation.viewDiagnostics.test.ts,不改其现有断言)+ changeset。前置已落:PR fix(app-shell): expand view edit-gate union failures into per-field diagnostics #3624 已在 main(c993ff2),同文件障碍解除。
• 裁决(有界授权):先测量 config.columns 的嵌套 union(string[] | ColumnDef[])在 Zod issue 树里的形态,评估 fix(app-shell): expand view edit-gate union failures into per-field diagnostics #3624 的展开机制能否按内容判别递归下去(数组首元素 string vs object 是可用判别式 — 与「按 issue 数/深度」的启发式不同,后者已被 metadata-admin 的 view 编辑路走 union 门后,逐字段诊断塌成一条根级「Invalid input」 #3606 实测否决,⛔ 仍禁用)。判定门与噪音控制约束与 fix(app-shell): expand view edit-gate union failures into per-field diagnostics #3624 完全相同(判定不动、只动呈现、不全量展开)。若测量表明内容判别在此处不干净(空数组等边界无法判别),停,把测量写进报告 — 届时并入 objectstack#6391 的 spec 侧诉求,不硬凑。
• 创建路与编辑路修后须保持收敛一致(issue 已实测两路同病 — 修一路时确认另一路同步受益或明确记录差异)。

---

Generated by Claude Code

[yinlianghui]

验收 ACCEPT → PR #3677(session_01GTRjn8xBqp75dk7kFupVRt)。

已核:CI 18 项 0 失败;新增 20 条测试,#3624 的 18 条一行未改;创建/编辑两路收敛由 toEqual 断言(非论证);逆向验证 A 恰 7 红。

裁决记录(三项记入方法库):

1. 先走全树再定规则:16 个无判别式嵌套 union 的普查发现 columns 独一无二、sort 会被朴素规则误选 — 范畴判定条款(「union 节点上直接拒绝了值类型的成员没看过内容,内容不能作为它的证据」)是内容判别的正确形式化;无深度计数器,弃权即边界。
2. 逆向验证 B(验证验证器):A 下两向皆绿的钉子证明不了自己有效 → 单独扰动收窄条款,1 红打印出误选原话(对正确写数组的人说 expected string)。「每条防御性条款需要能证明它在防御的扰动」— 收录。
3. 不可判别处保持塌陷是对的:[42] 两成员同 path 对等拒绝,选一个 = 凭空发明偏好;空数组结构上走不到失败路径 — 两处预测偏差的落账方式正确。
4. 新发现 metadata-admin:嵌套 union「只剩一个成员接受了值的类型」时仍塌成 Invalid input(config.sort 等) #3678(唯一候选规则空档,sort[].order 本可无歧义具名)入池 — 「另一条规则不在本单授权内」的停手正确,与 objectstack#6391 交叉链接完整。

#3606/#3626 诊断程序至此:根级 + 嵌套一层落地,剩余空档(#3678 消费侧 / #6391 spec 侧)账目清晰。

---

Generated by Claude Code