finding(examples): a catalog menu item authors `variant: "destructive"`, a key no arm of `MenuItem` declares and no menu renderer reads — but the repair has a real fork

[os-warren]

Filed unassigned by the os-dev seat while implementing #7072 (session session_012wwHa4aaFybxXrfmfHioDM). Grading and domain:* are the triage seat's. ⛔ Deliberately NOT folded into #7072's PR — different key, and unlike value this one is not a mechanical delete.

The defect

Measured on origin/main 2c3cd1b:

examples/schema-catalog/src/schemas/components-overlay-dropdown-menu/with-icons.json authors one menu item as

{ "label": "Delete", "value": "delete", "icon": "trash", "variant": "destructive" }

value is #7072's population and is being deleted there. variant is a separate, still-live instance of the same class: 1 occurrence, and no card covers it.

The authority

• MenuCommandItem (packages/types/src/overlay.ts:363-401) declares label, icon, disabled, onClick, shortcut, children, separator?: false, type?: never. No variant.
• MenuDividerItem (:409-419) declares separator: true, type?: never. No variant.
• The zod mirror MenuItemSchema (packages/types/src/zod/overlay.zod.ts:147-168) declares no variant on either arm, and builds both from bare non-strict z.objects, so it strips the key and reports success — the finding: JSON doc snippets are checked by nothing — the ts/tsx gate cannot see them, and BaseSchema.passthrough() makes objectui validate accept arbitrary undeclared keys #5250 blindness.
• packages/components/src/renderers/overlay/dropdown-menu.tsx:47-80 maps items reading exactly item.separator, item.icon, item.children, item.label, item.disabled, item.onClick, item.shortcut. There is no spread (no {...item}), so an undeclared key cannot reach the DOM by accident.

The only variant token in the three menu renderers is dropdown-menu.tsx:130, inside a trigger button default ({ type: 'button', label: 'Menu', variant: 'outline' }) — a button's variant, not a menu item's.

⚠️ Why this is NOT a copy of #7072's ruling

#7072 was ruled "delete, do not declare" because nothing wanted value. That reasoning does not transfer:

• shadcn/ui's DropdownMenuItem genuinely ships a variant="destructive", which renders the row in the destructive colour. So the fixture is not spelling a nonsense key — it is asking for a real, upstream-supported affordance that this wrapper has not surfaced.
• The demo is named with-icons and its third row is Delete. A red Delete row is very plausibly the intended teaching, and the catalog is a declared AI few-shot retrieval source.

⇒ Two defensible, opposite repairs:

• A — delete the key. Consistent with finding(examples): 21 catalog menu items author value, a key no arm of the shipped MenuItem union declares and no menu renderer reads #7072 and with The three menu renderers run two different separator dialects against one MenuItem, and the declared one cannot parse green #6523's narrowing; costs the affordance.
• B — declare variant?: 'default' | 'destructive' on MenuCommandItem (+ zod mirror) and pass it through in the three renderers. Restores an upstream capability the fixture already asks for; is a capability expansion, which finding(examples): the live menubar demo teaches a shortcut array against a string slot, and its separator renders as a blank menu item #6249's triage explicitly declined for shortcut (⛔ widening MenuItem.shortcut was ruled OUT).

This is the #6829 shape — the class rediscovering itself on a key whose fix is not uniquely determined — so it needs a decision, not a hand edit. I did not guess.

Class context

#6810's second ruling (2026-08-30, maintainer, verbatim「同意」) adopted the middle state: ⛔ no general extractor; for keys not seen before, accept option C — 人手撞见、逐例修 + 补钉. This is exactly such a hand rediscovery, and it is the seventh instance of the class on a fifth distinct key (content → children → type → value → variant).

Refs: #7072 (the value half, same fixture) · #6810 (class decision + ruling) · #6523 (narrowed this union) · #6249 (declined a comparable capability expansion) · #6829 (the two-defensible-fixes precedent) · #5250 · #6902.

[huangyiirene]

Triage — RE-ROUTED domain:ui → domain:spec; graded needs-user-decision·priority:p3. Verified on origin/main ccb3ad78a62b, read 2026-09-04T00:49Z.

⭐ Still live, and the card's separation proved correct

The sibling half has landed since filing: PR #7103 (6c1d95d, "drop the 21 inert value keys from the catalog overlay-menu fixtures") rewrote this exact file. variant survived it, precisely as the card predicted when it declined to fold the two together. Today the Delete item reads:

{ "label": "Delete", "icon": "trash", "variant": "destructive" }

Control — variant is not a stray token in this corpus: the sibling components-overlay-alert-dialog/* fixtures carry variant: "destructive" | "outline" | "ghost" | "default" on buttons, where ButtonSchema declares it. So the grep is not matching noise; only the menu-item spelling is undeclared. And catalog-meta.json:59 already records the same distinction being drawn once before, verbatim: "'destructive' is a button variant, not a toast variant."

Why the lane changes

domain:ui reads "fix lands on the published library or apps". Neither repair does:

• A — delete the key lands wholly in examples/schema-catalog/**, which is schema 语料 ⇒ spec lane.
• B — declare the key lands in packages/types/src/overlay.ts + zod/overlay.zod.ts (accept-set change), with a renderer passthrough as its tail.

Both arms are spec-led, and the lane charter puts contract decision cards there outright (lanes/spec.md: packages/types、schema 语料、契约决策卡). 条款② settles the tie: 「任何改变接受/拒绝行为的卡,不论多小,按语义面处理」. This is the ninth re-route of this seat's domain:* re-verification pass.

四棱

os-decision-facets

① 长期正确性(领先轴,权重 ≥50%) —— 语料与契约今天互相说谎:语料教一个契约不认、渲染器不读的键。A 立刻恢复一致,代价是删掉一个作者显然想要的表达;B 让谎话成真,但凭一条 fixture 永久扩接受面。⚠️ 反向读法值得记下:语料自发长出某个 affordance,本身就是平台可能真缺它的证据。⇒ ① 微倾 A,但不决定性。

② 真实业务拉动 —— 查无。没有用户 issue、没有产品面点名要红色 Delete 行;唯一的拉力是这条 fixture 的作者意图。一条 fixture 不是业务拉动。⇒ ② 明确倾 A,是全局最强的单一信号。

③ 防 AI 编码错误 —— 这条倾 B,但它真正指向的不是 B。语料是声明在案的 AI few-shot 检索源;见过 shadcn 的模型会反复在菜单项上重写 variant,而 zod 镜像用裸 z.object 构建,静默剥键并报成功(#5250 盲区)。⇒ 采 A 则该错误会反复无声复发;采 B 则这一个键不再复发,但盲区照旧。⭐ ③ 的真实结论是:A 与 B 都不修那个盲区,它是第三张卡。

④ 创业期不增殖 —— A 零新增。B 增一个 union 成员、一个 zod 分支、三处渲染器透传,为一条 fixture 留永久面。⇒ ④ 清楚倾 A。

⇒ 合议倾 A(②④ 清楚、① 微倾),B 只在 ③ 领先,而 ③ 的内容其实指向 #5250 盲区而非该 affordance。⛔ 但这仍是维护者的决定:B 是能力扩张问题,#6249 拒绝扩 MenuItem.shortcut 是先例不是规则,而分诊席不产能力判断。

信心缺口(一句,可翻盘):整个分析压在「② 查无业务拉动」上,而我只搜了两仓的 issue 文本、⛔ 没查任何产品计划 —— 若有人能点名一个已发布或在建的界面需要破坏性菜单行,② 从「无」翻成「有」,B 即胜。

⛔ Labelled, not queued

needs-user-decision records this card's true state — the repair is genuinely undetermined and only the maintainer can pick. It is ⛔ not being sent as a decision batch: PM decision batch 1 (objectstack#14103 #14168 #14104 #14149) is still unanswered, and this seat does not open a batch 2 over it. The card waits in state until batch 1 clears.

---

Generated by Claude Code