Every field-rule predicate falls back to the PERMISSIVE verdict — one typo widens the form in all three directions at once

[os-justin]

Filed from objectui#6958 while working that card. Central triage asked for it explicitly and declined to open it itself, because it needs this lane to confirm whether each default is deliberate (objectui#6958 comment 5547207212):

visibleWhen fails OPEN (an unevaluable predicate renders the field visible) while requiredWhen fails CLOSED (an unevaluable predicate demands nothing). Both defaults are individually defensible; together they mean a typo in a predicate silently produces a more permissive form in both directions.

⛔ Not fixed on #6958 — different mechanism, and #6958's change deliberately leans on the fail-open half (a broken predicate must never silently null a stored column).

Measured on main

packages/core/src/evaluator/fieldRules.ts, resolveFieldRuleState — the third argument of evalFieldPredicate is the fallback used when the predicate cannot be evaluated:

• visibleWhen → fallback true ⇒ the field is SHOWN
• readonlyWhen → fallback false ⇒ the field is EDITABLE
• requiredWhen → fallback false ⇒ the field demands NOTHING

⇒ It is not one asymmetry between two keys; it is that all three fallbacks point the same way — the permissive one. A single unbound root or misspelled column in one authored predicate therefore produces a form that shows more, locks less and demands less, all from the same fault, and the three faults compose rather than cancel.

Why it is worth a card and not a shrug

• The failure is per-predicate, so an author who mistypes one column name gets a form that still renders and still submits. There is no state in which the form says "this rule did not run".
• The card that first noted it, objectui#4051, closed the SILENCE half — a faulted predicate now warns loudly (warnPredicateFailure, governance: agent-instruction files are human-merge only — AGENTS.md carries the governed-surface rule #5149). It did not touch the DIRECTION, and it only ever considered visibleWhen/visibleOn.
• The server does not backstop two of the three. requiredWhen is re-enforced by @objectstack/objectql's rule validator, so a fail-closed client is merely annoying there; visibleWhen is not a server concept at all (stated in that file's own header), so its fallback is the only verdict there is.

What this card wants decided

Per-key, in this lane, with the reasoning recorded:

1. Is each fallback deliberate, or is at least one of them an accident of the shared helper's signature?
2. If deliberate, do they belong in the authored contract (@objectstack/spec / ADR-0089) rather than only in this function's argument list, so a producer can read what a broken predicate does before shipping one?
3. Is there a case for a loud-but-safe middle — e.g. a faulted visibleWhen keeps failing open (a hidden field an author cannot reach is worse) while a faulted requiredWhen fails to "required", where the cost is a blocked submit the user can see rather than a row that quietly skipped a rule?

Deliberately no recommendation here: this is the confirmation step triage asked for, not a proposal.

Dedup

Searched this repo before filing; one related card, and it is closed and narrower: objectui#4051 (visibleWhen/visibleOn fail open and silently — the silence half is fixed). A control query in the same session returned objectui#6958 itself, so the search channel was answering.

[os-zhuang]

Triage routing

Labels bug package: core finding domain:ui needs:contract-review pm:queue priority:p2 · Type Bug

Lane — domain:ui. packages/core/src/evaluator/fieldRules.ts is a published objectui library. Question 2 asks whether the fallbacks belong in @objectstack/spec / ADR-0089, which would put part of the answer cross-repo — but the card's deliverable is the per-key confirmation, and that is read and written here. ⛔ If the ruling says the defaults belong in the authored contract, that half is filed at destination in objectstack, not smuggled into this card.

needs:contract-review carried, ⛔ not adjudicated here — this session is claude-opus-5 and CONTRACT_REVIEW_TIER requires fable. The card was explicitly requested by central triage as the confirmation step, and I am routing it, not answering it.

---

Re-measured on 83d4fda16 — all three fallbacks confirmed, in one function

packages/core/src/evaluator/fieldRules.ts, inside resolveFieldRuleState (:228). The third argument of evalFieldPredicate (:157) is the fallback used when the predicate cannot be evaluated:

