finding(types): two widget prop types declare their `schema` as a hand-rolled inline object with no `BaseSchema` in its ancestry

[os-support-ai]

Found while censusing bind declarations for #6357 (PR #6574). Filed separately — it is a different defect from that card's, and fixing it there would have been out of scope.

The fact

Two widget prop types declare the node they render as an inline object literal type, written by hand, that never references BaseSchema or any exported schema type:

• packages/plugin-list/src/ObjectGalleryProps.schema — packages/plugin-list/src/ObjectGallery.tsx:18
• packages/plugin-dashboard/src/ObjectDataTableProps.schema — packages/plugin-dashboard/src/ObjectDataTable.tsx:34

Compare the normal shape, where the widened type is anchored to a real schema — ObjectPivotTable uses PivotTableSchema & {…}, ObjectTimeline uses TimelineSchema & {…}, ObjectKanban is annotated KanbanSchema.

Why it matters

Because there is no BaseSchema in the ancestry, none of its 21 declared members exists on these two types. Every base key an author may legitimately write — id, className, visible, visibleWhen, hidden, disabled, testId, ariaLabel, label, style, … — is undeclared there, so each must be hand-copied into the literal when the component happens to need it.

That is measurable, not theoretical: it is exactly why both of these types carry their own bind member. The #6357 census found four local bind declarations across the repo; two of them are these, and they are the two that could not simply be deleted once BaseSchema declared the key — deleting the member would delete the declaration rather than inherit it. PR #6574 therefore ratchets them (with reasons) instead of removing them.

The two types also disagree with each other on strictness: ObjectDataTableProps.schema carries [key: string]: any, ObjectGalleryProps.schema does not. So the same class of author error is silently absorbed by one widget and a compile error on the other.

Why this is not #5155 / #6269

Adjacent, but distinct, and worth keeping separate:

• finding(types): BaseSchema's [key: string]: any leaves every component schema open, so a "declare the surface" fix can never reject a misspelled TOP-LEVEL key #5155 is about BaseSchema's index signature leaving every schema that extends it open to misspellings.
• This is about two types that never reach BaseSchema at all, so they do not even inherit the members — a different failure with a different remedy.

Fixing #5155 would not touch these two; fixing these two would not touch #5155.

What needs measuring before anything is done

• Whether the right repair is GallerySchema / an existing DataTableSchema anchor plus an intersection (the house shape), or a new exported schema type for each. plugin-list may have no gallery schema to anchor to — that is the first thing to check.
• Whether either type's inline members have already drifted from what its component actually reads — the finding(plugin-timeline): the timeline renderer reads seven keys TimelineSchema does not declare, and declares three it never reads #6170 / [finding] schema.bind is read by data-scope consumers but declared by no schema shape #6357 defect class, which is what this file pattern structurally invites.
• The strictness disagreement above: whichever anchor is chosen, one of the two changes behaviour.

Deliberately no proposed patch — the anchor choice is the whole question.

Reproduce

sed -n '18,34p' packages/plugin-list/src/ObjectGallery.tsx
sed -n '34,50p' packages/plugin-dashboard/src/ObjectDataTable.tsx
git grep -n -F -- 'bind?:' packages
grep -rn "extends BaseSchema" packages/types/src/objectql.ts | head

Refs: #6357, PR #6574. Adjacent: #5155, #6269.

[os-support-ai]

Triage: graded — pm:queue + domain:ui (finding label off), type Task. Lands in packages/plugin-list/src/ObjectGallery.tsx and packages/plugin-dashboard/src/ObjectDataTable.tsx (published-library prop types → ui lane).

Rationale: measurement-first repair with named landing points; anchoring the two orphan prop types to a real schema restores the house invariant the other widgets already hold (PivotTableSchema & {…} shape), it is not new capability. The card's own three measurements are the dispatch's first steps: (1) whether an anchor exists for plugin-list (a GallerySchema may not exist — if a new exported schema type must be created, that is new public surface: stop and report, don't invent it silently); (2) whether the inline members have drifted from what each component reads (#6170/#6357 class); (3) the strictness disagreement — whichever anchor is chosen, one widget's compile-time acceptance changes, so the PR must state which side moved and why, with the #5424 present-and-undefined discipline in mind.

Serial constraint: PR #6574 (#6357) is in flight and ratchets these two types' local bind members — dispatch only after it lands and re-verify both sites on the merged ref. Not folded with #6357: different defect, different remedy (the card argues this and the ratchet-vs-delete asymmetry proves it).

---

Generated by Claude Code