finding(spec): dashboard widget.filter (dashboard.zod.ts:387, :720) still declares FilterConditionSchema — a further location under ui#6206-B outside ComponentPropsMap, and the console's DashboardWidgetInspector authors exactly that record form #15829

Filed unassigned from the #15442 / #15449 consumer census (PM session session_01M59rPZZFzqhfMUPFqqZTkf, os-dev seat, 2026-09-05). Measured on objectstack origin/main fc20f7bda and the objectui pin a472b07 (.objectui-sha).

Blocked-by: #15828

Measured

• packages/spec/src/ui/dashboard.zod.ts:387 — filter: FilterConditionSchema.optional().describe('Presentation-scope filter (runtimeFilter)'); :720 — filter: FilterConditionSchema.optional().describe('Filter to apply to source object'). Both are MongoDB-style record doors.
• The designer WRITES that record: objectui packages/app-shell/src/views/metadata-admin/inspectors/datasetFilterCondition.ts (groupToCondition emits { [field]: { $op: value } } from the DashboardWidgetInspector builder).
• The lint walks these keys as record nodes (packages/lint/src/filter-walk.ts:60, FILTER_KEYS; validate-empty-combinators.ts:146 surfaces dashboards).

Why it is a card and not a fix

ui#6206-B (2026-08-25, verbatim 「同意」) reads "one filter orthography platform-wide" but its operative sentence names ComponentPropsMap['element:number'].filter. #15442 (element bindings) and #15449 (the four object-* doors) are the two locations under measurement now; the dashboard widget filter is a third location with a live designer PRODUCER of the record form, so any family-wide ADR-0087 D3 entry either names it or records why the dashboard family stays on the record. Observation class: nothing is broken here today; the widget's downstream (/analytics/query, where = FilterConditionSchema) natively takes the record.

Refs: #15442 · #15449 · #14406 · objectui#6206.

⚙️ Bookkeeping, 2026-09-08 — the Blocked-by: line above transcribes the blocker the PM who set this state already named; it invents nothing and it moves nothing.

The card was moved pm:queue → pm:blocked on 2026-09-06T23:03Z with the reason stated in prose: "What unblocks it: the family-wide ADR-0087 D3 entry for ui#6206-B. The nearest live decision is #15828 (needs-user-decision, p1)." That reasoning is correct and is not being revisited — but it lived only in a comment, so the unlock sweep could never reach this card when #15828 is answered. A pm:blocked card with no machine-readable Blocked-by: line is invisible to the mechanism that exists to release it.

⚠️ One thing the directive deliberately does not encode. #15828 is a needs-user-decision card, so "closed" is not by itself the release condition — what releases this card is the family-wide ADR-0087 D3 entry that ruling produces. If #15828 is answered without a D3 entry being written, this card is still not deliverable, and whoever runs the unlock scan should re-read before returning it to the queue. 「上游关单放回解锁卡」 is the trigger, ⛔ not the verdict.

⭐ And the constraint both cards' authors flagged stays attached to it: dashboard.zod.ts:387 / :720 have a live producer — objectui's datasetFilterCondition.ts groupToCondition emits { [field]: { $op: value } } from DashboardWidgetInspector — so #15828's option (A) must be additive (accept record or array). ⛔ Replacing the record with the array would begin refusing what the designer emits today.

Checked with the repo's own predicate rather than a hand-rolled regex: directiveValues(body, 'Blocked-by') from scripts/pm/check-half-states.mjs. Added by the domain:spec execution seat, session session_016N6xmWt5hYm94ffVEwGH8x. ⛔ No pm state changed, no label moved, no assignee set, nothing closed.

Generated by Claude Code