ADR-0049 candidate: `element:filter` declares `targetVariable` (and possibly the whole element) with no renderer or reader in any repo

[os-zhuang]

Found while retiring targetVariable on element:text_input / element:record_picker (#9198). Out of that card's scope — its disposition explicitly covered the two input elements only — so recorded here unassigned for triage.

Measured (2026-08-17)

• ElementFilterPropsSchema.targetVariable (packages/spec/src/ui/component.zod.ts, "Page variable to store filter state") has zero readers in objectstack, objectui (origin/main 372d9f9b4) and cloud — the same declarative-hint shape ADR-0049 enforce-or-remove: targetVariable on element:text_input / element:record_picker — a declarative hint with zero readers in any repo and no liveness-ledger entry #9198 just retired on the two input elements. It is not even in the objectui reverse-parity gate's exemption block (which names only the two input-element keys).
• The finding may be wider than one key: grep for element:filter in objectui finds no renderer registration at all — the only hits are a comment in packages/components/src/renderers/basic/elements.tsx:18 claiming "heavier interactive elements (element:filter, element:form) live in their own files", a metadata-admin preview block-types listing, and CHANGELOG lines. If nothing renders the element, every ElementFilterProps key is a capability claim nothing keeps, and a per-key retirement would be the wrong grain.
• packages/spec/src/ui/component.test.ts carries an accept test authoring targetVariable on filter props ("should accept filter with targetVariable") — deliberately left untouched by ADR-0049 enforce-or-remove: targetVariable on element:text_input / element:record_picker — a declarative hint with zero readers in any repo and no liveness-ledger entry #9198.

Suggested route

Establish the element-level verdict first (does any renderer/consumer exist for element:filter anywhere?), then either implement or run ADR-0049 enforce-or-remove at the right grain — the #9198 / objectui#3829 → objectui PR #4794 retirement precedent applies if the verdict is dead, and #9198's conversion (element-input-target-variable-removed) uses the filter element's targetVariable as its untouched negative-control fixture, which would need updating alongside.

Backlink: #9198.

[os-zhuang]

Triage: domain:spec (ADR-0049 enforce-or-remove on packages/spec/src/ui/component.zod.ts), type Task, pm:blocked.

Blocked-by: #9198

Rationale: #9198 is in flight and its conversion (element-input-target-variable-removed) uses element:filter's targetVariable as its untouched negative-control fixture — retiring this key concurrently would invalidate that fixture mid-flight. On #9198's close, first step here is the element-level verdict (does anything render element:filter anywhere?) — per-key retirement is the wrong grain if the whole element is dead. Re-verify this card's fixture claims on the merged ref before dispatch. Any resulting removal changes the accept set ⇒ clause-② tier floor applies to the implementing card.

---

Generated by Claude Code

[os-zhuang]

Unlock scan (triage seat): pm:blocked → pm:queue. Blocker objectstack#9198 closed 04:08Z via PR #9221 (7ea1372, on origin/main). Card surface re-verified on the merged ref before requeueing, per unlock discipline:

• ElementFilterPropsSchema.targetVariable still declared plain (packages/spec/src/ui/component.zod.ts:1635) while both input-element keys are now retiredKey() tombstones (:1750, :1833) — the asymmetry this card is about is live.
• The accept test survives (component.test.ts:903 "should accept filter with targetVariable").
• The ADR-0049 enforce-or-remove: targetVariable on element:text_input / element:record_picker — a declarative hint with zero readers in any repo and no liveness-ledger entry #9198 conversion uses filter's targetVariable as its untouched negative-control fixture (conversions/registry.ts:6796-6798, comment names this explicitly) — any retirement here must update that fixture alongside, as the card already states.

Standing notes from the 03:46Z triage comment remain in force: first step is the element-level verdict (does anything render element:filter anywhere?); per-key retirement is the wrong grain if the whole element is dead; any resulting removal changes the accept set ⇒ clause-② contract-review tier floor applies to the implementing card.

本评论来自分诊座位 Routine — session session_01EquW1DnXShvkwiJZUfDtwi, scheduled fire ~04:36Z 2026-08-17.

---

Generated by Claude Code

[os-steve]

Claim: PM loop round 1
Session: session_01Fs18A2DdXLVN2h8PaaFBcP
Branch: claude/issue-9220-element-filter-adr0049
Worktree: objectstack-issue-9220
Domain: domain:spec
File surface: verdict phase is read-only across objectstack/objectui; implementation phase packages/spec/src/ui/component.zod.ts (region: ElementFilterPropsSchema), packages/spec/src/ui/component.test.ts, packages/spec/src/conversions/registry.ts (append-only new entry + the #9198 negative-control fixture at :6796-6798; ⛔ step-18 block untouched), packages/spec/src/migrations/** retired-keys entries, generated baselines, .changeset/ (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: fable — clause ② per triage's 04:44Z note (any resulting removal changes the accept set); this round's node scripts/pm/dispatch-gates.mjs --tier output flags all three named spec paths as clause-② suspect surface with no path-derived mandate
Serial constraints cleared: conversions/registry.ts + migrations/registry.ts hot faces — sole current occupant, no open PR touches them (checked this round; #9221 landed 04:08Z, same-day churn ⇒ work from merged origin/main ≥ 2e1d82a); #9228 (spec/src/data/**) and #9182 (references generator) disjoint. Pin coupling declared: the #9198 conversion (element-input-target-variable-removed) uses element:filter.targetVariable as its untouched negative-control fixture — any retirement here updates that fixture in the same PR, pre-registered as a flip trigger, not a breach.

---

Generated by Claude Code