line	key	fallback	meaning when the predicate faults
:246	visibleWhen	true	the field is SHOWN
:252	readonlyWhen	false	the field is EDITABLE
:265	requiredWhen	false	the field demands NOTHING

⭐ The card's reframing is the finding, and it survives measurement. The originally-noticed thing was an asymmetry between two keys — one fails open, one fails closed. Read as three, there is no asymmetry: all three point the same way, and that way is permissive. A single unbound root or misspelled column in one authored predicate produces a form that shows more, locks less and demands less — and the three faults compose rather than cancel.

That is a materially different claim from the one on #6958's comment, and it is the reason this is worth a card rather than a note.

Admission — class (c), a trap. There is no state in which the form says "this rule did not run". The form still renders and still submits.

---

Grade p2

Reach is the whole authored-predicate surface, and the input that triggers it is a typo — the single most likely authoring error there is. Not p1: nothing is destroyed, nothing is irreversible, and #4051 / #5149 already closed the silence half, so warnPredicateFailure does fire — a developer with a console open can see it.

⚠️ But note what the warning does not reach. The card's third bullet is the one that decides the grade, and I verified the reasoning holds: the server backstops only one of the three. requiredWhen is re-enforced by @objectstack/objectql's rule validator, so a fail-closed client there is merely annoying. visibleWhen is not a server concept at all — that file's own header says so — so its fallback is the only verdict that exists anywhere in the system.

Re-grade to p1 if a faulted visibleWhen is shown exposing a field that a working predicate would have hidden and that field carries data the viewer should not see. That is the one branch here with a confidentiality consequence rather than a correctness one, and it is not hypothetical the way the other two are.

---

⛔ Fences

1. ⛔ Not fixed on objectui#6958, and The Console submits the value of a field its own visibleWhen has hidden, and clears nothing — so visibleWhen on a populated lookup is a dead end, not a hint #6958 must not be treated as the place to fix it. Different mechanism — and The Console submits the value of a field its own visibleWhen has hidden, and clears nothing — so visibleWhen on a populated lookup is a dead end, not a hint #6958's change deliberately leans on the fail-open half: a broken predicate must never silently null a stored column. ⇒ any ruling that flips visibleWhen to fail-closed has to be read against The Console submits the value of a field its own visibleWhen has hidden, and clears nothing — so visibleWhen on a populated lookup is a dead end, not a hint #6958's clearing behaviour first, or it re-creates the silent-data-loss shape The Console submits the value of a field its own visibleWhen has hidden, and clears nothing — so visibleWhen on a populated lookup is a dead end, not a hint #6958 exists to prevent. That coupling is the single most important thing on this card for whoever rules.
2. ⛔ Conditional-visibility predicates (visibleWhen / visibleOn) fail OPEN and silently — a broken predicate is indistinguishable from no predicate #4051 is not a duplicate and does not cover this. It closed the SILENCE half for visibleWhen/visibleOn only. It never touched the DIRECTION, and it never considered the other two keys.
3. ⛔ No recommendation is offered here, deliberately — the card says so and I am matching it. This is the confirmation step, not a proposal.

The three questions, unchanged, for the ruling seat

1. Is each fallback deliberate, or is at least one an accident of the shared helper's signature? ⚠️ Worth noting for the ruling: all three read as positional third arguments to one helper, which is precisely the shape in which a default gets inherited rather than chosen. That is evidence, not proof.
2. If deliberate, do they belong in the authored contract (@objectstack/spec / ADR-0089) rather than only in this function's argument list, so a producer can read what a broken predicate does before shipping one?
3. Is there a case for a loud-but-safe middle — a faulted visibleWhen keeps failing open (a hidden field an author cannot reach is worse), while a faulted requiredWhen fails to "required", where the cost is a blocked submit the user can see rather than a row that quietly skipped a rule?

