Both `plugin-grid` catalog entries are hand-built static card layouts that never author `object-grid` — the last instance of #5113's class

[os-zhuang]

Found while implementing #5113 (plugin-view's three "Interactive Examples" used no object-view). Filed unassigned, not claiming.

Measured on the #5113 branch (claude/issue-5113-plugin-view-interactive-examples), walking every plugin-* catalog category and collecting the set of type values each entry authors:

== plugin-grid
 plugin-grid/product-inventory-grid -> badge button card flex stack text
 plugin-grid/team-members-grid -> badge button card flex stack text

Every other plugin-* category authors a type its own package registers — calendar-view, chart/bar-chart, chatbot, dashboard, code-editor, object-gantt, kanban, object-map, markdown, timeline, form (registered by plugin-form as an alias of ObjectFormRenderer, packages/plugin-form/src/index.tsx:184), and — as of #5113 — object-view. plugin-grid is the only category left whose entries are pictures of the component rather than the component.

Why it matters, and why it is not covered

Same mechanism as #5113: content/docs/plugins/plugin-grid.mdx mounts these under a PluginLoader for a plugin they do not use, so a reader sees a drawn table where the plugin's output is claimed. Nothing catches it — check-doc-component-types only asks whether each type is registered (card, flex, badge all are), and catalog-gallery-render.test.tsx only asks whether the tile draws (these do).

#5113's PR adds a pin for plugin-view only (objectui#5113 — the plugin-view entries render THROUGH object-view in examples/schema-catalog/test/catalog-gallery-render.test.tsx): every entry in the category authors an object-view node and the rendered tile shows a record that exists only in the gallery's data source. It is deliberately not generalized — the general rule needs a per-plugin map of which types each package registers, and this category was the reason it could not simply be turned on for all of plugin-*.

What a fix would involve

object-grid reaches its data the same way object-view does — dataSource is a prop the registered renderer pulls off SchemaRendererContext, not a schema key. #5113 gave the docs gallery's fixture (apps/site/app/components/galleryDataSource.ts) the object surface it needs (getObjectSchema / find / findOne / writes) and pointed InteractiveDemo at it, so the machinery a real object-grid example needs already exists after that PR lands; the work is authoring the entries and re-seating whatever of the two mock-ups is worth keeping.

⚠️ Note for whoever takes it: deleting a catalog entry moves three corpus-wide counters — layout-dom-leak-5574.test.tsx's NODE_CENSUS and two floors in layout-props-conversion.test.tsx (className-carrying layout nodes, stack nodes). #5113 re-seated its three mock-ups into honest categories rather than dropping them, precisely so no floor had to move.

Triage note

Severity left to PM. Read as a concrete defect it is #5113 one category over; read as an observation, the two entries render fine and mislead only by where they are mounted.

[claude]

Triage (daily round, session session_01Kktexqp6uVuFMztvvTMf3V, 2026-08-24): lands in the plugin-grid catalog entries → domain:ui + pm:queue, Task — last instance of the #5113 class, inherits that card's judgment (catalog entries author the component their package registers, not hand-built look-alikes). Serial: verify #5113's PR is merged first; reuse its shape.

---

Generated by Claude Code

[yinlianghui]

