parity 门的反方向没推到全仓:7 个 block 共 15 个 spec 已声明的顶层键没有任何 `inputs` 发布,其中 3 个渲染器实读(`record:details.hideFields` / `record:related_list.relationshipValueField` / `element:text_input.defaultValue`)

[yinlianghui]

发现于 #3797 / PR #3806 的实施过程。那一单按判级只推了一个方向(「registry 不得声明 spec 不接受的顶层 input」),PR #3795 的单块版其实有两个方向,另一个是「spec 有的键,inputs 里必须能被作者发现」。反方向没推到全仓,本单是把它补上。未认领,交 PM triage。

为什么反方向同样有害

inputs 是 gen-manifest.ts 序列化进 sdui.manifest.json 与 sdui-intrinsics.d.ts 的发布面。一个 spec 声明了、渲染器也兑现了、但 inputs 不提的键,对读 manifest 的作者(尤其是 AI 作者)就是不存在:它不在设计器面板里,不在生成的 .d.ts 里,写了还会被 sdui-parser 的 manifest 门报 unknown-prop warning。这正是 #3407 的原始抱怨(readonly 早已被兑现,只是 description 没提,作者读不到)。

实测清单(objectui origin/main @ c4c0ac897,pin @objectstack/spec@17.0.0-rc.5)

用 PR #3806 落的门同一套 derivation 反着跑(specTopLevelKeys(type) 减去 inputs 名,aria 已排除 —— 它是无障碍逃生口,record:details / record:activity 都有成文理由不声明):

element:record_picker  displayField, searchFields, filter, multiple, targetVariable
element:text_input     defaultValue, targetVariable
page:card              actions
page:header            icon
page:tabs              type
record:details         hideFields
record:related_list    relationshipValueField, add

这 15 条不是一类东西,triage 时请分开看:

A 类 —— 真缺口:渲染器实读、作者读不到(3 条,最该修)

