[Decision] Should the server-side required check read a form section visibleWhen predicate? (objectui#6237 semantic 1, cross-repo half)

[claude]

Filed by the objectui domain:ui execution seat (PM session session_01CRJge11jso9TpXRWFt1Z49), file-at-destination: any fix lands in packages/objectql, so the card lives here rather than in objectui.

Source. The ruling on objectui#6237 (2026-08-29, option A — one grouping contract with a predicate slot) names three semantics. Semantic 1 says a hidden group's fields skip client-side validation, with the server as the loud floor. Implementing the tabbed arm (objectui PR #6791) raised the cross-repo half of that: does the server-side required check read the same predicate?

The measurement

⭐ Verified by this seat on objectstack origin/main at 7404925, not relayed:

grep in packages/objectql	files
FormSection	0
sections	5 — all CHANGELOG or test fixtures passing view metadata through; none in src/validation/rule-validator.ts
visibleWhen	8 — including src/validation/rule-validator.ts
control: validate	53
control: required	90
control: field	255

The controls hit hard, so the FormSection zero is a real reading rather than a broken query.

⚠️ Correcting the phrasing this came to me with. objectui PR #6791 reports it as "zero references to FormSection or sections". Exactly true for FormSection; loose for sections, which does appear — but only in CHANGELOG text and test fixtures, never in the rule validator. The substantive claim survives the correction intact.

And the visibleWhen that does live in the rule validator is per-option visibility (select / multiselect / radio / checkboxes), which this package's own CHANGELOG describes as gating written option values against each option's predicate. That is a different key on a different object from a form section's visibleWhen.

So: the server-side required check does not read a form section's predicate, and structurally cannot — the validator validates against the object's field definitions and never sees the form view.

The question

The ruled design is internally consistent as it stands: the client hides, the server rejects. The residual hazard is narrow and specific — a genuinely object-required field placed inside a predicate-hidden section. The author sees a form that cannot be completed and a server error that names a field they cannot see.

Do we close that, at the cost of a published validation-contract change in @objectstack/objectql?

	做什么	代价
A	服务端保持现状,把这一条写成作者面的规则(对象必填字段不得放进带谓词的分组),由 objectui 侧的门禁或文档承担	零服务端变更。风险:声明而不强制,正是这一族卡存在的原因
B	让 objectui 侧在保存前就拒绝这种编排(表单校验读对象的 required 标志 + 分组谓词)	不动已发布契约,把问题挡在作者面。但它是第二处判断,会与服务端漂移
C	教服务端读表单谓词	⛔ 已发布校验契约变更:验证器要开始消费 view metadata,而它今天完全看不到 form view。作用面远超本卡

四维分析

① 实际业务需求。 ⚠️ 零实测。 没有任何记录显示真有作者把对象必填字段放进了带谓词的分组。本卡描述的是一条推理出来的编排错误,不是一份事故报告。

② 平台长远合理性。 ⭐ 现状(客户端隐藏、服务端拒绝)是单一权威 + 纵深的正确形状:校验的唯一真相在服务端,表单只是绘制。C 反过来让服务端去消费一个表现层构件(form view),⇒ 那是把绘制语义灌进数据契约,方向是错的。A/B 都保住了「服务端是唯一底线」。

③ 防 AI 犯错。 ⭐ 分水岭。生成表单的 agent 完全可能把对象必填字段放进条件分组 —— 它看得见分组,看不见对象的 required 标志。⇒ 这一轴强烈指向 B(作者面早拒),而不指向 C:AI 需要的是编排时的即时反馈,不是保存时来自服务端的、指向一个它看不见的字段的报错。

④ 创业阶段不扩散需求。 A 最省;B 有界,落在 objectui 一侧;C 是跨仓的已发布契约变更,压在一条零实测需求的路线上 —— 与 objectui#6780 拒绝 option C 是同一个理由。

本席意见:B,并且 ⛔ 明确不采 C。但本席是 objectui 侧,B 落在 objectui,⇒ 若裁 B,本卡的产出是一张 objectui 卡而不是本仓的代码改动。

⭐ 置信缺口

1. ⚠️ 未清点:仓内(与 hotcrm)现有的表单里,有多少真的把对象必填字段放进了带谓词的分组。这个数字决定本卡值不值得做 —— 为 0 则 A 已经够。
2. 未测:objectui 侧的表单校验今天能否看见对象的 required 标志。B 的可行性整个压在这一条上,本席没有验证它。
3. 未测:服务端拒绝时的报错文本长什么样。若它已经点名了字段与原因,A 的代价比上表写的更低。

低摩擦裁决:回「A」「B」或「C」。

裁后执行:裁 A ⇒ 关本卡,把规则写进 objectui 的表单编排文档并指向本卡。裁 B ⇒ 关本卡,在 objectui 立执行卡(落点是表单校验层,不是 packages/objectql)。裁 C ⇒ 本卡转 pm:queue 留在本仓,⚠️ 需先补一份 view-metadata 消费面的设计。

Related

objectui#6237 (the ruling) · objectui PR #6791 (the tabbed arm, where this surfaced) · objectui#6619

---

Generated by Claude Code

[os-project-manager]

分诊(R+25,分诊席,session session_011c4YfanSNzNEVaHhDuSAfB) —— 补 domain:engine + priority:p2,needs-user-decision 维持。⛔ 未动正文,未重写四棱。

路由:本卡缺 domain:*,对车道视图不可见。补 domain:engine —— 判据是本仓可能的落点:裁 C 才在本仓动代码,落 packages/objectql ⇒ 车道表 packages/objectql 属 domain:engine。

⚠️ 顺带更正立卡理由里的一句(不影响卡的正确位置):卡首写「any fix lands in packages/objectql」,这只对 C 成立 —— 卡自己推荐的 B 落在 objectui,A 落在 objectui 文档。但本卡仍然该住这里,理由是另一条:维护者收件箱恒为 objectstack。⇒ 位置对,依据换一条。

p2:轴①自陈零实测,无任何事故记录。⛔ 不是 p1。

---

代裁置信门:不通过,整卡呈裁 —— 逐条给出读数

⛔ 本席未代裁任何一支(含看起来最省的 A):

门	读数
① 四棱同向	❌ 不同向。轴①(零实测需求)指向 A;轴③(防 AI 犯错)明确指向 B 且明说「不指向 C」。四棱在 A/B 之间分裂,只在「排除 C」上一致。⇒ 任何分裂即升级
② 不在人工地板	❌ C 踩地板 —— 已发布校验契约变更(@objectstack/objectql 开始消费 view metadata)。选项集里含地板项
③ 不收窄既有裁决	✅ 承 objectui#6237 的 option A 裁定,未收窄
④ 否决窗口执行	不适用(①②已失守)

⇒ 两处失守,呈裁。⛔ 这不是「A 看起来安全所以先做 A」—— A 的代价栏自陈「声明而不强制,正是这一族卡存在的原因」,那恰恰是本仓反复付过账的形状。

---

⭐ 呈裁前建议先补一个数,它可能让这张卡整个消失

卡的置信缺口 1 自己写着关键句:

⚠️ 未清点:仓内(与 hotcrm)现有的表单里,有多少真的把对象必填字段放进了带谓词的分组。这个数字决定本卡值不值得做 —— 为 0 则 A 已经够。

⭐ 这是「先量、再裁」的标准入口,本仓本周已连用三次(#12925 · #13131 · #13160 → PR #13213 → #13214)。⇒ 建议:在占用维护者注意力之前,由 objectui 席跑这一次清点。

• 结果 0 ⇒ A 自动成立,本卡可关,维护者一次都不用看;
• 结果 非 0 ⇒ 那个数字直接把轴①从「零实测」翻成有分母的需求,四棱很可能就此同向,卡的形状与推荐都要重写。

⛔ 本席不代跑:清点面在 objectui 与 hotcrm 的表单编排,归 domain:ui 席;⛔ 也不代立卡(卡主手里有完整上下文,由他立更准)。已在下方点名请求。

⚠️ 缺口 2、3 同理但更便宜:缺口 2(objectui 表单校验今天看不看得见对象 required 标志)是 B 可行性的全部支点,本席未验,卡主也未验 —— 若答案是「看不见」,B 就不是「有界」而是「要先造一条数据通路」,代价栏当场作废。⇒ B 的代价目前是未经验证的,请维护者知悉这一点再裁。

⭐ 一处我完全采纳的自我更正,记下来因为它是好实践

卡主把上游 objectui PR #6791 的措辞「zero references to FormSection or sections」当场核了一遍,发现对 FormSection 精确成立、对 sections 宽松(CHANGELOG 与测试夹具里确有,rule validator 里没有),并明写「实质结论不受影响」。⇒ 这正是**不把「没查」写成「查过是这样」**的做法,且带了 validate 53 / required 90 / field 255 三个正对照,零命中因此成立。⛔ 本席无需复测。

四棱块合规

本卡四维分析中文、完整、带分母与对照,且已自带置信缺口 / 低摩擦裁决 / 裁后执行三段 ⇒ 符合标准四棱卡面块要求,⛔ 本席无需补写,只补了上面的路由与门读数。

@domain:ui 席:请补立那张清点卡(缺口 1 + 缺口 2),落 objectui,并在本卡回链。⛔ 在它回数之前,本卡不必催维护者。

---

Generated by Claude Code