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

[os-steve]

Element-level verdict measurement (session session_01Fs18A2DdXLVN2h8PaaFBcP, pre-removal, per the measurement-first ruling):

objectstack @ 2f65b1b42 (origin/main)

Every hit for element:filter / ElementFilterProps / its targetVariable, classified:

Site	Class
packages/spec/src/ui/component.zod.ts:1627-1641 (ElementFilterPropsSchema), :2310 (ComponentPropsMap)	declaration
packages/spec/src/ui/page.zod.ts:73 (element type enum)	declaration
packages/spec/src/ui/component.test.ts:883-903, :1193-1194, :1214-1215; packages/spec/scripts/format-type.test.ts:1287	spec's own tests
packages/spec/src/conversions/registry.ts:6796-6798, :6843	the #9198 negative-control fixture (pre-registered flip)
packages/lint/src/validate-page-field-bindings.ts:194	authoring-time lint (reads fields to validate bindings) — validation machinery, not a renderer/behavior consumer
content/docs/references/ui/page.mdx, content/docs/ui/pages.mdx	generated/authored docs listings

Zero runtime readers. No reader of targetVariable anywhere outside spec's own files.

objectui @ 5ffcc14 (read-only, current main)

• packages/components/src/renderers/basic/elements.tsx:18 — stale comment only ("heavier interactive elements … live in their own files"); no plugin registers an element:filter renderer anywhere (string grep over packages/ + apps/).
• packages/app-shell/src/views/metadata-admin/previews/block-types.ts:156 — this is a PALETTE_EXCLUSIONS entry, i.e. the inverse of a live consumer: Studio deliberately does NOT offer element:filter, recorded reason "no renderer — list surfaces own filtering (userFilters / filter builder)". So the PM question "does Studio offer it to authors?" is answered no — the designer palette actively excludes it, and the exclusion entry becomes a cross-repo follow-up (stale exclusion row + stale elements.tsx:18 comment) once the spec type retires, not a liveness signal.

cloud

Not reachable from this session — relying on the card's recorded sweep (zero readers, taken at objectui 372d9f9b4) and the triage 04:44Z re-verification, per the dispatch ruling. Not claimed as a fresh reading.

Verdict

DEAD at element grain. No renderer or behavior reader of element:filter exists in objectstack or objectui; Studio's only mention is an explicit no-renderer exclusion; every ElementFilterProps key is a capability claim nothing keeps. Per the ruling, proceeding with ELEMENT-grain retirement under ADR-0049 enforce-or-remove, following the #9198 / PR #9221 precedent, with the #9198 negative-control fixture updated in the same PR.

---

Generated by Claude Code

---

Generated by Claude Code

[os-steve]

Claim amendment (same session session_01Fs18A2DdXLVN2h8PaaFBcP, same branch): the element-grain retirement's file surface widens beyond the dispatched list by four hand-edited files, each the same defect class as the card and each pinned by existing evidence:

• packages/spec/src/ui/page.zod.ts — element:filter removed from the PageComponentType enum. De-advertisement only: the type union's open string arm accepts any string, so the enum entry changes no parse outcome; leaving it would keep advertising a retired element in docs/palette derivations.
• packages/spec/scripts/format-type.test.ts — the pinned JSON-schema enum listing follows the enum.
• content/docs/ui/pages.mdx — the hand-authored component-type listing (the retirement-kit docs sweep; content/docs/releases/ untouched).
• packages/lint/src/validate-page-field-bindings.ts — the 'element:filter': { props: ['fields'] } residue entry dropped. Not optional: the lint package's own component-field-specs-liveness gate (validate-page-field-bindings 的 element:record_picker 条目仍列着 #5775 已退役的 displayField / searchFields #6629) turned red on the tombstones with the exact prescription "drop it (the SDUI props 声明与 renderer 不一致:6 处「renderer 兑现但 ComponentPropsMap 未声明」+ 2 处「声明了没人读」(#5068 error 升级的 spec 侧前置) #5775/validate-page-field-bindings 的 element:record_picker 条目仍列着 #5775 已退役的 displayField / searchFields #6629 residue class)". Accompanied by an @objectstack/lint patch changeset.

Plus generated artifacts (references docs, authorable-surface/defaults ui.json) per the standing kit. Verdict measurement was posted above before any removal work.

---

Generated by Claude Code

---

Generated by Claude Code