Filed unassigned by the dev seat working #8893 (console pin bump to objectui 82a94170c405). ⛔ Not fixed there — out of that card's scope (it moves .objectui-sha only). No domain:* / target:* set; triage's fields.
Measurement
packages/spec/src/ui/component.zod.ts, inside PageAccordionProps.items:
label: I18nLabelSchema,
icon: z.string().optional(),
collapsed: z.boolean().default(false),
children: z.array(z.unknown()).describe('Child components'),
So icon is an authorable key on a page:accordion item: a strict-object member, no guidance prescription against it, and it therefore parses clean and reads to an author (and to the Studio designer) as a supported spelling.
objectui retires the reader for it. One of the ten declared-breaking entries in the range this repo is pinning into (665661ab0932...82a94170c405) is, in objectui's own words: "Settle the two declared-but-unread keys on AccordionItem: retire icon, wire disabled (objectui#4652)" (objectui commit 75444e38a).
⇒ Once #8893's pin lands, an author who writes icon on an accordion item gets: schema-accepted, designer-accepted, rendered nowhere, with no diagnostic anywhere. That is the ADR-0049 declared-but-unenforced shape — the same class the maintainer already ruled on for PageHeaderProps.icon in #6946, one component over.
⚠️ Note the neighbouring key in the same declaration is handled the other way and is worth reading as the precedent: value on the same item is deliberately not declared, with a guidance prescription telling the author to remove it, precisely because the renderer overwrites what is authored. icon is the same fact pattern arriving later, with the declaration still standing.
Why this is not part of #8893
#8893's diff is .objectui-sha plus the generated @objectstack/console changeset; it changes no spec surface, so nothing stored becomes invalid and there is no ADR-0087 conversion for it to write (that PR's disposition records this residual explicitly and is where this issue number should be cross-read from). Deciding between retiring the declaration and asking objectui to restore the reader is a spec-side ADR-0049 route choice, which is its own card.
Options for triage
Recommendation: A, unless a maintainer judges the icon a real authoring need. It is the route the same maintainer already took for PageHeaderProps.icon, it keeps declared = enforced, and an inert declared key is exactly the surface an AI-authored metadata app writes into and gets silently nothing back from.
⛔ Not verified here: whether any shipped example app or fixture currently authors an accordion item icon. That census belongs to whoever takes the card, and it decides whether route A needs a conversion entry with real rewriting to do or only a tombstone.
Filed unassigned by the dev seat working #8893 (console pin bump to objectui
82a94170c405). ⛔ Not fixed there — out of that card's scope (it moves.objectui-shaonly). Nodomain:*/target:*set; triage's fields.Measurement
packages/spec/src/ui/component.zod.ts, insidePageAccordionProps.items:So
iconis an authorable key on apage:accordionitem: a strict-object member, no guidance prescription against it, and it therefore parses clean and reads to an author (and to the Studio designer) as a supported spelling.objectui retires the reader for it. One of the ten declared-breaking entries in the range this repo is pinning into (
665661ab0932...82a94170c405) is, in objectui's own words: "Settle the two declared-but-unread keys onAccordionItem: retireicon, wiredisabled(objectui#4652)" (objectui commit75444e38a).⇒ Once #8893's pin lands, an author who writes
iconon an accordion item gets: schema-accepted, designer-accepted, rendered nowhere, with no diagnostic anywhere. That is the ADR-0049 declared-but-unenforced shape — the same class the maintainer already ruled on forPageHeaderProps.iconin #6946, one component over.valueon the same item is deliberately not declared, with aguidanceprescription telling the author to remove it, precisely because the renderer overwrites what is authored.iconis the same fact pattern arriving later, with the declaration still standing.Why this is not part of #8893
#8893's diff is
.objectui-shaplus the generated@objectstack/consolechangeset; it changes no spec surface, so nothing stored becomes invalid and there is no ADR-0087 conversion for it to write (that PR's disposition records this residual explicitly and is where this issue number should be cross-read from). Deciding between retiring the declaration and asking objectui to restore the reader is a spec-side ADR-0049 route choice, which is its own card.Options for triage
iconfromPageAccordionProps.itemsunder ADR-0049 enforce-or-remove, with the ADR-0087 conversion + tombstone the retirement route requires. Matches the [spec] Retire three zero-reader UI keys per maintainer ruling: PageHeaderProps.icon, PageCardProps.actions, RecordDetailsProps.layout (objectui#3829 / objectui#3818) #6946 ruling for the analogousPageHeaderProps.icon.guidanceprescription, the wayvalueon the very same item is handled today. Cheapest, and it stops an author being told a dead key is fine, but it leaves a declared key with no reader.Recommendation: A, unless a maintainer judges the icon a real authoring need. It is the route the same maintainer already took for
PageHeaderProps.icon, it keeps declared = enforced, and an inert declared key is exactly the surface an AI-authored metadata app writes into and gets silently nothing back from.⛔ Not verified here: whether any shipped example app or fixture currently authors an accordion item
icon. That census belongs to whoever takes the card, and it decides whether route A needs a conversion entry with real rewriting to do or only a tombstone.