`object.form.ts` 的 20 处 `visibleWhen` 写的是裸标识符(`type == 'formula'`),同仓 `field.form.ts` 写的是 `data.type` —— 同一面两种拼写,必有一种不生效

[hotlong]

Filed unassigned from #6128 / PR #6248,那里为了给新闸门定爆炸半径把全仓可见性谓词扫了一遍。本单只记录发现,不含修法承诺 —— 它没有被 #6248 的闸门判到,原因见下。

事实:同一层的两种拼写

metadata 编辑表单(*.form.ts)的绑定根是 data(编辑中的那一行)—— packages/spec/src/ui/view.zod.ts:1416 / :1510 的 describe 原文,ADR-0089 D3 §Context 同。

packages/spec/src/data/field.form.ts 全部照此书写:

{ field: 'minLength', visibleWhen: "data.type == 'text' || data.type == 'textarea'" }
{ field: 'reference',  visibleWhen: "data.type == 'lookup' || data.type == 'master_detail'" }

packages/spec/src/data/object.form.ts 则一律写裸标识符,约 20 处(行号 120-190):

{ field: 'maxLength', visibleWhen: "type in ['text','textarea','email',…]" }
{ field: 'expression', visibleWhen: "type == 'formula'" }
{ field: 'autonumberFormat', visibleWhen: "type == 'autonumber'" }

view.form.ts / page.form.ts / report.form.ts / action.form.ts 也都是 data. 写法。只有 object.form.ts 是裸的。

需要先确定的一件事(不要凭印象判)

object.form.ts 的这些字段嵌在 object 表单的 repeater(字段列表)的 fields[] 里,行本身就是一个字段定义。所以有两种读法:

1. repeater 子字段的谓词也按整张表单的 data 绑定求值 ⇒ 这 20 处全是坏谓词,Studio 的对象/字段编辑器里这些条件字段从来没有真正条件化过(fail-open ⇒ 一直显示);
2. repeater 行在子字段谓词里另有一层行级绑定 ⇒ 裸写法是对的,那么这层绑定在 spec 里没有任何一句话写下来,而 field.form.ts 的 data. 写法就成了另一头的错。

无论哪一种,现状都是「同一个面上两种拼写并存,且没有文档说清楚」——这本身就是要修的东西。

为什么 #6248 的新闸门没有判到它

三条独立原因,记下来免得接手者以为闸门坏了:

1. packages/spec 的 *.form.ts 不是任何 app stack 的一部分,os validate 不会 lint 它们;
2. 全仓没有任何调用方传 layer: 'metadata' —— 该层目前只有测试在跑;
3. 即便前两条都补上,type 恰好是 CEL 自己声明的类型名标识符,type == 'formula' 到 checker 那里是类型 overload 错误而非「未知变量」,feat(lint): view/page 谓词裸标识符构建期闸门 —— 坏谓词发不出去 (#6128) #6248 的闸门按设计不判它(改读 overload 消息会误杀合法的 type(record.x) == string)。这一条已在 PR feat(lint): view/page 谓词裸标识符构建期闸门 —— 坏谓词发不出去 (#6128) #6248 里作为已知盲点钉了测试。

也就是说:这 20 处即使把闸门指过去也抓不到,得靠人读或靠一条专门的判据。

Refs:#6128 / PR #6248(发现处与盲点说明)、#5149(可见性谓词 fail-open 静默一族)、ADR-0089 D3。

[claude]

Triage: pm:queue + domain:spec.

Landing site. packages/spec/src/data/object.form.ts (and, depending on which reading wins, packages/spec/src/data/field.form.ts and the binding sentence in packages/spec/src/ui/view.zod.ts) ⇒ domain:spec. Premise checked against origin/main@2598216: neither form file has been touched since the repo-wide 7f62706 sweep, so both spellings are still live.

Why pm:queue and not needs-user-decision. The issue opens with an unresolved question ("does a repeater sub-field predicate evaluate against the form-root data binding, or a row-level one?"), but that is a technical question answerable by reading the evaluator — not a product call about what authors may write. Routing is never escalated, and neither is a question the code can answer. Both branches also converge on the same deliverable: one spelling across both files, plus the binding rule written down where the schema describes it, because today the repo ships both spellings and documents neither.

Acceptance a dev can state in one sentence: every visibleWhen on this surface uses the same binding form, and the rule that makes it correct is stated in the schema's own describe text.

Not on the release board. If reading 1 holds, the affected surface is the Studio metadata editor's conditional field display (fail-open ⇒ fields always shown) — a shipped surface, but a cosmetic/authoring-UX degradation rather than data damage or a contract lie. Sits with the next train; veto welcome.

Dedup. No other open issue or PR in the three repos names object.form.ts as its subject (#5628 mentions it in passing about readonly on autonumber builders — different key, different defect). PR #6248's new bare-identifier gate structurally cannot catch these 20 sites: type is a CEL-declared type-name identifier, so the checker reports an overload error rather than an unknown variable, and that blind spot is already pinned by a test in that PR.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code