Uh oh!
There was an error while loading. Please reload this page.
feat(plugin-dashboard): publish the honoured dashboard inputs, pin the two ruled-out keys (#5742) - #5829
Merged
os-zhuang merged 2 commits intoAug 23, 2026
Conversation
…e two ruled-out keys (#5742) The `dashboard` registration published exactly three inputs (columns/gap/ className) while DashboardRenderer honoured widgets, label (legacy title), description, header, globalFilters, dateRange and refreshInterval — so `validateTree` and the generated sdui.manifest.json / sdui-intrinsics.d.ts warned authors off keys that work, `widgets` included: the very prop the objectui#5709 unconsumed-options warning descends into. Per-key triage (the shipped #4668 / #5091 line — declare only what the spec's strict DashboardSchema accepts AND the renderer reads): - DECLARED: widgets, label (string | locale map), description (string | locale map), header, globalFilters, dateRange, refreshInterval — plus the existing columns/gap/className, untouched. - NON-AUTHOR, pinned: `title` (legacy spelling; spec rejects it by name; the `schema.title || schema.label` read stays for documents in the wild) and `aria` (spec tombstone from the #3896 audit close-out; measured: this package has NO aria read site, correcting the issue body on that one key). - RAISED, not guessed: `name` (spec accepts it; renderer reads it for the dashboards.{name}.* translation lookups; but it is document identity written by the stored-dashboard path, no docs example authors it inline, and no sibling registration declares a name input). Open question on #5742. The new dashboardAuthoredInputs test pins all three faces: author reach (previously-unknown-prop keys now clean on an inline dashboard node, with off-arm and silenced-check controls), the exclusion pins in the gridNonAuthorKeys shape, and the generated manifest/intrinsics via the same manifestFromConfigs/generateDts pair gen-manifest.ts uses. Fixes#5742 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EuPCi56cnGyykygi3z9w4m
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
…ne (#5742) Comments only; no behaviour, no test, no declared input changes. The registration comment and the pin-test docblock both carried `name`'s absence from `inputs` as "pending (not ruled)". It is now ruled non-author for the inline node, and both markers are replaced with the ruling and, importantly, with the REASON — which is not the one the neighbours carry: - It is NOT a spec rejection. `title` and `aria` are excluded because the spec rejects them by name. The spec ACCEPTS `name`, but on the DOCUMENT form where it is required, not on the inline node — so the shipped "spec accepts + renderer reads => declare" line never fires here at all. Left unsaid, a reader seeing `name` excluded beside `title` would assume the same reason and be wrong. - The `schema.name` read is untouched; it still keys the `dashboards.{name}.*` translation lookups. - The evidence is producer-side alone (`DashboardView` / the document loader hands the loaded document to the renderer), which makes this a weaker pin than the other two — each of which asserts a re-checkable spec verdict — and is why `name` carries no `NON_AUTHOR` row. Both comments say so plainly rather than papering over it. Supporting reason, recorded in both places: publishing `name` inline would teach authors, AI authors especially, to fabricate a dashboard identity that resolves no translations and fails silently — a newly manufactured silently-inert key, the exact defect class this card removes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EuPCi56cnGyykygi3z9w4m
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
os-zhuang
marked this pull request as ready for review
August 23, 2026 14:41
Uh oh!
There was an error while loading. Please reload this page.
os-zhuang
deleted the
claude/issue-5742-dashboard-declare-honoured-inputs
branch
August 23, 2026 14:41
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#5742
What
The
dashboardregistration (packages/plugin-dashboard/src/index.tsx) published exactly three inputs —columns,gap,className— whileDashboardRendererhonoured far more, sovalidateTreeover the live manifest reportedunknown-propon keys that work,widgetsincluded: the very prop whose contents the #5709unconsumed-widget-optionwarning descends into.dashboardis inPUBLIC_BLOCKS, soinputsis contract surface, serialized intosdui.manifest.jsonandsdui-intrinsics.d.ts.public-blocks.tsis untouched (reference surface, not the fix site).Not "declare all of them": per #5091's precedent this is a per-key triage, with the deliberate exclusions pinned so they read differently from an oversight.
Per-key triage — a reviewer can strike any one row without unpicking the rest
The line applied is the one both shipped precedents (#4668, #5091) drew: declare a key only when the renderer reads it AND the spec's strict
DashboardSchemaaccepts it (so the manifest never offers a key the save gate refuses); a spec-rejected honoured key becomes a pinned non-author exclusion.widgetsschema.widgets ?? [], layout/reorder/mobile split);defaultPropsalready carriedwidgets: []array. Notrequiredon the inline node: the renderer has a live default and every widget-less node today is legal — making it a hard error is a strictness increase beyond this cardlabelschema.title || schema.labelheader title (spec-canonical spelling, framework#1878)string | inline locale map['string','object']descriptionDashboardViewchrome)string | inline locale map['string','object']headershowTitle/showDescription/actions[]{ showTitle?, showDescription?, actions? }objectglobalFiltersGlobalFilter[]arraydateRange{ field?, defaultRange?, allowCustomRange? }objectrefreshInterval<= 0disables; needs hostonRefresh)number(0 / negative / fractional all parse — renderer semantics stated in the input description per the 2026-08-17 "spec is the sole judge of values" ruling)numbertitleunrecognized_keys: title)ariaschema.ariareads in this package (the issue body listed it among the honoured reads; that one claim is false)namedashboards.{name}.*translation lookupsname— RULED non-author (PM, 2026-08-23; issue #5742 comment 5386380368)This was opened as a question and has since been decided.
nameis not an author input on the inlinedashboardnode.title's, and the difference is load-bearing.titleandariaare excluded because the spec rejects them by name.nameis excluded because the shipped "spec accepts + renderer reads → declare" line never fires here: the spec accepts (indeed requires)nameon the document form, not on the inline node, so the heuristic's premise is about a different shape. A reader who seesnameexcluded next totitleand assumes "spec rejects it" would be wrong.Two consequences carried into the code comments:
schema.nameread stays untouched — it still keys thedashboards.{name}.*lookups.DashboardView/ the document loader hands the loaded document to the renderer), which makes it a weaker pin than thetitle/ariaones, each of which can assert a re-checkable spec verdict. That weakness is stated in the docblock rather than papered over, and ⛔ no spec rejection is asserted fornameanywhere.Supporting reason: publishing
nameinline would teach authors — AI authors especially — to fabricate a dashboard identity that resolves no translations and fails silently. That is a newly manufactured silently-inert key: the exact defect class this PR exists to remove.Tests
packages/plugin-dashboard/src/__tests__/dashboardAuthoredInputs.test.tsx(30 tests), all three faces with silenced-check controls:dashboardnode, judged by the samemanifestFromConfigs+validateTreepair the save gate and JSX-page compiler use; an undeclared probe key still drawsunknown-prop(the check is live); off-arm values still drawtype-mismatch(declaring is not disarming); both union arms are derived from the spec's own verdicts.gridNonAuthorKeysshape):title/arianot published (withlabel/widgetsas declared controls), spec rejectstitleby name and refuses everyariavalue through the standing tombstone, both drawunknown-propfrom the real validator, and the legacytitleread still renders its header title (canonicallabelas the control).generateDts(the same generatorgen-manifest.tsruns) types the new keys — unions included — withtitle/ariaabsent from the emittedDashboardPropsblock.sdui.manifest.json/sdui-intrinsics.d.tsare build-time codegen (not checked in), so the change to them is pinned through their own generators rather than hand-shown.Verification (all from repo root)
pnpm exec vitest run packages/plugin-dashboard/ apps/console/src/__tests__/registry-inputs-spec-parity.test.ts apps/console/src/__tests__/public-contract.test.ts apps/console/src/__tests__/ga-honoured-inputs-author-reach.test.ts apps/console/src/__tests__/component-input-union-specimens.test.ts apps/console/src/__tests__/public-block-binding-reach.test.tsx→ 81 files / 836 tests passed (run at6a1e9040e, the branch head).pnpm --filter @object-ui/plugin-dashboard type-checkandlint→ clean (0 errors; pre-existing warnings only), after building the dependency closure.node scripts/check-changeset-presence.mjs,check-phantom-dependencies.mjs(new@object-ui/sdui-parserdevDep),check-control-bytes.mjs,check-doc-component-types.mjs,check-doc-snippet-types.mjs(on a built tree: "Every covered documentation snippet compiles against the built types"),check-changeset-fixed.mjs,check-changeset-no-major.mjs→ all exit 0, verdict lines verified.git checkout HEAD~1 -- packages/plugin-dashboard/src/index.tsx→ 20 of 30 tests red (all 9 author-reach rows via restoredunknown-prop, all 7 off-arm rows, the 2 not-published control legs, both artifact legs); restore →git diff HEAD --statempty → 30/30 green. Legs that do not discriminate the registration change, by design: reachability + probe-key control, the five spec-verdict legs (they pin the spec, not the registry),unknown-propontitle/aria(true before and after), and the two render legs (the reads were never touched).Scope notes
### DashboardSchema API block incontent/docs/plugins/plugin-dashboard.mdxnow lists the published keys (plaintext block; no ts/tsx snippet added).minorfor@object-ui/plugin-dashboard.@object-ui/types'DashboardComponentSchemadrift (declaresariathe spec tombstoned; lackslabel/description) is out of scope here and recorded separately.options.inverthas no observable effect, and nothing can say so — it is an undeclared key ridingDashboardWidgetOptionsSchema.passthrough()#5709 is not addressed here; page:header / page:tabs / record:details: five keys spec 17.0.0 GA declares and the renderers already honour are never published as inputs #4668 and ObjectGrid 用(schema as any)读的 4 个键不在GRID_QUERY_INPUTS里 —— #4648 要消除的「渲染器读得到、声明面否认」在这些键上仍然存在 #5091 remain closed precedents, cited only.Generated by Claude Code
Generated by Claude Code