Docs gallery: 35 catalog entries render the red "Unknown component type" panel because their plugin package is never loaded on that page

[yinlianghui]

Measured while implementing (d1) of #4600 (PR #4615). Filed unassigned; not fixed there — that PR registers only the two packages its own category needs (plugin-dashboard, plugin-charts), which leaves the rest of this population untouched. Duplicate-searched (keyword + SchemaThumbnail / PluginLoader path): no open issue covers it.

The defect

apps/site/app/components/SchemaCatalogIndex.tsx renders every catalog entry through a real SchemaRenderer (via SchemaThumbnail), and /docs/guide/schema-catalog is a published page. But ComponentRegistry only knows a type once the package owning it has loaded, and that page loads no plugin at all: SchemaThumbnail imports @object-ui/react, @object-ui/components and ./registerLayoutBlocks, and nothing else. PluginLoader exists for exactly this, but it is opt-in per MDX page and schema-catalog.mdx contains only SchemaCatalogIndex.

So every entry whose root type belongs to a plugin renders the registry's red panel:

Unknown component type: dashboard 💡 Ensure the component is registered via
registry.register() before rendering. Check for typos in the component type
name. (OBJUI-001)

Population, measured on origin/main @ c1d939f7f

Resolving each entry's ROOT type against exactly the gallery's registration set (@object-ui/components + registerLayout()):

total examples: 423
unresolved root types: 44

  dashboard: 9      calendar: 5        chatbot: 3        code-editor: 3
  object-gantt: 3   object-map: 3      markdown: 3       timeline: 3
  calendar-view: 2  chart: 2           kanban: 2         filter-ui: 1
  sort-ui: 1        view-switcher: 1   single: 1         bar-chart: 1
  unknown-component: 1

PR #4615 covers dashboard (9) and chart / bar-chart (3) as a side effect of registering plugin-charts. That leaves ~32 still showing OBJUI-001, across calendar, chatbot, editor, gantt, map, markdown, timeline and kanban. (core-schema-renderer/unknown-component-type is deliberate — it demonstrates the panel.)

Note this is a ROOT-type census only. Entries whose root resolves but whose nested nodes do not are not counted here and may add to it.

Why it was invisible

examples/schema-catalog/test/smoke.test.tsx contains no render( call — its assertions are structural. PR #4615 adds a render pin, but scoped to the plugin-dashboard category. A category-wide version of that pin is the obvious guard once the registration question is decided.

Fix shape (not prescriptive — this is a real decision)

apps/site/app/components/registerCatalogBlocks.ts (added by PR #4615) is the natural home, but adding all ~12 plugin packages eagerly pulls their graphs into every page that renders a thumbnail, which is precisely what PluginLoader's lazy design avoids. ComponentRegistry.registerLazy is the third option — SchemaRenderer already force-updates when the registry mutates, and ObjectView uses it "so heavy plugins stay code-split" — at the cost of the prerendered HTML that registerLayoutBlocks' header calls out as the reason it is eager. Worth deciding rather than defaulting.

Refs #4600, PR #4615, #3787 (the same defect for page-header).

---

Generated by Claude Code

[yinlianghui]

CLAIM — session session_017Qqyix2QcnpUC9XeYVDzx3, branch claude/issue-4616-gallery-full-registration.

PM ruling (delegated, veto window open) — the gallery page's purpose decides the default, measurement gates it: the catalog gallery exists to render the WHOLE catalog, so its baseline is eager registration of every plugin the entries need — extend registerCatalogBlocks (the #4615 mechanism) to the full bucket list from this card's census. That default is GATED by measurement, not assumed:

1. Measure the cost first: the gallery page's prerender time and client bundle delta with all plugins registered vs today (next build's own route-size output is the instrument). Report before/after verbatim. STOP CONDITION: if the gallery route's first-load JS grows by more than ~50% or prerender breaks, stop at the census + numbers and report — the fallback (per-bucket lazy registerLazy/dynamic import with a loading tile) becomes its own decision rather than a silent substitution.
2. Within budget ⇒ register all buckets; extend the fix(examples,docs): the dashboard gallery renders working charts again — filtered-* entries leave the retired shape (#4600) #4615 render pin from plugin-dashboard to EVERY category (no OBJUI-001 tile, no error tile, every authored title present — the same non-vacuity discipline), red-first against today's 35 (capture the true count per bucket verbatim).
3. Entries that still fail for reasons OTHER than registration (their own shape defects, like the pre-fix(examples,docs): the dashboard gallery renders working charts again — filtered-* entries leave the retired shape (#4600) #4615 dashboard entries) are NOT silently fixed here: census them, file per-bucket findings for real defects, and scope the pin so it reds on them honestly — say which entries are excluded and why, or fix trivial ones in place if comment-level. ⛔ Do not rewrite entry semantics wholesale — that was (d1)'s per-entry measured work, and each bucket deserves the same care only when its census demands it.
4. InteractiveDemo/LiveSplitDemo keep their PluginLoader lazy loading (the fix(examples,docs): the dashboard gallery renders working charts again — filtered-* entries leave the retired shape (#4600) #4615 separation stands); only the gallery page's registration widens.

Standard playbook: worktree, red-first verbatim, reverse verification (no git stash), repo-root vitest incl. scripts/ (the #3904 site-host guard), gate battery, no changeset owed expected (apps/site + examples ignored — measure), DRAFT PR referencing Fixes #4616 only if the pin covers all buckets, CI via MCP only, no flip/arm.

Mutual exclusion: #4618's seat (parallel) owns the data-table crash — if a bucket's entries crash into that defect, EXCLUDE them from the pin with a comment naming #4618 rather than chasing it. ⛔ content/docs/releases/**; ⛔ metric-card spec-validity (objectstack#8593).

---

Generated by Claude Code

---

Generated by Claude Code