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

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

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

The defect

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

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

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

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

The authority

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

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

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

Why nothing red covers it

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

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

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

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

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

Suggested repair

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

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

Generated by Claude Code

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

ZONE 1 — RULING (⛔ not re-adjudicable)

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

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

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

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

Zero-hit discipline

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

⚠️ One absorber to check first

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

Premise-first

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

Generated by Claude Code

🔒 Claimed by the `os-dev` seat

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

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

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

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

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

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

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

Generated by Claude Code

os-dev-report

{
  "issue": 7072,
  "status": "done",
  "branch": "claude/issue-7072-catalog-menu-value-keys",
  "pr": "https://github.com/objectstack-ai/objectui/pull/7103",
  "premise_still_valid": true,
  "base": "2c3cd1b7572a8aca2958da3551c990164186c9c1",
  "final_head": "d421fc8",
  "files_changed": [
    "examples/schema-catalog/src/schemas/components-overlay-menubar/application-menubar.json",
    "examples/schema-catalog/src/schemas/components-overlay-context-menu/basic-context-menu.json",
    "examples/schema-catalog/src/schemas/components-overlay-dropdown-menu/basic-dropdown-menu.json",
    "examples/schema-catalog/src/schemas/components-overlay-dropdown-menu/with-icons.json",
    ".changeset/7072-catalog-menu-value-keys.md"
  ],
  "occurrence_counts": {
    "before": { "menubar/application-menubar": 11, "context-menu/basic-context-menu": 4, "dropdown-menu/basic-dropdown-menu": 3, "dropdown-menu/with-icons": 3, "total": 21 },
    "after": { "total": 0 },
    "count_moved_since_card": false,
    "catalog_wide_value_objects_before_after": [288, 267],
    "delta": 21,
    "note": "Card measured at 592acafb; re-counted on 2c3cd1b. Distribution identical, file for file. Catalog-wide delta is exactly 21, so nothing outside the four fixtures moved. Counted by tree POSITION, not filename, so the #7077 button-group population is separated by construction (its files appear in the catalog-wide list and are untouched)."
  },
  "authority_reverified": {
    "MenuCommandItem": "packages/types/src/overlay.ts:363-401 — label, icon, disabled, onClick, shortcut, children, separator?: false, type?: never. No value.",
    "MenuDividerItem": "packages/types/src/overlay.ts:409-419 — separator: true, type?: never. No value.",
    "card_line_numbers_drifted": "YES, slightly: card cited :363-400 and :409-421; re-derived spans are :363-401 and :409-419.",
    "renderer_value_reads": "ZERO .value reads in menubar.tsx / dropdown-menu.tsx / context-menu.tsx. Precisely: menubar.tsx and dropdown-menu.tsx contain zero occurrences of the token; context-menu.tsx:95 has ONE occurrence, a WRITE constructing a fallback text node ({ type: 'text', value: 'Right click here' }) whose own renderer does read value. No menu item's value is read anywhere.",
    "no_spread": "dropdown-menu.tsx:47-80 maps items reading separator/icon/children/label/disabled/onClick/shortcut explicitly — no object spread, so an undeclared key cannot reach the DOM incidentally.",
    "zod": "MenuItemSchema packages/types/src/zod/overlay.zod.ts:147-168 — bare non-strict z.objects on both arms, so value is stripped and parse reports success (#5250 blindness)."
  },
  "sanitizer_check": "CHECKED. Card body is INTACT — every section present, occurrence table closes on its 21 total, Refs line and signature footer both survive; no truncation. The pervasive ampersand-hash entity spellings are the sanitizer's quote escaping, not loss. PR #7103 body also read back in full after creation: intact through the footer, and the single angle-bracket shape in it survived escaped rather than eaten.",
  "absorber_check_6810": "DECISIVE, and it resolves toward proceeding. #6810 is NOT undecided as the dispatch expected — it was ruled twice. Second ruling (comment 5469403582, 2026-08-30, maintainer, verbatim agreement) adopted the middle state: narrow ratchet, explicitly NO general extractor; option A (family-wide sweep) refused in as many words; never-before-seen keys take option C — hand rediscovery, case-by-case fix PLUS a pin. My stop-condition was 'ruled toward a family-wide sweep'; the ruling went the opposite way, so this card is not absorbed — it is exactly the hand fix that ruling prescribes.",
  "summary": "Deleted the 21 inert `value` keys from the four overlay-menu catalog fixtures (menubar 11, context-menu 4, dropdown-menu 3, with-icons 3), re-counted on current main 2c3cd1b rather than trusting the card's 592acafb figures. The count had NOT moved. Edit was made by JSON parse-and-reserialise after proving all four files round-trip byte-identically, so the diff is minimal by construction: 21 value lines removed plus 14 label lines re-punctuated (trailing comma dropped where value had been last), no content altered. Fixtures only — no type, no zod mirror, no renderer, as ruled. The `+ pin` half of #6810's ruling is deliberately NOT included and is flagged below as the one thing I did not do.",
  "tests": "All figures below are from the FINAL commit d421fc8 unless stated. Exit codes captured by redirect-then-capture, never across a pipe. (1) SUITES, root-relative from repo root per #3378: `pnpm exec vitest run examples/schema-catalog/test/{component-fixture-declared-keys.test.ts,safe-validate-corpus-6318.test.ts,catalog-authored-key-6805-6806.test.tsx,catalog-gallery-render.test.tsx} --maxWorkers=2` => 'Test Files 4 passed (4) · Tests 656 passed (656)', EXIT=0, and the banner 'RUN v4.1.10 /home/user/objectui-issue-7072' confirms it did NOT silently re-root onto apps/console. (2) GATES, each EXIT=0 on d421fc8: check:control-bytes ('OK (scanned 5883 tracked text files; skipped 85 binary)'), changeset:check ('All workspace packages are in the changeset fixed group' + 'No changeset declares a major bump'), check:doc-types ('Every documented component type is registered'), check:icon-record-names ('OK lucide icon names: 182 authored/declared names ... are live icons keys'), check:docs-route-closure. (3) CHANGESET, 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 I added an EMPTY-FRONTMATTER changeset, not a patch bump; presence gate then reported '5 file(s) changed ... 1 changeset(s) added', EXIT=0. No skip-changeset label applied (in objectui that label is a historical mis-mint no workflow reads). (4) ZERO-HIT CONTROL: after deletion `value` hits 0 in all four files while the control `label` still hits 14/4/4/4 in the same query — both at zero would have meant emptied files, not fixed ones. Structure intact: menubar still 13 items / 2 separators / 11 labelled, which is what the pre-existing `expect(items).toHaveLength(13)` pin asserts. (5) RENDER EQUIVALENCE — the reading I used: rendered output UNCHANGED, the correct expectation here because the keys are inert (opposite of a fixture-content fix). Measured, not assumed: a scratch harness rendered each dropdown fixture at BASE and at HEAD with defaultOpen:true injected (a closed menu renders only its trigger, which never carried the key — the comparison would have been vacuous), normalised Radix per-instance ids, and asserted identical HTML, textContent and role=menuitem counts; its CONTROL, mutating the READ key `label`, was required to differ and did. COVERAGE STATED HONESTLY: that DOM measurement directly covers only the 6 items in the two dropdown fixtures; menubar (11) and context-menu (4) cannot be forced open that way (Radix needs a menubar value / a real right-click), so their inertness rests on the zero-read derivation plus the corpus suites. TWO NEGATIVE RESULTS REPORTED AS SUCH: my first harness lacked the component-registration side-effect import and fell back to a raw-JSON PRE dump — its control caught it; and an earlier version read the HEAD side via `git show :path`, which reads the INDEX, and with the fixture edits unstaged would have compared BASE against itself and passed vacuously. Both were fixed before any number was banked. Scratch harness was deleted and unstaged; final diff is 5 files, verified. (6) LINT, proven narrowing not a skip: the diff contains zero JS/TS files; `eslint --format json` over the changed .json and .md reports 2 files / 0 real messages, each 'File ignored because no matching configuration was supplied' — population read from eslint's OWN config, count read from --format json, and no eslint config was touched so no untouched file's verdict can move. Plain form, no --no-inline-config. (7) NOT RUN, declared: packages/components suites. The two menu icon tests reference these fixtures but by INLINE LITERAL, not by reading the files, so they cannot be affected by this diff — that is also why they are finding #7102 rather than a breakage. Gate family was derived BY HAND from objectui's own package.json and .github/workflows/, because scripts/pm/dispatch-gates.mjs lives only in objectstack and would have answered about that tree.",
  "mcp_calls": "12 — REST was 403 for this seat on a repo-scoped probe (GET /repos/.../issues/7072) and `gh` is absent, so ALL issue/PR reads and writes went through MCP: 4 reads (#7072 get + comments, #6810 get + comments), 1 targeted search_issues for dedup (non-vacuous: 8 hits including this card and the whole menu family), 2 issue_write creates (#7101, #7102), 1 create_pull_request, 1 pull_request_read (body read-back), 3 add_issue_comment (claim, this report, and its read-back). No wide-table scans, no full pagination.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #7101: the same with-icons.json fixture authors `variant: \"destructive\"` on its Delete item — undeclared on both MenuItem arms, unread by all three renderers (dropdown-menu.tsx maps items with NO spread). NOT fixed here on purpose: unlike `value` this has a genuine fork, because shadcn's DropdownMenuItem really does ship a destructive variant, so 'declare and render it' is a defensible opposite repair. That is the #6829 shape and needs a decision, and this card's ZONE 1 says a type change is a fork — stop and report.",
    "filed as #7102: context-menu-item-icon.test.tsx:169-173 and dropdown-menu-item-icon.test.tsx:122-124 transcribe these fixtures inline INCLUDING `value`, so the phantom spelling survives this PR as copyable example code and their comments ('the basic-context-menu.json catalog fixture') become false once this lands. Mechanical to fix, but it sits in packages/components — a different vitest project and gate family, outside this card's declared file surface.",
    "NOT FILED, escalated to PM instead — the `+ pin` half of #6810's ruling is missing for this key. That ruling prescribes case-by-case fix PLUS a named pin with a counter-probe, and this PR delivers only the fix, so nothing goes red if `value` is re-authored tomorrow. I did not take it unilaterally for two reasons: (a) this card's fence is the four fixtures under src/schemas/, and the pin's home is a test file; (b) more substantively, the natural home — the menubar sweep in component-fixture-declared-keys.test.ts — documents in its OWN header that it stays menubar-scoped deliberately and that widening it to the dropdown-menu/context-menu families is 'a separate verification surface this fix does not need'. A menubar-only pin would cover 11 of 21 while reading as though it covered all of them, which is worse than none. PM's call whether to widen the fence or queue it separately. Useful datum for whoever takes it: component-fixture-declared-keys.test.ts ALREADY uses `value` as its negative control at the schema level (it feeds {label,icon,disabled,shortcut,value} to MenuItemSchema and asserts only the first four survive), so the type-level fact is pinned already — the gap is purely the CORPUS assertion."
  ]
}

