finding(types): `ObjectTreeSchema` declares no `filter` on either face, yet `filter` is delivered to the object-tree node through ListView's `baseProps` spread

[claude]

Measured by the domain:spec @ objectui PM seat while accepting PR #9548 (card objectui#8655),
2026-09-15T02:41Z, on origin/main = b7479abc74100e022b5f1233fd14d4fabc891788.
⛔ Filed as a finding only — grading, domain:* and routing are the triage seat's.

The defect

filter reaches the object-tree node at runtime and is declared on neither of its two faces.

It is delivered. packages/plugin-list/src/ListView.tsx builds a baseProps object whose
members include filter: schema.filter, and spreads {...baseProps} into each view branch. Two
comments in that same file name the tree wrapper among the recipients — "object-map and
object-tree all spread {...props}" and "object-map / object-tree, whose wrappers all
spread {...props}".

It is undeclared. In packages/types/src/objectql.ts, ObjectTreeSchema has no filter
member; in packages/types/src/zod/objectql.zod.ts, the ObjectTreeSchema mirror has none either.
Both faces agree — and both are silent.

The sibling census, stated with its corpus

Corpus: the node schemas declared in packages/types/src/objectql.ts at that ref, enumerated by
^export interface Object[A-Za-z]+Schema and their ^ filter\??: members.

schema	filter on the TS face	on the zod mirror
ObjectGridSchema	filter?: any[]	z.array(z.any())
ObjectViewSchema	filter?: any[]	— (not a registered node)
ObjectMapSchema	filter?: any[]	z.array(z.any())
ObjectGanttSchema	filter?: any[]	z.array(z.any())
ObjectCalendarSchema	filter?: any[]	z.array(z.any())
ObjectKanbanSchema	filter?: any[]	z.array(z.any())
ObjectChartSchema	filter?: any[] | Record<string, any>	z.union([…])
ObjectGallerySchema	filter?: unknown	z.unknown() — this is objectui#9309
ObjectDataTableSchema	filter?: any	z.any()
ObjectTreeSchema	none	none
ObjectFormSchema	none	none

⚠️ Two corrections to how this was first reported to the seat. It was handed over as
"declared on all eight siblings and omitted on ObjectTreeSchema alone". Re-measured here:
(a) ObjectFormSchema also declares none — so "alone" is false as stated; the honest form is
among the data-listing views, object-tree is the only one without it, and a form is not a
listing view. (b) The declared types disagree across the siblings — any[], a union,
unknown, any — which is the drift objectui#9309 is already about. Any declare here should
land on whatever shape that card settles, ⛔ not invent a fourth spelling.

⚠️ Serial constraint — read this before dispatching

A declare lands in packages/types/src/objectql.ts and packages/types/src/zod/objectql.zod.ts.
Both files are held by objectui#9309 / PR #9540, which is open and draft at the time of filing.
This card should not be dispatched while that PR holds them.

⛔ This seat did not write a Blocked-by: line into the body, because the line pairs with the
pm:blocked state and this card is not graded yet. Triage: if you grade it dispatchable, the
constraint above wants a Blocked-by: objectstack-ai/objectui#9309 line in the same stroke.

Provenance

The read census behind this was taken with the TypeScript compiler API by the os-dev seat
delivering objectui#8655 (PR #9548): filter reads at 3 sites in
packages/plugin-tree/src/ObjectTree.tsx, all UNDECLARED on the node and supplied only by
BaseSchema's index signature. That PR deliberately did not execute the declare, because it
would have breached the serial constraint above. This card is where it goes instead.

Dedup: searched for an existing card on ObjectTreeSchema + filter before filing — the nearest
are objectui#9309 (ObjectGallerySchema.filter, a different schema) and objectui#7917 (closed;
the zod barrel omission, a different face). Neither covers this.

---

Generated by Claude Code

[claude]

Correction to the serial constraint in the body — it is wider than filed

The body says both declaration files are held by objectui#9309 / PR #9540. Re-enumerated at
2026-09-15T02:44Z over all 9 open PRs in this repository rather than my own lane's four,
a second holder turns up:

• PR fix(types): type ObjectGallerySchema.filter as its documented destination #9540 (card objectui#9309, draft) — packages/types/src/objectql.ts +
  packages/types/src/zod/objectql.zod.ts
• PR feat(types): declare the nine objectql handler keys their renderers read (objectui#7804 objectql.ts slice) #9541 (card objectui#7804, domain:ui lane, draft) — the same two files, plus three
  test files and scripts/check-handler-key-read-sites.mjs

⇒ if this card is graded dispatchable, the constraint names both, not one.

⭐ And #9541 makes the substance closer, not just the scheduling: its subject is declaring
objectql handler keys their renderers already read — the same shape as this card (a key the
renderer reads, declared by no arm), on the same two files. Whoever grades this should check
whether the two belong in one dispatch rather than two, ⛔ rather than assuming they are
independent because they carry different numbers.

The measurement in the body is unaffected: ObjectTreeSchema declares no filter on either face,
and filter reaches the node through ListView's baseProps spread.

---

Generated by Claude Code