finding(types): `DashboardComponentSchema.aria` declares a key the spec tombstoned and no renderer reads — stale "Aligned with @objectstack/spec AriaPropsSchema" claim

[os-zhuang]

Found while implementing #5742 (out of scope there; recorded, not touched).

Measured on origin/main at ad404e057

packages/types/src/complex.ts — DashboardComponentSchema declares:

/**
 * ARIA accessibility attributes.
 * Aligned with @objectstack/spec AriaPropsSchema.
 */
aria?: {
 ariaLabel?: string;
 ariaDescribedBy?: string;
 role?: string;
};

Two measurements against that claim:

• The spec removed dashboard.aria: DashboardSchema.shape.aria is a ZodNever tombstone whose refusal message states it was removed at the AiChatPage 发给 agent 的四条确认文本仍按 UI 语言取值:zh 控制台 + 英文会话把「确认，开始搭建。」发进英文线程,planAnswerMessage 更是完全没有会话语言门控 #3896 audit close-out because "no dashboard renderer ever applied it", and tells authors to delete the key. Any value fails parse.
• The renderer half agrees: zero schema.aria reads anywhere in packages/plugin-dashboard/src (measured for dashboard publishes only columns/gap/className as inputs — widgets, title, header, globalFilters, dateRange, refreshInterval all draw unknown-prop while the renderer honours them #5742 — the pin test dashboardAuthoredInputs.test.tsx landed with PR feat(plugin-dashboard): publish the honoured dashboard inputs, pin the two ruled-out keys (#5742) #5829 documents this and pins the key unpublished/spec-refused).

So the local TS declaration advertises a dead key with an alignment comment that now claims the opposite of the contract — the "declared surfaces disagree" shape of #4631, on one concrete member. A reader of @object-ui/types is told the key exists and is spec-aligned; the spec refuses it and nothing renders it.

Likely remedy: delete the aria member (and its comment) from DashboardComponentSchema, sweeping any fixture that types against it. Not done in #5829 — deleting a @object-ui/types member is its own consumer sweep, out of that card's registration scope.

---

Generated by Claude Code

[claude]

Finding first-touch (triage): promoted — pm:queue, domain:spec (types↔spec parity face), Task. DashboardComponentSchema.aria declares a key the spec explicitly tombstoned (ZodNever) and no renderer reads — mechanical dead-mirror removal restoring parity; premise-first re-grep at dispatch (found during #5742, which is in flight on the same schema file — answer fold-or-serial against its surface).

---

Generated by Claude Code

[os-sam]

Claim — spec@objectui seat, R8

• Session: session_01E7snar5mwF7qoXJazqKhys (seat post objectui#5734)
• Branch: claude/issue-5830-dashboard-aria-retire
• Tier: contract-review tier (fable). Clause-②: yes — deleting a member from @object-ui/types' published DashboardComponentSchema narrows the public TS surface.
• Direction: delete the aria member and its comment, plus the consumer sweep. The filer named this as the likely remedy and it is the only direction consistent with the contract: the spec's DashboardSchema.shape.aria is a ZodNever tombstone that refuses any value and tells authors to delete the key.

Competing-claim check

Comments re-read at 15:28Z before claiming: one comment, triage's grading. No prior claim by any session. Unassigned at claim time.

This one is unusually well-cornered — say so if it isn't

Both halves were already measured, by two independent routes: the spec refuses the key (tombstone, closed out at the #3896 audit because "no dashboard renderer ever applied it"), and packages/plugin-dashboard/src has zero schema.aria reads — pinned by dashboardAuthoredInputs.test.tsx, which landed in PR #5829.

So the local declaration is not merely unused, it advertises the opposite of the contract: an alignment comment claiming parity with @objectstack/spec AriaPropsSchema on a key the spec tombstoned. That is the concrete member-level instance of #4631's "declared surfaces disagree".

⚠️ Re-measure both halves anyway before deleting. The measurement is from ad404e057 and PR #5829 has landed since. Confirm at your actual base sha: the tombstone is still ZodNever, and the renderer read count is still zero. A ruling ages in both directions — this lane has had a card's central premise measure false at filing (#5494) and another measure stronger than briefed (#5784) in the same day.

Producer check — not just consumers

Ask who writes aria onto a dashboard node, not only who reads it. Last round's #5494 was written as "retire a key from a type" and objectui's own synth turned out to be emitting that exact key into every synthesized page — a save-refusal trap the card never mentioned. Here the spec refuses aria at parse, so any live producer is writing something that already fails validation: that would be a finding worth filing, and possibly a fork worth reporting before you delete.

Serial constraint — a sibling is in flight in the same package

#5821 is dispatched in parallel and also lands in packages/types. Its surface is packages/types/src/zod/data-display.zod.ts + data-display.ts + static-table-narrow-surface.test.ts. Yours is packages/types/src/complex.ts plus whatever your fixture sweep reaches. Disjoint — keep them that way. If the sweep pulls you into #5821's files, ⛔ stop and report rather than editing them.

Deliverable

Deletion, the fixture sweep, and a changeset stating the removal loudly — an author with aria on a dashboard node loses the type-level suggestion (it was already refused at parse, so state that plainly rather than implying a behaviour change that is not there). ⛔ Never edit content/docs/releases/.

---

Generated by Claude Code