Generated by Claude Code

ACCEPT WITH FOLLOW-UP — PR #7103. The fix is right; the ruling's second half is owed, and the dev was right to escalate rather than take it.

domain:ui seat, session session_012wwHa4aaFybxXrfmfHioDM. Reviewed against GitHub and origin/main, ⛔ not against the report's self-description.

⛔ First: my dispatch order's stop-condition pointed the wrong way, and the dev checked anyway

I wrote "#6810 … still undecided (which I expect)" and set the stop-condition as "if it has since been ruled toward a family-wide sweep, stop."

#6810 was ruled twice, and the second ruling went the opposite direction from the one I fenced against. I verified it myself rather than relaying — comment 5469403582, 2026-08-30, maintainer, verbatim「同意」:

对「已再生过的键 × 类型对」逐对钉死 … 落点沿用既有 component-fixture-declared-keys.test.ts 的具名钉形制(每钉带反探针)

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

⇒ Option A (the sweep I told you to stop for) was refused in as many words. And the prescription for a newly-rediscovered key is fix + pin, not fix.

⭐ A stop-condition written against the wrong branch is worse than none, because it reads as though the space was covered. The only reason it cost nothing is that the dev read the ruling instead of pattern-matching my sentence.

What I verified independently

claim	my reading on the PR branch
all 21 `value` keys gone from the four fixtures	✅ 0 hits across all four
control — `label` must still hit	✅ 14 (menubar) / 4 (context-menu)
scope held	✅ 5 files: the four fixtures + changeset. ⛔ No type, no zod mirror, no renderer
count had not moved since the card	✅ distribution identical file-for-file; catalog-wide `value` objects 288 → 267, delta exactly 21, so nothing outside the four fixtures moved

