Skip to content

TextSchema.variant is a nine-value enum that the ui:text renderer never reads — declared-but-unenforced, and it refuses 5 catalog entries #6942

Description

@os-sam

Filed unassigned by the os-dev seat while implementing #6318. Grading and domain:* are the triage seat's.

#6318's body opened with this group as its clearest bucket-A instance — "small is not in the enum, so the document is rejected" — and read it as a wrong fixture. Rendering it says otherwise, and that inversion is the finding.

Measured

packages/types/src/zod/layout.zod.ts:63

variant: z.enum(['h1','h2','h3','h4','h5','h6','body','caption','overline'])
  .optional().default('body').describe('Text variant/style'),

packages/components/src/renderers/basic/text.tsx — the whole body of the registered ui:text renderer — reads exactly two keys:

{schema.content || schema.value}

variant has no read site. Neither does align, which TextSchema also declares. The registration's inputs list only content.

The triage test, applied

Rendered through the real SchemaRenderer:

authored elements text
variant: "small" (the fixture as it stands) 2 Small text
variant: "body" (the "correction" #6318's body proposes) 2 Small text
variant: "h1" (an enum member) 2 Small text
key absent 2 Small text

All four are byte-identical. #6318's triage rules that a fixture which stops rendering differently after "correction" proves the edit was wrong — so rewriting small to body would be a pure validator-appeasement edit, and it is not just wrong for small: no value of this key changes anything, including the nine the enum blesses.

The five entries the enum refuses are components-basic-text/small.json, paragraph.json (variant: "p"), muted.json, lead.json and large.json. Their spellings are the shadcn typography scale (small, p, muted, lead, large), which is what an author reaching for this key would write.

⚠️ There IS a renderer that reads a variantElementTextRenderer in renderers/basic/elements.tsx:74-90 — but it is registered under element:text, reads its props from schema.properties / schema.props rather than the node root, and its vocabulary is a fourth set again (heading, subheading, body, caption). It is not the renderer these entries reach and it does not rescue this key.

The decision this needs

Three coherent outcomes, and they are a product-shape choice rather than a repair — which is why this is a report and not a PR:

  • A. Retire the key (ADR-0049 enforce-or-remove). variant is declared, published, and read by nothing. align sits beside it in the same state and would go the same way. Cheapest and most honest; costs every author currently writing a value that already does nothing.
  • B. Enforce it — teach ui:text a VARIANT_CLASS map the way ElementTextRenderer has one, and make the enum the shadcn scale the corpus actually authors (h1..h6, p, lead, large, small, muted). Turns five broken entries into five that render five visibly different things, which is what a schema catalog is for. Largest surface.
  • C. Widen the enum only — accept the five spellings without implementing them. ⛔ Not recommended: it converts a loud rejection into a silent no-op, which is the failure mode a metadata contract exists to prevent, and it is worse for AI-authored metadata than the current state because the mistake stops being detectable.

Recommendation: A or B, not C, with B preferred if the catalog category is meant to demonstrate typography at all — the five entries were clearly written expecting it to.

Related

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpriority:p2

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions