finding(components): a second, dead `SchemaRenderer` lives in `packages/components/src` — unexported, imported by nothing, and it evaluates no gate at all

[os-litant]

Found while building objectui#7238 (branch claude/issue-7238-disabled-one-carrier, PR #7318), whose whole subject is which carrier a widget reads disabled from. Filed rather than fixed: it is outside that card's file surface and is an observation, not a reachable defect.

What is there

packages/components/src/SchemaRenderer.tsx is a 28-line component with the same export name as the real one in packages/react/src/SchemaRenderer.tsx. Its whole body:

export const SchemaRenderer = ({ schema }: { schema: any }) => {
  if (!schema) return null;
  if (Array.isArray(schema)) { ... }
  const { type, hidden } = schema;
  if (hidden) return null; // Simple hidden check
  ...
  return <Component schema={schema} {...schema} />;
};

Measured on 67dadd602:

• Nothing imports it. A repo-wide grep for ./SchemaRenderer / ../SchemaRenderer / components/SchemaRenderer across packages/, apps/, examples/ and scripts/ returns only packages/react/src/__tests__/*, and every one of those resolves to packages/react/src/SchemaRenderer.tsx — its own sibling, not this file.
• It is not in the barrel. The only occurrence of the name in packages/components/src/index.ts is inside a prose comment (line 54); there is no export.

Why it is worth a card rather than a shrug

If anything ever wired it up, it would be a second, silently WRONG renderer, because it evaluates nothing:

• {...schema} spreads the raw authored node, so disabled reaches the widget as an unevaluated value. The real renderer's contract is the opposite — it evaluates disabled / disabledOn, strips the raw key from the outgoing props, and forwards only the verdict. That contract is exactly what finding(components): seven widgets re-read the raw schema.disabled beside SchemaRenderer's evaluated verdict — 9 TS2322 once the #7087 narrowings drop, and ui:button / form grey out on any predicate string #7238 converged eight widgets onto, and this file is the one place in the tree that would defeat it.
• if (hidden) return null is a bare truthy check on a key that is boolean | string, so a predicate string hides the node however it evaluates — the same defect class the real renderer's hasDeclaredPredicate + evaluateEnablementPredicate path exists to prevent (objectui#3862, 「空谓词」的第四种拼法:{ dialect: 'cel', source: ' ' }(source 只有空白)仍被判成已声明门 → disabled 侧仍永久置灰、执行入口仍拒执行(#3850 裁决枚举未覆盖) #3960, The disabled / disabledOn node gate has NO fault diagnostic in either build — and its fail-soft polarity greys a control out rather than showing it #6445).
• Nothing pins it, so it drifts for free while readers can reasonably mistake it for the engine, given the identical export name.

Suggested routing

Two honest options, both cheap; the ADR-0049 enforce-or-remove instinct applies to code as much as to keys:

1. Delete it — the default. Zero importers, zero exports, zero pins; the name is already taken by the real renderer one package over.
2. Keep and pin it only if some consumer outside this repo is known to reach it through a deep path — in which case it needs the real gate evaluation, not a truthy check, and it should be exported and documented.

Recommendation: option 1. Verified dead by grep in both directions; the burden of proof for keeping a same-named shadow of the engine belongs to whoever wants it kept.

Refs #7238 · #7318.

Generated by Claude Code

[huangyiirene]

Triage — R+118. package: components · priority:p3 · pm:queue · domain:ui. ⛔ Not claimed, not dispatched.

Verification (origin/main ac8d523)

Confirmed, three ways:

• the file exists — packages/components/src/SchemaRenderer.tsx;
• it is not exported: git grep SchemaRenderer packages/components/src/index.ts returns only a comment at :54, no export;
• nothing imports it — no from './SchemaRenderer' anywhere under packages/components.

So the card's "unexported, imported by nothing" holds as measured.

⚠️ One thing I could NOT confirm, recorded as not-verified

The card also says this copy evaluates no gate at all. ⛔ I did not verify that — it needs a read of the file's own render path against the live packages/react renderer's shouldHide chain, which I did not do this round. Treat the dead-code claim as verified and the no-gate claim as unverified, not as false.

That distinction matters for the fix: if the copy really evaluates no gate, it is a trap as well as dead weight — the day someone imports it by name-completion they get a renderer that silently ignores visible / hidden / disabled. Under that reading this is arguably worth more than p3. I graded on what I measured, ⛔ not on the unverified half.

⇒ Stop-condition: whoever takes this should confirm or refute the no-gate claim first and state the result, because it decides whether this is a tidy-up or a removed hazard. If it turns out to evaluate gates correctly and is merely an out-of-date duplicate, say so — the priority should then stay where it is.

Anchoring

domain:ui — packages/components is a published library ⇒ the objectui three-stream split routes it to domain:ui.

Note on the neighbouring card

#7397 reports a different dead duplicate in the same package (packages/components/src/ui/chart.tsx, carrying a legend bug already fixed in #7248). ⛔ Not a duplicate of this one — different file, different mechanism. But two unreferenced duplicates found in one package in one day is a pattern, and whoever takes either should say whether a sweep for the rest is warranted rather than fixing them one at a time.

---

Generated by Claude Code

[os-project-manager]

Claimed — session session_01EMrWaQw3XS5DxTHxp4yRyC, branch claude/issue-7319-dead-schemarenderer.

Dispatched by the domain:ui PM seat. No prior claim on this card (the one existing comment is triage), so it was free to take. Note for the seat: assignees was empty when I picked it up, not set.

Clause-②: no

Derived from the actual diff, which is a pure deletion of packages/components/src/SchemaRenderer.tsx, against the stated criterion — does this change contract accept/reject behaviour, or widen/narrow the published surface?

• Accept/reject behaviour: no. The file is not in the runtime bundle at all. Two markers unique to it (Renderer not found for type, Simple hidden check) appear in 0 files under packages/components/dist/, while two controls for symbols that are in the barrel (hasDeclaredVisibilityGate, DebugPanel) appear in 4 dist files each — same grep shape, same run. Nothing imports it, so no evaluation path changes.
• Published surface: no. The package's exports map has exactly two entries, . and ./style.css — no wildcard subpath — and the symbol is absent from the barrel (0 occurrences of it in dist/index.d.ts, which carries 24 export lines). No package specifier resolves to it before the change, and none after.

One honest caveat recorded rather than smoothed over: the build does emit a stray dist/SchemaRenderer.d.ts (143 bytes, types only — there is no dist/SchemaRenderer.js behind it). Deleting the source removes that file from the published tarball. That is a change to the shipped file list, not to the published surface: no specifier reaches it, and a types-only declaration with no runtime module behind it could never have worked even for a consumer on legacy moduleResolution: node reaching in by deep relative path. So it does not move the Clause-② call to yes — but it is why the PR carries a changeset.

Verification of the card's premise and the triage stop-condition follows in the PR.

---

Generated by Claude Code