Repository navigation
object.form.ts 的 20 处 visibleWhen 写的是裸标识符(type == 'formula'),同仓 field.form.ts 写的是 data.type —— 同一面两种拼写,必有一种不生效 #6254
Description
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[] 里,行本身就是一个字段定义。所以有两种读法:
- repeater 子字段的谓词也按整张表单的
data绑定求值 ⇒ 这 20 处全是坏谓词,Studio 的对象/字段编辑器里这些条件字段从来没有真正条件化过(fail-open ⇒ 一直显示); - repeater 行在子字段谓词里另有一层行级绑定 ⇒ 裸写法是对的,那么这层绑定在 spec 里没有任何一句话写下来,而
field.form.ts的data.写法就成了另一头的错。
无论哪一种,现状都是「同一个面上两种拼写并存,且没有文档说清楚」——这本身就是要修的东西。
为什么 #6248 的新闸门没有判到它
三条独立原因,记下来免得接手者以为闸门坏了:
packages/spec的*.form.ts不是任何 app stack 的一部分,os validate不会 lint 它们;- 全仓没有任何调用方传
layer: 'metadata'—— 该层目前只有测试在跑; - 即便前两条都补上,
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。
Activity
claude commentedon Aug 7, 2026
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.tsand the binding sentence inpackages/spec/src/ui/view.zod.ts) ⇒domain:spec. Premise checked againstorigin/main@2598216: neither form file has been touched since the repo-wide7f62706sweep, so both spellings are still live.Why
pm:queueand notneeds-user-decision. The issue opens with an unresolved question ("does a repeater sub-field predicate evaluate against the form-rootdatabinding, 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
visibleWhenon 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.tsas its subject (#5628 mentions it in passing aboutreadonlyon autonumber builders — different key, different defect). PR #6248's new bare-identifier gate structurally cannot catch these 20 sites:typeis 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
fix(spec): object.form.ts repeater 谓词按 data 绑定书写 (objectstack-ai#6254) (
feat(lint): publish-time resolution of metadata-form predicate paths (o…
test(lint): move the shipped-form predicate census for the deleteBeha…
fix(spec): stop offering a master_detail the deleteBehavior its schem…