finding(types): `ObjectTreeSchema` is the one node schema of eleven missing from the `@object-ui/types` root barrel — its zod twin is exported and there is no `./objectql` subpath to reach around it

[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

ObjectTreeSchema is a declared node schema that an author cannot import from
@object-ui/types. Its ten node-schema siblings can be.

• packages/types/src/index.ts (the root barrel) names these Object*Schema symbols:
  ObjectCalendarSchema, ObjectChartSchema, ObjectDataTableSchema, ObjectFormSchema,
  ObjectGallerySchema, ObjectGanttSchema, ObjectGridSchema, ObjectKanbanSchema,
  ObjectManagerSchema, ObjectMapSchema, ObjectQLComponentSchema,
  ObjectStackDefinitionSchema, ObjectStackSchema, ObjectViewSchema — fourteen, and
  ObjectTreeSchema is not among them (occurrence count in that file: 0).
• Of the eleven node schemas declared in packages/types/src/objectql.ts (Grid, Form, View,
  Map, Tree, Gantt, Calendar, Kanban, Chart, Gallery, DataTable), the barrel carries ten.
  ObjectTreeSchema is the only one missing.
• The zod barrel does export it: ObjectTreeSchema occurs once in
  packages/types/src/zod/index.zod.ts (control in the same file: ObjectGridSchema also once).
• There is no ./objectql subpath to reach around it. The package exports map declares
  ".", ./base, ./complex, ./data, ./data-display, ./feedback, ./form,
  ./internal/retired-field-keys, ./layout, ./navigation, ./overlay, ./zod — and nothing
  else. The root barrel is the only route, and it does not carry the name.

Why it matters, and the measured consequence

The os-dev seat delivering objectui#8655 needed this type to stop ObjectTreeProps.schema being
any. Because the name is not importable, it had to spell the type as
Extract<ObjectQLComponentSchema, { type: 'object-tree' }> rather than import it — an idiom that
works, but that every future reader of that file has to decode, for one node type out of eleven.
⇒ the omission is not inert; it has already shaped code.

Prior art — the mirror image of this gap was already fixed once

objectui#7917 (closed, completed) was "BreadcrumbSchema and ObjectTreeSchema are
declared node schemas that @object-ui/types/zod never exports, so 2 of 107 component types cannot
be validated on their own". That card repaired the zod barrel. This card is the same omission
on the TypeScript barrel, for one of the same two names — which is why the zod side reads
clean today and the TS side does not.

Sibling in the same family, filed independently: objectui#9526 (the root barrel names
CommandSchema but not CommandItem / CommandGroup). ⇒ this is a recurring barrel-completeness
shape, and whoever grades these two may want to ask whether the repair is per-name or a gate.

What a repair has to decide

⛔ Not obvious, which is why this is filed rather than fixed:

1. Add the name to the root barrel. Smallest change; adds one symbol to a published surface.
2. Add it and also check the others. BreadcrumbSchema's TS-side status is ⚠️ NOT MEASURED
   here — this card measured the Object* family only. A repair round should enumerate, not
   assume the rest are clean because this one was reported.
3. Gate it. A check that every declared node schema is reachable from the barrel that publishes
   its family would catch all three of these cards at once and stop the fourth.

Dedup: searched before filing; objectui#7917 (closed, zod barrel) and objectui#9526 (different
symbols) are the nearest, and neither covers the TS barrel omission of this name.

---

Generated by Claude Code

[claude]

Sharper population for the body's count — the union's arms, not a hand-picked set of interfaces

Raised as finding F1 by the independent review of PR #9548, and re-measured in this seat rather
than adopted: origin/main = b7479abc74100e022b5f1233fd14d4fabc891788, 2026-09-15T03:05Z.

The body counts "eleven node schemas declared in packages/types/src/objectql.ts, of which the
barrel carries ten". That population is a set of interfaces I enumerated by eye. ⭐ The principled
population is the one the type system itself names — the arms of
export type ObjectQLComponentSchema, the type that says what an ObjectQL node may be:

ObjectGridSchema · ObjectFormSchema · ObjectViewSchema · ObjectMapSchema · ObjectTreeSchema
ObjectGanttSchema · ObjectCalendarSchema · ObjectKanbanSchema · ObjectChartSchema
ObjectGallerySchema · ObjectDataTableSchema · ListViewSchema

12 arms. 11 are named by packages/types/src/index.ts. Exactly one is not: ObjectTreeSchema
(occurrence count in that file, per arm: 2 · 2 · 2 · 1 · 0 · 1 · 1 · 2 · 1 · 1 · 1 · 3).
Absent-token control in the same file: 0.

⇒ the two arms my first count had left out — ListViewSchema and ObjectViewSchema — are both
exported, so the finding survives the wider population and gets stronger: it is not "ten of eleven
by one reading", it is one arm of twelve, and only one, missing from the barrel that publishes
the union.

⛔ Nothing in the body is false; it is just measured over a population I chose instead of one the
code declares. ⭐ The lesson is the one this lane keeps paying for: the population you choose
defines the defects you cannot find — and when a type already declares the population, using a
hand-rolled one is choosing to be less checkable for no gain.

Whoever grades or repairs this should quote the 12 / 11 / 1 reading.

---

Generated by Claude Code