docs(components): correct four props that no shipped type declares (#6143 round 2, option B)

[yinlianghui-tw]

Part of #6143.

Round 2. The PM re-ruled to option B after round 1's measurement falsified the original option-2 ruling: BaseSchema ends with a deliberate [key: string]: any, so 73 of 87 importable names are OPEN and an annotated literal accepts any key. Option 2 would have turned an uncompiled vacuous block into a compiled vacuous block while raising blocks-to-compile — negative, not neutral. The import mechanism is therefore sequenced behind #5155's strict-variant program and is not attempted here.

What is left is four ordinary docs corrections.

The four corrections

Each resolved against a freshly built packages/types/dist/*.d.tsand against the zod schemas, which #5155 ruled to be the enforcement boundary. Both layers agree on all four.

page	was	now	declaration
feedback/toast.mdx	variant?: 'default' | 'destructive'	variant?: 'default' | 'success' | 'warning' | 'error' | 'info'	feedback.d.ts:123 · zod/feedback.zod.js:59
form/radio-group.mdx	direction?: 'vertical' | 'horizontal'	orientation?: 'horizontal' | 'vertical'	form.d.ts:377 · zod/form.zod.js:263
form/combobox.mdx	searchPlaceholder, emptyText	removed	form.d.ts:1283 · zod/form.zod.js:378
form/command.mdx	CommandItem.shortcut	removed	form.d.ts:1329 · zod/form.zod.js:76

toast.mdx is the one that mattered: 'destructive' is not a member, it is the Shadcn vocabulary a reader arrives with, and it is the value most likely to be copied verbatim.

One precision.emptyText is removed from ComboboxSchema only. CommandSchema really does declare it (form.d.ts:1368, zod/form.zod.js:406), so command.mdx keeps it.

Renderer check before every removal, because a key a renderer genuinely reads is an undeclared capability rather than a doc error. None of these four is read — renderers/form/combobox.tsx contains neither searchPlaceholder nor emptyText; renderers/form/command.tsx contains no shortcut; renderers/feedback/toast.tsx contains no 'destructive'.

Omissions left alone, deliberately.toast.mdx still omits position and onDismiss. A reference page may show a subset, and round 2 was dispatched as exactly four corrections.

Blocks-to-compile did not move — the ordered proof

Nothing was re-fenced, annotated or imported; these blocks stay plaintext and stay outside the compile population. pnpm check:doc-snippets, before and after, on the same freshly built types:

measure	before	after
covered / ungated	178 / 44	178 / 44
documents holding a ts or tsx block	73	73
covered blocks	359	359
blocks to compile	248	248
declared fragments	111	111
judged / failed	248 / 0	248 / 0

Identical resolution control line on both runs:

resolution Module name '@object-ui/types' was successfully resolved to '/home/user/objectui-6143/packages/types/dist/index.d.ts'
sentinel importing 'ThisNameIsDefinitelyNotExported' produced 1 diagnostic(s) (TS2305)
positive importing 'ComponentSchema' produced 0 diagnostic(s)

Gates — all at cc607b380, each quoting its own verdict line, exit captured before any pipe

gate	exit	its own verdict line
check:doc-snippets	0	Every covered documentation snippet compiles against the built types.
check:doc-types	0	✅ Every documented component type is registered. (183 docs, 1054 blocks, 887 type literals)
check:control-bytes	0	✅ check-control-bytes: OK (scanned 5092 tracked text file(s); skipped 85 binary).
check-changeset-presence	0	✅ No source of a released package changed in this range, so no changeset is owed.
check-changeset-fixed	0	✅ All workspace packages are in the changeset fixed group.
check-changeset-no-major	0	✅ No changeset declares a major bump.
check-doc-links	0	Links are valid across 15 scan roots.

Builds ran under the shared verify lock: pnpm --filter @object-ui/types build — VERDICT command-exit 0.

Lint, narrowed and the narrowing proved. ESLint's own flat config admits only **/*.{ts,tsx} (and one named .ts); no block admits .md or .mdx. Read from ESLint itself rather than asserted: eslint --no-inline-config --format json over all five changed files returns 5 results, every one of them File ignored because no matching configuration was supplied, 0 errors and 0 files actually linted. Invariance for untouched files is trivial here — no type-aware linting is configured (no projectService, no project), and the diff contains no .ts or .tsx at all, so no untouched file's verdict can move.

Vitest: this diff implicates no suite, verified rather than assumed. No test references any of the four pages; the three files matching content/docs/components name span.mdx and div.mdx in prose comments. The only other references to these filenames are in apps/site/.source/*, which is gitignored codegen.

Render-check, from the prerendered HTML

next build of apps/site succeeded (VERDICT command-exit 0) and .next/server/app/docs/components/feedback/toast.html shows the reader-visible line as:

variant?: 'default' | 'success' | 'warning' | 'error' | 'info';

The only surviving destructive strings on that page are Tailwind classes on a rendered button — where 'destructive' genuinely is a member of ButtonSchema.variant — and a demo fixture id. No toast variant teaches it any more.

⚠️ Two pre-existing worktree gaps were cleared to get that build: @object-ui/plugin-gantt and @object-ui/plugin-map were linked but had never been built here, so the first next build died on Module not found. Building them cleared it. Unrelated to this diff, which touches no TypeScript.

Two findings filed, not fixed

• finding(examples): the live SchemaExample fixtures on four component pages teach the same invented keys the prose blocks just stopped teaching #6157 — the live SchemaExample fixtures on these same pages still carry the invented keys the prose just stopped teaching: the toast action payload in two fixtures, shortcut on three CommandItem entries, and direction in both radio-group layout fixtures. Arguably the worse half, since a reader copies a working demo more readily than an interface block. Note one precision recorded there: the top-level"variant": "destructive" on those toast fixtures is a legitimate button variant, so a blanket replace would break two working buttons.
• finding(components): RadioGroupSchema.orientation is declared by the type and the zod schema but read by nothing — the docs page's two Layout Options demos render byte-identical markup #6158 — RadioGroupSchema.orientation, the key this PR corrects the page to, is declared by the type and the zod schema and read by nothing. Measured from the prerendered HTML: all eight radiogroup roots on the page render byte-identical markup, so the two demos under ## Layout Options are indistinguishable and the horizontal one renders vertically. The mirror image of finding(types): 13 top-level schema keys that component renderers genuinely READ are declared by no shipped type — measured across all 76 content/docs/components pages #6150.

Refusals honoured

No type, export, union member or subpath minted. Nothing re-fenced or annotated, no block changed shape. ToggleGroupItem reachability, sidebar.mdx, SpanSchema, PageSchema, SemanticSchema, Breadcrumb and FilterCondition untouched. #6132's five files — sonner, context-menu, menubar, dropdown-menu, button-group — are byte-identical. #6150 and #6151 are not touched here.

⚠️ Draft on purpose. Not marked ready, auto-merge not enabled — the PM verifies CI and lands it.

---

Generated by Claude Code