Skip to content

[Decision] Should button declare isContainer? — the one public hit among the 53, carved out of #6779 by ruling #6804

Description

@claude

Filed by the domain:ui execution seat (PM session session_01CRJge11jso9TpXRWFt1Z49) as ordered by the ruling on #6779, 2026-08-29 (director session batch #3), point 2:

button 排除在清单之外、单独立卡裁:声明它会把 Button 从每个 kind:'react' 页作用域删掉(唯一 public 命中),且它读 children 是 label 兜底非布局包含——public-tier 取舍是产品决定;执行席按本裁决立卡送分诊。

button is therefore excluded from #6779's ratchet-to-zero list and is not in that card's dispatch. This card carries it.

What this seat verified directly

On origin/maind06059f24, packages/components/src/renderers/form/button.tsx:58:

{schema.label || renderChildren(schema.body || schema.children)}

⇒ Confirms the ruling's second ground: button reads children as a label fallback, not as layout containment. It renders children only when schema.label is absent.

⚠️ What this seat did NOT verify

That react-page.tsx iterates getPublicConfigs() rather than the whole registry, and that button is therefore the only public hit among the 53. That is #6764's measurement, relayed. What I did confirm is that getPublicConfigs() exists and is the predicate source pinned by packages/components/src/__tests__/react-page-scope.test.tsx and layout-containers-declare-containment.test.tsx — corroboration, not the reading itself. Re-derive the public-hit count before ruling, because "only one is public" is the fact the whole trade-off rests on.

⭐ A cross-card interaction neither ruling mentions

That same line reads schema.body || schema.children.

button is simultaneously inside two live questions ruled on the same day:

cardrulingwhat it wants from button
#6779census pin + ratchet listexcluded, pending this card
#6771retire the body dialect in the renderer, children only⚠️ its point 3 says renderers reading children || body drop the body arm in the same change

Read literally, #6771's execution note reaches this line — while #6779 deliberately carved button out. The two are not in conflict about containment, which is #6779's subject, but they do touch the same expression. ⇒ Whoever rules this card should say which change owns that line, and whoever implements #6771 should be told whether button is in or out of its body-arm removal. Flagging it before two branches edit one expression from opposite directions.

The question

Should button declare isContainer?

代价
A声明⛔ 按 #6764 的测量,这会把 Button每一个kind:'react' 页的作用域里删掉。它是 53 个里唯一的 public 命中,所以这是这批里唯一有真实用户可见代价的一个
B不声明,永久记录理由普查 pin 需要一条具名例外,且该例外必须写明依据(读 children 是 label 兜底),否则下一个人会把它当遗漏补上 —— 而那正是本族缺陷三次重发现的原因

四维分析

① 实际业务需求。⚠️ 零实测:没有记录显示有人把内容塞进 button 当布局容器。反过来,Button 从 react 页作用域消失是立刻可见的能力损失。⇒ 两边一个是假想收益,一个是确定代价。

② 平台长远合理性。isContainer 的语义是布局包含,不是"这个标签会渲染 children"。button 读 children 是 label 兜底 —— 声明它会让这个谓词从此意味着两件事。⇒ 本轴指向 B,而且理由是语义正确,不是权宜。

③ 防 AI 犯错。 ⭐ 分水岭,而且指向 B 但附一个硬条件:一个没有写明依据的例外,与一个漏网的遗漏,在证据上不可区分 —— 这正是 #3900 / #6740 / #6764 三次独立重发现的机制。⇒ 裁 B 必须把依据钉进 pin 本身(例外带理由字段),⛔ 不能只在清单里留个空条目。

④ 创业阶段不扩散。 B 零成本。A 要同时处理 react 页作用域的回退路径,量级完全不同。

本席意见:B + 例外带依据,但 ⛔ 不代裁 —— 裁决自己说了 public-tier 取舍是产品决定。

置信缺口

  1. ⚠️ 「唯一 public 命中」未经本席复核(见上)。这个数字若不是 1,整张卡的权衡改变。
  2. 未测:Buttonkind:'react' 页作用域消失后,现有的 AI 生成页面里有多少真的用了它。
  3. 未测:上面那条 body || children 的双重归属,finding(sdui-parser/components): the manifest tier reports unknown-prop on body — the one child-list key 10+ registrations actually honour #6771 的实施是否已经会碰它。

低摩擦裁决:回「A」或「B」。裁 B 请一并确认例外必须在 pin 里带依据。

⚠️分诊席:本卡由执行席按裁决代立,domain:* 与定级请照常由分诊产出 —— 本席只挂了 needs-user-decision

Related

#6779(裁决出处,ratchet 清单)· #6771(body 方言退役,与本卡共用一行表达式)· #6764(普查)· #6740 · #3900


Generated by Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpriority:p1

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions