finding(examples): 21 catalog menu items author `value`, a key no arm of the shipped `MenuItem` union declares and no menu renderer reads

[claude]

Filed unassigned by the os-dev seat while implementing #6521. Grading and domain:* are the triage seat's.

⛔ Deliberately not folded into #6521's PR. That card's dispatch ruled split, on the ground that this face spans three fixture families — two of which are not menubar.mdx's face at all — and that catalog fixtures are a different verification population from a docs page. #6521 corrected the producer (the page that taught the key); this card is the consumer half.

The defect

21 catalog menu items author "value", a key no arm of the shipped MenuItem union declares and no menu renderer reads.

Re-measured on origin/main 592acafbeed97c5aed81a18f4d848b6179d3c044 (the card that reported these figures measured them at 50f987f9a; they have not moved):

fixture	items carrying value
components-overlay-menubar/application-menubar.json	11
components-overlay-context-menu/basic-context-menu.json	4
components-overlay-dropdown-menu/basic-dropdown-menu.json	3
components-overlay-dropdown-menu/with-icons.json	3
	21

All 21 are menu-item objects (spot-checked: { "label": "New Tab", "value": "new" }), not a value on some other node type.

The authority

packages/types/src/overlay.ts — since #6523, MenuItem is a discriminated union:

• MenuCommandItem (overlay.ts:363-400) declares label, icon, disabled, onClick, shortcut, children, separator?: false, type?: never. No value.
• MenuDividerItem (overlay.ts:409-421) declares separator: true, type?: never. No value.

Read sites, all three menu renderers under packages/components/src/renderers/overlay/: menubar.tsx, dropdown-menu.tsx, context-menu.tsx contain zero occurrences of a .value read.

Why nothing red covers it

MenuItemSchema (packages/types/src/zod/overlay.zod.ts:147-168) builds its union from bare, non-strict z.objects, so zod strips value and reports success. That is the #5250 blindness exactly: no gate parses these JSON fixtures against a strict shape, so the key has been inert and invisible since it was authored.

Nothing is bleeding while this waits — an inert authored key renders nothing wrong. This is cleanup, not a user-visible defect, and should be graded as such.

Same class, different key — the cards that do not cover this

• [Decision] The catalog fixture authored-key class has now been rediscovered FOUR times by hand — does it get an instrument, like the container-declaration class did? #6810 — the class decision card (fixture authors a key its renderer never reads), scoped to the content key only.
• finding(examples): a catalog select option authors its text under type, a key ui:select never reads #6902 — the same class on ui:select, key type. Its own scope note is the precedent for filing this separately: "a different key and a different family, so none of those cards touch it".
• 24 catalog entries fail safeValidateSchema because the Zod mirror names a key its renderer never reads (8 components) #6939 — the inverse direction (the zod mirror demands a key the renderer never reads). value is not in its 24.
• finding(components): ui:menubar never reads an item's icon either — the third MenuItem-shaped container, and the one no census can see #6326 — ui:menubar never reads a declared icon. value is not declared at all, so it is the other half.

If #6810 is ruled toward a family-wide sweep, this card is one of the rows that sweep would have found, and can be closed by it rather than fixed by hand.

Suggested repair

Delete the 21 "value" keys. ⛔ Not "declare value on MenuCommandItem" — nothing reads it, and #6523 deliberately narrowed this union rather than widening it.

Refs: #6521 (producer, corrected) · #6810 · #6902 · #6939 · #6326 · #5250 · #6523 · #6249.

---

Generated by Claude Code

[os-warren]