⭐ Counting by tree position rather than filename is what keeps #7077's button-group population out by construction rather than by care — its files are in the catalog-wide figure and untouched.

⭐ The render-equivalence reading, and two negative results reported rather than buried

The expectation here is unchanged output — the opposite of a fixture-content fix — and that is the easy thing to assert without measuring. It was measured instead: both dropdown fixtures rendered at BASE and HEAD with defaultOpen: true injected (⭐ because a closed menu renders only its trigger, which never carried the key — the comparison would have been vacuous), Radix per-instance ids normalised, and the control mutating the read key label was required to differ and did.

And the coverage is stated honestly rather than overclaimed: the DOM measurement covers the 6 items in the two dropdown fixtures; menubar (11) and context-menu (4) cannot be forced open that way, so their inertness rests on the zero-read derivation plus the corpus suites.

Two failures caught by controls before any number was banked:

A first harness lacked the component-registration side-effect import and fell back to a raw-JSON dump — its control caught it.
An earlier version read the HEAD side via git show :path, which reads the index; with the fixture edits unstaged it would have compared BASE against itself and passed vacuously.

⇒ That second one is the sharpest thing in this report. A vacuous pass is indistinguishable from a real one from the outside.

✅ Housekeeping

Empty-frontmatter changeset with the gate's verdict line quoted · vitest root-relative with the RUN v4.1.10 /home/user/objectui-issue-7072 banner proving no re-root onto apps/console · eslint plain form, narrowing proven from eslint's own config (the diff has zero JS/TS files) · #7101 and #7102 filed and correctly not folded in.

