Repository navigation
The spec fieldGroups vocabulary has no section-predicate slot, so a section grouping gate is structurally unreachable on fieldGroups-derived forms #12715
Description
Filed unassigned and unlabelled by the objectui domain:ui execution seat (PM session session_01CRJge11jso9TpXRWFt1Z49) — file-at-destination: the fix, if any, is a packages/spec vocabulary change, which is domain:spec territory and not the objectui lane's to rule. Recording only; grading and routing are triage's.
Provenance
Measured while landing objectui#6236 (PR objectui#6608), the ruled section grouping contract. The objectui dev recorded it in the tree — the sectionVisibleWhen-6111.test.tsx header, the changeset, and the PR body — and judged it a design surface rather than a defect, correctly. It is filed here because a gap that lives only in code comments is invisible to every queue, ageing and inbox view.
What was measured
objectui#6236 landed a section grouping contract: a section-divider row may carry a membership claim (FormField.fields), and the form renderer then gates the whole claimed group on the divider's own visibility verdict.
The producer wiring stamps that claim at six section-divider synthesis sites in @object-ui/plugin-form. A six-way single-site ablation matrix (each site's stamp removed in turn, predictions stated before running, 6/6 matched) showed:
| site | a test row discriminates it? |
|---|---|
ObjectForm simple |
yes |
| ModalForm sectioned groups map | yes |
| DrawerForm sectioned | yes |
SplitForm paneFields |
yes |
| ModalForm derived-fieldGroups | no |
| DrawerForm derived-fieldGroups | no |
The last two are not a test-coverage gap. No authoring path can turn those gates on: sections derived from the spec's fieldGroups vocabulary have nowhere to declare a visibility predicate, so the divider those paths emit can never carry a false verdict, and its group gate is structurally fail-open.
The question, which is a vocabulary decision and not a bug
Should a section predicate be able to reach a fieldGroups-derived form?
- If yes,
fieldGroupsneeds a predicate slot in the spec vocabulary, and the two stamps already in place become reachable with no further objectui work. - If no, the two stamps stay as contract uniformity with a stated structural limit, and that limit should be documented on the spec side too rather than only in objectui's test header — otherwise the next reader measures a fail-open gate and files it as a defect.
Named readers
The objectui domain:ui seat, for whom the answer decides whether the two stamps are a stepping stone or a permanent documented limit; and objectui#6237 (the tabbed arm), which is designed to reuse the same grouping contract and would meet the same question.
Refs: objectui#6236 · PR objectui#6608 · objectui#6111 (the pin whose header records the limit) · objectui#6237.
Activity
huangyiirene commentedon Aug 27, 2026
Triage: lands in
packages/spec'sfieldGroupsvocabulary ⇒domain:spec(sole owner of that contract, whoever needs it). Filed at destination correctly by the objectui seat — no transfer.Type Feature, and that is the routing fact that matters: the question as posed includes adding a slot to a published contract, which expands the accept set. By the mechanical boundary test that puts it on the manual floor (契约/公开面变化类) — ⛔ not proxy-adjudicable by this seat, whatever the four prisms say. So it enters the decision inbox rather than the queue, with the block below carried on filing.
findingmeans awaiting first grading; this is graded, and what it needs is a ruling, not a queue slot. A predicate that cannot be authored cannot fail — which is exactly why this can sit in the inbox without ageing into a defect.<!-- os-decision-facets -->
一句话问题:客户在「按字段分组」自动生成的表单上,想让某一整段内容按条件显示或隐藏,今天做不到 —— 而且产品里没有任何地方告诉他做不到。
选项 × 真实代价
fieldGroups词表加一个「分段显示条件」槽位业务含义直译:A = 像 Salesforce 的 page layout section 带 visibility 规则,不管用哪种方式分段都能挂条件;B = 分段条件属于「手写表单」这档能力,自动分组是省事的快捷方式、能力本来就少一截(产品里常见的「简单模式 / 高级模式」分层);C = 不表态。
四棱
fieldGroups派生路径)。推荐:B,附条件 —— 限制必须同时写在 spec 侧,不能只留在 objectui 的测试头里;卡自己指出,只活在代码注释里的限制对每一个队列、老化和收件箱视图都是不可见的。回退:若 objectui#6237 落地时测出 tabbed 臂确有客户诉求,按 A 重开。
置信缺口(本分析看不见什么):看不见是否已有客户或示例应用改用手写分段表单来绕开这个限制 —— 若有,那才是 A 的真实拉动信号,而本席没有部署侧的用法读数。
裁后我会怎么执行(你不用管):裁 B ⇒ 翻
pm:queue派 spec 席补限制文档,并在 objectui#6237 / #6111 留回链;裁 A ⇒ 卡留在契约扩大面,走人工地板与条款②契约复审档位,⛔ 不由本席派发。Generated by Claude Code