toRenderableSchema's header still says the bridge is temporary and its callers "can go back to forwarding directly" — the reconciliation landed and that instruction is now the main-red recipe

[yinlianghui]

Observation-class. Nothing a user hits — this is a doc comment on packages/react/src/schema-input.ts whose closing paragraph became false when PR #4608 merged, and whose instruction, if followed, reproduces the #4617 main-red exactly. Filed unassigned while implementing #4617 (PR #4621); not fixed there because packages/react was explicitly out of that card's surface.

Duplicate-searched: no open issue mentions toRenderableSchema, schema-input, or carries SchemaNode in its title.

The stale paragraph

packages/react/src/schema-input.ts, last paragraph of the JSDoc on toRenderableSchema:

It exists because the two competing repo-wide SchemaNode spellings
(@object-ui/core's interface vs @object-ui/types' union) have not been
reconciled; that reconciliation is tracked separately. When it lands, the
call sites using this can go back to forwarding directly.

Both sentences are now wrong, and in opposite directions:

1. "have not been reconciled … tracked separately" — the reconciliation landed. finding(types): two competing SchemaNode declarations — core's interface vs types' union #4580 / PR fix(types): one SchemaNode and one label vocabulary — the union wins, labels resolve where the locale lives (#4580) #4608 replaced core's hand-declared interface with export type { SchemaNode } from '@object-ui/types';.
2. "When it lands, the call sites using this can go back to forwarding directly" — this is the harmful half. The reconciliation resolved the collision in favour of the union, so after it landed a SchemaNode is less assignable to SchemaRenderer's schema prop than before, not more. Forwarding directly is precisely what the five apps/site call sites were doing, and it is why Build Docs was red on every push to main for ~5 hours (main is RED: Build Docs fails on SchemaNode vs SchemaRenderer's schema prop — the docs site has not built since #4608 landed #4617).

PR #4608 itself was clear about the outcome, in its own must-not-change section:

toRenderableSchema in packages/react remains. SchemaRenderer's component-level union deliberately excludes number/boolean (#4548 ruling Q2), so the bridge still normalizes those after reconciliation.

So the ruling and the code agree; only the header disagrees, and it is the artifact a reader reaches first — it sits directly above the function every future author will call.

Why this is worth a card rather than a silent edit

The header does not merely describe a stale fact, it issues an instruction with a trigger condition that has now fired. An author who reads it correctly concludes that removing the bridge call is the intended cleanup. That is a plausible "tidy-up" PR, it would type-check on any package whose local SchemaNode is not the union, and it lands the same red.

Suggested shape

Rewrite the last paragraph to say what is now true: the two spellings are reconciled (#4580 / PR #4608), and the bridge is permanent because the reconciliation went to the union while SchemaRenderer's prop stays deliberately narrow per #4548 ruling Q2 — a bridge between two intentionally different unions, not scaffolding awaiting a merge. Worth naming #4617 as the measured cost of the old reading.

The first two paragraphs of the header are accurate and should stay as they are.

Refs #4617, PR #4621, #4608, #4580, #4548.

---

Generated by Claude Code