⭐ Deriving the gate family by hand from objectui's own package.json and .github/workflows/ — because dispatch-gates.mjs lives only in objectstack and would have answered about that tree — is the right call and the kind of thing that usually goes unnoticed.

The follow-up, and the fence extension that unblocks it

The ruling's pin half is owed. Your two reasons for not taking it unilaterally were both good, and they get different answers:

(b) upheld. ⛔ Do not widen the menubar sweep. You are right that a menubar-only pin covers 11 of 21 while reading as though it covered all — worse than none — and that the sweep's own header declares it deliberately menubar-scoped.
(a) resolved — I am extending the fence. My order fenced you to src/schemas/, and you correctly refused to write a test outside it. ⇒ The fence is now examples/schema-catalog/, the same package including its test/ directory. That is my scope decision and it is on the record.

⇒ Patch round sent: a separately named corpus pin over all four overlay-menu fixtures, carrying a counter-probe that goes red when value is reintroduced into a fixture. ⭐ Your own datum sharpens what is missing: the file already uses value as a negative control at the schema level, so the type-level fact is pinned — the gap is purely the corpus assertion.

⛔ PR stays draft until that lands. ⚠️ #7102 becomes live the moment #7103 merges (two test comments naming these fixtures go false), so it wants picking up promptly — but it is packages/components, a different package and gate family, and stays its own card.

Generated by Claude Code

os-dev-report

Addendum — patch round. Delta only; ⛔ not restating the accepted parts.

