finding: `element:number.filter` declares the arm `'array'`, but `ElementNumberProps.filter` accepts only a record/object — the manifest gate clears a value spec refuses

[yinlianghui-tw]

Found while implementing #4971 (the declared-arm ⊆ spec-accepted gate). Filed unassigned, not claiming. Not fixed in that PR — #4971's dispatch is explicit that the accept set and every declaration stay unchanged, so this is carried there as a reasoned, issue-backed exemption pointing here.

The divergence

authority	what it says about element:number.filter
packages/components/src/renderers/basic/elements.tsx:472 (the registration)	{ name: 'filter', type: 'array', label: 'Filter' } — declared array
@objectstack/spec@17.2.0 ComponentPropsMap['element:number'].filter	record | object, .describe('Filter criteria') — an array is refused
elements.tsx:375-451 (the renderer)	opaque passthrough: filter?: unknown, handed to adapter.aggregate({ …, filter }) and to adapter.find(object, { $filter: filter }) — it commits to no shape at all

Measured on the installed pin, key-scoped so the required siblings do not speak for it:

ElementNumberProps.safeParse({ object: 'a', aggregate: 'count', filter: [] })
 → [{"expected":"record","code":"invalid_type","path":["filter"], …},
 {"expected":"object","code":"invalid_type","path":["filter"], …}]
ElementNumberProps.safeParse({ object: 'a', aggregate: 'count', filter: {} }) → success

Why it matters (the #4971 harm, live on this key)

sdui-parser's checkType clears filter={[…]} because the declared arm says array; sdui.manifest.json and the generated sdui-intrinsics.d.ts publish it as legal; os validate / os build is the first layer to refuse it. declared = enforced inverts silently — the platform's own manifest recommends a write the contract rejects (AGENTS.md #0.1's second dialect).

Which side is wrong is a CONTRACT question, not an implementation detail

The repo is uniform in the opposite direction: every other filter input in the tree is declared 'array' — object-grid.filter (plugin-grid/src/index.tsx:218, "Filter criteria in JSON-rules form"), object-metric.filter (plugin-dashboard/src/index.tsx:207), record:related_list.filter (plugin-detail/src/index.tsx:489, spec ViewFilterRule entries), plugin-list, data-list. Their spec entries accept anything (z.any()), so only element:number — whose spec entry is a typed record — collides.

So the two readings are:

• (a) the spec entry is the odd one out — ElementNumberProps.filter should take the same ViewFilterRule array form every other block's filter takes, and the fix is upstream in @objectstack/spec (this repo does not edit the spec — AGENTS.md #0);
• (b) the declaration is wrong on this one block — element:number really does want a record-shaped filter, and the input should be declared 'object' (and the description should say so), diverging from every sibling filter surface.

Nothing in-tree settles it: the renderer is an opaque passthrough and expresses no preference, and there is no element:number filter fixture either way. Needs a maintainer/upstream decision rather than a guess.

How to re-derive

sed -n '472p' packages/components/src/renderers/basic/elements.tsx
pnpm exec vitest run apps/console/src/__tests__/registry-inputs-spec-parity.test.ts # the #4971 arm gate; entry `element:number.filter:array`

Deleting the exemption entry in registry-inputs-spec-parity.test.ts is what closes this card — the gate's stale-exemption test demands it the moment either side moves.

[claude]

Triage: → needs-user-decision + domain:spec (contract face of the objectui three-stream split): the disagreement is between @objectstack/spec ComponentPropsMap['element:number'].filter (record/object) and the registration's declared arm (array, elements.tsx:472), with the renderer committing to no shape at all. The card's own reading stands — which side is wrong is a contract question, and the #4971 stale-exemption test closes it the moment either side moves. Type: Bug.

① 项目长远合理性:filter 形状全平台应当只有一种正字法;spec 已声明 record/object,若给这个键留 array 例外就是契约增生 —— 除非运行时真的普遍接受 array 过滤(那是 spec 在低声明)。
② 实际业务拉动:作者照 manifest 提示写 filter={[…]},os validate/os build 才第一个拒绝 —— 平台自己的清单在推荐契约拒绝的写法,撞上的是「跟着补全走反而报错」。
③ 防 AI 犯错:声明臂 ⊆ spec 接受集是响亮的编写期约束;放着分歧,AI 按 manifest 生成的页面到 build 才炸 —— 或者更糟,adapter 静默吃掉错形状的 filter。
④ 创业阶段不扩散:改注册声明(array→object)一行即收敛、不新增任何面;反向裁 spec 扩臂收 array 则要 conformance 跟上,成本高一档。
推荐:A = 注册声明改 object,对齐 spec(一行 + 删 #4971 豁免条目);B = spec 扩臂收 array(需先实测 adapter 对 array filter 的真实行为)。回一个字母即可。
置信缺口:未实测各 adapter.find(object, { $filter }) 实现对 array 形状的实际接受度 —— 若 array 三元组过滤在别处历史合法,B 的证据面变厚。

---

Generated by Claude Code

[os-steve]

Maintainer ruling (2026-08-25, batch adjudication, batch 4; verbatim: 「同意」): Option B — one filter orthography platform-wide: the spec entry ComponentPropsMap['element:number'].filter aligns to the platform's ViewFilterRule array form, rather than leaving this one block as the record-shaped exception every author and AI would have to remember. Measurement-first is binding: the upstream card must verify the adapter/runtime behaviour on array filters for this element's read path before editing — if the runtime genuinely cannot take the array form, that is a fork back to triage, not a silent flip to Option A.

Execution is upstream in @objectstack/spec — filed as objectstack-ai/objectstack#12039 (family-folded with ui#6207's key, spec lane queue, Clause-② yes).

Blocked-by: objectstack-ai/objectstack#12039

Unlock criterion (cross-repo, consumer-installable): a released spec version carrying the change reaches this repo's installed pin. On unlock: delete the element:number.filter:array exemption entry from registry-inputs-spec-parity.test.ts (the gate then enforces convergence) and correct the registration's description if it still says record. State transition: needs-user-decision → pm:blocked.

---

Generated by Claude Code