Uh oh!
There was an error while loading. Please reload this page.
test(schema-catalog): derive the own-plugin pin and generalize it to all 13 plugin-* categories - #6174
Merged
Conversation
…all 13 plugin-* categories `catalog-gallery-render.test.tsx`'s "entries use their own plugin" pin ran over a hand-enumerated two-entry `CATEGORY_OWN_TYPE` table. Replace it with a map derived from the `register()` calls (`deriveRegistryKeys`, joined on the `packages/<dir>` registration site) and turn the pin on for every `plugin-*` catalog category. The value is a set, because `plugin-charts` entries author `chart` and `bar-chart`, and the rule stays per entry. objectui#5113's RENDER half only applies where a record can exist that the entry's own JSON could not supply, so rather than degrade to STRUCTURE for the eleven categories that author their data inline, add a MOUNT half that applies to all of them: replacing every own-plugin node with an inert probe must put the probe's marker on screen. Data provenance is unchanged for the entries that bind to a fixture object, derived per entry from `objectName`. The gate prints and pins its own coverage split. The derivation immediately falsified the filing's hand-written table: `form` is registered by `packages/components`, not `@object-ui/plugin-form`, so both `plugin-form` entries are the third instance of objectui#5113's class. They are ledgered against objectui#6167 with a case asserting they still fail.
yinlianghui-tw
marked this pull request as ready for review
August 24, 2026 22:34
Uh oh!
There was an error while loading. Please reload this page.
This was referenced Aug 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes#6024
Tests and test-config only. All gate output below was measured on
7ef59ccd1, which is this branch's head.What changed
examples/schema-catalog/test/catalog-gallery-render.test.tsx's "entries use their own plugin" pin ran over a hand-enumerated two-row table (plugin-view,plugin-grid). It now runs over everyplugin-*catalog category — thirteen of them — with the category/type map derived from theregister()calls.1. The map is a derivation, not a literal
deriveRegistryKeysfromscripts/check-doc-component-types.mjs— the same derivationscripts/regenerate-known-schema-types.mjsalready consumes — returnskey -> registration sites. Joining those sites on thepackages/DIRthat owns them givescategory -> key set, because catalog category and package directory are the same string. The value is a set, whichplugin-chartsrequires (chartandbar-chart), and the rule stays per entry: every entry authors a node whose type is in the set its own package registers. Not "the category authors at least one".The derivation earned its keep on its first run. The filing's hand-written table read
plugin-form form. Measured against the register calls that is wrong —formis registered bypackages/components/src/renderers/form/form.tsx:962, not by@object-ui/plugin-form, whose own keys areobject-form,embeddable-form,form-analytics,object-master-detail-form. Bothplugin-formentries are therefore the third instance of #5113's class. Filed as #6167, ledgered inOWN_PLUGIN_DEBTwith a case asserting they still fail, so the ledger cannot rot green.2. The RENDER half generalizes as MOUNT — it did not degrade to STRUCTURE
#5113's render half (a record that exists only in the gallery data source reaches the screen) cannot transfer to the eleven categories that author their data inline: there is no record they could not have supplied themselves. Rather than record them structure-only, they get a different formulation of "this really rendered through the plugin":
A stray
typethat is not a node, a node under a branch the parent never renders, and a node behind a satisfiedhiddenall satisfy STRUCTURE and all fail MOUNT. It also costsplugin-editorandplugin-mapnothing: the probe replaces the renderer that wants Monaco / WebGL2, so theirEXCLUSIONSentries buy them no reduction in this pin.Data provenance is kept unweakened where it applies, and which entries those are is derived from each entry's own
objectNameagainst the fixture's object names — not declared, so a category that becomes object-bound picks the half up with no edit here.3. The gate states its own split
it('states its own coverage split ...')pins the classification as a literal:plugin-grid,plugin-viewplugin-formA new category, a new entry, or an entry changing tier turns that case red for review.
4. Two weaker render formulations were built, measured and rejected
Both as "the live tile shows content the probe-substituted tile does not":
plugin-chartsrenders recharts into a container happy-dom gives zero size, soadvanced-line-chartandsimple-bar-chartpaint 0 new text tokens against the probe render.React.lazycategories (kanban,markdown,code-editor) additionally make the count depend on whether the dynamic import has landed.A discriminator that is red on correct entries gets the gate deleted, so the honest claim is the one asserted and the split says how far it goes.
Verification
The derivation probe — the map FOLLOWS a rename
packages/plugin-markdown/src/index.tsx, oneregister()call renamed in a throwaway probe (restore trap onEXIT INT TERM; on-disk mutation confirmed by counting the deleted anchor and the injected text, not by the editor's exit code):A first attempt on
plugin-markdownused a single-line anchor that does not match its multi-lineregister(call. The mutation guard refused the reading (MUTATION DID NOT LAND - reading below is VOID) rather than reporting a green no-op.Non-vacuity — two instruments blind, one not, over one tree
plugin-markdown/basic-markdown(a newly covered category, notplugin-view/plugin-grid) reverted to a hand-builtcard/h1/textpicture of the component:The #4616 sweep still reports
basic-markdown renders without a red tileandputs its authored content on screenas green. That contrast is the case for this pin existing.The load-bearing half — MOUNT catches what STRUCTURE cannot
The same picture, plus a stray
markdownnode parked insidepropswhere no renderer reads it:STRUCTURE passes on this tree. MOUNT is the only thing that goes red. That is the measurement behind the claim that the eleven newly covered categories did not quietly get the cheap half.
A fact the pin found while being written
no plugin-* entry authors Alice Johnsonwas first written corpus-wide and turned red immediately:components-layout-card/profile-detail-cardandcomponents-layout-card/user-list-carddo author the string. They are hand-built cards, they carry no data half, and a corpus-wide assertion would have been red on two correct entries — so the case is scoped to this pin's own universe, with the two named in the comment.Gates per this diff, each quoting its OWN verdict line
Exit codes captured before any pipe; three files changed (
.changeset/*.md, the test,tsconfig.test.json).vitest run examples/schema-catalog/test/catalog-gallery-render.test.tsxTest Files 1 passed (1)/Tests 564 passed (564)vitest run examples/schema-catalog/Test Files 12 passed (12)/Tests 1768 passed (1768)vitest run scripts/__tests__/{check-doc-component-types,known-schema-types-derivation-5115,scripts-type-check,vitest-invocation-guard}.test.tsTest Files 4 passed (4)/Tests 89 passed (89)pnpm --filter @object-ui/example-schema-catalog type-checktscprojects, no diagnostics)pnpm turbo run lint --concurrency=2Tasks: 47 successful, 47 total— 0 errors repo-widenode scripts/check-type-check-coverage.mjs✅ test type-check coverage: 41/41 packages compile their tests, 0 declared debtnode scripts/check-lint-coverage.mjs✅ lint coverage: 46/46 packages linted, 0 with outstanding errors (0 total).node scripts/check-control-bytes.mjs✅ check-control-bytes: OK (scanned 5099 tracked text file(s); skipped 85 binary).node scripts/check-doc-component-types.mjs✅ Every documented component type is registered.node scripts/check-changeset-no-major.mjs✅ No changeset declares amajorbump.node scripts/check-changeset-presence.mjs✅ No source of a released package changed in this range, so no changeset is owed.pnpm type-check:scriptsVitest was run from the repo root throughout (objectui#3378). The repo-wide lint farm ran in full, so no narrowing is claimed.
Note on
tsconfig.test.jsonexamples/schema-catalog/tsconfig.test.jsongainsallowJs(withcheckJsoff) and a repo-rootrootDir. That is the same answertsconfig.scripts.jsonreached in objectui#3494 for importing a plain-JS CI helper into a typed pin test: the alternative, a hand-written.d.mtsbeside the.mjs, is a second source of truth free to drift, whereas inferred types mean changing the helper's exported signature turns this test red.rootDiris checked against every file in the program (TS6059) even undernoEmit, and nothing else reads it here.Generated by Claude Code