{
  "issue": 7072,
  "round": "patch-1 (pin half of the #6810 ruling, on PM's extended fence)",
  "status": "done",
  "branch": "claude/issue-7072-catalog-menu-value-keys",
  "pr": "https://github.com/objectstack-ai/objectui/pull/7103",
  "head_before": "d421fc8",
  "head_now": "8595e42",
  "files_changed_this_round": ["examples/schema-catalog/test/component-fixture-declared-keys.test.ts (+146)"],
  "fence": "Extended by PM to examples/schema-catalog/ including test/. Stayed inside it: the only file touched this round is that package's test file. ⛔ #6249's menubar sweep NOT touched and NOT widened, per your upheld objection (b).",
  "pin_added": {
    "location": "examples/schema-catalog/test/component-fixture-declared-keys.test.ts, new describe block appended",
    "name": "catalog corpus: no overlay-menu item authors the undeclared `value` key (objectui#7072)",
    "named_for_its_population": "Named 'overlay-menu', not 'menubar'. Its header states in full why it is a SEPARATE block rather than a widening — #6249's sweep walks one node shape and its own header calls extending it to dropdown-menu/context-menu 'a separate verification surface this fix does not need' — and why a menubar-only pin would have been worse than none (11 of 21, reading as though it covered the class).",
    "population_measured": "The overlay-menu corpus is exactly 4 containers across the 4 fixtures (menubar 1, dropdown-menu 2, context-menu 1) holding 25 items total: 21 labelled, 4 separators. Measured over all 433 catalog fixtures, so the block covers the complete population, not a sample.",
    "tests": [
      "non-vacuity: items.toHaveLength(25) + one representative position asserted per container shape, including the deeper menus[].items[] nesting only menubar has, so a walker that stops matching a shape fails loudly instead of returning a clean zero",
      "the assertion: no overlay-menu item authors `value`, with in-query controls label=21 and separator=4 so an empty or unparsed corpus cannot masquerade as a pass",
      "counter-probe (corpus-level, NOT schema-level)"
    ]
  },
  "counter_probe": "⛔ Deliberately not a .safeParse probe. MenuItemSchema strips `value` and returns success, so a schema-level probe is structurally blind to this defect — it was green the entire time all 21 keys sat in the corpus, which is exactly your point that the type-level fact was already pinned and the CORPUS assertion was the gap. The probe instead deep-clones a REAL fixture from the corpus the pin judges (basic-dropdown-menu), re-authors `value` into items[0], runs the identical collector, and asserts it is reported at the exact position ('counter-probe.items[0].value'); it then asserts the untouched fixture at the same position is clean and that both walks return the same item count, so the probe cannot pass by always reporting a hit.",
  "ablation_pin_goes_red": "Ran on disk, not argued. Committed the pin FIRST (8595e42) so the restore leg had a correct reference. MUTATION PROVEN ON DISK before the run: `value` key count 0 -> 1 in basic-dropdown-menu.json, injected text '\"value\": \"profile\"' present (grep -c = 1), blob hash 7e72503b -> ece5381c, file still valid JSON. RESULT, EXIT=1: '× no overlay-menu item authors `value` — AssertionError: expected [ Array(1) ] to deeply equal []' and '× counter-probe: ... — AssertionError: expected [ \\'pristine.items[0].value\\' ] to deeply equal []' (the probe's own pristine leg correctly detected that its control fixture was no longer pristine, which is evidence it reads the real corpus rather than a hardcoded copy); 'Tests 2 failed | 34 passed (36)'. The non-vacuity test stayed GREEN throughout, correctly — a key was added, not an item. RESTORE LEG PROVEN, not assumed: git checkout HEAD -- ABSOLUTE_PATH, then `value` count back to 0, blob hash equals the HEAD blob hash exactly, and git diff HEAD empty. A trap on EXIT INT TERM guarded the mutation window.",
  "verbose_by_name": "Confirmed by name under --reporter=verbose, since an aggregate count does not prove a specific new test ran: '✓ 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', '✓ ... > no overlay-menu item authors `value`', '✓ ... > counter-probe: the same sweep DOES flag a `value` key put back into a real fixture'.",
  "reruns": "SUITES, root-relative from repo root, EXIT=0: the same four files => 'Test Files 4 passed (4) · Tests 659 passed (659)', banner 'RUN v4.1.10 /home/user/objectui-issue-7072' confirming no re-root onto apps/console. 659 = the prior 656 plus exactly these 3 new tests. GATES on 8595e42, all EXIT=0: check:control-bytes, changeset:check, check:doc-types, check:icon-record-names, check:docs-route-closure, check-changeset-presence.mjs (now '6 file(s) changed ... 1 changeset(s) added', same verdict line: 'No source or published contract of a released package changed in this range, so no changeset is owed.'). CHANGESET left empty-frontmatter as instructed.",
  "new_surface_this_round": "The diff now contains a .ts file, so two checks that were empty last round are no longer empty and were run rather than carried over. LINT: eslint plain form on the test file EXIT=0, and --format json confirms it was ACTUALLY linted (0 errors, 0 warnings, no 'File ignored' message) rather than skipped. TYPE-CHECK: `pnpm --filter @object-ui/example-schema-catalog type-check` EXIT=0 with the script body echoed ('tsc --noEmit && tsc -p tsconfig.test.json') so a zero-match filter cannot read as a green — the package spells it hyphenated, the named trap. ⚠️ NOT MEASURED trap avoided: the package's main tsconfig.json EXCLUDES test/, so that green alone would say nothing about the new pin; --listFiles confirms component-fixture-declared-keys.test.ts is genuinely in the tsconfig.test.json program (889 files). The dependency closure had to be built first — before it every test file in the package, including ones this PR never touches, reported 'Cannot find module @object-ui/types/zod', which reads exactly like a break I caused and is not one.",
  "pr_body_updated": "YES, and flagging it because it was not requested. The body carried a section asserting the pin half was deliberately NOT in this PR; that became false this round, so leaving it would have misled the reviewer. Rewritten to describe the pin, its counter-probe and the ablation. Per known platform behaviour the PATCH downgraded the signature footer from session-URL to bare form; the session URL survives in my claim comment and in the first report comment.",
  "not_done": "⛔ #7101 and #7102 not folded in, as instructed — #7101 is a genuine fork (shadcn ships a destructive item variant, so 'declare and render it' is defensible) and stays a decision; #7102 lives in packages/components, a different package and gate family, and stays its own card. PR remains DRAFT; no force-push; #6249's menubar sweep untouched.",
  "mcp_calls_this_round": "3 — 1 update_pull_request (body correction), 1 add_issue_comment (this addendum), 1 read-back of it. Running total for the card: 16."
}

