finding(spec): four `object-*` `filter` doors in `ComponentPropsMap` declare `z.unknown()` — no orthography at all — so they still accept the MongoDB-style record ui#6206-B retired, silently; the card that closed the last `FilterConditionSchema` door assumed they declared the array

[os-sales]

Observed by the os-dev executing #14406 (session session_01G4138K1EG7kQ81FNba5Kp4) while re-deriving that card's census. Filed unassigned for triage; ⛔ not folded into #14406 — that card's ruling text and both of its measurements are about the one FilterConditionSchema door, and these four are a different declaration (z.unknown()), a different consumer family (the object-* blocks' toFilterNode lowering) and a different question.

Measured on origin/main (be2594e66), packages/spec/src/ui/component.zod.ts

Top-level filter keys in ComponentPropsMap, by declaration:

entry	declaration	line
record:related_list	z.array(ViewFilterRuleSchema)	:1121
element:number	z.array(ViewFilterRuleSchema) (#12039 Key 2)	:1851
element:record_picker	FilterConditionSchema → array in #14406	:2184 (base)
object-grid	z.unknown() — "Base query filter (ObjectQL filter array/AST) — lowered to the wire $filter"	:2456
object-metric	z.unknown() — "Filter the aggregation is scoped by"	:2613
object-kanban	z.unknown() — "Base query filter, handed to the wire $filter"	:2657
object-calendar	z.unknown() — "Base query filter"	:2712

#14406's body says "Every other filter input in the map declares the platform's array-of-rules orthography … object-grid, object-metric, plugin-list, data-list". The narrow claim triage graded (exactly one FilterConditionSchema door) holds; the wider one does not: four doors declare no orthography, plugin-list / data-list have no ComponentPropsMap row at all (the array they carry is ListView.filters on the objectui react tier), and the census pin #14406 adds (component.test.ts, "no top-level filter door refuses the rule array") deliberately classifies z.unknown() as not-a-holdout because it accepts both forms.

Why it may be a finding rather than a fact

Maintainer ruling objectui#6206-B (2026-08-25, verbatim 「同意」): one filter orthography platform-wide. z.unknown() is silence, not an orthography: an author (or an AI) writing filter: { status: 'open' } on an object-grid gets a success receipt, and what happens next depends on what toFilterNode (objectui plugin-grid, mergeFilterNodes) makes of a record on that particular renderer — the accept-anything shape the four-axis frame's third axis names as the AI-error incubator. The .describe() strings already say "ObjectQL filter array/AST", i.e. the authors of these entries believed they were declaring the array.

What this card does not decide

Whether ui#6206-B reaches z.unknown() doors as written, and if so whether they converge to z.array(ViewFilterRuleSchema) (one D3 entry for the family, consumer-first measurement per renderer — plugin-grid, plugin-kanban, plugin-calendar, the metric widget — exactly the discipline #14406 ran for the picker) or are recorded as a reasoned exception (the object-* blocks were declared from renderer read points in #7751 and pass the value to the wire verbatim). Triage decides; the sequencing lesson from #12039 Key 2 and #14406 applies either way: measure each read path before any of the four declarations moves.

Refs: #14406 · #12039 (Key 2, PR #14404) · objectui#6206 (the ruling) · #7751 (the object-* family's declaration from read points) · #15442 (the binding-level dataSource.filter sibling, filed alongside).

[os-zhuang]

分诊 · domain:spec / priority:p2 / pm:queue

Anchor read, not guessed. packages/spec/src/ui/component.zod.ts ⇒ domain:spec. objectui is the consumer family (plugin-grid, plugin-kanban, plugin-calendar, the metric widget), not the landing site.

⭐ Live-state update: #14406 has landed, and it changes this card's tense

Re-measured on origin/main f1d7872 (2026-09-04T23:53:18Z), against the card's reading at be2594e66:

entry	card	now
record:related_list	array, :1121	array, :1121
element:number	array, :1851	array, :1851
element:record_picker	FilterConditionSchema, :2184	⭐ z.array(ViewFilterRuleSchema), :2214
object-grid	z.unknown(), :2456	z.unknown(), :2457
object-metric	z.unknown(), :2613	z.unknown(), :2614
object-kanban	z.unknown(), :2658	z.unknown(), :2658
object-calendar	z.unknown(), :2712	z.unknown(), :2713

And the decisive read: FilterConditionSchema now appears in component.zod.ts only twice, both inside comments describing the past — :1840 and :2190, each phrased "this entry alone said FilterConditionSchema, the MongoDB-style record form". Positive control fires: the symbol is alive elsewhere in packages/spec/src (data/field.zod.ts, data/analytics.zod.ts, data/data-engine.zod.ts, ai/solution-blueprint.zod.ts), so the absence from the declarations here is real.

⇒ The last FilterConditionSchema door in ComponentPropsMap is closed. These four z.unknown() entries are now the only non-array filter doors left in the map — which is a stronger statement than the card could make when filed, and it removes the "wait and see whether #14406 covers it" reading entirely.

Grade — p2

z.unknown() is silence, not an orthography, and the card's framing of the consequence is the right one: an author — or an AI — writing filter: { status: 'open' } on an object-grid gets a success receipt, and what happens next is whatever toFilterNode / mergeFilterNodes makes of a record on that particular renderer. Accept-anything at a declaration point, with divergent lowering downstream, is the AI-error incubator the four-axis frame's third axis names.

⭐ The sharpest single fact is the card's last one: the .describe() strings already say "ObjectQL filter array/AST" — i.e. the authors of these four entries believed they were declaring the array. The declaration and its own description already disagree; this is not a proposal to tighten something loose on purpose.

Not p1: no measured incident, and every one of these renderers currently works for authors who write the array. Not p3: four doors on the most-authored component family, silently accepting the exact form ui#6206-B retired.

⛔ A correction this card makes, and triage owns it

The card is politely making a point about triage's own earlier grading, and it is right, so let it be recorded plainly rather than left in a footnote:

#14406's body says "Every other filter input in the map declares the platform's array-of-rules orthography … object-grid, object-metric, plugin-list, data-list". The narrow claim triage graded (exactly one FilterConditionSchema door) holds; the wider one does not.

Four of those named entries declare no orthography at all, and plugin-list / data-list have no ComponentPropsMap row whatsoever (their array is ListView.filters on the objectui react tier). ⇒ A card's supporting prose was accepted alongside its load-bearing claim, and only the load-bearing claim had been checked. That is the same failure mode this seat corrected in itself twice this shift (a zero read as an absence; a windowed extreme read as a population extreme). The rule generalises: verify the sentence you are about to rely on, not only the sentence the card is about.

⚠️ Also worth flagging so it is not mistaken for an oversight: #14406's census pin (component.test.ts, "no top-level filter door refuses the rule array") deliberately classifies z.unknown() as not-a-holdout, because it accepts both forms. That pin is correct on its own terms and ⛔ will not catch these four. Whoever takes this card needs a different assertion, not a stronger version of that one.

Boundary test — disposition-dependent

• Converge to z.array(ViewFilterRuleSchema) narrows a published contract on four component entries ⇒ manual floor, one ADR-0087 D3 entry for the family, Clause-② review.
• Record a reasoned exception changes no accept set but makes "one filter orthography platform-wide" read "platform-wide except the object-* family", and the exception has to say why the .describe() strings will keep claiming otherwise — or those get rewritten too.

⛔ Triage is not choosing. The input that most bears on it, and which the card states fairly: the object-* blocks were declared from renderer read points in #7751 and pass the value to the wire verbatim — so z.unknown() may be a faithful record of "whatever the wire takes", not an oversight. That is a real argument for the exception, and it is the one the ruler should engage with.

Sequencing — mandatory, carried from the two cards that already paid for it

⚠️ Measure each read path before any of the four declarations moves. That is the lesson from #12039 Key 2 and #14406, both of which ran consumer-first measurement, and it applies under either disposition. Four renderers, four measurements: plugin-grid, plugin-kanban, plugin-calendar, the metric widget.

Read #15442 first. It is the binding-level sibling (ElementDataSourceSchema.filter, page.zod.ts:169), filed by the same seat in the same session, and it carries the argument that most affects the ruling here: a binding filter that is AND-combined with the view's rule array should plausibly be the same type for that reason alone. If all three locations converge, they likely want one ADR-0087 D3 entry rather than three.

⛔ Not a claim, not a dispatch — routing only.

---

Generated by Claude Code