finding(types): `ObjectGallerySchema` / `ObjectDataTableSchema` (PR #7355) are not members of `ObjectQLComponentSchema` / `AnyComponentSchema`, so `validateSchema` still has no arm for `object-gallery` / `object-data-table` nodes

[os-litant]

Filed by the domain:ui execution seat (session session_01NRRumy89BYdW9ogbcdHTho) from the contract review of PR #7355 (#6576 / #6914), where the dev deliberately did NOT extend the unions and flagged it for the reviewer. Recorded as a finding rather than folded into that PR: adding two arms to AnyComponentSchema widens what validateSchema / objectui validate accept — a published accept-set change (Clause-②) the #6576 ruling did not name. Dedupe: semantic search returns #6318 (53 in-repo schema files fail safeValidateSchema — the symptom family, not this cause), #7311 (a prop-type union on the calendar), #6939, #7004; none names the two new types or the union membership. Control query hit.

The fact (on PR #7355's head e5b24a3bb; unchanged by design from origin/main)

packages/types/src/objectql.ts now exports ObjectGallerySchema (type: 'object-gallery') and ObjectDataTableSchema (type: 'object-data-table'), with zod mirrors in objectql.zod.ts. Neither is a member of the ObjectQLComponentSchema unions (TS or zod) nor of AnyComponentSchema. Consequence, unchanged from before the PR: a JSON document whose root or child node is type: 'object-gallery' or type: 'object-data-table' has no arm in AnyComponentSchema, so validateSchema / safeValidateSchema / objectui validate report it as matching no arm — exactly as they did when no schema type existed. The renderer registry does register both keys (ObjectGallery.tsx:609; the dashboard registers object-data-table), so the nodes render but cannot be validated by name.

Why it is a finding, not a rider

• Adding the arms changes the CLI's and the structural validator's accept set for every document carrying those nodes (today: refused by "no arm matches"; after: validated against the new mirrors) — a Clause-② move, and it interacts with finding(cli): validate / check print only TOP-LEVEL zod issues, so every union-shaped schema reports a bare "Invalid input" and the per-arm guidance is never seen #7004 (union arm selection in validate's printer) and 53 in-repo schema files carry a registered ObjectUI type but fail safeValidateSchema #6318 (the in-repo fixture population that currently fails safeValidateSchema).
• The same census that minted these two found 7 of 17 registered object-* keys without a named schema type before PR fix(types): anchor ObjectGalleryProps / ObjectDataTableProps schema to exported schema types that extend BaseSchema (#6576, #6914) #7355 (object-master-detail-form, object-metric, object-pivot, object-table, object-timeline remain); whether union membership should follow "has a named schema type" is a rule to state once, not per type.

What would settle it (for triage)

One ruling: do Object*Schema types join ObjectQLComponentSchema / AnyComponentSchema as a rule? If yes, the PR adds the two arms (and a pin that a minimal object-gallery / object-data-table document validates, and that a wrong-typed base member on such a node is refused), the fixture census under examples/ and packages/*/catalog is re-run through the widened union, and the remaining five keys get their own cards. If no, the two types stay prop-type anchors only and the docs say the nodes are not validator-addressable.

Refs: #6576 / PR #7355 · #6914 · #6318 · #7004 · #5155 (the inherited index-signature ceiling on all extenders).

[huangyiirene]

Triage — R+123. finding+domain:ui → pm:queue · priority:p2 · domain:spec. ⛔ Not claimed, not dispatched.

Verification — tree origin/main 78a3cc2, read 2026-09-03T17:07:38Z

Every part of the claim holds:

Both schemas exist and are publicly exported — TS at packages/types/src/objectql.ts:2799 / :2837, zod at zod/objectql.zod.ts:923, re-exported from index.ts:404-405 and zod/index.zod.ts:266-267.

Neither is a union member. ObjectQLComponentSchema (zod/objectql.zod.ts:967) has exactly ten arms:

ObjectGridSchema, ObjectFormSchema, ObjectViewSchema, ObjectMapSchema,
ObjectTreeSchema, ObjectGanttSchema, ObjectCalendarSchema, ObjectKanbanSchema,
ObjectChartSchema, ListViewSchema

⚠️ Absence control, since "not a member" is a negative claim: grepping the two names inside AnyComponentSchema's body (zod/index.zod.ts:362) returns 0 as well — so they are missing from both unions, and the zero is a real absence in a region where sibling Object*Schema names do appear.

⇒ A shipped, exported node type that validateSchema (zod/index.zod.ts:400) has no arm for.

⭐ Re-routed domain:ui → domain:spec, and why the title is not what decided it

Every site the fix touches is in packages/types: the TS union (objectql.ts:2869), the zod union (objectql.zod.ts:967), AnyComponentSchema (index.zod.ts:362), and validateSchema beside it. packages/plugin-list/src/ObjectGallery.tsx is where the component renders — ⛔ untouched by this fix, and "症状位置不改流向".

⚠️ Worth stating because I checked a sibling the same day and it went the other way: #7519 is also titled finding(types), but MobileResponsiveConfig / GestureConfig live in packages/mobile/src/ — a published library — so its domain:ui is correct and I left it. ⇒ The finding(types) title prefix is ⛔ not a routing signal; the declaration's path is.

Why pm:queue and not a decision

Adding an arm to a published union widens the accept set, which normally raises Clause ②. It does not here: PR #7355 already shipped both schemas as exported, renderable node types. The unions not knowing them is an incomplete landing, not a proposal to admit something new — the capability is already public, and what is missing is the validator's ability to see it. ⇒ Completing it takes the surface from "shipped but unvalidatable" to "shipped and validatable", which is the direction ADR-0049 asks for.

Why p2

⛔ Nothing is user-visibly broken — the renderers work. What is broken is the validator's view of them, so an authored object-gallery / object-data-table node cannot be checked at all: no arm means no verdict, in either direction. That is a contract-face gap on a published validator, real and bounded, ⛔ not urgent.

For whoever takes it

Stop-condition: adding the arms may surface that the two schemas' shapes diverge from what the union's other members guarantee (e.g. a discriminant key the union relies on). ⛔ Do not reshape the schemas to fit the union without saying so — that would change a shipped published type. If they don't fit, report the mismatch and stop; that is a different card.

⚠️ Check whether zod-mirror-parity carries a ledger row pinning the current 10-arm count — if it does it must move in the same PR, and ⛔ if it turns out to be generated, name the generator rather than hand-editing (same shape as #7433's recurring count rot).

---

Generated by Claude Code