Generated by Claude Code

ACCEPT — patch round discharges the ruling's pin half. PR #7103 is complete; landing on CI.

domain:ui seat, session session_012wwHa4aaFybxXrfmfHioDM. Verified against the branch at 8595e42, ⛔ not against the report.

What I checked myself

claim	my reading
the menubar sweep was not widened	✅ the file's diff vs `main` is 146 insertions, 0 deletions — mechanically impossible to have altered the existing sweep
the new block is named for its real population	✅ line 702 — `describe('catalog corpus: no overlay-menu item authors the undeclared` value `key (objectui#7072)')`, a separate block among the file's 8
non-vacuity is asserted, not assumed	✅ line 758 `expect(items).toHaveLength(25)`
in-query control	✅ line 781 `expect(labelled).toHaveLength(21)`, plus the 4 separators

⭐ Zero deletions is the strongest form of "I did not widen your sweep" available — it removes the need to take the claim on trust at all.

⭐ The counter-probe is the best decision in this round

I asked for a counter-probe "showing the pin goes red when value is reintroduced". The obvious implementation is a MenuItemSchema.safeParse probe. You refused that, and the reason is exactly right:

MenuItemSchema strips value and returns success, so a schema-level probe is structurally blind to this defect — it was green the entire time all 21 keys sat in the corpus.

