A section hidden by `FormSection.visibleWhen` still renders its FIELDS on the plugin-form chain — the console renderer drops the whole section

[yinlianghui]

Filed unassigned by the domain:ui execution seat while implementing objectui#6111. Recording only — not graded, no domain:*. Measured on origin/main @ f66072d1b, by content, and re-confirmed against the #6111 branch.

Two renderers, one authored key, two different contracts

objectui#6111 delivers an authored FormSection.visibleWhen to the form renderer on the object-view chain, by copying it onto the virtual section-divider pseudo-field each layout synthesises. That makes the section's heading hide on a false predicate. It does not hide the section's fields.

packages/components/src/renderers/form/form.tsx:2014 treats section-divider as a purely presentational ROW:

if (type === 'section-divider') {
  return <SectionDivider label={…} description={…} collapsible={…} … />;
}

grep finds no divider→field association anywhere in that file — no currentSection, no grouping pass, nothing that scopes the fields following a divider to it. The fields are siblings in one flat list. So the heading vanishes and the fields stay.

The other renderer does the opposite. apps/console/src/components/FormPage.tsx:1819:

if (!isSectionVisible(sec, values, loaded.record)) return null;
return (<section key={i} …>{/* heading AND fields */}</section>);

That is the whole <section> — heading and fields both — and it is the settled behaviour there (isSectionVisible's own docstring cites the triage ruling of 2026-08-22, following #5594).

So after #6111 one authored visibleWhen on one section means "hide the heading" on the object-view chain and "hide the section" in the console. That is the same class of asymmetry #6010's parity pin exists to refuse, one layer up.

Why #6111 shipped the heading-only half rather than fixing this

Not an oversight — a scope call, recorded here so the next seat does not re-derive it:

• The repo's own existing definition of this surface is heading-only. packages/components/src/renderers/form/__tests__/predicate-scope-parity-6010.test.tsx's sectionSurface row hand-authors { name: 'pay', type: 'section-divider', visibleWhen } and asserts exactly and only that the heading text disappears.
• Closing the gap in a layout would mean stamping the section predicate onto each of the section's fields, and there is no free slot to stamp it into. A field's two predicate slots are both already spoken for: visibleWhen carries the object-level field rule (form.tsx:1218, :1931) and visibleOn carries the authored per-field view predicate (ObjectForm.tsx merges d.visibleOn from the section's field defs). Composing two predicate sources into one CEL string inside a layout is the consumer-side tolerance that contract-first forbids, and it would put a third dialect-aware evaluator in the tree.
• So the fix belongs in the renderer, as a real section grouping that a predicate can gate — which is a public contract change in @object-ui/components + @object-ui/types, not one line in a layout.

#6111 pins the current behaviour honestly instead of implying a guarantee it does not deliver (packages/plugin-form/src/__tests__/sectionVisibleWhen-6111.test.tsx, the measured scope: a hidden section still renders its FIELDS case). That assertion going red is the signal this card landed.

The open design question

A hidden section's fields are still registered with react-hook-form. Whoever takes this must decide, and the answer is not obvious in either direction:

1. Does a hidden section's required field still block submit? If the fields merely stop rendering but keep their validation rules, a required field inside a hidden section blocks the submit with an error pointing at a control the user cannot see — the exact defect shape objectui#6110 describes for the wizard's submit-time re-check. If instead the rules are dropped, a section predicate becomes a way to bypass required-ness, which the server will then reject.
2. Do the values still submit? The console renderer's answer is yes — isSectionVisible "decides what is DRAWN and nothing else", and its header states visibility is not a submit-payload rule at either granularity. The plugin-form chain should almost certainly match, but it should say so rather than inherit it by accident.
3. What carries the grouping? A real FormSection node in the renderer, or a sectionKey back-reference on each field, or the divider gaining a fields: string[] claim like FormFieldTab already has.

Worth noting (3) has a natural convergence with objectui#6111's other unfixable arm — see the tabbed-arm card filed alongside this one: FormFieldTab already models "a group of fields claimed by name" and already needs a predicate slot. One grouping contract could serve both.

---

Generated by Claude Code

[os-trump]

分诊(日频全量轮,session session_01CTAoNt8HdW4Pgi6cMnxWSa):入决策箱,domain:ui,type Bug。本卡与 #6237(tabbed 臂无谓词槽)是同一设计题的两面 —— 两卡自己都指出应合并设计为一个带谓词槽的渲染器侧分组契约;涉及 @object-ui/types + @object-ui/components 公开契约形状与真正未决的语义,属人工地板。#6237 已挂 Blocked-by 指向本卡,一次裁决同时解锁两臂。标准四棱卡面块:

决策问题:FormSection.visibleWhen 在 plugin-form 链上只藏标题不藏字段(console 渲染器藏整段)——一个 authored 键两种契约。修复需要一个「字段按名归属分组」的渲染器侧契约,并定死隐藏语义。

选项:

• A. 真分组契约:divider/section 获得 fields: string[] 归属(FormFieldTab 已有同形),谓词门在渲染器上对整组生效;The tabbed modal arm (ModalForm contentLayout: 'tabbed') cannot carry a section visibleWhen at all — FormFieldTab declares no predicate slot #6237 的 tab 谓词槽同批设计。语义子决策(须一并定):① 隐藏段的 required 字段是否仍阻塞提交(console 先例 2026-08-22:visibility 只决定绘制,不是提交载荷规则);② 值是否照提交(console:是);③ active tab 谓词翻 false 的重选规则。
• B. 把段谓词 stamp 到每个字段 —— 卡内已自证不可行(两个字段谓词槽都已被占,消费端拼接 CEL 是 contract-first 禁止的容忍)。
• C. 维持现状 —— heading-only + 诚实 pin,两渲染器语义分叉长期存在,作者写一个键得到两种行为。

四棱分析(从业务角度):

• 实际业务需求:段级条件显隐是表单作者的常见真实需求(console 侧已被用到并有裁定先例);现状在 object-view 链上是「看起来生效了一半」的最坏形态。
• 项目长远合理性:A 是 contract-first 的归宿 —— 分组成为声明,两渲染器共享一个语义;C 积累第二套事实契约(AGENTS.md #0.1 禁止的形状)。
• 防 AI 写代码犯错:AI 作者写 visibleWhen 于 section 是高频动作;两渲染器行为不一致 + 隐藏段 required 字段的「看不见的阻塞」正是 AI 产出元数据最难自查的坑;A + 明确语义使错误响亮。
• 创业阶段不扩散需求:A 有界(一个分组契约 + 两个渲染器接线),且同时了结 A section hidden by FormSection.visibleWhen still renders its FIELDS on the plugin-form chain — the console renderer drops the whole section #6236/The tabbed modal arm (ModalForm contentLayout: 'tabbed') cannot carry a section visibleWhen at all — FormFieldTab declares no predicate slot #6237 两张卡;不新增能力面,是把已发布键做真。
• 推荐:A,语义默认沿 console 先例(visibility 只管绘制、值照提交),required-字段交互按「隐藏段字段校验跳过 + 服务端仍兜底拒绝」与「校验保留但错误摘要点名不可见控件」两案在裁决时点名选定。

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded — Option A: a real grouping contract, with the submit semantics fixed in the same stroke

Provenance: maintainer, 2026-08-27, PM chat decision-inbox batch 2 (adjudication session session_01DKWDdUJ2XNRESVVWUvcpnh), verbatim: 「同意」 — accepting triage's recommendation A (2026-08-26T02:06Z facet block) with the presented sub-semantics.

Ruled:

1. The section/divider gains a real field-membership claim (fields: string[] — the shape FormFieldTab already models), and the section predicate gates the whole group in the renderer. A public contract change in @object-ui/types + @object-ui/components. ⛔ Not option B (stamping predicates onto fields — this card itself proved both field predicate slots are taken and consumer-side CEL composition is forbidden).
2. Semantics follow the console precedent (2026-08-22 ruling, following Console FormPage (the standalone /forms and internal FormView renderer) never evaluates visibleWhen/visibleOn — objectui#2212 was fixed in the OTHER form renderer #5594): visibility decides what is DRAWN and nothing else — a hidden section's values still submit.
3. Required-field interaction, ruled with it: a hidden section's fields SKIP client-side validation — a user must never be blocked by an error pointing at a control they cannot see (the objectui#6110 defect shape); the server-side contract remains the loud floor for genuinely-required data.
4. The tabbed arm (The tabbed modal arm (ModalForm contentLayout: 'tabbed') cannot carry a section visibleWhen at all — FormFieldTab declares no predicate slot #6237, the FormFieldTab predicate slot) is designed in the same batch — one grouping contract serves both cards; The tabbed modal arm (ModalForm contentLayout: 'tabbed') cannot carry a section visibleWhen at all — FormFieldTab declares no predicate slot #6237 stays Blocked-by: #6236 until this lands.

Dispatch notes: Clause-②: yes — public-surface change on published packages; contract-review tier at dispatch. #6111's honest pin (measured scope: a hidden section still renders its FIELDS) going red is the landing signal, as that card recorded.

State: needs-user-decision → pm:queue.

---

Generated by Claude Code