`element:record_picker.filter` 是渲染器实读、spec 已声明、`inputs` 不提的第 4 个 A 类缺口 —— #3808 的三类清单把它漏出了分类

[yinlianghui]

发现于 #3808 的实施过程(围栏外,本 PR 未夹带)。未认领,交 PM triage。

#3808 的分类漏了这一条

#3808 的实测清单里 element:record_picker 那一行是 5 个键:

element:record_picker  displayField, searchFields, filter, multiple, targetVariable

而下面的三类只交代了其中 4 个 —— C 类写了 displayField / searchFields / multiple(objectstack#5775 的 retiredKey() 墓碑)与 targetVariable(declarative hint),filter 没有出现在 A / B / C 任何一类里。它既不是墓碑,也不是 hint,而是标准的 A 类:渲染器实读 + spec 已声明 + inputs 不发布,和 #3808 修的那三条完全同形。

(#3808 正文自称「15 条」,按 block 逐行相加实为 13 条,C 类小计写 5 条实为 6 条 —— 分类过程中掉了一条,就是这个 filter。)

逐键证据(objectui origin/main @ c85268256,pin @objectstack/spec@17.0.0-rc.5)

• spec 声明:ElementRecordPickerProps 的顶层键为 object, displayField, searchFields, filter, multiple, targetVariable, placeholder, aria(运行时 Object.keys(shape) 实测)。

• 渲染器实读:packages/components/src/renderers/basic/record-picker.tsx:78

  const filter = ds.filter ?? props.filter;
  

  props 就是 readProps(schema),即节点顶层 props;filter 随后进 :103 的 query.$filter,并参与 :90 的 filterKey memo —— 是真正决定查什么记录的键,不是装饰。

• inputs 不提:record-picker.tsx:180-186 只声明 object / labelField / valueField / placeholder / label。

有害在哪

element:record_picker 不在 PUBLIC_BLOCKS(packages/core/src/registry/public-blocks.ts:78 明确注释「record picking is a field widget, not a page block」),所以它不进 sdui.manifest.json。但它仍然发布一个运行时白名单:packages/components/src/renderers/layout/page.tsx:462 用 getKnownTypes() + 各自的 inputs 现搭一份 manifest 给 JSX 页面编译器。于是一个 JSX 页面写了 record picker 的 filter:

1. sdui-parser/src/validate.ts:74 在 comp.inputs 里找不到它 → unknown-prop warning;
2. 渲染器照样兑现它、照样按它过滤;
3. 设计器面板里没有这个字段,作者也无从发现它存在。

三个层面三个答案,和 #3797 / #3808 要消掉的是同一件事。

为什么没在 #3808 里一起修

#3808 的判级评论把范围钉在「正文 A 类三条」+ record:related_list.add 的核对,并明确「C 类不动」。filter 落在分类之外,不在派发范围内 —— 按 Prime Directive #10 另开本单,而不是在那个 PR 里悄悄扩面。

落地

一行 inputs 声明,和 #3808 的四条同形:

{ name: 'filter', type: 'array', label: 'Filter', description: <从 :78/:103 的实际行为取材> }

注意 description 要交代 ds.filter ?? props.filter 的优先级(节点上的 dataSource.filter 压过顶层 filter),否则作者不知道两处都写时谁生效。type 取 'array' 还是 'object' 需按 spec 的实际 shape 定(filter 在 spec 里是 z.unknown() 一类的宽类型时,ComponentInput 的粗类型会产生误报 —— 见另一单)。

当前的兜底

#3808 落的反方向门把这一条列为带理由的显式豁免并引用本单;门里的 carries no stale exemption 断言会在有人声明它的那一刻要求删掉豁免条目。

参考位置

• packages/components/src/renderers/basic/record-picker.tsx:78 / :90 / :103(读)、:180-186(声明)
• packages/components/src/renderers/layout/page.tsx:462(运行时 JSX manifest)
• packages/sdui-parser/src/validate.ts:74(unknown-prop)
• apps/console/src/__tests__/registry-inputs-spec-parity.test.ts(两个方向的门 + 豁免名单)

关联:#3808、#3797 / PR #3806、#3407 / PR #3795、objectstack#5775

[claude]

Triage: pm:queue.

• The 4th A-class gap in parity 门的反方向没推到全仓:7 个 block 共 15 个 spec 已声明的顶层键没有任何 inputs 发布,其中 3 个渲染器实读(record:details.hideFields / record:related_list.relationshipValueField / element:text_input.defaultValue) #3808's own classification (its 15-key count vs 13 classified lines dropped filter): the renderer really reads it (record-picker.tsx:78 ds.filter ?? props.filter, flowing into :103 query.$filter — live @ f5f8744), spec declares it, and the inputs block (~:181-186) omits it. One-line inputs declaration, same shape as parity 门的反方向没推到全仓:7 个 block 共 15 个 spec 已声明的顶层键没有任何 inputs 发布,其中 3 个渲染器实读(record:details.hideFields / record:related_list.relationshipValueField / element:text_input.defaultValue) #3808's fixes; batchable with that family once parity 门的反方向没推到全仓:7 个 block 共 15 个 spec 已声明的顶层键没有任何 inputs 发布,其中 3 个渲染器实读(record:details.hideFields / record:related_list.relationshipValueField / element:text_input.defaultValue) #3808 lands.
• Dedup: no shadow; parity 门的反方向没推到全仓:7 个 block 共 15 个 spec 已声明的顶层键没有任何 inputs 发布,其中 3 个渲染器实读(record:details.hideFields / record:related_list.relationshipValueField / element:text_input.defaultValue) #3808 is dispatched and its grading comment explicitly scoped this key out.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code