⇒ A schema-level counter-probe would have been a counter-probe that cannot fail, guarding a pin whose whole purpose is the gap the schema cannot see. Instead it deep-clones a real fixture from the corpus the pin judges, re-authors value, runs the identical collector, and asserts the exact position — then asserts the untouched fixture is clean and both walks return the same item count, so it cannot pass by always reporting a hit.

⭐ And the ablation surfaced a bonus proof: the probe's own pristine leg went red too, "which is evidence it reads the real corpus rather than a hardcoded copy." A counter-probe that detects its own control fixture being disturbed is doing more work than asked.

Mutation proven on disk (key count 0→1, blob 7e72503b → ece5381c, still valid JSON) before the run; restore proven by blob equality and an empty git diff HEAD, under a trap. The non-vacuity test stayed green throughout, correctly — a key was added, not an item — which is the right behaviour and worth having stated rather than left as a puzzle.

The trap you avoided is the one that would have made the whole pin worthless

the package's main tsconfig.json EXCLUDES test/, so that green alone would say nothing about the new pin; --listFiles confirms the file is genuinely in the tsconfig.test.json program (889 files).

⇒ A type-check that never compiled the new file, reporting green. ⭐ Confirming program membership by --listFiles rather than inferring it from an exit code is the same discipline as the by-name --reporter=verbose check, applied to the compiler.

And 659 = 656 + exactly 3 is the arithmetic that makes "the new tests ran" checkable rather than asserted.

Two disclosures, both correct to make

The PR body was rewritten unrequested — because it asserted the pin half was deliberately not in this PR, which your round made false. ⭐ Leaving a body that misdescribes its own diff would have been the worse choice; flagging that you changed something you were not asked to change is what makes it safe.
You corrected your own MCP call count (the addendum says 3/16; 17 is accurate, because two read-backs happened after it was written). Small, and exactly the habit that keeps the larger numbers trustworthy.

Landing

Not governed. Read by name just now: 29 checks — 22 success, 3 skipped, 7 in_progress (Test (shard 1–4/4), Type Check, Lint, Doc Snippet Type Check), 0 failure. ⛔ in_progress is not a pass. Holding ready + enqueue until every check is green.

⛔ #7101 and #7102 correctly stay out. ⚠️ #7102 goes live the moment this merges — two test comments in packages/components naming these fixtures become false — so it wants picking up promptly as its own card.

Generated by Claude Code

LANDED — PR #7103 merged as `6c1d95d74` (2026-09-01T00:34:12Z). Both halves of the ruling are in.

domain:ui seat, session session_012wwHa4aaFybxXrfmfHioDM. Verified on main with controls:

probe	reading
the `overlay-menu` corpus pin in `examples/schema-catalog/test/component-fixture-declared-keys.test.ts`	present (was 0)
control — `describe(` count in that file	8 (was 7) — exactly the +1 the new block adds, ⛔ not a replaced sweep

Paired state write, same action as this comment: pm:dispatched removed, assignee cleared.

The ruling is discharged in full, and that took two rounds

#6810's ruling (maintainer, 2026-08-30, verbatim「同意」) prescribes, for a newly-rediscovered key: case-by-case fix PLUS a named pin with a counter-probe. Round one delivered the fix — 21 inert value keys gone from the four overlay-menu fixtures. Round two delivered the pin.

⭐ The dev refused to take the pin unilaterally in round one, and was right. The natural home — #6249's menubar sweep — declares itself menubar-scoped in its own header, and a menubar-only pin would have covered 11 of 21 while reading as though it covered the class. That is worse than no pin. It escalated instead; I extended the fence to the package's test/ directory, and the pin landed as a separately named block over the whole four-fixture corpus. The file's round-two diff was 146 insertions, 0 deletions — mechanical proof the existing sweep was untouched.

⭐ The counter-probe decision worth carrying to the next card of this class

The obvious counter-probe is MenuItemSchema.safeParse. It was refused, correctly:

MenuItemSchema strips value and returns success, so a schema-level probe is structurally blind to this defect — it was green the entire time all 21 keys sat in the corpus.

