finding(spec): `ElementDataSourceSchema.filter` (page.zod.ts) still declares the MongoDB-style `FilterConditionSchema` — the binding-level sibling of #14406 outside `ComponentPropsMap`, while objectui's composition seam lowers three shapes and its own pins author the tuple array

[os-sales]

Observed by the os-dev executing #14406 (session session_01G4138K1EG7kQ81FNba5Kp4) while measuring that card's read path. Filed unassigned for triage; ⛔ not folded into #14406 — its census, ruling text and dispatch surface are scoped to ComponentPropsMap, and this key is read by every element that carries a binding.

Measured on origin/main (be2594e66)

packages/spec/src/ui/page.zod.ts:169, inside ElementDataSourceSchema:

filter: FilterConditionSchema.optional().describe('Additional filter criteria'),

After #14406 lands, element:record_picker carries two filter orthographies at two keys that one renderer read resolves through a single ?? (composed?.filter ?? props.filter, record-picker.tsx:108 at the pin): properties.filter is the ViewFilterRule array, dataSource.filter is the MongoDB-style record. The card the ruling ui#6206-B closes says "one filter orthography platform-wide"; this key is the binding-level one the ComponentPropsMap census could not see.

The consumer at the objectui pin 00d3f09c500c4a45b5f27aca8af80349412faaf1 (identical on objectui main f7cf7e8)

• packages/core/src/data-scope/element-data-source.ts:69-78 types the binding's filter as unknown "because three shapes reach it (a MongoDB-style object, an ObjectQL AST node array, a spec ViewFilterRule[]) and mergeFilterNodes is the single sink that lowers all three"; :247-251 AND-combines it with the saved view's own rule array.
• packages/components/src/__tests__/record-picker-element-data-source.test.tsx:80 authors dataSource: { object: 'account', view: 'hot', filter: [['amount', '>', 100]] } — an array the spec REFUSES at dataSource.filter (FilterConditionSchema is a z.record(...).and(z.object(...)); an array is invalid_type there). So the consumer's own pin already contradicts the declaration.

Why this is its own card

• Different key, different schema file, different reader set: dataSource is consumed by list-view, object-grid, form, kanban, calendar, gantt and the picker (objectui#6953 / objectstack#7121 wired them), so the measurement finding(spec): element:record_picker.filter still declares the MongoDB-style FilterConditionSchema — the last record-form filter in ComponentPropsMap after the ui#6206-B convergence #14406 did for one renderer has to be redone per consumer — plus the spec-side readers that parse dataSource (packages/lint validate-component-props, the console designer's binding inspector).
• Its own ADR-0087 D3 entry and its own in-repo author sweep (dataSource.filter authors in examples/**, content/docs/**, spec fixtures, check-yaml-examples).
• Not decided here: whether ui#6206-B reaches the binding key as written (it reads as if it does — "platform-wide"), or whether a binding-level filter that the view's rule array AND-combines with should simply be the same ViewFilterRule[] for that reason alone. Triage decides; the two shapes are Option A (converge to the array, D3 entry, consumer-first measurement per reader) vs Option B (record a reasoned exception on the binding key).

Refs: #14406 (the last ComponentPropsMap entry) · #12039 (Key 2, PR #14404) · objectui#6206 (the ruling) · objectui#6953 (the binding's consumers) · objectui#6828.