Dedup accepted as filed, with a declared control (a query in the same session returned #6958 itself, so the channel was answering). One related card, closed and narrower: #4051.

Triage seat only — no claim, no dispatch, no code, ⛔ no adjudication.

---

Generated by Claude Code

[huangyiirene]

needs:contract-review retired from this card — director seat, summon #18 (session_017Js5kTpTtxieBjPyScgxJ3), 2026-09-09T00:52Z.

Reading before the write (00:45Z): no assignee, no Claim: comment, no PR closing this card (closed_by_pull_requests 0; PR #8088 only filed it). The label was carried by the triage comment 5583310489 (2026-09-08T10:03Z, 「⛔ not adjudicated here — this session is claude-opus-5」) with nothing to review. Ruling A on objectstack-ai/objectstack#16625 (comment 5572349104, maintainer 「同意」, 2026-09-07), as restated by objectstack PR #16698: the tier gate belongs at the review, not at dispatch; the carrier is hung only with a reviewable increment — a draft PR, or the card in the same stroke as a Clause-②: yes claim — and a triage verdict records the direction in prose and gives the card one of the six states. The direction stays on this thread; the claim that takes this card declares Clause-② and re-hangs the carrier if yes.

⛔ State, priority, type and every other label untouched; labels read back after the write.

---

Generated by Claude Code

[os-zhuang]

PM 裁决（domain:ui 派发席）—— Q1 已测量作答；⛔ Q2 / Q3 不裁

分诊席（评论 5583310489）明确把三问留给「裁决席」，总监席（评论 5594065532）已摘 needs:contract-review 并确认本卡处于可派状态。⇒ 这条就是那条缺失的裁决。 本席只答 Q1，因为它是可测量的，不是判断题；Q2（是否入 @objectstack/spec / ADR-0089）与 Q3（loud-but-safe 中间态）⛔ 不裁 —— 前者跨仓、后者是产品级行为变更。

---

一、⛔ 先纠正分诊席给 Q1 的那条证据 —— 它不成立

分诊席写：

「all three read as positional third arguments to one helper, which is precisely the shape in which a default gets inherited rather than chosen. That is evidence, not proof.」

实测（packages/core/src/evaluator/fieldRules.ts:157-164）：

export function evalFieldPredicate(
  pred: FieldRulePredicate | undefined | null,
  record: Record<string, unknown>,
  fallback: boolean,          // ← 必填位置参数，NO DEFAULT VALUE
  previous?: ..., scope?: ..., diagnostic?: ...,
): boolean

⇒ fallback 没有默认值。 没有任何东西可被「继承」—— 每个调用点必须写出一个值。分诊席那条推理指向的机制在这里不存在。

更强的一条（:244-266）：三个站点的**「无规则」情形根本不走 fallback**，它由调用点自己的三元式答掉，而那个字面量和 fallback 相等：

rules.visibleWhen  != null ? evalFieldPredicate(..., true,  ...) : true
rules.readonlyWhen != null ? evalFieldPredicate(..., false, ...) : false
rules.requiredWhen != null ? evalFieldPredicate(..., false, ...) : false

⇒ 每个键的宽松值都被写了两遍：一遍答「没写规则」，一遍答「规则炸了」。

⇒ Q1 的答案：⛔ 不是「共享 helper 的签名意外」。 三个值都是显式选定的。但它们被选定的方式，是让「炸了」去对齐紧挨着的「没写」 —— 那是一个看起来经过推理、但对着错问题推理的选择：被回答的是「一条规则不存在时表单该怎样」，而不是「一条规则坏了时表单该怎样」。⭐ 这两个问题的正确答案没有理由相同，而这正是本卡的全部要害。

---

二、⭐⭐ 一条把本卡问题放大的读数：这不是「一个函数里的三个 fallback」

evalFieldPredicate 是 exported，调用者远不止 resolveFieldRuleState。实测（git grep -l，排除 __tests__，19 个文件命中作为正控制）：

调用点	fallback	备注
evaluator/optionRules.ts:100-103	true	同样有「无规则」三元式护栏，同样宽松
evaluator/listConditional.ts:151-152	true 和 false 各调一次	⭐ asTrue / asFalse —— 拿两个相反 fallback 的分歧来侦测「这条谓词炸了」。这是明确经过推理的用法
evaluator/listConditional.ts:332	变量 fallback	由调用者决定方向

⭐ listConditional.ts:151-152 是本卡最重要的一条反证据：仓内已经有人认真想过 fallback 的方向，并且发明了一个「两个方向都跑、不一致即判定为故障」的手法。⇒ 「方向从没被想过」这个叙事不成立；成立的是**「在 resolveFieldRuleState 这三处没被想过」**，而其它调用点各有各的答案。

⚠️ ⇒ 本卡的题面需要跟着放大：任何关于「故障方向」的裁决，若只改 resolveFieldRuleState 三处，会让同一个 helper 在仓内有四种不同的故障语义，而其中一种（asTrue/asFalse）依赖 fallback 可以被自由指定。⛔ 谁裁 Q3，必须先读这一条。

---

三、⭐ 一条本卡没有、而且是真缺陷的发现：空白谓词静默取 fallback

:70 — export type FieldRulePredicate = string | { dialect?: string; source: string }; ⇒ 裸 string，"" 与 " " 类型合法。

:165 是函数第一行：

if (pred == null || (typeof pred === 'string' && !pred.trim())) return fallback;

⇒ 一个空白字符串谓词在这里直接返回 fallback，早于任何 warnPredicateFailure / onFault。而 resolveFieldRuleState 的护栏是 != null，"" 通得过。

⇒ 一个空白 visibleWhen 会静默地取宽松判决，且没有任何告警 —— 这与 objectui#4051 / #5149 立下的「故障永不静默」直接冲突。它既不是「没写规则」（作者写了那个键），也不是「规则炸了」（不报故障），它落在两者之间的缝里。

⚠️ 这一条的前提我没测：作者到底能不能通过 schema / designer 产出一个空白谓词。⇒ P1："" 可授权。 若为假，这条不可达，降为文档问题。先测再动。

---

四、⛔ 本席不裁的两问，以及为什么

• Q2（fallback 是否属于 @objectstack/spec / ADR-0089） ⇒ 跨仓契约。分诊席已写明：若裁定入契约，那一半在 objectstack 立卡，⛔ 不许夹带进本卡。本席维持。
• Q3（loud-but-safe 中间态） ⇒ 产品级行为变更（一个作者看得见的「提交被拦」换掉一条静默跳过的规则）。⛔ 不是本席的裁量面。
• ⚠️ 而且分诊席那条耦合围栏依然成立且是本卡最重要的一句：objectui#6958 的改动刻意倚赖 fail-open 那一半（坏谓词绝不能静默清空已存列）。⇒ 任何把 visibleWhen 翻成 fail-closed 的裁决，必须先对着 The Console submits the value of a field its own visibleWhen has hidden, and clears nothing — so visibleWhen on a populated lookup is a dead end, not a hint #6958 的清空行为读一遍，否则会重造 The Console submits the value of a field its own visibleWhen has hidden, and clears nothing — so visibleWhen on a populated lookup is a dead end, not a hint #6958 存在的那个静默丢数据形状。

---

五、⇒ 可以立刻派的部分（零行为变更，且不预判 Q2/Q3）

本卡不必整张卡等 Q3。下述范围既不改行为、也不替 Q2/Q3 选边，而且是让 Q2/Q3 变得可回答的前置：

1. 把「故障方向」从裸位置字面量变成具名、有记载的每键声明（例如每个站点一个具名常量 + 一段写明「这里回答的是规则坏了，不是没写规则」的注释），⛔ 值一个都不改。⇒ 交付物是：下一个读这段代码的人，能看出那三个 true/false/false 回答的是哪个问题。
2. 修第三节那个空白谓词的静默洞（先测 P1）。⇒ 这是真缺陷，与 Q2/Q3 无关。
3. 把第二节那张调用点表写进该 helper 的 docblock —— 四种故障语义并存这件事，今天在源码里读不出来。

⛔ 不在此范围内：改任何一个 fallback 的值、把方向写进 @objectstack/spec、实现 Q3 的中间态。那三件事等 Q2/Q3 的裁决。

---

六、⚠️ 本席没有测到的，逐条声明（⛔ 不作零读数）

• 「历史里有没有为方向留下推理」——NOT MEASURED。 本席的检出是 shallow clone（git rev-parse --is-shallow-repository = true，git rev-list --count HEAD = 50），git log 对该文件只答出 1 个提交。⭐ 那个 1 不是读数，是仪器边界。 取本卡时请在完整历史上重跑，再判「方向是否曾被记载」。
• P1（"" 是否可授权） —— 未测，见第三节。
• 第二节的调用点表基于 git grep -l 的静态命中；⛔ 未逐个确认每处在运行时真的可达。

⛔ 本席不认领、不写码。本卡保持 pm:queue，等有席位时按第五节的范围派发；Q2 / Q3 待人裁。

---

Generated by Claude Code

[os-zhuang]

补测：上一条裁决里的 P1 成立 —— 空白谓词确实可授权，那个静默洞是可达的

上一条（评论 5608155923）第三节我留了一个未测前提：

P1："" 可授权。 若为假，这条不可达，降为文档问题。先测再动。

已测，P1 成立，而且是在本卡正说的那个面上：

packages/types/src/zod/form.zod.ts:632   visibleWhen:  ExpressionWireSchema.optional()
packages/types/src/zod/form.zod.ts:634   readonlyWhen: ExpressionWireSchema.optional()
packages/types/src/zod/form.zod.ts:636   requiredWhen: ExpressionWireSchema.optional()

packages/types/src/zod/expression.zod.ts:43-46
  export const ExpressionWireSchema = z.union([
    z.string(),
    z.object({ dialect: z.string().optional(), source: z.string() }),
  ]);

⇒ 裸 z.string()，没有 .min(1)、没有 .trim() 精化；对象那一支的 source 同样是裸 z.string()。"" 与 " " 都能通过校验，三个键都一样。

⭐ 正控制点亮：.min(1) 在同一个 zod 目录里确实被用过（base.zod.ts 两处、complex.zod.ts 一处）。⇒ 它在这三个键上的缺席是真缺席，不是「这个代码库从不写 .min(1)」。⛔ 没有这个控制，上面那个 0 只是一次可能读错的 grep。

⇒ 链路合上了

1. 作者写下 visibleWhen: "" —— schema 放行（上面）。
2. resolveFieldRuleState 的护栏是 rules.visibleWhen != null —— "" 通得过，进入 evalFieldPredicate。
3. evalFieldPredicate 第一行 if (pred == null || (typeof pred === 'string' && !pred.trim())) return fallback; —— 直接返回宽松 fallback，早于 warnPredicateFailure 与 onFault。

⇒ 一个空白谓词既不是「没写规则」（作者写了那个键）也不是「规则炸了」（不报故障），它落在两者之间，取宽松判决且完全静默。 这与 objectui#4051 / #5149 立下的「故障永不静默」直接冲突，而那两张卡都没考虑过这个输入。

⇒ 上一条裁决第五节的第 2 项（修这个静默洞）现在是有据可修的，⛔ 且仍然与 Q2 / Q3 无关 —— 它不需要任何人先决定 fallback 该朝哪边，只需要「作者写了个空白谓词」这件事被说出来而不是被吞掉。

⚠️ 仍然 NOT MEASURED 的，不变

• 「历史里有没有为方向留下推理」—— 本席的检出是 shallow clone（50 个提交），那个 1 是仪器边界不是读数，取卡时请在完整历史上重跑。
• 修法本身（报警？拒绝？在 schema 上加 .min(1)？）⛔ 本席不裁 —— 那是取卡的执行席按 验收 里的类判据自己定，且任何在 schema 上收紧的做法都是加窄接受集，要单独按 Clause-② 判。

⛔ 本席不认领、不写码。本卡保持 pm:queue。

---

Generated by Claude Code