Uh oh!
There was an error while loading. Please reload this page.
fix(types): retire DashboardComponentSchema.aria — spec-tombstoned, renderer-dead - #5855
Merged
Merged
Conversation
…enderer-dead (#5830) Delete the `aria` member (and its "Aligned with @objectstack/spec AriaPropsSchema" comment) from `DashboardComponentSchema`: the spec removed `dashboard.aria` at the #3896 audit close-out (`DashboardSchema.shape.aria` is a tombstone refusing any value), the Zod twin inherits that refusal via `SpecDashboardFields`, and plugin-dashboard has no `schema.aria` read site. - Replace p1-spec-alignment's "should accept ARIA props on DashboardComponentSchema" with the house-style removal note (the widget sibling above it took the same form): kept, it would green-wash through BaseSchema's index signature while asserting the opposite of the contract. - Pin both halves in dashboard-aria-retired-contract-twins.test.ts: declared-key-set probe for the TS half (the index signature absorbs a @ts-expect-error literal pin), tombstone refusal by name + controls for the Zod half. - Changeset: type-level suggestion removed; no runtime behaviour change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E7snar5mwF7qoXJazqKhys
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-sam
marked this pull request as ready for review
August 24, 2026 01:13
Uh oh!
There was an error while loading. Please reload this page.
yinlianghui pushed a commit
that referenced
this pull request
Aug 24, 2026
Remove `DashboardConfig.aria` (packages/types/src/designer.ts) and turn its Zod
twin `DashboardConfigSchema.aria` (packages/types/src/zod/complex.zod.ts) into an
ADR-0049 retirement tombstone.
The pair declared `{ label?, description? }` — spellings that match neither
@objectstack/spec's `AriaProps` (`ariaLabel`/`ariaDescribedBy`/`role`) nor any
renderer vocabulary, so no read point could have consumed them. Re-measured on
main: zero `.aria` reads in plugin-designer/src, plugin-dashboard/src and
apps/console/src (the same grep family finds the live `schema.aria` reads in
plugin-detail and plugin-list); zero occurrences of either name in objectstack;
and DashboardConfigPanel.tsx — the panel the interface's doc comment claims to
serve — imports neither name.
- TS half: plain deletion + in-place comment tombstone, mirroring the landed
shape of #5855 (#5830) on the sibling `DashboardComponentSchema.aria`. The
interface's `[key: string]: any` catch-all means an authored `aria` still
compiles; what goes is the type-level suggestion and the false contract claim.
- Zod half: `z.never({ error }).optional().describe(...)` rather than a plain
delete. Measured: `DashboardConfigSchema` is a bare `z.object` with no
`.strict()`, so a deletion would have turned an accepted-and-PRESERVED key
into a silently STRIPPED one (the #6068 behaviour). Loud refusal is this
package's ruled outcome for retirements (data-display.zod.ts
StaticTableColumnSchema, the set crud.zod.ts `confirm` established).
- Tests: the aria-only pin in dashboard-config.test.ts is FLIPPED, not deleted —
it now asserts refusal by name and message, with two controls (an undeclared
key still rides through, proving the red is the tombstone and not strictness;
a legal config still parses). The `aria:` line in the full-config TS literal is
replaced by a removal note; kept, it would have green-washed through the index
signature.
Claude-Session: https://claude.ai/code/session_01CSoz9uGhaaSgiq3hshtN7L
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 24, 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
2 participants
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#5830
Clause-②: yes— this narrows@object-ui/types' published TS surface:DashboardComponentSchemano longer declares theariamember (ariaLabel/ariaDescribedBy/role). Changeset declares aminorbump per the no-major house rule, with the breaking semantics stated in its body.What changed
packages/types/src/complex.ts— deleted theariamember and its "Aligned with @objectstack/spec AriaPropsSchema" comment (the claim was the opposite of the contract); left the house-style removal note.packages/types/src/__tests__/p1-spec-alignment.test.ts— replacedshould accept ARIA props on DashboardComponentSchemawith the same removal-note form its widget-level sibling already uses. Kept, it would have stayed green after the deletion — see the index-signature note below — while asserting the opposite of the contract.packages/types/src/__tests__/dashboard-aria-retired-contract-twins.test.ts— new pin, both halves: a declared-key-set probe for the TS half, and the zod twin's tombstone refusal by name with two controls..changeset/dashboard-aria-member-retired-5830.md— states the removal as a lost type-level suggestion; no runtime behaviour change (the key was already refused at parse and never rendered).Premise re-measured at base
da8db03a6(card measured atad404e057; PR #5829 landed between)Both halves still hold —
premise_still_valid: true:DashboardSchema.shape.ariafrom@objectstack/spec/ui(installed 17.2.0, matches lockfile) refuses any value; measured refusal message: "dashboard.ariawas removed in @objectstack/spec 17.0.0 (AiChatPage 发给 agent 的四条确认文本仍按 UI 语言取值:zh 控制台 + 英文会话把「确认，开始搭建。」发进英文线程,planAnswerMessage 更是完全没有会话语言门控 #3896 audit close-out) — no dashboard renderer ever applied it … Delete the key." Full-document parse with the key also fails at patharia.grep -rn "schema\.aria" packages/plugin-dashboard/srcfinds exactly 2 hits, both prose insidedashboardAuthoredInputs.test.tsxdocumenting "no read site". Positive control: the same pattern family finds liveschema.widgetsreads inDashboardRenderer.tsx(5+ sites).zod/complex.zod.ts) already refusesaria—SpecDashboardFieldsderives from the spec's shape andariais not in its exclusion list, so the tombstone flows in by reference. The TS interface was the last surface still advertising the key.Honest direction note — the reverse verification is not the naive one
BaseSchemacarries an index signature ([key: string]: any), so deleting the member does not make an authoredaria:a tsc error — reads and literal writes still compile through the index signature. The deletion's real effect is exactly what the card's changeset language priced: the type-level suggestion and the false parity claim disappear from the published.d.ts. A naive@ts-expect-errorpin cannot stick here, so the pin extracts the interface's literal key set (string extends Kfilters the index signature) and assertsariais not a declared member, withwidgets/dateRangeas positive controls through the same extraction.Reverse verification, run from the committed state (mutation = restore the base file; on-disk confirmed by anchored grep before each reading; both legs
--noEmit, dist untouched; restored and re-confirmed after):Built-surface evidence at HEAD
9a9b09ce0:grep -c "aria?:" packages/types/dist/complex.d.ts= 0 after build (positive controldateRange?:= 1); base src had the member (count 1 atda8db03a6).Consumer sweep (the real work — every
ariasite in the repo, triaged)Typed against
DashboardComponentSchema['aria']: one site, the p1-spec-alignment test replaced above. Everything else is a different surface, verified live or separately retired:aria(DashboardWidgetSchema) — retired upstream (objectstack#5010), inherits?: neverfrom the spec; pinned byreport-chart-query-spec-parity.test.ts. Untouched.ChartConfigSchema.aria(plugin-charts test, passes viaas any) — pins that chart-level aria changes no DOM attribute. Untouched.BaseSchema.ariaLabel(flat key) andprops.ariaincomponents/renderers/basic/elements.tsx— live, different keys. Untouched.aria(spec-bridgelist-view.tscopy,record-quick-actions.tsxreads, p1 page test) — live surfaces on other node types. Untouched.DashboardConfig.aria+DashboardConfigSchema.aria— separate declared-but-dead pair, out of scope here; filed as finding(types): designer-surfaceDashboardConfig.aria/DashboardConfigSchema.ariadeclare a{ label, description }aria object nothing reads — and the panel they document does not consume them #5852 (unassigned).content/docs/plugins/plugin-dashboard.mdxstates the "ariakey is neither read nor authorable". No doc edit needed.Producer sweep (who writes the key, not only who reads): no dashboard bridge exists in
spec-bridge/bridges/(only form-view — whose aria copy was already removed at the #3896 close-out — and list-view, a live different surface); none of thetype: 'dashboard'node constructors (DashboardDesignPage, builtinComponents, nav sync, anchors) writesaria; zero authoredariain examples/, content/, docs/ JSON or MDX corpora. Stored customer metadata is not reachable from this seat (#5741), so this is "no reachable producer/usage", not "no usage" — and any stored document carrying the key already fails spec parse today, so the deletion changes no runtime outcome.Serial constraint (#5821, same package, in flight): surfaces stayed disjoint — this diff touches
complex.ts,p1-spec-alignment.test.ts, one new test file, one changeset; none ofdata-display.zod.ts/data-display.ts/static-table-narrow-surface.test.ts.Local gates, by name, at HEAD
9a9b09ce0(after the final commit)turbo run type-check --filter=@object-ui/types --filter=@object-ui/plugin-dashboard(builds dependency closure; both packages runtsc --noEmit && tsc -p tsconfig.test.json): "Tasks: 14 successful, 14 total", exit 0 captured pre-pipe.pnpm exec vitest run packages/types/ packages/plugin-dashboard/ --maxWorkers=2(repo root, per AGENTS.md): "Test Files 126 passed (126) / Tests 1267 passed (1267)", exit 0.pnpm check:spec-symbols(the gateType Checkcarries at ci.yml:238): "✅ spec symbol derivation … ✅ spec alignment claims", exit 0. Deleting the false "Aligned with" claim only helps this gate.node scripts/check-changeset-presence.mjs: "✅ … declares 1 changeset(s)"..tsfiles only (--format json: 3 files, 0 errors, 8 pre-existingno-explicit-anywarnings on lines this diff does not touch — the live-scan control). Corpus: rooteslint.config.jscovers the repo viapnpm lint; invariance: the config declares noparserOptions.project/ type-aware services, so verdicts are per-file and this diff cannot move untouched files' results. The full farm is CI's run.CI to read by name:
Type Check(carriescheck:spec-symbols),changeset-check.Build Docsis red onmain(#5668, inherited) — excluded with cause, not evidence either way.Test (shard n/4)is not a required check.Generated by Claude Code