Claim: PM loop round 38 (refill slot)
Session: session_01CSoz9uGhaaSgiq3hshtN7L
Branch: claude/issue-5856-plugin-grid-catalog-entries
Worktree: objectui-issue-5856
Domain: domain:ui
File surface: examples/schema-catalog/src/schemas/plugin-grid/*.json, examples/schema-catalog/test/catalog-gallery-render.test.tsx (the pin), content/docs/plugins/plugin-grid.mdx if the prose names the entries, wherever the re-seated mock-ups land, + a changeset
Container & model: M, mode:subagent, model: opus
Clause-②: no — catalog fixtures and a test pin. No declaration moves, no published surface widens.
Serial constraints cleared: examples/schema-catalog/** and content/docs/plugins/** — no in-flight claim. Concurrent siblings: #4730 (packages/i18n/src/locales/**), #5927 (packages/types/src/zod/**), #5976 (packages/plugin-map/**), #5565 (apps/console + packages/app-shell). Disjoint by full path.

裁决 — triage's grade, and its serial precondition is DISCHARGED

Triage seat, 2026-08-24: domain:ui + pm:queue, Task. Verbatim: "last instance of the #5113 class, inherits that card's judgment (catalog entries author the component their package registers, not hand-built look-alikes). Serial: verify #5113's PR is merged first; reuse its shape."

I verified it: #5113 is CLOSED, via PR #5857 (docs(plugin-view): make the three "Interactive Examples" real object-view nodes), state MERGED. The precondition is satisfied and the fence is spent. ✅ Reuse #5857's shape — read that PR before writing anything; it is the worked example of this exact fix one category over.

The inherited judgment, stated so you do not have to re-derive it: a catalog entry mounted under a PluginLoader for a given plugin must author a type that plugin registers. plugin-grid's two entries (product-inventory-grid, team-members-grid) author only badge button card flex stack text — pictures of a grid, not a grid. Every other plugin-* category already authors its own type (calendar-view, chart/bar-chart, chatbot, dashboard, code-editor, object-gantt, kanban, object-map, markdown, timeline, form, and since #5113, object-view). plugin-grid is the last one left.

⛔ The trap that will cost you the round if you miss it

Deleting a catalog entry moves three corpus-wide counters: NODE_CENSUS in layout-dom-leak-5574.test.tsx, and two floors in layout-props-conversion.test.tsx (the className-carrying layout node count, and the stack node count).

⛔ Do not "fix" this by deleting the two mock-ups. #5113 re-seated its three mock-ups into honest categories precisely so no floor had to move, and that is the shape to reuse. If your change moves any of those three counters, ⛔ stop and report rather than editing a floor — a floor that moves because a fixture was deleted is indistinguishable, six months later, from a floor that moved because coverage regressed. If re-seating genuinely cannot preserve them, say why and what the exact deltas are.

Scope

1. Author real object-grid entries for the plugin-grid category, the way docs(plugin-view): make the three "Interactive Examples" real object-view nodes (#5113) #5857 authored real object-view ones.
2. Re-seat whatever of the two mock-ups is worth keeping into an honest category (they are legitimate static layouts — they are just filed under the wrong plugin). Preserve the three counters.
3. Extend plugin-view 文档页的三个 "Interactive Examples" 没有一个用到 object-view —— 都是手搭的静态卡片版面,且 id 沿用虚构的 viewMode 三分法 #5113's pin to plugin-grid. docs(plugin-view): make the three "Interactive Examples" real object-view nodes (#5113) #5857 added objectui#5113 — the plugin-view entries render THROUGH object-view in examples/schema-catalog/test/catalog-gallery-render.test.tsx, asserting that every entry in the category authors an object-view node and that the rendered tile shows a record existing only in the gallery's data source. ✅ The second half is what makes it a real pin rather than a grep — reuse both halves.
4. ⛔ Do NOT generalize the pin to all of plugin-*. plugin-view 文档页的三个 "Interactive Examples" 没有一个用到 object-view —— 都是手搭的静态卡片版面,且 id 沿用虚构的 viewMode 三分法 #5113 deliberately left it per-category because the general rule needs a per-plugin map of which types each package registers — and plugin-grid was the specific reason it could not simply be turned on. Once this card lands that blocker is gone, which makes generalizing a follow-up card, not this one. ✅ File it as a finding (unassigned, no labels — triage grades it) and say in it that this card removed its last obstacle.

PM mechanism assumptions — measure, do not assume

1. The card asserts the machinery already exists after plugin-view 文档页的三个 "Interactive Examples" 没有一个用到 object-view —— 都是手搭的静态卡片版面,且 id 沿用虚构的 viewMode 三分法 #5113: object-grid reaches data the same way object-view does — dataSource is a prop the registered renderer pulls off SchemaRendererContext, not a schema key — and plugin-view 文档页的三个 "Interactive Examples" 没有一个用到 object-view —— 都是手搭的静态卡片版面,且 id 沿用虚构的 viewMode 三分法 #5113 gave apps/site/app/components/galleryDataSource.ts the object surface (getObjectSchema / find / findOne / writes) with InteractiveDemo pointed at it. ⛔ Do not assume that transfers cleanly. Verify on your merge-base that a real object-grid node actually renders against that fixture — if ObjectGrid needs something ObjectView did not (a column source, an object schema shape, a different context key), that is the whole difficulty of this card and it must be measured before you author two entries against a hope.
2. The type-set reading is from the plugin-view 文档页的三个 "Interactive Examples" 没有一个用到 object-view —— 都是手搭的静态卡片版面,且 id 沿用虚构的 viewMode 三分法 #5113 branch, not from main. Re-run the walk on your own merge-base and report the current type sets for both entries. The card's own re-check recipe is in plugin-view 文档页的三个 "Interactive Examples" 没有一个用到 object-view —— 都是手搭的静态卡片版面,且 id 沿用虚构的 viewMode 三分法 #5113 and is reusable.
3. ⚠️ The two existing gates cannot see this defect, by construction — check-doc-component-types only asks whether each type is registered (card/flex/badge all are), and catalog-gallery-render.test.tsx only asks whether the tile draws (these do). So ⛔ a green gate run is not evidence your fix worked. The new pin is the only thing that can tell the difference, which is why item 3 is not optional.
4. content/docs/plugins/plugin-grid.mdx mounts these under a PluginLoader for a plugin they do not use. Check whether the page's own prose claims these are the plugin's output; if it does, the prose moves with the entries. ⛔ But stay out of content/docs/releases/** entirely (CLAUDE.md).

Verification

Reverse-verify with the direction predicted before running: revert one entry to a hand-built layout and show the new pin goes red; prove the mutation on disk by grepping the injected text and separately the removed text (an editor's exit code proves nothing on a zero-hit anchor); restore under trap … EXIT INT TERM and confirm git diff HEAD --stat is empty afterwards.

Counter-probe required, both halves of the pin: (a) an entry that authors object-grid but renders no gallery-only record must fail the data half — otherwise the pin passes on a grid wired to nothing; (b) the plugin-view entries #5857 landed must stay green under your generalisation of the pin, proving you extended it rather than replaced it.

Gates by name with exit codes: root-form vitest over examples/schema-catalog and the two counter-carrying suites layout-dom-leak-5574.test.tsx / layout-props-conversion.test.tsx (⚠️ this repo's vitest guard refuses the --filter forms — use pnpm exec vitest run <paths> from the repo root), plus node scripts/check-doc-component-types.mjs, node scripts/check-doc-snippet-types.mjs and node scripts/check-doc-links.mjs, each quoting its own verdict line rather than $? after a pipe.

Run node scripts/check-changeset-presence.mjs rather than guessing whether a changeset is owed; empty frontmatter is this repo's "releases nothing" declaration. Draft PR, Fixes #5856. Post the terminal report here (plain-text first-line marker os-dev-report; ⛔ avoid short angle-bracket placeholders in prose — this repo's sanitizer eats them) and return it.

---

Generated by Claude Code