docs(plugin-view): make the three "Interactive Examples" real object-view nodes (#5113)

[os-zhuang]

Fixes#5113

The plugin-view docs page presented three hand-built static card layouts as this plugin's "Interactive Examples", inside a PluginLoader plugins={['view']} wrapper none of them used, under ids named after the fabricated viewMode trichotomy #5088 had already removed from the prose. Verified on the merge base (d40d2953e) with the issue's own probe: the three entries' node types were badge/button/card/flex/stack/text, avatar/button/card/flex/stack/text and button/card/flex/grid/input/label/select/stack/text — no object-view, no objectName, no data source anywhere.

The fix makes the examples be the thing they claimed to be, rather than renaming the ids so the fiction reads tidier.

What changed

Three real object-view entries (examples/schema-catalog/src/schemas/plugin-view/), one per axis the page's own prose teaches:

entry	teaches
object-view-list	the list surface — table.columns, sort, pagination, the toolbar flags
object-view-named-views	listViews + defaultListView, two saved views over one object
object-view-record-surface	layout / navigation / form / operations — create, read and edit as one surface

The docs gallery's data source gained an object surface (apps/site/app/components/galleryDataSource.ts). This is the machinery question the triage note asked to measure first, and the answer was that the existing fixture — introduced by #4600 for dataset-bound dashboard widgets — is the right home: dataSource is not a schema key, it is the prop the registered renderer pulls off SchemaRendererContext (packages/plugin-view/src/index.tsx), so with nothing behind that context a plugin-view example can only be a drawing of one. It now answers getObjectSchema / find / findOne and the three writes for one canned users object. No renderer capability was added, no type widened, no pin loosened.

InteractiveDemo now supplies that fixture — it supplied {} — which is what lets the page's own previews reach data at all. It is the same module SchemaThumbnail already hands the gallery, not a second one.

Honesty about the fixture's limits, on the page and in the file. The fixture answers $search, $orderby and the $skip/$top window, and does not answer $filter. So the three entries author showFilters: false and the page says why: a filter affordance that silently did nothing would be the same defect this card removes, one control over.

The three mock-ups are re-seated, not deleted — they are legitimate static card compositions, just not examples of this plugin: components-layout-card/user-list-card, components-layout-card/profile-detail-card, forms/create-user-form. Their gallery descriptions now say what they are and point at the object-bound examples. Deleting them was tried first and rejected on evidence: it dropped three corpus-wide counters below their floors (layout-dom-leak-5574's NODE_CENSUS, and two ratchets in layout-props-conversion — className-carrying layout nodes 172 < 175, stack nodes 152 < 153). Re-seating keeps every node in the corpus, so no floor and no census moved. For the same reason grid-columns-key.test.tsx's #4001 row is renamed, not dropped: plugin-view/form-view-mode → forms/create-user-form is the same file with the same columns: 2 grid node, so the repair that row pins is still pinned.

A new pin (examples/schema-catalog/test/catalog-gallery-render.test.tsx), because "does every tile draw" could not see this defect: every plugin-view entry authors an object-view node, and its rendered tile shows a record that exists only in the gallery's data source. The second half is the discriminating one — it cannot be satisfied by a picture of a view. Host-parity cases pin that both docs hosts hand the fixture to the renderer and that the host fixture still exposes every method the test's mirror implements.

plugin-view.mdx keeps its ## Interactive Examples heading, which is now true.

Verification — all at 7a4c3a477

Each line below is the gate's own verdict, not a shell exit code.

• pnpm exec vitest run examples/schema-catalog/ (repo root) — Test Files 10 passed (10), Tests 1632 passed (1632).
• pnpm exec vitest run scripts/__tests__/{site-catalog-card-interactive-nesting-3903,site-playground-layout-registration-3904,extract-mdx-demos,doc-version-claims,catalog-index-regenerable-4633,check-doc-component-types}.test.ts — Test Files 6 passed (6), Tests 96 passed (96).
• node scripts/check-doc-component-types.mjs — ✅ Every documented component type is registered. (882 type literals against 659 registered keys).
• node scripts/check-doc-snippet-types.mjs — Every covered documentation snippet compiles against the built types.Semantic phase: 101 of 101 block(s) judged, 0 failed.
• node scripts/check-doc-links.mjs — Links are valid across 13 scan roots.
• node scripts/check-changeset-presence.mjs — ✅ No source of a released package changed in this range, so no changeset is owed. (apps/site and examples/schema-catalog are both private.)
• python3 scripts/regenerate-catalog-index.py --check — examples/schema-catalog/src/index.ts is up to date (426 entries).
• node scripts/check-control-bytes.mjs — ✅ check-control-bytes: OK (scanned 4871 tracked text file(s)).
• pnpm --filter @object-ui/example-schema-catalog type-check and pnpm --filter @object-ui/site type-check — both exit 0 with their scripts echoed (tsc --noEmit && tsc -p tsconfig.test.json; fumadocs-mdx && next typegen && tsc --noEmit). The site run is only meaningful after @object-ui/example-schema-catalog is built — unbuilt, it reports three phantom TS2307s.

Reverse verification — both halves of the new pin were shown to fail, each with the mutation confirmed on disk before the run and restored by an EXIT trap:

1. Replaced object-view-list.json with a static card ("type": "card" count 1, object-view count 0 in the file): expected [ 'card', 'text' ] to include 'object-view'. The render half still passed — deliberately, because that mutation hard-coded the row text, which is exactly why both halves exist.
2. Starved the test's fixture mirror (data: [...USERS_ROWS] occurrences 1 → 0): all three render cases red — expected 'User DirectoryEveryone with an accoun…' to contain 'Alice Johnson' — while the structure half stayed green.

Declared narrowing: repo-wide pnpm lint was not run locally; ESLint ran on the five changed .ts/.tsx files — exit 0, files linted: 5 read from --format json, 0 errors and one pre-existing warning on generated index.ts line 13 ('ExampleMeta' is defined but never used), a line byte-identical on origin/main. The narrowing is sound because this repo's ESLint config declares no project/projectService (eslint.config.jslanguageOptions is ecmaVersion + globals only), so it is not type-aware and no untouched file's verdict can move. CI runs the full farm regardless.

Out of scope, filed

• Both plugin-grid catalog entries are hand-built static card layouts that never author object-grid — the last instance of #5113's class #5856 — both plugin-grid catalog entries are the same defect one category over (badge button card flex stack text, no object-grid). A census across every plugin-* category is in that issue; after this PR, plugin-grid is the only one left. The new pin is deliberately not generalized to all of plugin-* — the general rule needs a per-plugin map of registered types, and that category is why it could not simply be switched on.

Generated by Claude Code

---

Generated by Claude Code