fix(examples): drop the 21 inert value keys from the catalog overlay-menu fixtures

[os-warren]

Fixes#7072

Twenty-one menu items in the four overlay-menu catalog fixtures authored a value key that no arm of the shipped MenuItem union declares and no menu renderer reads. This deletes them, and pins that they stay gone.

Re-derived on current main, because the card's numbers were days old

The card measured at 592acafb; main is now 2c3cd1b. The count has not moved — 21, distributed exactly as the card's table claims:

fixture	value keys
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
total	21

Counted by a walker that classifies each value key by its position in the tree rather than by filename, so the neighbouring buttons[].value population (#7077, button-group) is separated by construction and cannot leak in. Catalog-wide the walker sees 288 objects carrying value before and 267 after — a delta of exactly 21, so nothing outside the four fixtures moved.

⚠️ One correction to the card: its cited line spans are slightly off. Re-derived, MenuCommandItem is packages/types/src/overlay.ts:363-401 (card said :363-400) and MenuDividerItem is :409-419 (card said :409-421).

The authority, re-verified

• MenuCommandItem (overlay.ts:363-401) declares label, icon, disabled, onClick, shortcut, children, separator?: false, type?: never. No value.
• MenuDividerItem (:409-419) declares separator: true, type?: never. No value.
• The three renderers under packages/components/src/renderers/overlay/ perform zero .value reads. Stated precisely, because it is not zero occurrences of the token: context-menu.tsx:95 contains { type: 'text', value: "Right click here" } — a write constructing a text node, whose renderer genuinely reads value. No menu item's value is ever read.
• 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 — 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. Nothing red covered this.

Deleted rather than declared: nothing reads value, and #6523 deliberately narrowed this union rather than widening it.

The pin — #6810's second half

#6810's ruling (2026-08-30, maintainer, verbatim「同意」) prescribes 逐例修 + 补钉 for a key this class has regenerated on: the case-by-case fix plus a named pin carrying its own counter-probe, in the existing component-fixture-declared-keys.test.ts ledger form. This PR now carries both halves.

⛔ Not a widening of #6249's menubar sweep — a new, separately named block. That sweep walks one node shape and its own header states that extending it to dropdown-menu / context-menu is "a separate verification surface this fix does not need"; it is untouched. value was authored across all three containers, so a menubar-scoped pin would have covered 11 of 21 while reading as though it covered the class, which is worse than no pin.

The new block sweeps the whole overlay-menu corpus — all three container shapes, including the deeper menus[].items[] nesting only menubar has, and submenu children:

• non-vacuity: 25 items (menubar 13 + context-menu 5 + dropdown 4 + with-icons 3), one representative position asserted per container shape, so a walker that stops matching a shape fails loudly instead of reporting a clean zero.
• the assertion: no overlay-menu item authors value, with label (21) and separator (4) as in-query controls, so an empty or unparsed corpus cannot masquerade as a pass.
• the counter-probe: ⛔ deliberately corpus-level, not schema-level. MenuItemSchema strips value and returns success, so a .safeParse probe is structurally blind here — it stayed green through all 21 authored keys. The probe re-authors value into a real fixture taken from the corpus and asserts the identical sweep reports it at the right position, with the untouched fixture clean alongside.

⭐ The pre-existing declared-key controls in the menubar block already fed {label, icon, disabled, shortcut, value} to MenuItemSchema and asserted only the first four survive. That pinned the type-level fact and was green the whole time the 21 keys sat in the corpus. The gap was only ever the corpus assertion.

Ablation — the pin demonstrably goes red. With "value": "profile" re-authored into basic-dropdown-menu.json on disk (mutation confirmed: value key count 0 → 1, injected text present, blob hash 7e72503b → ece5381c, still valid JSON), the suite fails:

× ... > no overlay-menu item authors `value`
AssertionError: expected [ Array(1) ] to deeply equal []
× ... > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture
AssertionError: expected [ 'pristine.items[0].value' ] to deeply equal []
Tests 2 failed | 34 passed (36)

The non-vacuity test stayed green throughout, correctly — a key was added, not an item. Restore leg proven rather than assumed: git checkout HEAD -- <abs path>, value count back to 0, blob hash matches the HEAD blob exactly, git diff HEAD empty.

Evidence

The diff is only what it claims. Every changed fixture line is one of: a removed "value": … line (21), or a "label" line re-punctuated because value had been the last key on that item (14 removed / 14 added, identical but for the trailing comma). No content changed. All four files round-trip byte-identically through JSON.stringify(…, null, 2), so the edit was made by parse-and-reserialise and the diff is minimal by construction.

Zero-hit control. After the deletion, value hits 0 in all four files while the control label still hits 14 / 4 / 4 / 4 in the same query — a zero for both would have meant the files were emptied, not fixed. Structure intact: menubar still has 13 items (2 separators, 11 labelled), matching the existing expect(items).toHaveLength(13) pin.

Rendered output is unchanged — which is the correct expectation here, the opposite of a fixture-content fix. The keys were inert, so the DOM must not move. Measured rather than assumed: a scratch harness rendered each dropdown fixture at 2c3cd1b and at this branch with defaultOpen: true injected (a closed menu renders only its trigger, which never carried the key, and would have made the comparison vacuous), normalised Radix's per-instance generated ids, and asserted identical HTML, text and [role="menuitem"] counts. Its control — mutating a key the renderer does read (label) — was required to produce a difference, and did. Scratch-only; not part of this diff.

⚠️Coverage of that DOM measurement, stated honestly: it directly covers the 6 items in the two dropdown-menu fixtures. menubar (11) and context-menu (4) cannot be forced open the same way — Radix opens them via a menubar value and a real right-click — so their inertness rests on the zero-read derivation above plus the corpus suites. My first attempt at this harness was discarded outright: without registering the renderers it fell back to a raw-JSON dump, and its control caught it.

Suites, on the final commit 8595e42:

pnpm exec vitest run \
examples/schema-catalog/test/component-fixture-declared-keys.test.ts \
examples/schema-catalog/test/safe-validate-corpus-6318.test.ts \
examples/schema-catalog/test/catalog-authored-key-6805-6806.test.tsx \
examples/schema-catalog/test/catalog-gallery-render.test.tsx
=> Test Files 4 passed (4) · Tests 659 passed (659) [RUN root: objectui-issue-7072]

659 = the prior 656 plus this PR's 3 new tests. Confirmed by name under --reporter=verbose rather than by an aggregate count:

✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > the sweep reaches all three container shapes and every one of their items — non-vacuity
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > no overlay-menu item authors `value`
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture

Run root-relative from the repo root, per #3378 — the RUN v4.1.10 /home/user/objectui-issue-7072 banner confirms it did not silently re-root onto apps/console.

Type-check.pnpm --filter @object-ui/example-schema-catalog type-check (the package spells it hyphenated) => EXIT 0, 0 errors, with the script body echoed (tsc --noEmit && tsc -p tsconfig.test.json) so a zero-match filter cannot pass for a green. ⚠️ The package's main tsconfig.jsonexcludes test/, so that green would say nothing about the new pin on its own; --listFiles confirms component-fixture-declared-keys.test.ts is really in the tsconfig.test.json program (889 files). The dependency closure was built first — before it, every test file in the package reported Cannot find module '@object-ui/types/zod', including ones this PR never touches.

Gates, on 8595e42, exit codes captured before any pipe:

gate	exit
check:control-bytes	0
changeset:check	0
check:doc-types	0
check:icon-record-names	0
check:docs-route-closure	0
check-changeset-presence.mjs	0

Gate family derived by hand from this repo's own package.json and .github/workflows/ — scripts/pm/dispatch-gates.mjs lives only in objectstack and would have answered about that tree.

Changeset. The presence gate's verdict line, verbatim:

✅ No source or published contract of a released package changed in this range, so no changeset is owed.

examples/schema-catalog is private: true, so the artifact is an empty-frontmatter changeset (.changeset/7072-catalog-menu-value-keys.md) — ⛔ not a patch bump, which would falsely claim a released package changed. Adding a test does not change that. ⛔ No skip-changeset label: in this repo that label is a historical mis-mint that no workflow reads.

Lint.pnpm exec eslint examples/schema-catalog/test/component-fixture-declared-keys.test.ts => EXIT 0, and --format json confirms the file was actually linted (0 errors, 0 warnings, no "File ignored" message) rather than silently skipped. The four JSON fixtures and the changeset carry no eslint configuration and report as ignored. Plain form; ⛔ no --no-inline-config.

Absorber check — #6810 is ruled, and it rules for this shape

The dispatch flagged #6810 as a possible absorber, expected to be undecided. It is not — it was ruled twice, and the second ruling adopted the middle state: narrow ratchet, ⛔ no general extractor, with option A (the family-wide sweep) 明确不采 and never-before-seen keys taking option C — 人手撞见、逐例修 + 补钉. So this card is not a row of a sweep; it is exactly the hand fix that ruling prescribes, and the pin above is its second half.

Filed, not fixed

• 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 #7101 — the same fixture authors variant: "destructive" on its Delete item; also undeclared on both arms and unread by all three renderers (dropdown-menu.tsx maps items with no spread). ⛔ Not a mechanical delete: shadcn's DropdownMenuItem really does ship a destructive variant, so "declare and render it" is a defensible opposite repair. That is the finding(examples): seven catalog badge nodes author their text under children, which ui:badge never reads — three demos draw nothing at all #6829 shape and needs a decision.
• finding(components): two menu icon tests transcribe catalog fixtures verbatim including the undeclared value key, so the phantom spelling survives #7072 as copyable example code #7102 — context-menu-item-icon.test.tsx:169-173 and dropdown-menu-item-icon.test.tsx:122-124 transcribe these fixtures inline includingvalue, so the phantom spelling survives this PR as copyable example code. Mechanical to fix, but in packages/components — a different package and gate family.

⛔ #7077 is not addressed here; its buttons[].value population is a different component family.

---

Generated by Claude Code

[os-warren]

Fixes#7072

Twenty-one menu items in the four overlay-menu catalog fixtures authored a value key that no arm of the shipped MenuItem union declares and no menu renderer reads. This deletes them, and pins that they stay gone.

Re-derived on current main, because the card's numbers were days old

The card measured at 592acafb; main is now 2c3cd1b. The count has not moved — 21, distributed exactly as the card's table claims:

fixture	value keys
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
total	21

Counted by a walker that classifies each value key by its position in the tree rather than by filename, so the neighbouring buttons[].value population (#7077, button-group) is separated by construction and cannot leak in. Catalog-wide the walker sees 288 objects carrying value before and 267 after — a delta of exactly 21, so nothing outside the four fixtures moved.

⚠️ One correction to the card: its cited line spans are slightly off. Re-derived, MenuCommandItem is packages/types/src/overlay.ts:363-401 (card said :363-400) and MenuDividerItem is :409-419 (card said :409-421).

The authority, re-verified

• MenuCommandItem (overlay.ts:363-401) declares label, icon, disabled, onClick, shortcut, children, separator?: false, type?: never. No value.
• MenuDividerItem (:409-419) declares separator: true, type?: never. No value.
• The three renderers under packages/components/src/renderers/overlay/ perform zero .value reads. Stated precisely, because it is not zero occurrences of the token: context-menu.tsx:95 contains { type: 'text', value: "Right click here" } — a write constructing a text node, whose renderer genuinely reads value. No menu item's value is ever read.
• 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 — 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. Nothing red covered this.

Deleted rather than declared: nothing reads value, and #6523 deliberately narrowed this union rather than widening it.

The pin — #6810's second half

#6810's ruling (2026-08-30, maintainer, verbatim「同意」) prescribes 逐例修 + 补钉 for a key this class has regenerated on: the case-by-case fix plus a named pin carrying its own counter-probe, in the existing component-fixture-declared-keys.test.ts ledger form. This PR now carries both halves.

⛔ Not a widening of #6249's menubar sweep — a new, separately named block. That sweep walks one node shape and its own header states that extending it to dropdown-menu / context-menu is "a separate verification surface this fix does not need"; it is untouched. value was authored across all three containers, so a menubar-scoped pin would have covered 11 of 21 while reading as though it covered the class, which is worse than no pin.

The new block sweeps the whole overlay-menu corpus — all three container shapes, including the deeper menus[].items[] nesting only menubar has, and submenu children:

• non-vacuity: 25 items (menubar 13 + context-menu 5 + dropdown 4 + with-icons 3), one representative position asserted per container shape, so a walker that stops matching a shape fails loudly instead of reporting a clean zero.
• the assertion: no overlay-menu item authors value, with label (21) and separator (4) as in-query controls, so an empty or unparsed corpus cannot masquerade as a pass.
• the counter-probe: ⛔ deliberately corpus-level, not schema-level. MenuItemSchema strips value and returns success, so a .safeParse probe is structurally blind here — it stayed green through all 21 authored keys. The probe re-authors value into a real fixture taken from the corpus and asserts the identical sweep reports it at the right position, with the untouched fixture clean alongside.

⭐ The pre-existing declared-key controls in the menubar block already fed {label, icon, disabled, shortcut, value} to MenuItemSchema and asserted only the first four survive. That pinned the type-level fact and was green the whole time the 21 keys sat in the corpus. The gap was only ever the corpus assertion.

Ablation — the pin demonstrably goes red. With "value": "profile" re-authored into basic-dropdown-menu.json on disk (mutation confirmed: value key count 0 → 1, injected text present, blob hash 7e72503b → ece5381c, still valid JSON), the suite fails:

× ... > no overlay-menu item authors `value`
AssertionError: expected [ Array(1) ] to deeply equal []
× ... > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture
AssertionError: expected [ 'pristine.items[0].value' ] to deeply equal []
Tests 2 failed | 34 passed (36)

The non-vacuity test stayed green throughout, correctly — a key was added, not an item. Restore leg proven rather than assumed: git checkout HEAD -- <abs path>, value count back to 0, blob hash matches the HEAD blob exactly, git diff HEAD empty.

Evidence

The diff is only what it claims. Every changed fixture line is one of: a removed "value": … line (21), or a "label" line re-punctuated because value had been the last key on that item (14 removed / 14 added, identical but for the trailing comma). No content changed. All four files round-trip byte-identically through JSON.stringify(…, null, 2), so the edit was made by parse-and-reserialise and the diff is minimal by construction.

Zero-hit control. After the deletion, value hits 0 in all four files while the control label still hits 14 / 4 / 4 / 4 in the same query — a zero for both would have meant the files were emptied, not fixed. Structure intact: menubar still has 13 items (2 separators, 11 labelled), matching the existing expect(items).toHaveLength(13) pin.

Rendered output is unchanged — which is the correct expectation here, the opposite of a fixture-content fix. The keys were inert, so the DOM must not move. Measured rather than assumed: a scratch harness rendered each dropdown fixture at 2c3cd1b and at this branch with defaultOpen: true injected (a closed menu renders only its trigger, which never carried the key, and would have made the comparison vacuous), normalised Radix's per-instance generated ids, and asserted identical HTML, text and [role="menuitem"] counts. Its control — mutating a key the renderer does read (label) — was required to produce a difference, and did. Scratch-only; not part of this diff.

⚠️Coverage of that DOM measurement, stated honestly: it directly covers the 6 items in the two dropdown-menu fixtures. menubar (11) and context-menu (4) cannot be forced open the same way — Radix opens them via a menubar value and a real right-click — so their inertness rests on the zero-read derivation above plus the corpus suites. My first attempt at this harness was discarded outright: without registering the renderers it fell back to a raw-JSON dump, and its control caught it.

Suites, on the final commit 8595e42:

pnpm exec vitest run \
examples/schema-catalog/test/component-fixture-declared-keys.test.ts \
examples/schema-catalog/test/safe-validate-corpus-6318.test.ts \
examples/schema-catalog/test/catalog-authored-key-6805-6806.test.tsx \
examples/schema-catalog/test/catalog-gallery-render.test.tsx
=> Test Files 4 passed (4) · Tests 659 passed (659) [RUN root: objectui-issue-7072]

659 = the prior 656 plus this PR's 3 new tests. Confirmed by name under --reporter=verbose rather than by an aggregate count:

✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > the sweep reaches all three container shapes and every one of their items — non-vacuity
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > no overlay-menu item authors `value`
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture

Run root-relative from the repo root, per #3378 — the RUN v4.1.10 /home/user/objectui-issue-7072 banner confirms it did not silently re-root onto apps/console.

Type-check.pnpm --filter @object-ui/example-schema-catalog type-check (the package spells it hyphenated) => EXIT 0, 0 errors, with the script body echoed (tsc --noEmit && tsc -p tsconfig.test.json) so a zero-match filter cannot pass for a green. ⚠️ The package's main tsconfig.jsonexcludes test/, so that green would say nothing about the new pin on its own; --listFiles confirms component-fixture-declared-keys.test.ts is really in the tsconfig.test.json program (889 files). The dependency closure was built first — before it, every test file in the package reported Cannot find module '@object-ui/types/zod', including ones this PR never touches.

Gates, on 8595e42, exit codes captured before any pipe:

gate	exit
check:control-bytes	0
changeset:check	0
check:doc-types	0
check:icon-record-names	0
check:docs-route-closure	0
check-changeset-presence.mjs	0

Gate family derived by hand from this repo's own package.json and .github/workflows/ — scripts/pm/dispatch-gates.mjs lives only in objectstack and would have answered about that tree.

Changeset. The presence gate's verdict line, verbatim:

✅ No source or published contract of a released package changed in this range, so no changeset is owed.

examples/schema-catalog is private: true, so the artifact is an empty-frontmatter changeset (.changeset/7072-catalog-menu-value-keys.md) — ⛔ not a patch bump, which would falsely claim a released package changed. Adding a test does not change that. ⛔ No skip-changeset label: in this repo that label is a historical mis-mint that no workflow reads.

Lint.pnpm exec eslint examples/schema-catalog/test/component-fixture-declared-keys.test.ts => EXIT 0, and --format json confirms the file was actually linted (0 errors, 0 warnings, no "File ignored" message) rather than silently skipped. The four JSON fixtures and the changeset carry no eslint configuration and report as ignored. Plain form; ⛔ no --no-inline-config.

Absorber check — #6810 is ruled, and it rules for this shape

The dispatch flagged #6810 as a possible absorber, expected to be undecided. It is not — it was ruled twice, and the second ruling adopted the middle state: narrow ratchet, ⛔ no general extractor, with option A (the family-wide sweep) 明确不采 and never-before-seen keys taking option C — 人手撞见、逐例修 + 补钉. So this card is not a row of a sweep; it is exactly the hand fix that ruling prescribes, and the pin above is its second half.

Filed, not fixed

• 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 #7101 — the same fixture authors variant: "destructive" on its Delete item; also undeclared on both arms and unread by all three renderers (dropdown-menu.tsx maps items with no spread). ⛔ Not a mechanical delete: shadcn's DropdownMenuItem really does ship a destructive variant, so "declare and render it" is a defensible opposite repair. That is the finding(examples): seven catalog badge nodes author their text under children, which ui:badge never reads — three demos draw nothing at all #6829 shape and needs a decision.
• finding(components): two menu icon tests transcribe catalog fixtures verbatim including the undeclared value key, so the phantom spelling survives #7072 as copyable example code #7102 — context-menu-item-icon.test.tsx:169-173 and dropdown-menu-item-icon.test.tsx:122-124 transcribe these fixtures inline includingvalue, so the phantom spelling survives this PR as copyable example code. Mechanical to fix, but in packages/components — a different package and gate family.

⛔ #7077 is not addressed here; its buttons[].value population is a different component family.

---

Generated by Claude Code

[os-warren]

Fixes#7072

Twenty-one menu items in the four overlay-menu catalog fixtures authored a value key that no arm of the shipped MenuItem union declares and no menu renderer reads. This deletes them, and pins that they stay gone.

Re-derived on current main, because the card's numbers were days old

The card measured at 592acafb; main is now 2c3cd1b. The count has not moved — 21, distributed exactly as the card's table claims:

fixture	value keys
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
total	21

Counted by a walker that classifies each value key by its position in the tree rather than by filename, so the neighbouring buttons[].value population (#7077, button-group) is separated by construction and cannot leak in. Catalog-wide the walker sees 288 objects carrying value before and 267 after — a delta of exactly 21, so nothing outside the four fixtures moved.

⚠️ One correction to the card: its cited line spans are slightly off. Re-derived, MenuCommandItem is packages/types/src/overlay.ts:363-401 (card said :363-400) and MenuDividerItem is :409-419 (card said :409-421).

The authority, re-verified

• MenuCommandItem (overlay.ts:363-401) declares label, icon, disabled, onClick, shortcut, children, separator?: false, type?: never. No value.
• MenuDividerItem (:409-419) declares separator: true, type?: never. No value.
• The three renderers under packages/components/src/renderers/overlay/ perform zero .value reads. Stated precisely, because it is not zero occurrences of the token: context-menu.tsx:95 contains { type: 'text', value: "Right click here" } — a write constructing a text node, whose renderer genuinely reads value. No menu item's value is ever read.
• 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 — 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. Nothing red covered this.

Deleted rather than declared: nothing reads value, and #6523 deliberately narrowed this union rather than widening it.

The pin — #6810's second half

#6810's ruling (2026-08-30, maintainer, verbatim「同意」) prescribes 逐例修 + 补钉 for a key this class has regenerated on: the case-by-case fix plus a named pin carrying its own counter-probe, in the existing component-fixture-declared-keys.test.ts ledger form. This PR now carries both halves.

⛔ Not a widening of #6249's menubar sweep — a new, separately named block. That sweep walks one node shape and its own header states that extending it to dropdown-menu / context-menu is "a separate verification surface this fix does not need"; it is untouched. value was authored across all three containers, so a menubar-scoped pin would have covered 11 of 21 while reading as though it covered the class, which is worse than no pin.

The new block sweeps the whole overlay-menu corpus — all three container shapes, including the deeper menus[].items[] nesting only menubar has, and submenu children:

• non-vacuity: 25 items (menubar 13 + context-menu 5 + dropdown 4 + with-icons 3), one representative position asserted per container shape, so a walker that stops matching a shape fails loudly instead of reporting a clean zero.
• the assertion: no overlay-menu item authors value, with label (21) and separator (4) as in-query controls, so an empty or unparsed corpus cannot masquerade as a pass.
• the counter-probe: ⛔ deliberately corpus-level, not schema-level. MenuItemSchema strips value and returns success, so a .safeParse probe is structurally blind here — it stayed green through all 21 authored keys. The probe re-authors value into a real fixture taken from the corpus and asserts the identical sweep reports it at the right position, with the untouched fixture clean alongside.

⭐ The pre-existing declared-key controls in the menubar block already fed {label, icon, disabled, shortcut, value} to MenuItemSchema and asserted only the first four survive. That pinned the type-level fact and was green the whole time the 21 keys sat in the corpus. The gap was only ever the corpus assertion.

Ablation — the pin demonstrably goes red. With "value": "profile" re-authored into basic-dropdown-menu.json on disk (mutation confirmed: value key count 0 → 1, injected text present, blob hash 7e72503b → ece5381c, still valid JSON), the suite fails:

× ... > no overlay-menu item authors `value`
AssertionError: expected [ Array(1) ] to deeply equal []
× ... > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture
AssertionError: expected [ 'pristine.items[0].value' ] to deeply equal []
Tests 2 failed | 34 passed (36)

The non-vacuity test stayed green throughout, correctly — a key was added, not an item. Restore leg proven rather than assumed: git checkout HEAD -- <abs path>, value count back to 0, blob hash matches the HEAD blob exactly, git diff HEAD empty.

Evidence

The diff is only what it claims. Every changed fixture line is one of: a removed "value": … line (21), or a "label" line re-punctuated because value had been the last key on that item (14 removed / 14 added, identical but for the trailing comma). No content changed. All four files round-trip byte-identically through JSON.stringify(…, null, 2), so the edit was made by parse-and-reserialise and the diff is minimal by construction.

Zero-hit control. After the deletion, value hits 0 in all four files while the control label still hits 14 / 4 / 4 / 4 in the same query — a zero for both would have meant the files were emptied, not fixed. Structure intact: menubar still has 13 items (2 separators, 11 labelled), matching the existing expect(items).toHaveLength(13) pin.

Rendered output is unchanged — which is the correct expectation here, the opposite of a fixture-content fix. The keys were inert, so the DOM must not move. Measured rather than assumed: a scratch harness rendered each dropdown fixture at 2c3cd1b and at this branch with defaultOpen: true injected (a closed menu renders only its trigger, which never carried the key, and would have made the comparison vacuous), normalised Radix's per-instance generated ids, and asserted identical HTML, text and [role="menuitem"] counts. Its control — mutating a key the renderer does read (label) — was required to produce a difference, and did. Scratch-only; not part of this diff.

⚠️Coverage of that DOM measurement, stated honestly: it directly covers the 6 items in the two dropdown-menu fixtures. menubar (11) and context-menu (4) cannot be forced open the same way — Radix opens them via a menubar value and a real right-click — so their inertness rests on the zero-read derivation above plus the corpus suites. My first attempt at this harness was discarded outright: without registering the renderers it fell back to a raw-JSON dump, and its control caught it.

Suites, on the final commit 8595e42:

pnpm exec vitest run \
examples/schema-catalog/test/component-fixture-declared-keys.test.ts \
examples/schema-catalog/test/safe-validate-corpus-6318.test.ts \
examples/schema-catalog/test/catalog-authored-key-6805-6806.test.tsx \
examples/schema-catalog/test/catalog-gallery-render.test.tsx
=> Test Files 4 passed (4) · Tests 659 passed (659) [RUN root: objectui-issue-7072]

659 = the prior 656 plus this PR's 3 new tests. Confirmed by name under --reporter=verbose rather than by an aggregate count:

✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > the sweep reaches all three container shapes and every one of their items — non-vacuity
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > no overlay-menu item authors `value`
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture

Run root-relative from the repo root, per #3378 — the RUN v4.1.10 /home/user/objectui-issue-7072 banner confirms it did not silently re-root onto apps/console.

Type-check.pnpm --filter @object-ui/example-schema-catalog type-check (the package spells it hyphenated) => EXIT 0, 0 errors, with the script body echoed (tsc --noEmit && tsc -p tsconfig.test.json) so a zero-match filter cannot pass for a green. ⚠️ The package's main tsconfig.jsonexcludes test/, so that green would say nothing about the new pin on its own; --listFiles confirms component-fixture-declared-keys.test.ts is really in the tsconfig.test.json program (889 files). The dependency closure was built first — before it, every test file in the package reported Cannot find module '@object-ui/types/zod', including ones this PR never touches.

Gates, on 8595e42, exit codes captured before any pipe:

gate	exit
check:control-bytes	0
changeset:check	0
check:doc-types	0
check:icon-record-names	0
check:docs-route-closure	0
check-changeset-presence.mjs	0

Gate family derived by hand from this repo's own package.json and .github/workflows/ — scripts/pm/dispatch-gates.mjs lives only in objectstack and would have answered about that tree.

Changeset. The presence gate's verdict line, verbatim:

✅ No source or published contract of a released package changed in this range, so no changeset is owed.

examples/schema-catalog is private: true, so the artifact is an empty-frontmatter changeset (.changeset/7072-catalog-menu-value-keys.md) — ⛔ not a patch bump, which would falsely claim a released package changed. Adding a test does not change that. ⛔ No skip-changeset label: in this repo that label is a historical mis-mint that no workflow reads.

Lint.pnpm exec eslint examples/schema-catalog/test/component-fixture-declared-keys.test.ts => EXIT 0, and --format json confirms the file was actually linted (0 errors, 0 warnings, no "File ignored" message) rather than silently skipped. The four JSON fixtures and the changeset carry no eslint configuration and report as ignored. Plain form; ⛔ no --no-inline-config.

Absorber check — #6810 is ruled, and it rules for this shape

The dispatch flagged #6810 as a possible absorber, expected to be undecided. It is not — it was ruled twice, and the second ruling adopted the middle state: narrow ratchet, ⛔ no general extractor, with option A (the family-wide sweep) 明确不采 and never-before-seen keys taking option C — 人手撞见、逐例修 + 补钉. So this card is not a row of a sweep; it is exactly the hand fix that ruling prescribes, and the pin above is its second half.

Filed, not fixed

• 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 #7101 — the same fixture authors variant: "destructive" on its Delete item; also undeclared on both arms and unread by all three renderers (dropdown-menu.tsx maps items with no spread). ⛔ Not a mechanical delete: shadcn's DropdownMenuItem really does ship a destructive variant, so "declare and render it" is a defensible opposite repair. That is the finding(examples): seven catalog badge nodes author their text under children, which ui:badge never reads — three demos draw nothing at all #6829 shape and needs a decision.
• finding(components): two menu icon tests transcribe catalog fixtures verbatim including the undeclared value key, so the phantom spelling survives #7072 as copyable example code #7102 — context-menu-item-icon.test.tsx:169-173 and dropdown-menu-item-icon.test.tsx:122-124 transcribe these fixtures inline includingvalue, so the phantom spelling survives this PR as copyable example code. Mechanical to fix, but in packages/components — a different package and gate family.

⛔ #7077 is not addressed here; its buttons[].value population is a different component family.

---

Generated by Claude Code

[os-warren]

Fixes#7072

Twenty-one menu items in the four overlay-menu catalog fixtures authored a value key that no arm of the shipped MenuItem union declares and no menu renderer reads. This deletes them, and pins that they stay gone.

Re-derived on current main, because the card's numbers were days old

The card measured at 592acafb; main is now 2c3cd1b. The count has not moved — 21, distributed exactly as the card's table claims:

fixture	value keys
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
total	21

Counted by a walker that classifies each value key by its position in the tree rather than by filename, so the neighbouring buttons[].value population (#7077, button-group) is separated by construction and cannot leak in. Catalog-wide the walker sees 288 objects carrying value before and 267 after — a delta of exactly 21, so nothing outside the four fixtures moved.

⚠️ One correction to the card: its cited line spans are slightly off. Re-derived, MenuCommandItem is packages/types/src/overlay.ts:363-401 (card said :363-400) and MenuDividerItem is :409-419 (card said :409-421).

The authority, re-verified

• MenuCommandItem (overlay.ts:363-401) declares label, icon, disabled, onClick, shortcut, children, separator?: false, type?: never. No value.
• MenuDividerItem (:409-419) declares separator: true, type?: never. No value.
• The three renderers under packages/components/src/renderers/overlay/ perform zero .value reads. Stated precisely, because it is not zero occurrences of the token: context-menu.tsx:95 contains { type: 'text', value: "Right click here" } — a write constructing a text node, whose renderer genuinely reads value. No menu item's value is ever read.
• 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 — 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. Nothing red covered this.

Deleted rather than declared: nothing reads value, and #6523 deliberately narrowed this union rather than widening it.

The pin — #6810's second half

#6810's ruling (2026-08-30, maintainer, verbatim「同意」) prescribes 逐例修 + 补钉 for a key this class has regenerated on: the case-by-case fix plus a named pin carrying its own counter-probe, in the existing component-fixture-declared-keys.test.ts ledger form. This PR now carries both halves.

⛔ Not a widening of #6249's menubar sweep — a new, separately named block. That sweep walks one node shape and its own header states that extending it to dropdown-menu / context-menu is "a separate verification surface this fix does not need"; it is untouched. value was authored across all three containers, so a menubar-scoped pin would have covered 11 of 21 while reading as though it covered the class, which is worse than no pin.

The new block sweeps the whole overlay-menu corpus — all three container shapes, including the deeper menus[].items[] nesting only menubar has, and submenu children:

• non-vacuity: 25 items (menubar 13 + context-menu 5 + dropdown 4 + with-icons 3), one representative position asserted per container shape, so a walker that stops matching a shape fails loudly instead of reporting a clean zero.
• the assertion: no overlay-menu item authors value, with label (21) and separator (4) as in-query controls, so an empty or unparsed corpus cannot masquerade as a pass.
• the counter-probe: ⛔ deliberately corpus-level, not schema-level. MenuItemSchema strips value and returns success, so a .safeParse probe is structurally blind here — it stayed green through all 21 authored keys. The probe re-authors value into a real fixture taken from the corpus and asserts the identical sweep reports it at the right position, with the untouched fixture clean alongside.

⭐ The pre-existing declared-key controls in the menubar block already fed {label, icon, disabled, shortcut, value} to MenuItemSchema and asserted only the first four survive. That pinned the type-level fact and was green the whole time the 21 keys sat in the corpus. The gap was only ever the corpus assertion.

Ablation — the pin demonstrably goes red. With "value": "profile" re-authored into basic-dropdown-menu.json on disk (mutation confirmed: value key count 0 → 1, injected text present, blob hash 7e72503b → ece5381c, still valid JSON), the suite fails:

× ... > no overlay-menu item authors `value`
AssertionError: expected [ Array(1) ] to deeply equal []
× ... > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture
AssertionError: expected [ 'pristine.items[0].value' ] to deeply equal []
Tests 2 failed | 34 passed (36)

The non-vacuity test stayed green throughout, correctly — a key was added, not an item. Restore leg proven rather than assumed: git checkout HEAD -- <abs path>, value count back to 0, blob hash matches the HEAD blob exactly, git diff HEAD empty.

Evidence

The diff is only what it claims. Every changed fixture line is one of: a removed "value": … line (21), or a "label" line re-punctuated because value had been the last key on that item (14 removed / 14 added, identical but for the trailing comma). No content changed. All four files round-trip byte-identically through JSON.stringify(…, null, 2), so the edit was made by parse-and-reserialise and the diff is minimal by construction.

Zero-hit control. After the deletion, value hits 0 in all four files while the control label still hits 14 / 4 / 4 / 4 in the same query — a zero for both would have meant the files were emptied, not fixed. Structure intact: menubar still has 13 items (2 separators, 11 labelled), matching the existing expect(items).toHaveLength(13) pin.

Rendered output is unchanged — which is the correct expectation here, the opposite of a fixture-content fix. The keys were inert, so the DOM must not move. Measured rather than assumed: a scratch harness rendered each dropdown fixture at 2c3cd1b and at this branch with defaultOpen: true injected (a closed menu renders only its trigger, which never carried the key, and would have made the comparison vacuous), normalised Radix's per-instance generated ids, and asserted identical HTML, text and [role="menuitem"] counts. Its control — mutating a key the renderer does read (label) — was required to produce a difference, and did. Scratch-only; not part of this diff.

⚠️Coverage of that DOM measurement, stated honestly: it directly covers the 6 items in the two dropdown-menu fixtures. menubar (11) and context-menu (4) cannot be forced open the same way — Radix opens them via a menubar value and a real right-click — so their inertness rests on the zero-read derivation above plus the corpus suites. My first attempt at this harness was discarded outright: without registering the renderers it fell back to a raw-JSON dump, and its control caught it.

Suites, on the final commit 8595e42:

pnpm exec vitest run \
examples/schema-catalog/test/component-fixture-declared-keys.test.ts \
examples/schema-catalog/test/safe-validate-corpus-6318.test.ts \
examples/schema-catalog/test/catalog-authored-key-6805-6806.test.tsx \
examples/schema-catalog/test/catalog-gallery-render.test.tsx
=> Test Files 4 passed (4) · Tests 659 passed (659) [RUN root: objectui-issue-7072]

659 = the prior 656 plus this PR's 3 new tests. Confirmed by name under --reporter=verbose rather than by an aggregate count:

✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > the sweep reaches all three container shapes and every one of their items — non-vacuity
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > no overlay-menu item authors `value`
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture

Run root-relative from the repo root, per #3378 — the RUN v4.1.10 /home/user/objectui-issue-7072 banner confirms it did not silently re-root onto apps/console.

Type-check.pnpm --filter @object-ui/example-schema-catalog type-check (the package spells it hyphenated) => EXIT 0, 0 errors, with the script body echoed (tsc --noEmit && tsc -p tsconfig.test.json) so a zero-match filter cannot pass for a green. ⚠️ The package's main tsconfig.jsonexcludes test/, so that green would say nothing about the new pin on its own; --listFiles confirms component-fixture-declared-keys.test.ts is really in the tsconfig.test.json program (889 files). The dependency closure was built first — before it, every test file in the package reported Cannot find module '@object-ui/types/zod', including ones this PR never touches.

Gates, on 8595e42, exit codes captured before any pipe:

gate	exit
check:control-bytes	0
changeset:check	0
check:doc-types	0
check:icon-record-names	0
check:docs-route-closure	0
check-changeset-presence.mjs	0

Gate family derived by hand from this repo's own package.json and .github/workflows/ — scripts/pm/dispatch-gates.mjs lives only in objectstack and would have answered about that tree.

Changeset. The presence gate's verdict line, verbatim:

✅ No source or published contract of a released package changed in this range, so no changeset is owed.

examples/schema-catalog is private: true, so the artifact is an empty-frontmatter changeset (.changeset/7072-catalog-menu-value-keys.md) — ⛔ not a patch bump, which would falsely claim a released package changed. Adding a test does not change that. ⛔ No skip-changeset label: in this repo that label is a historical mis-mint that no workflow reads.

Lint.pnpm exec eslint examples/schema-catalog/test/component-fixture-declared-keys.test.ts => EXIT 0, and --format json confirms the file was actually linted (0 errors, 0 warnings, no "File ignored" message) rather than silently skipped. The four JSON fixtures and the changeset carry no eslint configuration and report as ignored. Plain form; ⛔ no --no-inline-config.

Absorber check — #6810 is ruled, and it rules for this shape

The dispatch flagged #6810 as a possible absorber, expected to be undecided. It is not — it was ruled twice, and the second ruling adopted the middle state: narrow ratchet, ⛔ no general extractor, with option A (the family-wide sweep) 明确不采 and never-before-seen keys taking option C — 人手撞见、逐例修 + 补钉. So this card is not a row of a sweep; it is exactly the hand fix that ruling prescribes, and the pin above is its second half.

Filed, not fixed

• 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 #7101 — the same fixture authors variant: "destructive" on its Delete item; also undeclared on both arms and unread by all three renderers (dropdown-menu.tsx maps items with no spread). ⛔ Not a mechanical delete: shadcn's DropdownMenuItem really does ship a destructive variant, so "declare and render it" is a defensible opposite repair. That is the finding(examples): seven catalog badge nodes author their text under children, which ui:badge never reads — three demos draw nothing at all #6829 shape and needs a decision.
• finding(components): two menu icon tests transcribe catalog fixtures verbatim including the undeclared value key, so the phantom spelling survives #7072 as copyable example code #7102 — context-menu-item-icon.test.tsx:169-173 and dropdown-menu-item-icon.test.tsx:122-124 transcribe these fixtures inline includingvalue, so the phantom spelling survives this PR as copyable example code. Mechanical to fix, but in packages/components — a different package and gate family.

⛔ #7077 is not addressed here; its buttons[].value population is a different component family.

---

Generated by Claude Code

[os-warren]

Fixes#7072

Twenty-one menu items in the four overlay-menu catalog fixtures authored a value key that no arm of the shipped MenuItem union declares and no menu renderer reads. This deletes them, and pins that they stay gone.

Re-derived on current main, because the card's numbers were days old

The card measured at 592acafb; main is now 2c3cd1b. The count has not moved — 21, distributed exactly as the card's table claims:

fixture	value keys
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
total	21

Counted by a walker that classifies each value key by its position in the tree rather than by filename, so the neighbouring buttons[].value population (#7077, button-group) is separated by construction and cannot leak in. Catalog-wide the walker sees 288 objects carrying value before and 267 after — a delta of exactly 21, so nothing outside the four fixtures moved.

⚠️ One correction to the card: its cited line spans are slightly off. Re-derived, MenuCommandItem is packages/types/src/overlay.ts:363-401 (card said :363-400) and MenuDividerItem is :409-419 (card said :409-421).

The authority, re-verified

• MenuCommandItem (overlay.ts:363-401) declares label, icon, disabled, onClick, shortcut, children, separator?: false, type?: never. No value.
• MenuDividerItem (:409-419) declares separator: true, type?: never. No value.
• The three renderers under packages/components/src/renderers/overlay/ perform zero .value reads. Stated precisely, because it is not zero occurrences of the token: context-menu.tsx:95 contains { type: 'text', value: "Right click here" } — a write constructing a text node, whose renderer genuinely reads value. No menu item's value is ever read.
• 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 — 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. Nothing red covered this.

Deleted rather than declared: nothing reads value, and #6523 deliberately narrowed this union rather than widening it.

The pin — #6810's second half

#6810's ruling (2026-08-30, maintainer, verbatim「同意」) prescribes 逐例修 + 补钉 for a key this class has regenerated on: the case-by-case fix plus a named pin carrying its own counter-probe, in the existing component-fixture-declared-keys.test.ts ledger form. This PR now carries both halves.

⛔ Not a widening of #6249's menubar sweep — a new, separately named block. That sweep walks one node shape and its own header states that extending it to dropdown-menu / context-menu is "a separate verification surface this fix does not need"; it is untouched. value was authored across all three containers, so a menubar-scoped pin would have covered 11 of 21 while reading as though it covered the class, which is worse than no pin.

The new block sweeps the whole overlay-menu corpus — all three container shapes, including the deeper menus[].items[] nesting only menubar has, and submenu children:

• non-vacuity: 25 items (menubar 13 + context-menu 5 + dropdown 4 + with-icons 3), one representative position asserted per container shape, so a walker that stops matching a shape fails loudly instead of reporting a clean zero.
• the assertion: no overlay-menu item authors value, with label (21) and separator (4) as in-query controls, so an empty or unparsed corpus cannot masquerade as a pass.
• the counter-probe: ⛔ deliberately corpus-level, not schema-level. MenuItemSchema strips value and returns success, so a .safeParse probe is structurally blind here — it stayed green through all 21 authored keys. The probe re-authors value into a real fixture taken from the corpus and asserts the identical sweep reports it at the right position, with the untouched fixture clean alongside.

⭐ The pre-existing declared-key controls in the menubar block already fed {label, icon, disabled, shortcut, value} to MenuItemSchema and asserted only the first four survive. That pinned the type-level fact and was green the whole time the 21 keys sat in the corpus. The gap was only ever the corpus assertion.

Ablation — the pin demonstrably goes red. With "value": "profile" re-authored into basic-dropdown-menu.json on disk (mutation confirmed: value key count 0 → 1, injected text present, blob hash 7e72503b → ece5381c, still valid JSON), the suite fails:

× ... > no overlay-menu item authors `value`
AssertionError: expected [ Array(1) ] to deeply equal []
× ... > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture
AssertionError: expected [ 'pristine.items[0].value' ] to deeply equal []
Tests 2 failed | 34 passed (36)

The non-vacuity test stayed green throughout, correctly — a key was added, not an item. Restore leg proven rather than assumed: git checkout HEAD -- <abs path>, value count back to 0, blob hash matches the HEAD blob exactly, git diff HEAD empty.

Evidence

The diff is only what it claims. Every changed fixture line is one of: a removed "value": … line (21), or a "label" line re-punctuated because value had been the last key on that item (14 removed / 14 added, identical but for the trailing comma). No content changed. All four files round-trip byte-identically through JSON.stringify(…, null, 2), so the edit was made by parse-and-reserialise and the diff is minimal by construction.

Zero-hit control. After the deletion, value hits 0 in all four files while the control label still hits 14 / 4 / 4 / 4 in the same query — a zero for both would have meant the files were emptied, not fixed. Structure intact: menubar still has 13 items (2 separators, 11 labelled), matching the existing expect(items).toHaveLength(13) pin.

Rendered output is unchanged — which is the correct expectation here, the opposite of a fixture-content fix. The keys were inert, so the DOM must not move. Measured rather than assumed: a scratch harness rendered each dropdown fixture at 2c3cd1b and at this branch with defaultOpen: true injected (a closed menu renders only its trigger, which never carried the key, and would have made the comparison vacuous), normalised Radix's per-instance generated ids, and asserted identical HTML, text and [role="menuitem"] counts. Its control — mutating a key the renderer does read (label) — was required to produce a difference, and did. Scratch-only; not part of this diff.

⚠️Coverage of that DOM measurement, stated honestly: it directly covers the 6 items in the two dropdown-menu fixtures. menubar (11) and context-menu (4) cannot be forced open the same way — Radix opens them via a menubar value and a real right-click — so their inertness rests on the zero-read derivation above plus the corpus suites. My first attempt at this harness was discarded outright: without registering the renderers it fell back to a raw-JSON dump, and its control caught it.

Suites, on the final commit 8595e42:

pnpm exec vitest run \
examples/schema-catalog/test/component-fixture-declared-keys.test.ts \
examples/schema-catalog/test/safe-validate-corpus-6318.test.ts \
examples/schema-catalog/test/catalog-authored-key-6805-6806.test.tsx \
examples/schema-catalog/test/catalog-gallery-render.test.tsx
=> Test Files 4 passed (4) · Tests 659 passed (659) [RUN root: objectui-issue-7072]

659 = the prior 656 plus this PR's 3 new tests. Confirmed by name under --reporter=verbose rather than by an aggregate count:

✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > the sweep reaches all three container shapes and every one of their items — non-vacuity
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > no overlay-menu item authors `value`
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture

Run root-relative from the repo root, per #3378 — the RUN v4.1.10 /home/user/objectui-issue-7072 banner confirms it did not silently re-root onto apps/console.

Type-check.pnpm --filter @object-ui/example-schema-catalog type-check (the package spells it hyphenated) => EXIT 0, 0 errors, with the script body echoed (tsc --noEmit && tsc -p tsconfig.test.json) so a zero-match filter cannot pass for a green. ⚠️ The package's main tsconfig.jsonexcludes test/, so that green would say nothing about the new pin on its own; --listFiles confirms component-fixture-declared-keys.test.ts is really in the tsconfig.test.json program (889 files). The dependency closure was built first — before it, every test file in the package reported Cannot find module '@object-ui/types/zod', including ones this PR never touches.

Gates, on 8595e42, exit codes captured before any pipe:

gate	exit
check:control-bytes	0
changeset:check	0
check:doc-types	0
check:icon-record-names	0
check:docs-route-closure	0
check-changeset-presence.mjs	0

Gate family derived by hand from this repo's own package.json and .github/workflows/ — scripts/pm/dispatch-gates.mjs lives only in objectstack and would have answered about that tree.

Changeset. The presence gate's verdict line, verbatim:

✅ No source or published contract of a released package changed in this range, so no changeset is owed.

examples/schema-catalog is private: true, so the artifact is an empty-frontmatter changeset (.changeset/7072-catalog-menu-value-keys.md) — ⛔ not a patch bump, which would falsely claim a released package changed. Adding a test does not change that. ⛔ No skip-changeset label: in this repo that label is a historical mis-mint that no workflow reads.

Lint.pnpm exec eslint examples/schema-catalog/test/component-fixture-declared-keys.test.ts => EXIT 0, and --format json confirms the file was actually linted (0 errors, 0 warnings, no "File ignored" message) rather than silently skipped. The four JSON fixtures and the changeset carry no eslint configuration and report as ignored. Plain form; ⛔ no --no-inline-config.

Absorber check — #6810 is ruled, and it rules for this shape

The dispatch flagged #6810 as a possible absorber, expected to be undecided. It is not — it was ruled twice, and the second ruling adopted the middle state: narrow ratchet, ⛔ no general extractor, with option A (the family-wide sweep) 明确不采 and never-before-seen keys taking option C — 人手撞见、逐例修 + 补钉. So this card is not a row of a sweep; it is exactly the hand fix that ruling prescribes, and the pin above is its second half.

Filed, not fixed

• 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 #7101 — the same fixture authors variant: "destructive" on its Delete item; also undeclared on both arms and unread by all three renderers (dropdown-menu.tsx maps items with no spread). ⛔ Not a mechanical delete: shadcn's DropdownMenuItem really does ship a destructive variant, so "declare and render it" is a defensible opposite repair. That is the finding(examples): seven catalog badge nodes author their text under children, which ui:badge never reads — three demos draw nothing at all #6829 shape and needs a decision.
• finding(components): two menu icon tests transcribe catalog fixtures verbatim including the undeclared value key, so the phantom spelling survives #7072 as copyable example code #7102 — context-menu-item-icon.test.tsx:169-173 and dropdown-menu-item-icon.test.tsx:122-124 transcribe these fixtures inline includingvalue, so the phantom spelling survives this PR as copyable example code. Mechanical to fix, but in packages/components — a different package and gate family.

⛔ #7077 is not addressed here; its buttons[].value population is a different component family.

---

Generated by Claude Code

[os-warren]

Fixes#7072

Twenty-one menu items in the four overlay-menu catalog fixtures authored a value key that no arm of the shipped MenuItem union declares and no menu renderer reads. This deletes them, and pins that they stay gone.

Re-derived on current main, because the card's numbers were days old

The card measured at 592acafb; main is now 2c3cd1b. The count has not moved — 21, distributed exactly as the card's table claims:

fixture	value keys
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
total	21

Counted by a walker that classifies each value key by its position in the tree rather than by filename, so the neighbouring buttons[].value population (#7077, button-group) is separated by construction and cannot leak in. Catalog-wide the walker sees 288 objects carrying value before and 267 after — a delta of exactly 21, so nothing outside the four fixtures moved.

⚠️ One correction to the card: its cited line spans are slightly off. Re-derived, MenuCommandItem is packages/types/src/overlay.ts:363-401 (card said :363-400) and MenuDividerItem is :409-419 (card said :409-421).

The authority, re-verified

• MenuCommandItem (overlay.ts:363-401) declares label, icon, disabled, onClick, shortcut, children, separator?: false, type?: never. No value.
• MenuDividerItem (:409-419) declares separator: true, type?: never. No value.
• The three renderers under packages/components/src/renderers/overlay/ perform zero .value reads. Stated precisely, because it is not zero occurrences of the token: context-menu.tsx:95 contains { type: 'text', value: "Right click here" } — a write constructing a text node, whose renderer genuinely reads value. No menu item's value is ever read.
• 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 — 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. Nothing red covered this.

Deleted rather than declared: nothing reads value, and #6523 deliberately narrowed this union rather than widening it.

The pin — #6810's second half

#6810's ruling (2026-08-30, maintainer, verbatim「同意」) prescribes 逐例修 + 补钉 for a key this class has regenerated on: the case-by-case fix plus a named pin carrying its own counter-probe, in the existing component-fixture-declared-keys.test.ts ledger form. This PR now carries both halves.

⛔ Not a widening of #6249's menubar sweep — a new, separately named block. That sweep walks one node shape and its own header states that extending it to dropdown-menu / context-menu is "a separate verification surface this fix does not need"; it is untouched. value was authored across all three containers, so a menubar-scoped pin would have covered 11 of 21 while reading as though it covered the class, which is worse than no pin.

The new block sweeps the whole overlay-menu corpus — all three container shapes, including the deeper menus[].items[] nesting only menubar has, and submenu children:

• non-vacuity: 25 items (menubar 13 + context-menu 5 + dropdown 4 + with-icons 3), one representative position asserted per container shape, so a walker that stops matching a shape fails loudly instead of reporting a clean zero.
• the assertion: no overlay-menu item authors value, with label (21) and separator (4) as in-query controls, so an empty or unparsed corpus cannot masquerade as a pass.
• the counter-probe: ⛔ deliberately corpus-level, not schema-level. MenuItemSchema strips value and returns success, so a .safeParse probe is structurally blind here — it stayed green through all 21 authored keys. The probe re-authors value into a real fixture taken from the corpus and asserts the identical sweep reports it at the right position, with the untouched fixture clean alongside.

⭐ The pre-existing declared-key controls in the menubar block already fed {label, icon, disabled, shortcut, value} to MenuItemSchema and asserted only the first four survive. That pinned the type-level fact and was green the whole time the 21 keys sat in the corpus. The gap was only ever the corpus assertion.

Ablation — the pin demonstrably goes red. With "value": "profile" re-authored into basic-dropdown-menu.json on disk (mutation confirmed: value key count 0 → 1, injected text present, blob hash 7e72503b → ece5381c, still valid JSON), the suite fails:

× ... > no overlay-menu item authors `value`
AssertionError: expected [ Array(1) ] to deeply equal []
× ... > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture
AssertionError: expected [ 'pristine.items[0].value' ] to deeply equal []
Tests 2 failed | 34 passed (36)

The non-vacuity test stayed green throughout, correctly — a key was added, not an item. Restore leg proven rather than assumed: git checkout HEAD -- <abs path>, value count back to 0, blob hash matches the HEAD blob exactly, git diff HEAD empty.

Evidence

The diff is only what it claims. Every changed fixture line is one of: a removed "value": … line (21), or a "label" line re-punctuated because value had been the last key on that item (14 removed / 14 added, identical but for the trailing comma). No content changed. All four files round-trip byte-identically through JSON.stringify(…, null, 2), so the edit was made by parse-and-reserialise and the diff is minimal by construction.

Zero-hit control. After the deletion, value hits 0 in all four files while the control label still hits 14 / 4 / 4 / 4 in the same query — a zero for both would have meant the files were emptied, not fixed. Structure intact: menubar still has 13 items (2 separators, 11 labelled), matching the existing expect(items).toHaveLength(13) pin.

Rendered output is unchanged — which is the correct expectation here, the opposite of a fixture-content fix. The keys were inert, so the DOM must not move. Measured rather than assumed: a scratch harness rendered each dropdown fixture at 2c3cd1b and at this branch with defaultOpen: true injected (a closed menu renders only its trigger, which never carried the key, and would have made the comparison vacuous), normalised Radix's per-instance generated ids, and asserted identical HTML, text and [role="menuitem"] counts. Its control — mutating a key the renderer does read (label) — was required to produce a difference, and did. Scratch-only; not part of this diff.

⚠️Coverage of that DOM measurement, stated honestly: it directly covers the 6 items in the two dropdown-menu fixtures. menubar (11) and context-menu (4) cannot be forced open the same way — Radix opens them via a menubar value and a real right-click — so their inertness rests on the zero-read derivation above plus the corpus suites. My first attempt at this harness was discarded outright: without registering the renderers it fell back to a raw-JSON dump, and its control caught it.

Suites, on the final commit 8595e42:

pnpm exec vitest run \
examples/schema-catalog/test/component-fixture-declared-keys.test.ts \
examples/schema-catalog/test/safe-validate-corpus-6318.test.ts \
examples/schema-catalog/test/catalog-authored-key-6805-6806.test.tsx \
examples/schema-catalog/test/catalog-gallery-render.test.tsx
=> Test Files 4 passed (4) · Tests 659 passed (659) [RUN root: objectui-issue-7072]

659 = the prior 656 plus this PR's 3 new tests. Confirmed by name under --reporter=verbose rather than by an aggregate count:

✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > the sweep reaches all three container shapes and every one of their items — non-vacuity
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > no overlay-menu item authors `value`
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture

Run root-relative from the repo root, per #3378 — the RUN v4.1.10 /home/user/objectui-issue-7072 banner confirms it did not silently re-root onto apps/console.

Type-check.pnpm --filter @object-ui/example-schema-catalog type-check (the package spells it hyphenated) => EXIT 0, 0 errors, with the script body echoed (tsc --noEmit && tsc -p tsconfig.test.json) so a zero-match filter cannot pass for a green. ⚠️ The package's main tsconfig.jsonexcludes test/, so that green would say nothing about the new pin on its own; --listFiles confirms component-fixture-declared-keys.test.ts is really in the tsconfig.test.json program (889 files). The dependency closure was built first — before it, every test file in the package reported Cannot find module '@object-ui/types/zod', including ones this PR never touches.

Gates, on 8595e42, exit codes captured before any pipe:

gate	exit
check:control-bytes	0
changeset:check	0
check:doc-types	0
check:icon-record-names	0
check:docs-route-closure	0
check-changeset-presence.mjs	0

Gate family derived by hand from this repo's own package.json and .github/workflows/ — scripts/pm/dispatch-gates.mjs lives only in objectstack and would have answered about that tree.

Changeset. The presence gate's verdict line, verbatim:

✅ No source or published contract of a released package changed in this range, so no changeset is owed.

examples/schema-catalog is private: true, so the artifact is an empty-frontmatter changeset (.changeset/7072-catalog-menu-value-keys.md) — ⛔ not a patch bump, which would falsely claim a released package changed. Adding a test does not change that. ⛔ No skip-changeset label: in this repo that label is a historical mis-mint that no workflow reads.

Lint.pnpm exec eslint examples/schema-catalog/test/component-fixture-declared-keys.test.ts => EXIT 0, and --format json confirms the file was actually linted (0 errors, 0 warnings, no "File ignored" message) rather than silently skipped. The four JSON fixtures and the changeset carry no eslint configuration and report as ignored. Plain form; ⛔ no --no-inline-config.

Absorber check — #6810 is ruled, and it rules for this shape

The dispatch flagged #6810 as a possible absorber, expected to be undecided. It is not — it was ruled twice, and the second ruling adopted the middle state: narrow ratchet, ⛔ no general extractor, with option A (the family-wide sweep) 明确不采 and never-before-seen keys taking option C — 人手撞见、逐例修 + 补钉. So this card is not a row of a sweep; it is exactly the hand fix that ruling prescribes, and the pin above is its second half.

Filed, not fixed

• 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 #7101 — the same fixture authors variant: "destructive" on its Delete item; also undeclared on both arms and unread by all three renderers (dropdown-menu.tsx maps items with no spread). ⛔ Not a mechanical delete: shadcn's DropdownMenuItem really does ship a destructive variant, so "declare and render it" is a defensible opposite repair. That is the finding(examples): seven catalog badge nodes author their text under children, which ui:badge never reads — three demos draw nothing at all #6829 shape and needs a decision.
• finding(components): two menu icon tests transcribe catalog fixtures verbatim including the undeclared value key, so the phantom spelling survives #7072 as copyable example code #7102 — context-menu-item-icon.test.tsx:169-173 and dropdown-menu-item-icon.test.tsx:122-124 transcribe these fixtures inline includingvalue, so the phantom spelling survives this PR as copyable example code. Mechanical to fix, but in packages/components — a different package and gate family.

⛔ #7077 is not addressed here; its buttons[].value population is a different component family.

---

Generated by Claude Code

[os-warren]

Fixes#7072

Twenty-one menu items in the four overlay-menu catalog fixtures authored a value key that no arm of the shipped MenuItem union declares and no menu renderer reads. This deletes them, and pins that they stay gone.

Re-derived on current main, because the card's numbers were days old

The card measured at 592acafb; main is now 2c3cd1b. The count has not moved — 21, distributed exactly as the card's table claims:

fixture	value keys
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
total	21

Counted by a walker that classifies each value key by its position in the tree rather than by filename, so the neighbouring buttons[].value population (#7077, button-group) is separated by construction and cannot leak in. Catalog-wide the walker sees 288 objects carrying value before and 267 after — a delta of exactly 21, so nothing outside the four fixtures moved.

⚠️ One correction to the card: its cited line spans are slightly off. Re-derived, MenuCommandItem is packages/types/src/overlay.ts:363-401 (card said :363-400) and MenuDividerItem is :409-419 (card said :409-421).

The authority, re-verified

• MenuCommandItem (overlay.ts:363-401) declares label, icon, disabled, onClick, shortcut, children, separator?: false, type?: never. No value.
• MenuDividerItem (:409-419) declares separator: true, type?: never. No value.
• The three renderers under packages/components/src/renderers/overlay/ perform zero .value reads. Stated precisely, because it is not zero occurrences of the token: context-menu.tsx:95 contains { type: 'text', value: "Right click here" } — a write constructing a text node, whose renderer genuinely reads value. No menu item's value is ever read.
• 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 — 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. Nothing red covered this.

Deleted rather than declared: nothing reads value, and #6523 deliberately narrowed this union rather than widening it.

The pin — #6810's second half

#6810's ruling (2026-08-30, maintainer, verbatim「同意」) prescribes 逐例修 + 补钉 for a key this class has regenerated on: the case-by-case fix plus a named pin carrying its own counter-probe, in the existing component-fixture-declared-keys.test.ts ledger form. This PR now carries both halves.

⛔ Not a widening of #6249's menubar sweep — a new, separately named block. That sweep walks one node shape and its own header states that extending it to dropdown-menu / context-menu is "a separate verification surface this fix does not need"; it is untouched. value was authored across all three containers, so a menubar-scoped pin would have covered 11 of 21 while reading as though it covered the class, which is worse than no pin.

The new block sweeps the whole overlay-menu corpus — all three container shapes, including the deeper menus[].items[] nesting only menubar has, and submenu children:

• non-vacuity: 25 items (menubar 13 + context-menu 5 + dropdown 4 + with-icons 3), one representative position asserted per container shape, so a walker that stops matching a shape fails loudly instead of reporting a clean zero.
• the assertion: no overlay-menu item authors value, with label (21) and separator (4) as in-query controls, so an empty or unparsed corpus cannot masquerade as a pass.
• the counter-probe: ⛔ deliberately corpus-level, not schema-level. MenuItemSchema strips value and returns success, so a .safeParse probe is structurally blind here — it stayed green through all 21 authored keys. The probe re-authors value into a real fixture taken from the corpus and asserts the identical sweep reports it at the right position, with the untouched fixture clean alongside.

⭐ The pre-existing declared-key controls in the menubar block already fed {label, icon, disabled, shortcut, value} to MenuItemSchema and asserted only the first four survive. That pinned the type-level fact and was green the whole time the 21 keys sat in the corpus. The gap was only ever the corpus assertion.

Ablation — the pin demonstrably goes red. With "value": "profile" re-authored into basic-dropdown-menu.json on disk (mutation confirmed: value key count 0 → 1, injected text present, blob hash 7e72503b → ece5381c, still valid JSON), the suite fails:

× ... > no overlay-menu item authors `value`
AssertionError: expected [ Array(1) ] to deeply equal []
× ... > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture
AssertionError: expected [ 'pristine.items[0].value' ] to deeply equal []
Tests 2 failed | 34 passed (36)

The non-vacuity test stayed green throughout, correctly — a key was added, not an item. Restore leg proven rather than assumed: git checkout HEAD -- <abs path>, value count back to 0, blob hash matches the HEAD blob exactly, git diff HEAD empty.

Evidence

The diff is only what it claims. Every changed fixture line is one of: a removed "value": … line (21), or a "label" line re-punctuated because value had been the last key on that item (14 removed / 14 added, identical but for the trailing comma). No content changed. All four files round-trip byte-identically through JSON.stringify(…, null, 2), so the edit was made by parse-and-reserialise and the diff is minimal by construction.

Zero-hit control. After the deletion, value hits 0 in all four files while the control label still hits 14 / 4 / 4 / 4 in the same query — a zero for both would have meant the files were emptied, not fixed. Structure intact: menubar still has 13 items (2 separators, 11 labelled), matching the existing expect(items).toHaveLength(13) pin.

Rendered output is unchanged — which is the correct expectation here, the opposite of a fixture-content fix. The keys were inert, so the DOM must not move. Measured rather than assumed: a scratch harness rendered each dropdown fixture at 2c3cd1b and at this branch with defaultOpen: true injected (a closed menu renders only its trigger, which never carried the key, and would have made the comparison vacuous), normalised Radix's per-instance generated ids, and asserted identical HTML, text and [role="menuitem"] counts. Its control — mutating a key the renderer does read (label) — was required to produce a difference, and did. Scratch-only; not part of this diff.

⚠️Coverage of that DOM measurement, stated honestly: it directly covers the 6 items in the two dropdown-menu fixtures. menubar (11) and context-menu (4) cannot be forced open the same way — Radix opens them via a menubar value and a real right-click — so their inertness rests on the zero-read derivation above plus the corpus suites. My first attempt at this harness was discarded outright: without registering the renderers it fell back to a raw-JSON dump, and its control caught it.

Suites, on the final commit 8595e42:

pnpm exec vitest run \
examples/schema-catalog/test/component-fixture-declared-keys.test.ts \
examples/schema-catalog/test/safe-validate-corpus-6318.test.ts \
examples/schema-catalog/test/catalog-authored-key-6805-6806.test.tsx \
examples/schema-catalog/test/catalog-gallery-render.test.tsx
=> Test Files 4 passed (4) · Tests 659 passed (659) [RUN root: objectui-issue-7072]

659 = the prior 656 plus this PR's 3 new tests. Confirmed by name under --reporter=verbose rather than by an aggregate count:

✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > the sweep reaches all three container shapes and every one of their items — non-vacuity
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > no overlay-menu item authors `value`
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture

Run root-relative from the repo root, per #3378 — the RUN v4.1.10 /home/user/objectui-issue-7072 banner confirms it did not silently re-root onto apps/console.

Type-check.pnpm --filter @object-ui/example-schema-catalog type-check (the package spells it hyphenated) => EXIT 0, 0 errors, with the script body echoed (tsc --noEmit && tsc -p tsconfig.test.json) so a zero-match filter cannot pass for a green. ⚠️ The package's main tsconfig.jsonexcludes test/, so that green would say nothing about the new pin on its own; --listFiles confirms component-fixture-declared-keys.test.ts is really in the tsconfig.test.json program (889 files). The dependency closure was built first — before it, every test file in the package reported Cannot find module '@object-ui/types/zod', including ones this PR never touches.

Gates, on 8595e42, exit codes captured before any pipe:

gate	exit
check:control-bytes	0
changeset:check	0
check:doc-types	0
check:icon-record-names	0
check:docs-route-closure	0
check-changeset-presence.mjs	0

Gate family derived by hand from this repo's own package.json and .github/workflows/ — scripts/pm/dispatch-gates.mjs lives only in objectstack and would have answered about that tree.

Changeset. The presence gate's verdict line, verbatim:

✅ No source or published contract of a released package changed in this range, so no changeset is owed.

examples/schema-catalog is private: true, so the artifact is an empty-frontmatter changeset (.changeset/7072-catalog-menu-value-keys.md) — ⛔ not a patch bump, which would falsely claim a released package changed. Adding a test does not change that. ⛔ No skip-changeset label: in this repo that label is a historical mis-mint that no workflow reads.

Lint.pnpm exec eslint examples/schema-catalog/test/component-fixture-declared-keys.test.ts => EXIT 0, and --format json confirms the file was actually linted (0 errors, 0 warnings, no "File ignored" message) rather than silently skipped. The four JSON fixtures and the changeset carry no eslint configuration and report as ignored. Plain form; ⛔ no --no-inline-config.

Absorber check — #6810 is ruled, and it rules for this shape

The dispatch flagged #6810 as a possible absorber, expected to be undecided. It is not — it was ruled twice, and the second ruling adopted the middle state: narrow ratchet, ⛔ no general extractor, with option A (the family-wide sweep) 明确不采 and never-before-seen keys taking option C — 人手撞见、逐例修 + 补钉. So this card is not a row of a sweep; it is exactly the hand fix that ruling prescribes, and the pin above is its second half.

Filed, not fixed

• 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 #7101 — the same fixture authors variant: "destructive" on its Delete item; also undeclared on both arms and unread by all three renderers (dropdown-menu.tsx maps items with no spread). ⛔ Not a mechanical delete: shadcn's DropdownMenuItem really does ship a destructive variant, so "declare and render it" is a defensible opposite repair. That is the finding(examples): seven catalog badge nodes author their text under children, which ui:badge never reads — three demos draw nothing at all #6829 shape and needs a decision.
• finding(components): two menu icon tests transcribe catalog fixtures verbatim including the undeclared value key, so the phantom spelling survives #7072 as copyable example code #7102 — context-menu-item-icon.test.tsx:169-173 and dropdown-menu-item-icon.test.tsx:122-124 transcribe these fixtures inline includingvalue, so the phantom spelling survives this PR as copyable example code. Mechanical to fix, but in packages/components — a different package and gate family.

⛔ #7077 is not addressed here; its buttons[].value population is a different component family.

---

Generated by Claude Code

[os-warren]

Fixes#7072

Twenty-one menu items in the four overlay-menu catalog fixtures authored a value key that no arm of the shipped MenuItem union declares and no menu renderer reads. This deletes them, and pins that they stay gone.

Re-derived on current main, because the card's numbers were days old

The card measured at 592acafb; main is now 2c3cd1b. The count has not moved — 21, distributed exactly as the card's table claims:

fixture	value keys
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
total	21

Counted by a walker that classifies each value key by its position in the tree rather than by filename, so the neighbouring buttons[].value population (#7077, button-group) is separated by construction and cannot leak in. Catalog-wide the walker sees 288 objects carrying value before and 267 after — a delta of exactly 21, so nothing outside the four fixtures moved.

⚠️ One correction to the card: its cited line spans are slightly off. Re-derived, MenuCommandItem is packages/types/src/overlay.ts:363-401 (card said :363-400) and MenuDividerItem is :409-419 (card said :409-421).

The authority, re-verified

• MenuCommandItem (overlay.ts:363-401) declares label, icon, disabled, onClick, shortcut, children, separator?: false, type?: never. No value.
• MenuDividerItem (:409-419) declares separator: true, type?: never. No value.
• The three renderers under packages/components/src/renderers/overlay/ perform zero .value reads. Stated precisely, because it is not zero occurrences of the token: context-menu.tsx:95 contains { type: 'text', value: "Right click here" } — a write constructing a text node, whose renderer genuinely reads value. No menu item's value is ever read.
• 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 — 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. Nothing red covered this.

Deleted rather than declared: nothing reads value, and #6523 deliberately narrowed this union rather than widening it.

The pin — #6810's second half

#6810's ruling (2026-08-30, maintainer, verbatim「同意」) prescribes 逐例修 + 补钉 for a key this class has regenerated on: the case-by-case fix plus a named pin carrying its own counter-probe, in the existing component-fixture-declared-keys.test.ts ledger form. This PR now carries both halves.

⛔ Not a widening of #6249's menubar sweep — a new, separately named block. That sweep walks one node shape and its own header states that extending it to dropdown-menu / context-menu is "a separate verification surface this fix does not need"; it is untouched. value was authored across all three containers, so a menubar-scoped pin would have covered 11 of 21 while reading as though it covered the class, which is worse than no pin.

The new block sweeps the whole overlay-menu corpus — all three container shapes, including the deeper menus[].items[] nesting only menubar has, and submenu children:

• non-vacuity: 25 items (menubar 13 + context-menu 5 + dropdown 4 + with-icons 3), one representative position asserted per container shape, so a walker that stops matching a shape fails loudly instead of reporting a clean zero.
• the assertion: no overlay-menu item authors value, with label (21) and separator (4) as in-query controls, so an empty or unparsed corpus cannot masquerade as a pass.
• the counter-probe: ⛔ deliberately corpus-level, not schema-level. MenuItemSchema strips value and returns success, so a .safeParse probe is structurally blind here — it stayed green through all 21 authored keys. The probe re-authors value into a real fixture taken from the corpus and asserts the identical sweep reports it at the right position, with the untouched fixture clean alongside.

⭐ The pre-existing declared-key controls in the menubar block already fed {label, icon, disabled, shortcut, value} to MenuItemSchema and asserted only the first four survive. That pinned the type-level fact and was green the whole time the 21 keys sat in the corpus. The gap was only ever the corpus assertion.

Ablation — the pin demonstrably goes red. With "value": "profile" re-authored into basic-dropdown-menu.json on disk (mutation confirmed: value key count 0 → 1, injected text present, blob hash 7e72503b → ece5381c, still valid JSON), the suite fails:

× ... > no overlay-menu item authors `value`
AssertionError: expected [ Array(1) ] to deeply equal []
× ... > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture
AssertionError: expected [ 'pristine.items[0].value' ] to deeply equal []
Tests 2 failed | 34 passed (36)

The non-vacuity test stayed green throughout, correctly — a key was added, not an item. Restore leg proven rather than assumed: git checkout HEAD -- <abs path>, value count back to 0, blob hash matches the HEAD blob exactly, git diff HEAD empty.

Evidence

The diff is only what it claims. Every changed fixture line is one of: a removed "value": … line (21), or a "label" line re-punctuated because value had been the last key on that item (14 removed / 14 added, identical but for the trailing comma). No content changed. All four files round-trip byte-identically through JSON.stringify(…, null, 2), so the edit was made by parse-and-reserialise and the diff is minimal by construction.

Zero-hit control. After the deletion, value hits 0 in all four files while the control label still hits 14 / 4 / 4 / 4 in the same query — a zero for both would have meant the files were emptied, not fixed. Structure intact: menubar still has 13 items (2 separators, 11 labelled), matching the existing expect(items).toHaveLength(13) pin.

Rendered output is unchanged — which is the correct expectation here, the opposite of a fixture-content fix. The keys were inert, so the DOM must not move. Measured rather than assumed: a scratch harness rendered each dropdown fixture at 2c3cd1b and at this branch with defaultOpen: true injected (a closed menu renders only its trigger, which never carried the key, and would have made the comparison vacuous), normalised Radix's per-instance generated ids, and asserted identical HTML, text and [role="menuitem"] counts. Its control — mutating a key the renderer does read (label) — was required to produce a difference, and did. Scratch-only; not part of this diff.

⚠️Coverage of that DOM measurement, stated honestly: it directly covers the 6 items in the two dropdown-menu fixtures. menubar (11) and context-menu (4) cannot be forced open the same way — Radix opens them via a menubar value and a real right-click — so their inertness rests on the zero-read derivation above plus the corpus suites. My first attempt at this harness was discarded outright: without registering the renderers it fell back to a raw-JSON dump, and its control caught it.

Suites, on the final commit 8595e42:

pnpm exec vitest run \
examples/schema-catalog/test/component-fixture-declared-keys.test.ts \
examples/schema-catalog/test/safe-validate-corpus-6318.test.ts \
examples/schema-catalog/test/catalog-authored-key-6805-6806.test.tsx \
examples/schema-catalog/test/catalog-gallery-render.test.tsx
=> Test Files 4 passed (4) · Tests 659 passed (659) [RUN root: objectui-issue-7072]

659 = the prior 656 plus this PR's 3 new tests. Confirmed by name under --reporter=verbose rather than by an aggregate count:

✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > the sweep reaches all three container shapes and every one of their items — non-vacuity
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > no overlay-menu item authors `value`
✓ catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072) > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture

Run root-relative from the repo root, per #3378 — the RUN v4.1.10 /home/user/objectui-issue-7072 banner confirms it did not silently re-root onto apps/console.

Type-check.pnpm --filter @object-ui/example-schema-catalog type-check (the package spells it hyphenated) => EXIT 0, 0 errors, with the script body echoed (tsc --noEmit && tsc -p tsconfig.test.json) so a zero-match filter cannot pass for a green. ⚠️ The package's main tsconfig.jsonexcludes test/, so that green would say nothing about the new pin on its own; --listFiles confirms component-fixture-declared-keys.test.ts is really in the tsconfig.test.json program (889 files). The dependency closure was built first — before it, every test file in the package reported Cannot find module '@object-ui/types/zod', including ones this PR never touches.

Gates, on 8595e42, exit codes captured before any pipe:

gate	exit
check:control-bytes	0
changeset:check	0
check:doc-types	0
check:icon-record-names	0
check:docs-route-closure	0
check-changeset-presence.mjs	0

Gate family derived by hand from this repo's own package.json and .github/workflows/ — scripts/pm/dispatch-gates.mjs lives only in objectstack and would have answered about that tree.

Changeset. The presence gate's verdict line, verbatim:

✅ No source or published contract of a released package changed in this range, so no changeset is owed.

examples/schema-catalog is private: true, so the artifact is an empty-frontmatter changeset (.changeset/7072-catalog-menu-value-keys.md) — ⛔ not a patch bump, which would falsely claim a released package changed. Adding a test does not change that. ⛔ No skip-changeset label: in this repo that label is a historical mis-mint that no workflow reads.

Lint.pnpm exec eslint examples/schema-catalog/test/component-fixture-declared-keys.test.ts => EXIT 0, and --format json confirms the file was actually linted (0 errors, 0 warnings, no "File ignored" message) rather than silently skipped. The four JSON fixtures and the changeset carry no eslint configuration and report as ignored. Plain form; ⛔ no --no-inline-config.

Absorber check — #6810 is ruled, and it rules for this shape

The dispatch flagged #6810 as a possible absorber, expected to be undecided. It is not — it was ruled twice, and the second ruling adopted the middle state: narrow ratchet, ⛔ no general extractor, with option A (the family-wide sweep) 明确不采 and never-before-seen keys taking option C — 人手撞见、逐例修 + 补钉. So this card is not a row of a sweep; it is exactly the hand fix that ruling prescribes, and the pin above is its second half.

Filed, not fixed

• 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 #7101 — the same fixture authors variant: "destructive" on its Delete item; also undeclared on both arms and unread by all three renderers (dropdown-menu.tsx maps items with no spread). ⛔ Not a mechanical delete: shadcn's DropdownMenuItem really does ship a destructive variant, so "declare and render it" is a defensible opposite repair. That is the finding(examples): seven catalog badge nodes author their text under children, which ui:badge never reads — three demos draw nothing at all #6829 shape and needs a decision.
• finding(components): two menu icon tests transcribe catalog fixtures verbatim including the undeclared value key, so the phantom spelling survives #7072 as copyable example code #7102 — context-menu-item-icon.test.tsx:169-173 and dropdown-menu-item-icon.test.tsx:122-124 transcribe these fixtures inline includingvalue, so the phantom spelling survives this PR as copyable example code. Mechanical to fix, but in packages/components — a different package and gate family.

⛔ #7077 is not addressed here; its buttons[].value population is a different component family.

---

Generated by Claude Code