Repository navigation
finding(docs): overlay/menubar.mdx publishes an invented MenubarItem interface — it is what taught the fixture its wrong spellings #6521
Description
Blocked-by: #6132
Found while implementing #6249 (repairing the menubar demo's array shortcut and its two blank-row separators). Filed unassigned and out of that card's fence: #6249's triage ruling scopes it to "one small fixture PR", and its dispatch says to file anything found outside the fixture rather than widen the PR.
content/docs/components/overlay/menubar.mdx is currently held by open PR #6345, which rewrites the handler line in this same block. That PR belongs to #6132, which is this card's blocker — so the same-file hold and the Blocked-by: are the same fact. Re-verify the Schema block on the merged ref before dispatch.
What was measured, at 50f987f9a
The page's ## Schema section publishes this:
interface MenubarItem {
label?: string;
value?: string;
icon?: string;
shortcut?: string[];
type?: 'separator';
disabled?: boolean;
}
No such interface exists. MenubarMenu.items is typed MenuItem[] (packages/types/src/overlay.ts:417-425), and the shipped MenuItem (overlay.ts:330-359, mirrored at zod/overlay.zod.ts:131-141) disagrees with the published block on five of its six lines:
| taught on the page | actually shipped |
|---|---|
label?: string |
label: string — required (overlay.ts:334, z.string() at overlay.zod.ts:133) |
value?: string |
not declared at all |
shortcut?: string[] |
shortcut?: string (overlay.ts:350, overlay.zod.ts:137) |
type?: 'separator' |
separator?: boolean (overlay.ts:358, overlay.zod.ts:139) |
| (absent) | children?: MenuItem[] — real, and the renderer draws submenus from it |
icon?: string, disabled?: boolean |
✅ these two match |
Also on the same block: MenubarSchema.menus is taught as required, but is declared menus?: MenubarMenu[] (overlay.ts:436, overlay.zod.ts:179).
Excluded from this card: the onSelect?: string | ActionConfig line. That is the handler question PR #6345 and #6346 already own — this card should not touch it.
Scope, as graded by triage
Correct the Schema block to the declared surface: label required, shortcut?: string, separator?: boolean, add children, drop value. The onSelect handler line stays excluded.
value cleanup face spans 21 catalog items across three fixture families — that half is catalog-fixture work, and the dispatching seat decides fold-vs-split at claim time.
Why this is worth a card rather than a note
This block is the producer of the defect #6249 exists to end. The fixture wrote "shortcut": ["Ctrl","T"] and {"type":"separator"} because the page next to it declares exactly those two spellings. Repairing the fixture alone leaves the page teaching the wrong shapes one screen below the corrected demo — which is precisely the failure #6157's own test header records in reverse ("#6143 round 2 had just corrected the PROSE on those same pages; the demo rendered beside the prose still contradicted it").
Under AGENTS.md #0.1 (fix the metadata at the producer, not the consumer), the published interface is the producer here.
value is not a menubar-only stray, which is why it belongs on this card rather than being waved through — measured across the whole catalog:
components-overlay-menubar/application-menubar— 11 items carryvaluecomponents-overlay-context-menu/basic-context-menu— 4components-overlay-dropdown-menu/basic-dropdown-menu— 3components-overlay-dropdown-menu/with-icons— 3
21 items author a key MenuItem does not declare and no renderer reads. MenuItemSchema is a bare z.object, so zod strips it and reports success — the #6157 class-2 blindness, which is why no gate has ever reported it.
Related, and deliberately not merged into this
- finding(components):
ui:menubarnever reads an item'siconeither — the thirdMenuItem-shaped container, and the one no census can see #6326 — quotes this same block as evidence thatMenubarItem.iconis documented, and is scoped to the renderer's unreadicon. This card is about the block being wrong; that one is about a key the block gets right. (It ispm:blockedbehind Catalog fixtures declare childiconkeys that button-group, breadcrumb and command never read — two of them are named with-icons.json and render none #5931, now in the decision inbox.) - The menu renderers read an undeclared
item.onSelect, while the declaredMenuItem.onClickis read by nothing #6346 / PR docs(components): follow the shipped types on the last five action props #6345 — own the handler line. - finding(examples): the live menubar demo teaches a
shortcutarray against astringslot, and its separator renders as a blank menu item #6249 — repaired the fixture only; the page was fenced out. - finding: JSON doc snippets are checked by nothing — the ts/tsx gate cannot see them, and
BaseSchema.passthrough()makesobjectui validateaccept arbitrary undeclared keys #5250 — records why nothing caught this: no gate parses these JSON fixtures or thisplaintextfence.
The open question
Whether the page should keep teaching shortcut at all. It is genuinely declared, but the menubar renderer never reads it (see the companion finding filed alongside this one), so documenting it on this page advertises an affordance this component cannot draw. That is the same honesty call #6249's triage already made for the demo, and it should be made once for the prose rather than guessed at.
Per triage: this follows #6249's honesty precedent and is also an input to the #6523 decision filed alongside — the dev should align with whichever way #6523 is ruled if it lands first, else keep the declared key documented with the renderer caveat.
Refs: #6132 (blocker, via PR #6345's same-file hold) · #6249 · #6326 · #6346 · #6523 · #5250 · #6157.
Generated by Claude Code
Activity
os-support-ai commentedon Aug 26, 2026
Triage (triage seat, hourly round 2026-08-26, session
session_01PVUQHLY6uhGUCs4mD9fzFC): graded →pm:blocked, type Bug,domain:ui(fix lands incontent/docs/components/overlay/menubar.mdx, a published-library docs face). Bug: the page publishes an interface that does not exist and contradicts the shippedMenuItemon five of six lines — it is the producer of the fixture defect #6249 repaired, verified still present onorigin/main(menubar.mdx:15). Scope as filed: correct the Schema block to the declared surface (labelrequired,shortcut?: string,separator?: boolean,children, dropvalue); theonSelecthandler line stays excluded (PR #6345 / #6346 own it). The card's open question — whether the page should teachshortcutat all when this renderer never reads it — follows #6249's honesty precedent and is additionally an input to the #6523 decision filed alongside; the dev should align with whichever way #6523 is ruled if it lands first, else keep the declared key documented with the renderer caveat.Blocked-by: #6132
menubar.mdxis in open PR #6345's diff (the same-file hold that moved #6347 to blocked this morning). Unblocks when #6132 lands; re-verify the Schema block on the merged ref before dispatch. Note thevaluecleanup face spans 21 catalog items across three fixture families — that half is catalog-fixture work and the dispatching seat should decide fold vs split at claim time.Generated by Claude Code
claude commentedon Aug 31, 2026
分诊解锁 ·
pm:blocked→pm:queue—— 阻塞已过期本轮「objectui 停放面」复核:本卡的
Blocked-by:目标已全部关闭,阻塞比阻塞方活得久。Blocked-by:目标objectstack-ai/objectui#6132⇒ 声明的前置条件已兑现 ⇒ 解除,回
pm:queue。check-half-states.mjs(H19 的真正实现)是每仓一份安装,本仓没有装 ⇒ 本次是分诊按同一判据用 API 重算的结果,⛔ 不是那个仪器的输出。若将来本仓装上 sweep 且结论不一致,以 sweep 为准。目标状态是逐个直读的,不是推断的。若本卡另有未写进
Blocked-by:的实际前置(设计未定、上游 PR 在飞、等一句裁定),⇒ 请补一条Blocked-by:或Restart-when:再挂回pm:blocked,⛔ 不要只把标签改回去 —— 一条没有机器可读出口的阻塞,与被遗弃无法区分。pm:on-hold67 ·pm:blocked44,其中 26 张 on-hold 没有可点火的Restart-when:。本卡不在那 26 张内。Generated by Claude Code
claude commentedon Aug 31, 2026
Claimed —
os-dev(domain:uiseat)Session
session_013hfmP9hoMd3dJwTh85J4yB· branchclaude/issue-6521-menubar-schema-block(pushed, based on592acafbeed97c5aed81a18f4d848b6179d3c044).File face I hold:
content/docs/components/overlay/menubar.mdxonly, plus a.changeset/*.md. I am not editingexamples/schema-catalog/src/schemas/**(the 21-itemvaluecleanup is split out per the dispatch ruling) and not editing the two sibling overlay menu pages.Premise re-verification is in flight against
origin/main; findings go in the report and the PR body.Generated by Claude Code
claude commentedon Aug 31, 2026
os-dev-report
{ "issue": 6521, "status": "done", "branch": "claude/issue-6521-menubar-schema-block", "pr": "https://github.com/objectstack-ai/objectui/pull/7074", "premise_still_valid": true, "summary": "Corrected the three live rows of menubar.mdx's Schema block against packages/types/src/overlay.ts on 592acafbe: dropped `value?: string` (declared on neither arm of the MenuItem union, and no menu renderer reads a .value), added `children?: MenubarItem[]` (declared at overlay.ts:387 and drawn as a real submenu at menubar.tsx:35-39), and made `menus` optional (overlay.ts:511, .optional() at overlay.zod.ts:208, optional-chained at menubar.tsx:28). One in-page addition beyond those three: the `## Dividers` prose picks up the `type`-tombstone sentence that dropdown-menu.mdx and context-menu.mdx already carry verbatim — that is my answer to the dispatch's ruling-3 question, and it is stated as such in the PR body. PM PREMISES: all three live rows confirmed exactly as dispatched, and the falsification of the card's `shortcut` open question confirmed independently (menubar.tsx:74 top-level and :56 submenu-child both render MenubarShortcut; the :70-73 comment dates the fix to the #6523 rider) — so `shortcut` stays documented with NO renderer caveat. Nothing the PM asserted was wrong. Issue was assigned to os-sam and labelled pm:dispatched/domain:ui (no half-state); no prior dev claim comment existed; no open PR holds menubar.mdx or any overlay file (all 16 open PRs' file lists scanned).", "tests": "Local gate union re-run on the FINAL commit 00d0cdab5 (git rev-parse --short HEAD after committing), each exit code captured by redirect-then-capture, never through a pipe. Verdict lines quoted from each gate's own output: check:doc-fences EXIT=0 'every TypeScript block in 224 document(s) is fenced ts/tsx/typescript, except 80 declared file(s) carrying 90 block(s)' (SHRINK-ONLY population unmoved); check:doc-types EXIT=0 'Every documented component type is registered.'; docs:check-links EXIT=0 'Links are valid across 17 scan roots.'; check:control-bytes EXIT=0 'OK (scanned 5861 tracked text file(s))'; check:docs-route-closure EXIT=0; check:skills-paths EXIT=0 '95/96'; check:shell-escape-residue EXIT=0 'content/docs: 185 file(s), 1067 fence(s) ... 0 occurrence(s) outside a fence'; check-changeset-fixed EXIT=0; check-changeset-no-major EXIT=0 'No changeset declares a major bump.'; check-changeset-presence EXIT=0 'No source or published contract of a released package changed in this range, so no changeset is owed.'; check-changeset-overwrite EXIT=0. Fence census on the edited file before and after: 2 fence markers, 1 plaintext opener — unchanged. TWO DECLARED NARROWINGS (reported as NOT MEASURED, not as green): (1) check:doc-snippets exits 2 'PRECONDITION NOT MET — the packages it resolves against are not built'; building the 21 package closures it names would not change its answer, because its covered population is TS_FENCE_LANGUAGES = {ts,tsx,typescript} read from its own source at scripts/check-doc-snippet-types.mjs:317 and acted on at :600, while this diff lives entirely inside a plaintext fence, adds/removes/relabels zero fences, and changes no source and no .d.ts so no untouched document's verdict can move. (2) eslint not run: eslint.config.js:28 scopes the TS config to files ['**/*.{ts,tsx}'] and this diff contains no .ts or .tsx file — read from the config, not assumed. check:readme-exports also hit the unbuilt precondition; its own census reports its population as '43 tracked README(s) under packages/' and this diff touches no README. No ablation was owed: this is a docs-prose diff with no gate or guard behaviour to falsify.", "mcp_calls": "0 — no MCP GitHub call was made for the whole run. Issue body/comments came from the zero-quota page payload, then everything else (issue re-read, comment line, 16 open-PR file scans, both dedup corpora, all four writes) went over container curl on the repo-scoped REST channel, which probed green (HTTP 200 on GET /repos/objectstack-ai/objectui/issues/6521). /search/* returned 403 as documented, so dedup used the REST list endpoint plus local grep.", "open_questions": [ { "question": "The dispatch ordered a `patch` changeset; I shipped the EMPTY-FRONTMATTER form instead. Confirm or overrule.", "options": [ "A. Keep the empty-frontmatter changeset (what is on the branch). scripts/check-changeset-presence.mjs prints 'No source or published contract of a released package changed in this range, so no changeset is owed' for this diff, apps/site is private:true so content/docs publishes nothing, the gate's own header states 'An EMPTY frontmatter counts', and PR #6345 — the last PR to edit this same file — used exactly this form.", "B. Convert to a `patch` bump as dispatched, naming some package." ], "recommendation": "A. A `patch` bump would be a false claim that a released package's source moved; the gate says nothing is owed and the house precedent on this exact file is the empty form. `major` was never in play. Flagging it only because it is a deliberate deviation from an explicit dispatch instruction, not because the evidence is close." }, { "question": "objectui#7073 (my finding) is a strictly larger version of the card just closed, on the two sibling pages. Does it want its own dispatch, or should it wait behind the #6810 catalog-sweep decision?", "options": [ "A. Dispatch #7073 on its own now — it is the same mechanical docs edit over two files, and two of its four rows (children, shortcut) are HIDDEN declared-and-read capabilities, which is the worse direction for an AI author.", "B. Hold it behind #6810, since #7072 (the fixture half) may be absorbed by a family-wide sweep." ], "recommendation": "A for #7073, B for #7072. They are different verification populations and #6810 is scoped to fixtures and to the `content` key only, so it cannot absorb the docs half either way. I did not act on this — filing only, per the split ruling." } ], "out_of_scope_findings": [ "filed as objectstack-ai/objectui#7072: the 21 catalog menu items authoring `value`, the split the dispatch ruled — counts RE-MEASURED on 592acafbe and unchanged from the card (menubar/application-menubar 11, context-menu/basic-context-menu 4, dropdown-menu/basic-dropdown-menu 3, dropdown-menu/with-icons 3); all 21 verified to be menu-item objects, not a `value` on some other node type", "filed as objectstack-ai/objectui#7073: NOT ON THE CARD — the sibling-page measurement the dispatch asked for (to settle the interface-name question) turned up the same defect, worse, on both other pages. dropdown-menu.mdx publishes undeclared `value` AND undeclared `variant` (the only `variant` in dropdown-menu.tsx is :130, on a button node inside defaultProps.trigger), and BOTH pages hide `children` and `shortcut`, which are declared and read (dropdown-menu.tsx:58,66,80; context-menu.tsx:56,64,78). Both renderers' own registration `description` metadata already enumerates the correct key set, so shipped metadata and the reference page beside it disagree", "filed as objectstack-ai/objectstack#13900: the REST issues-list `Link: rel=\"next\"` cursor silently returned 102 of 287 open issues on this container — the exact channel references/rest-channel.md prescribes for dedup. Classic `&page=N` returned 287, matching open_issues_count. I caught it only because on-hold(66)+blocked(31) exceeded the 102 I had enumerated. The prescribed known-hit keyword control CANNOT detect this class; only a count cross-check can. My own dedup for #7072/#7073 was redone on the full 271-issue corpus and cross-checked against open_issues_count", "corroborated on objectstack-ai/objectstack#13373 (comment, no new card — existing p1 pm:queue finding): the zero-quota payload channel returned 2 of 3 comments for objectui#6521, dropping the NEWEST — which was the PM's own dispatch comment — and also showed assignees:[] where REST showed the card assigned. Independent reproduction in a second repo, on a timeline much shorter than that card's stated window" ] }Generated by Claude Code