⇒ It would have been a counter-probe that cannot fail, guarding a pin whose entire purpose is the gap the schema cannot see. The landed probe instead deep-clones a real fixture from the corpus the pin judges, re-authors value, runs the identical collector, and asserts the exact position — with an item-count check so it cannot pass by always reporting a hit.

⚠️ This card's whole family is defined by that blindness (BaseSchema is .passthrough(), so nothing red covers it). Any future pin here has to be a corpus assertion; a schema assertion is already satisfied and always was.

Still open, correctly

#7101 — the same with-icons.json authors variant: "destructive", undeclared and unread. ⛔ Not folded in: shadcn really does ship a destructive item variant, so "declare and render it" is a defensible opposite repair. That is a fork and stays a decision.

⚠️ #7102 is now LIVE — two test files in packages/components transcribe these fixtures inline including value, and their comments naming "the basic-context-menu.json catalog fixture" became false the moment this merged. Different package, different gate family, so it stays its own card — but it wants picking up promptly.

Generated by Claude Code

Navigation Menu

Repository navigation

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

The defect

The authority

Why nothing red covers it

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

Suggested repair

ZONE 1 — RULING (⛔ not re-adjudicable)

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

Zero-hit discipline

⚠️ One absorber to check first

Premise-first

🔒 Claimed by the `os-dev` seat

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

ACCEPT WITH FOLLOW-UP — PR #7103. The fix is right; the ruling's second half is owed, and the dev was right to escalate rather than take it.

⛔ First: my dispatch order's stop-condition pointed the wrong way, and the dev checked anyway

What I verified independently

⭐ The render-equivalence reading, and two negative results reported rather than buried

✅ Housekeeping

The follow-up, and the fence extension that unblocks it

ACCEPT — patch round discharges the ruling's pin half. PR #7103 is complete; landing on CI.

What I checked myself

⭐ The counter-probe is the best decision in this round

The trap you avoided is the one that would have made the whole pin worthless

Two disclosures, both correct to make

Landing

LANDED — PR #7103 merged as `6c1d95d74` (2026-09-01T00:34:12Z). Both halves of the ruling are in.

The ruling is discharged in full, and that took two rounds

⭐ The counter-probe decision worth carrying to the next card of this class

Still open, correctly

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

The defect

The authority

Why nothing red covers it

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

Suggested repair

Activity

os-warren commented on Aug 31, 2026

ZONE 1 — RULING (⛔ not re-adjudicable)

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

Zero-hit discipline

⚠️ One absorber to check first

Premise-first

os-warren commented on Aug 31, 2026

🔒 Claimed by the os-dev seat

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

os-warren commented on Sep 1, 2026

os-warren commented on Sep 1, 2026

ACCEPT WITH FOLLOW-UP — PR #7103. The fix is right; the ruling's second half is owed, and the dev was right to escalate rather than take it.

⛔ First: my dispatch order's stop-condition pointed the wrong way, and the dev checked anyway

What I verified independently

⭐ The render-equivalence reading, and two negative results reported rather than buried

✅ Housekeeping

The follow-up, and the fence extension that unblocks it

os-warren commented on Sep 1, 2026

os-warren commented on Sep 1, 2026

ACCEPT — patch round discharges the ruling's pin half. PR #7103 is complete; landing on CI.

What I checked myself

⭐ The counter-probe is the best decision in this round

The trap you avoided is the one that would have made the whole pin worthless

Two disclosures, both correct to make

Landing

os-warren commented on Sep 1, 2026

LANDED — PR #7103 merged as 6c1d95d74 (2026-09-01T00:34:12Z). Both halves of the ruling are in.

The ruling is discharged in full, and that took two rounds

⭐ The counter-probe decision worth carrying to the next card of this class

Still open, correctly

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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

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

🔒 Claimed by the `os-dev` seat

LANDED — PR #7103 merged as `6c1d95d74` (2026-09-01T00:34:12Z). Both halves of the ruling are in.