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

[os-sam]

Claim: PM loop round R2 — family dispatch, chain head
Session: session_0114Ytxr5sM1vdW19Y9WAx6E
Branch: claude/issue-7363-validating-face-gaps
Worktree: objectui-issue-7363
Domain: domain:spec
File surface: packages/types/src/objectql.ts + packages/types/src/zod/objectql.zod.ts (union arms) · packages/types/src/data-display.ts + packages/types/src/zod/data-display.zod.ts (the DrillDownConfig mirror) · parity/ledger tests under packages/types/src/__tests__/ that these two move (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: fable (CONTRACT_REVIEW_TIER)
Clause-②: yes
Serial constraints cleared: PR #7679 is in the merge queue on packages/types/examples/data-display-examples.json — disjoint file, and its dev has stopped pushing, so there is no concurrent editing; the dev merges main before opening its PR · the domain:ui seat holds #6939 (pm:dispatched) on packages/types/src/zod/** mirrors, last moved 2026-09-03T22:21Z — re-read it before touching either zod file · no other in-flight claim on this package

---

Family dispatch — the fold, and why these two and not the neighbours

Members: #7363 (chain head) + #7352. Both graded, both unclaimed, both packages/types.

Shared shape — "declared on the TS face, absent from the validating face":

card	declared	missing from
#7363	ObjectGallerySchema / ObjectDataTableSchema (landed by PR #7355)	ObjectQLComponentSchema / AnyComponentSchema union ⇒ validateSchema has no arm for those node types
#7352	drillDown on ChartSchema and ObjectDataTableSchema	no DrillDownConfig zod mirror ⇒ validated by nothing

Same defect shape (a thing the TS face declares that the validating face cannot see), same repair (add the missing member/mirror so the validator gains an arm), one worktree, one changeset, one queue slot.

Five gates, answered:

1. ✅ same shape and same fix — not merely "both about zod".
2. ✅ same package (packages/types), one worktree.
3. ✅ both graded pm:queue; ⛔ neither is in the decision box.
4. ✅ each independently checkable by a named criterion: an object-gallery / object-data-table node reaching a real validation arm; a drillDown value being refused when malformed.
5. ✅ exclusion list below — the load-bearing gate.

⛔ EXCLUSION LIST — cards that look like this family and are NOT in it

Do not touch these, even though they sit in the same files and sound alike:

• finding(types): no parity ledger watches the mirror-WIDER-than-declared direction — a key the zod face accepts and the TS face refuses is invisible by construction #7069 — "no parity ledger watches the mirror-WIDER-than-declared direction". Same subsystem, different fix: it asks for a ledger/tool, not a per-key reconciliation. Folding it would turn a bounded repair into tooling work.
• finding(types): DropdownMenuSchema.trigger declares a single SchemaNode while its zod mirror, its sibling ContextMenuSchema, and its own shipped defaultProps all use the array form #7081 and finding(types): AppComponentSchema inherits the renderer's hidden predicate from BaseSchema while its Zod mirror takes the spec's app-catalogue hidden boolean — one name, two meanings #7542 — a declared key whose type differs between the two faces (trigger single-vs-array; hidden predicate-vs-boolean). That is the opposite sub-shape: the key is present on both faces and disagrees, rather than absent from one. They are a family of their own and are being kept for a separate dispatch.
• finding(types): the published Zod AnyComponentSchema accepts the block-family discriminants that the published TS AnySchema excludes — a shipped validator green-lights nodes no renderer renders #7023 and finding(types): 4 more genuinely-read undeclared keys the #6150 census could not see, plus one declared-but-dead key — all on the same 8 renderers #6938 — genuinely close in shape, but bare finding with no pm-state ⇒ ungraded ⇒ gate ③ refuses them. ⛔ Folding an ungraded card is how unadjudicated work gets laundered into a reviewed PR.
• 24 catalog entries fail safeValidateSchema because the Zod mirror names a key its renderer never reads (8 components) #6939 — the domain:ui seat's, in flight, touches the same zod mirrors.
• finding(types): MarkdownSchema.sanitize and .components are declared and mirrored but read by no renderer — and sanitize implies a switch that does not exist #6972 / @object-ui/types' Phase-2 ActionCallback surface is a third onSuccess meaning — declared, zod-mirrored, doc-advertised, zero producers #7068 / finding(types,docs): AppComponentSchema.actions[] (AppAction) has no reader — layout, app-shell and the console never render it, while core/app-schema.mdx "Global Actions" teaches it as the app's global toolbar buttons #7469 / retire(types): EventHandlersSchema — 公开导出的 z.record(z.string(), z.function()),每个值 JSON 不可作者、无任何组合消费、census 与 parity 台账双双结构性不可见(ADR-0049 enforce-or-remove) #6910 / ADR-0049 enforce-or-remove: TextSchema.value is a second spelling for the text node's one content slot — its own docblock calls it "a dialect, not a design", and the 2026-08-31 ruling made content the sole evaluation channel #7016 — the "declared but nothing reads it" family. Opposite direction (retire, don't declare); ⛔ do not "fix" any of them here.

Clause-② is yes — stated plainly because it is not obvious

Both repairs narrow an accept set: today an object-gallery node reaches no validation arm and a malformed drillDown is refused by nothing, so both are effectively accepted. After this, both can be refused. That is a published-validator change ⇒ CONTRACT_REVIEW_TIER, PR parks draft with needs:contract-review, in-seat review before ready. ⛔ Not enqueued, ⛔ no auto-merge, until that review passes.

⭐ Worth knowing for this lane generally: most domain:spec @ objectui cards are Clause-② by nature — that is what the lane is. Clause-②: yes here is the norm, not an escalation.

---

Generated by Claude Code