键	渲染器读点	证据
record:details.hideFields	packages/plugin-detail/src/renderers/record-details.tsx:147	spec 那段注释原文说它「由已发布的 sys_user 平台页面书写、由 RecordDetailsRenderer 读取,只是从来没被声明过」(objectstack#5611 已在 spec 侧补声明);本仓 inputs 至今不提
record:related_list.relationshipValueField	packages/plugin-detail/src/renderers/record-related-list.tsx:95(schema.relationshipValueField || 'id')	注释原文即写 spec relationshipValueField, default 'id'
element:text_input.defaultValue	packages/components/src/renderers/basic/text-input.tsx:73/76/119	用来给绑定的 page 变量播种初值

record:related_list.add 也可能属于这一类,没细查,triage 时一并看。

B 类 —— 声明了但渲染器不读(showSubscriptionToggle 同族,2 条)

page:header.icon 与 page:card.actions:spec 声明、containers.tsx 里没有任何读点。这两条的正确方向不是「补 input」,而是二择一 —— 要么接线,要么按 record:activity.showSubscriptionToggle 的先例(packages/plugin-detail/src/index.tsx:350-360)声明出来并在 description 写明 KNOWN GAP,让双向 parity 成立而不假装可配。不要无脑补 input:那会发布一个平台默默丢掉的键,正是 #3797 修的那个方向。

C 类 —— 已知的、不该动的(5 条)

• element:record_picker 的 displayField / searchFields / multiple:objectstack#5775 已在上游转成 retiredKey() 墓碑,pin 升上来后它们会从 spec 的接受集消失,本仓正确的做法就是不声明。
• page:tabs.type:载体冲突,type 是节点分发键,扁平载体里不可授权;正在 objectstack#6776 里定收敛方向。见 PR test(console): registry inputs 与 spec ComponentPropsMap 的 parity 门推到全仓,4 个 OFF-SPEC block 逐块判定 (#3797) #3806 的 body。
• element:record_picker.targetVariable / element:text_input.targetVariable:spec 自己写明这是「declarative hint」,实际绑定靠 PageVariableSchema 的 source 反查;要不要发布是个判断题,不是漏声明。

反过来还有一条本仓读了、pin 版 spec 没声明、上游已声明的:element:record_picker 的 emptyText / sort / limit(renderers/basic/record-picker.tsx 实读,objectstack#5775 已声明)。pin 升上来后它们会变成新的 A 类缺口,建议和这一单一起收。

建议的落地

在 PR #3806 落的 apps/console/src/__tests__/registry-inputs-spec-parity.test.ts 里加第二个方向的断言,同样运行时从 spec 推导 + 显式豁免名单 + 每条豁免理由(B/C 两类就是豁免的正当来源,理由写清是「不读,按先例处理」还是「载体冲突,见 objectstack#6776」)。这样两个方向同一处、同一套豁免纪律,不会再有一个方向被单独忘掉。

关联:#3797 / PR #3806(正方向,已落)、#3407 / PR #3795(单块双向版)、objectstack#5611、objectstack#5775、objectstack#6776

[yinlianghui]

分诊判级(objectui 分片 PM,session_01GTRjn8xBqp75dk7kFupVRt):pm:queue,可派,范围 = 正文 A 类三条(record:details.hideFields、record:related_list.relationshipValueField、element:text_input.defaultValue —— 渲染器实读却不可从 manifest 发现的真缺口,补 inputs 声明 + description 从渲染器实际行为取材)。⛔ B 类(spec 声明但渲染器不读)不许无脑补 input —— 那是 showSubscriptionToggle 同族的反向缺陷,若处理须逐条按 #3797 的两向判定另立;C 类不动。派发词须点名 PR #3806 的门与本单的关系:补声明后该键从「反向缺口」变「正向通过」,门的断言自动覆盖。

---

Generated by Claude Code

[yinlianghui]

🔒 认领(objectui 分片 PM,session_01GTRjn8xBqp75dk7kFupVRt)

• 分支:claude/issue-3808-inputs-reverse-parity
• 前序已清:PR fix(plugin-detail): record:details 的 sections 说明改为 spec 的对象形,不再教已退役的 Section IDs (#3807) #3820(record:details 的 sections input description 还在教已被 spec 退役的「Section IDs」形状,渲染器只认对象形 —— 照 manifest 写出来的 sections 一条都不渲染 #3807,plugin-detail/src/index.tsx 的 sections description)已落 main @ 4178d5a2e,该文件空闲;PR test(console): registry inputs 与 spec ComponentPropsMap 的 parity 门推到全仓,4 个 OFF-SPEC block 逐块判定 (#3797) #3806 的门文件为扩展落点。
• 范围(判级评论 + 正文三类):A 类三条补 inputs 声明(description 从渲染器实读派生,fix(plugin-detail): record:highlights 的 fields 声明补上 readonly,让 manifest 能被作者读到 (#3407) #3795/fix(plugin-detail): record:details 的 sections 说明改为 spec 的对象形,不再教已退役的 Section IDs (#3807) #3820 范式;record:related_list.add 按正文一并核,A 则同修、否则入豁免);反方向门加进 registry-inputs-spec-parity.test.ts(运行时推导 + 显式豁免带理由,B/C 即豁免正当来源);⛔ B 类不许无脑补 input(豁免 + KNOWN GAP 理由,接线属另单);C 类豁免带上游单号;emptyText/sort/limit 未来 A 类在豁免注释记档(pin 升级即醒)。
• 文件面:apps/console/src/__tests__/registry-inputs-spec-parity.test.ts + packages/plugin-detail/src/index.tsx + packages/components(text-input 注册处)+ 各自 parity 测试。与在飞 #3546切片四(i18n)/components/action/**: 同一真值可见性门在动作面上未收口 —— action:group / action:menu 成员动作声明 visible: false 照样渲染（#3758 的同族部分） #3812(components/action)/plugin-grid: 被 visible 压掉的 primary 行动作白占一个 inline 槽位，把本该 inline 的下一个 primary 挤进溢出菜单 #3762(plugin-grid)/create-plugin 生成产物的 dependencies 里 lucide-react: '^0.563.0' 被钉死在 0.563.x(仓内 23 处均为 ^1.28.0),且没有任何生成的源文件 import 它 #3755+create-plugin 生成的 src/types.ts 是死产物:没有任何生成源文件 import 它,exports map 又只暴露 .,消费者拿不到那个 Schema 接口 #3759(create-plugin)不相交。

即将派发 os-dev 实施。

---

Generated by Claude Code