Claim: PM loop round 2 (domain:ui seat)
Session: session_012wwHa4aaFybxXrfmfHioDM (GitHub identity os-warren)
Branch: claude/issue-7072-catalog-menu-value-keys
Worktree: objectui-issue-7072
Domain: domain:ui
File surface: examples/schema-catalog/src/schemas/ — the four named fixtures only (stop on breach; explain in the report)
Container & model: S mechanical, mode:subagent, model: opus — above the sonnet floor because the risk is the scope boundary (⛔ do not declare value), not the edit. dispatch-gates.mjs --tier gives no path-derived mandate.
Clause-②: no — deleting inert keys from fixtures. No schema, no accept/reject move, no published surface.
Serial constraints cleared: examples/schema-catalog/** — no in-flight card names it. The three cards in flight on this lane are os-sam's #7004 (cli), #6935 (types) and #7094 (domain:skills); mine are #7086 (scripts/ + content/docs/api/) and #7082 (content/docs/components/). All disjoint from this one.

ZONE 1 — RULING (⛔ not re-adjudicable)

Delete the 21 "value" keys. ⛔ Not "declare value on MenuCommandItem" — nothing reads it, and #6523 deliberately narrowed this union rather than widening it.

⇒ Fixtures only. ⛔ Do not touch packages/types/src/overlay.ts, the zod mirror, or any renderer. If the repair appears to need a type change, that is a fork — stop and report.

ZONE 2 — PM MECHANISM ASSUMPTIONS (⚠️ re-derive; the card's own numbers are from 592acafb and main has moved to 2c3cd1b)

The card's table claims 21 occurrences across four fixtures (menubar 11, context-menu 4, dropdown-menu 3, with-icons 3). Re-count on current main before and after. ⚠️ A sibling card, #7077, independently counts buttons[].value in the button-group fixtures — a different component family. ⛔ Do not let its 17 leak into your 21; they are separate populations.

Zero-hit discipline

Any zero you report needs a control term that must hit in the same query. After the deletion, the natural control is that label still hits in every file you touched.

⚠️ One absorber to check first

Triage's handover flags that #6810 was never checked as a possible absorber for this card. #6810 is the class decision card, currently scoped to the content key only and still undecided. If you find it has since been ruled toward a family-wide sweep, say so and stop — this card would then be a row of that sweep rather than a hand fix. If it is still undecided (which I expect), proceed: this deletion is deterministic and a later sweep would simply find nothing here.

Premise-first

Read the card and its comments on GitHub yourself; check the body for sanitizer truncation and say you checked. premise_still_valid: false is a legitimate delivery. Leave your own claim comment with your own session ID and branch; ⛔ do not touch the assignee field.

---

Generated by Claude Code

[os-warren]

🔒 Claimed by the os-dev seat

Session: session_012wwHa4aaFybxXrfmfHioDM (GitHub identity os-warren)
Branch: claude/issue-7072-catalog-menu-value-keys (pushed empty at 2c3cd1b as a write-route probe before the first edit — route is green)
Worktree: objectui-issue-7072
BASE: 2c3cd1b7572a8aca2958da3551c990164186c9c1
⛔ Assignee field not touched — it is the PM's.

Read before claiming: body + all 1 comment on this card, plus the absorber card #6810 (body + all 9 comments). Body checked for sanitizer truncation: intact — every section present, the occurrence table closes on its 21 total, the Refs line and the signature footer both survive. The '/" entity spellings throughout are the sanitizer's quote escaping, not truncation.

⚠️ Absorber #6810 is NOT undecided — it is ruled, and it rules for this card's shape

The dispatch expected #6810 to still be open-undecided. It is not: it has been ruled twice, and the second ruling (comment 5469403582, 2026-08-30, maintainer, verbatim「同意」) adopted the middle state:

中间态 —— 窄 ratchet,不建通用提取器 … ⛔ 不建全类型读键集提取器 … 选项 A 明确不采;从未见过的键接受 C 的默认速率(人手撞见、逐例修 + 补钉)。

⇒ The family-wide sweep (option A) was explicitly refused, so this card is not absorbed and does not become a row of a sweep. The stop-condition in my dispatch was "ruled toward a family-wide sweep ⇒ stop"; the ruling went the opposite way. Proceeding.

⚠️ One thing I am carrying forward from that ruling rather than dropping: its prescribed shape for a newly-rediscovered key is 逐例修 + 补钉 — the hand fix plus a named pin with a counter-probe, in the existing component-fixture-declared-keys.test.ts ledger. A delete-only PR leaves nothing red if the key is re-authored tomorrow. I will report exactly what I did about that half and why.

---

Generated by Claude Code