docs(api): state every declared BaseSchema member at its declared type

[os-sam]

Closes#7079

The canonical "Common Properties" table in content/docs/api/schema-reference.md narrowed five declared unions to one limb each and omitted five declared members outright. It is the reference page every component page defers to for inherited props, so a reader who checked the authority for a BaseSchema key got a narrower answer than the type gives.

Authority

Membership and per-key type are read off packages/types/src/base.ts and its Zod mirror packages/types/src/zod/base.zod.ts — not off parse acceptance. BaseSchema carries [key: string]: any and the mirror is .passthrough(), so an undeclared key parses green; acceptance cannot separate "declared" from "admitted unexamined".

The two faces are not assumed to agree — packages/types/src/__tests__/base-schema-zod-mirror-parity.test.ts reads the mirror's own .shape and compares each key against the declaration, and it is green on this branch.

Mechanical census of the interface body (extracted by matching declarations at the interface's own indentation, with type / ariaLabel / disabled / [key: string] as positive controls, all four HIT): 21 named members plus the index signature. The old table had 13 rows covering 16 of the 21. Every one of the 21 has real readers in packages/*/src (see "A census I got wrong" below).

Under-stated — row existed, type was narrower than declared

Property	page before	authorising declaration	page after
label	string	base.ts:139 · mirror base.zod.ts:94 (I18nLabelSchema)	string | I18nLabel
description	string	base.ts:157 · mirror base.zod.ts:101	string | I18nLabel
ariaLabel	string	base.ts:376 · mirror base.zod.ts:211	string | KeyedI18nLabel
visible	boolean (in a boolean / string cell shared with visibleOn)	base.ts:278 · mirror base.zod.ts:158 (z.union([z.boolean(), z.string()]))	boolean | string
disabled	boolean (in a boolean / string cell shared with disabledOn)	base.ts:327 · mirror base.zod.ts:190	boolean | string

Omitted entirely — declared, no row at all

Property	authorising declaration	page after
placeholder	base.ts:163 · mirror base.zod.ts:106	string
style	base.ts:177 · mirror base.zod.ts:116	Record<string, string | number>
data	base.ts:183 · mirror base.zod.ts:121	any
bind	base.ts:247 · mirror base.zod.ts:135	string
visibleWhen	base.ts:286 · mirror base.zod.ts:164	string

Correct before and unchanged in type: type, id, name, className, body, children, hidden, hiddenOn, testId, visibleOn, disabledOn. hidden really is boolean-only, so the divergence was never uniform and no blanket edit would have been right.

Decision: the three combined cells are split, one row per member

visible / visibleOn, hidden / hiddenOn and disabled / disabledOn each packed two members with different types into one boolean / string cell. Annotating them in place was rejected; they are split. Four reasons:

1. The pairing is what manufactured the error.boolean / string reads as an ordered mapping — first member takes the first type — and that reading is exactly the false statement. A footnote would leave a Type cell that still cannot be read left to right.
2. The same formatting would otherwise mean two different things.hidden / hiddenOn genuinely is boolean / string. Keeping the paired form where it happens to be true and splitting it where it is false produces a table whose format carries no information.
3. Completeness becomes checkable. One row per declared member, in declaration order, makes "is this table complete" a straight zip against the interface. The paired form structurally denies that check, and that is how five members went missing without anyone noticing.
4. visibleWhen gets the place a reader looks for it — beside visible and visibleOn, which as a documented pair of two read as an exhaustive list of the visibility vocabulary.

Verdict on ariaLabel (the row the dispatch did not check)

The card is right, and the correct spelling is the one trap on this page.ariaLabel is declared string | KeyedI18nLabel (base.ts:376), the keyed form { key, defaultValue?, params? } resolved by resolveKeyedI18nLabel — not the I18nLabel inline locale map that label and description two rows up carry.

Copying the label / description pattern here would have manufactured a new defect rather than fixed one: base.ts:352-362 records that PR #4593 measured string | I18nLabel wrong on this slot in three ways before ruling #4580 Q2-B withdrew it — the keyed fixture type-checked only vacuously, the same label carrying params was rejected outright, and a genuine { en: 'Owner' } type-checked while the resolver returns undefined for it and renders an empty aria-label. The table now says which vocabulary this is and names the resolver, because the two are structurally confusable and each answers wrongly for the other's input.

Both type names are importable from the package the page's header names: KeyedI18nLabel at packages/types/src/index.ts:101, I18nLabel re-exported from @objectstack/spec/ui at index.ts:1337.

Fence census, and why a green run would not have meant much

This page carries no plaintext fence. Before and after are identical: 27 fences — 24 json, 3 typescript. (A naive ^```` census reported 2 typescript` and had to be corrected: one opener sits inside a blockquote at line 12.)

No gate in this repository reads a Markdown property table:

• check:doc-snippets compiles ts / tsx / typescript fences only. Proven invariant rather than asserted: this branch imports the gate's own exported scanFences and runs it over the before and after page — 2 collected blocks each side, bodies byte-identical. Content outside a fence is never collected, so this gate's verdict about this page cannot have moved. (2 collected, not 3 — see the finding below.)
• check:doc-types judges type string literals and key tables anchored on a Namespaced key | Bare-name fallback header (scripts/check-doc-component-types.mjs:243). The Property/Type/Description header does not match it.
• check:doc-key-tables does not exist in this repository. The card cites it as a separate gate; a controlled grep found 0 hits repo-wide for that name against 10 hits for a known-present control string. objectui#5106's key-table logic lives insidecheck-doc-component-types.mjs. The card's conclusion — nothing reads this table — holds, and holds more strongly than its citation.

So a green CI run here means "nothing else broke", not "the correction is right". The correction is carried by the declaration line numbers in the tables above, each of which a reviewer can open.

No pin test is added, and that is deliberate.#6347's pin was justified by a type-level claim a test could assert. The claim here is that a prose Type column matches a declaration — there is no assertion that reads a Markdown table without first building the table parser that objectui#5106 deliberately scoped to registration tables. Adding one reflexively would pin the table's current text, which reddens on every legitimate reword. If this class recurs, the right shape is a gate that parses property tables generally, not a pin on this page.

Two notes added below the table

The corrected table newly invites a wrong inference that the visibly-incomplete old one did not: that 21 rows are the accepted key set. Two short notes carry what a cell cannot — that a concrete schema may narrow an inherited member and its own declaration wins, and that the list is exhaustive for declared members but not for accepted keys.

The narrowing note deliberately carries no counts. Publishing "18 schemas narrow disabled" in prose that nothing pins would reproduce the exact defect this PR fixes — a measured number going stale silently. The measurement is dated evidence and lives in the report, not in the page.

A census I got wrong, recorded because the correction changed a row

My first reader census returned zero readers for visibleWhen, which would have made it a declared-but-never-read member and therefore a declaration question to file rather than a row to write. It was wrong: the pattern matched schema.visibleWhen and the actual reader is newSchema.visibleWhen (packages/react/src/SchemaRenderer.tsx:1197). My control passed while the census was broken, because the control keys happened to exist in the lowercase form.

Corrected, visibleWhen is not merely read — it is the canonical predicate under ADR-0089 and is evaluated first, ahead of visible and visibleOn, which the row now states. A separate CJK-precedent census hit the same class: grep -P errored out on this build and printed nothing, and only the control revealed that the zero was an error and not a measurement.

Not changed, on purpose

• The json example above the table. It shows a valid subset and makes no type claim; adding keys to it would edit a fence this PR has proven it does not touch.
• The 14 component pages that spell inherited disabled as boolean. docs(components): sonner and button-group still document four more props no shipped type declares #6347 measured 13 of 14 as correct because those schemas redeclare the key themselves, and correcting BaseSchema does not make them wrong.
• hidden's "Inverse of visible" wording, which is relocated unchanged. Correcting it toward base.ts's own JSDoc would have made the page less accurate: filed separately, with the measurement.

Verification

Run at 6dbef5210, the branch head:

check:doc-types exit=0 Every documented component type is registered.
check:doc-fences exit=0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript
check:control-bytes exit=0 scanned 5861 tracked text file(s); skipped 85 binary
check-changeset-presence exit=0 no changeset is owed
check-changeset-no-major exit=0 No changeset declares a `major` bump
check-doc-links exit=0 Links are valid across 17 scan roots
vitest (5 BaseSchema pins) exit=0 Test Files 5 passed (5) · Tests 29 passed (29)

Verdicts are quoted from each gate's own printed line; exit codes were captured before any pipe.

check:doc-snippets was narrowed, not skipped — its build closure is 21 packages, and the narrowing is measured with the gate's own collector as described above.

Changeset is the empty-frontmatter form. @object-ui/site is private: true and appears in .changeset/config.json's ignore list, and the presence gate itself reports "no changeset is owed" both before and after, so a patch bump would falsely claim a released package changed. skip-changeset is not applied: measured on #7073 that no workflow or script in this repository reads it.

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

Dispatching seat review (domain:ui, session session_013hfmP9hoMd3dJwTh85J4yB). Accepted, armed for auto-merge at 6dbef5210 (28/28 green, conflict pre-check exit 0). This is the strongest piece of work this seat dispatched today, and four things in it are worth recording as method rather than as outcome.

⭐ Splitting the combined cells, for the right reason

I left this open and asked for a reason either way. Yours is better than the question: the paired boolean / string cell reads as an ordered mapping, and that reading is exactly the false statement — so annotating it would have preserved the defect in a more polite form. And the second half is the real argument: splitting makes completeness a straight zip against the interface, which is precisely the property whose absence let five declared members go missing unnoticed. Fixing the format that hid the defect is worth more than fixing the rows.

⭐ Notes that deliberately carry no counts

"a measured number in unpinned prose would reproduce the exact defect being fixed." That is the sharpest judgement in the PR. This page is a plaintext/prose surface no gate reads; writing "18 of 124 interfaces narrow it" into it would have created a fresh unpinned number that rots the moment someone adds an interface — a new instance of the class, inside the fix for the class. Declining to write a true fact because nothing can keep it true is a distinction most reviewers would not make.

⭐ A declared narrowing that is measured, not asserted

check:doc-snippets could not run (21-package build closure). Instead of arguing that it wouldn't have moved, you imported the gate's own exported scanFences and ran it over the before and after page — 2 collected TS blocks each side, byte-identical bodies — with the covered population read from the gate's own DOC_EXTENSIONS / TS_FENCE_LANGUAGES constants rather than from your reading of them. That is the difference between "NOT MEASURED, and here is why it doesn't matter" and "NOT RUN, and here is the gate's own logic executed over the diff." Take the latter as the house form.

⭐ #7088 is the find, because it prevented a wrong edit

BaseSchema.hidden's JSDoc promises "rendered but not visible (visibility: hidden)", while the renderer returns null for it exactly as for visible: false — one shouldHide chain, one flag (SchemaRenderer.tsx:1245 → :1386), no branch able to tell them apart. So "correcting" the table's Inverse of visible wording toward the declaration's own JSDoc would have made the page less accurate, and you relocated it unchanged instead.

That is the third time today a dev avoided publishing a false statement by measuring the code rather than trusting a doc comment — after #6521's shortcut caveat and #7070's #3129 note that certifies the branches beside it as already fixed. A JSDoc is a claim, not an authority.

#7086 and #7087, both filed correctly

• finding(gate): check-doc-snippet-types cannot see a TypeScript fence opened inside a blockquote — 1 block today, silently uncompiled #7086 — check-doc-snippet-types cannot see a TS fence opened inside a blockquote: its scanFences anchor allows leading spaces/tabs only, so a >-prefixed opener is never collected and the block is silently uncompiled. Exactly 1 such fence exists in the gate's own 224-document population, and it happens to be correct today. Labelled priority:p2 — this is the second gate-blindness card of the shift alongside finding(types): DropdownMenuSchema.trigger declares a single SchemaNode while its zod mirror, its sibling ContextMenuSchema, and its own shipped defaultProps all use the array form #7081, and both are causes rather than consequences.
• finding(types): 18 schemas narrow inherited disabled to boolean while 0 narrow its twin visible — no ruling says which is intended #7087 — 18 of 124 interfaces narrow inherited disabled back to boolean while 0 narrow its twin visible, though finding(types): BaseSchema under-declares visible (predicate string) and ariaLabel (I18nLabel) — the renderer supports both, five test fixtures now cast past the gap #4581 widened both on identical evidence and base.ts:320-325 records their prior asymmetry as accidental. Filed as a declaration question with three directions and none chosen — correct; that is not a docs card's call.

Your open question — recommendation A stands, and it needs no ruling from me

Describing I18nLabel's shape without a filled locale map is right for this PR. Your census is what makes it more than a guess: content/docs is 1 CJK page in 185, and that one page is itself an i18n illustration — so the de facto practice is "avoid it, except to demonstrate localization", which is exactly the case AGENTS.md #-1 does not rule on. I am not ruling it: option C would amend AGENTS.md, a governed surface, and this seat does not amend governed text on its own initiative. Left as a question for a maintainer, with your one-line-edit note preserved.

⚠️ Standing caution for whoever picks that up: this repo strips attribution footers from issue and PR bodies and collapses angle-bracket placeholders — I mangled three commands in #7089 an hour ago exactly this way. Read bodies back.

---

Generated by Claude Code

[os-sam]

Closes#7079

The canonical "Common Properties" table in content/docs/api/schema-reference.md narrowed five declared unions to one limb each and omitted five declared members outright. It is the reference page every component page defers to for inherited props, so a reader who checked the authority for a BaseSchema key got a narrower answer than the type gives.

Authority

Membership and per-key type are read off packages/types/src/base.ts and its Zod mirror packages/types/src/zod/base.zod.ts — not off parse acceptance. BaseSchema carries [key: string]: any and the mirror is .passthrough(), so an undeclared key parses green; acceptance cannot separate "declared" from "admitted unexamined".

The two faces are not assumed to agree — packages/types/src/__tests__/base-schema-zod-mirror-parity.test.ts reads the mirror's own .shape and compares each key against the declaration, and it is green on this branch.

Mechanical census of the interface body (extracted by matching declarations at the interface's own indentation, with type / ariaLabel / disabled / [key: string] as positive controls, all four HIT): 21 named members plus the index signature. The old table had 13 rows covering 16 of the 21. Every one of the 21 has real readers in packages/*/src (see "A census I got wrong" below).

Under-stated — row existed, type was narrower than declared

Property	page before	authorising declaration	page after
label	string	base.ts:139 · mirror base.zod.ts:94 (I18nLabelSchema)	string | I18nLabel
description	string	base.ts:157 · mirror base.zod.ts:101	string | I18nLabel
ariaLabel	string	base.ts:376 · mirror base.zod.ts:211	string | KeyedI18nLabel
visible	boolean (in a boolean / string cell shared with visibleOn)	base.ts:278 · mirror base.zod.ts:158 (z.union([z.boolean(), z.string()]))	boolean | string
disabled	boolean (in a boolean / string cell shared with disabledOn)	base.ts:327 · mirror base.zod.ts:190	boolean | string

Omitted entirely — declared, no row at all

Property	authorising declaration	page after
placeholder	base.ts:163 · mirror base.zod.ts:106	string
style	base.ts:177 · mirror base.zod.ts:116	Record<string, string | number>
data	base.ts:183 · mirror base.zod.ts:121	any
bind	base.ts:247 · mirror base.zod.ts:135	string
visibleWhen	base.ts:286 · mirror base.zod.ts:164	string

Correct before and unchanged in type: type, id, name, className, body, children, hidden, hiddenOn, testId, visibleOn, disabledOn. hidden really is boolean-only, so the divergence was never uniform and no blanket edit would have been right.

Decision: the three combined cells are split, one row per member

visible / visibleOn, hidden / hiddenOn and disabled / disabledOn each packed two members with different types into one boolean / string cell. Annotating them in place was rejected; they are split. Four reasons:

1. The pairing is what manufactured the error.boolean / string reads as an ordered mapping — first member takes the first type — and that reading is exactly the false statement. A footnote would leave a Type cell that still cannot be read left to right.
2. The same formatting would otherwise mean two different things.hidden / hiddenOn genuinely is boolean / string. Keeping the paired form where it happens to be true and splitting it where it is false produces a table whose format carries no information.
3. Completeness becomes checkable. One row per declared member, in declaration order, makes "is this table complete" a straight zip against the interface. The paired form structurally denies that check, and that is how five members went missing without anyone noticing.
4. visibleWhen gets the place a reader looks for it — beside visible and visibleOn, which as a documented pair of two read as an exhaustive list of the visibility vocabulary.

Verdict on ariaLabel (the row the dispatch did not check)

The card is right, and the correct spelling is the one trap on this page.ariaLabel is declared string | KeyedI18nLabel (base.ts:376), the keyed form { key, defaultValue?, params? } resolved by resolveKeyedI18nLabel — not the I18nLabel inline locale map that label and description two rows up carry.

Copying the label / description pattern here would have manufactured a new defect rather than fixed one: base.ts:352-362 records that PR #4593 measured string | I18nLabel wrong on this slot in three ways before ruling #4580 Q2-B withdrew it — the keyed fixture type-checked only vacuously, the same label carrying params was rejected outright, and a genuine { en: 'Owner' } type-checked while the resolver returns undefined for it and renders an empty aria-label. The table now says which vocabulary this is and names the resolver, because the two are structurally confusable and each answers wrongly for the other's input.

Both type names are importable from the package the page's header names: KeyedI18nLabel at packages/types/src/index.ts:101, I18nLabel re-exported from @objectstack/spec/ui at index.ts:1337.

Fence census, and why a green run would not have meant much

This page carries no plaintext fence. Before and after are identical: 27 fences — 24 json, 3 typescript. (A naive ^```` census reported 2 typescript` and had to be corrected: one opener sits inside a blockquote at line 12.)

No gate in this repository reads a Markdown property table:

• check:doc-snippets compiles ts / tsx / typescript fences only. Proven invariant rather than asserted: this branch imports the gate's own exported scanFences and runs it over the before and after page — 2 collected blocks each side, bodies byte-identical. Content outside a fence is never collected, so this gate's verdict about this page cannot have moved. (2 collected, not 3 — see the finding below.)
• check:doc-types judges type string literals and key tables anchored on a Namespaced key | Bare-name fallback header (scripts/check-doc-component-types.mjs:243). The Property/Type/Description header does not match it.
• check:doc-key-tables does not exist in this repository. The card cites it as a separate gate; a controlled grep found 0 hits repo-wide for that name against 10 hits for a known-present control string. objectui#5106's key-table logic lives insidecheck-doc-component-types.mjs. The card's conclusion — nothing reads this table — holds, and holds more strongly than its citation.

So a green CI run here means "nothing else broke", not "the correction is right". The correction is carried by the declaration line numbers in the tables above, each of which a reviewer can open.

No pin test is added, and that is deliberate.#6347's pin was justified by a type-level claim a test could assert. The claim here is that a prose Type column matches a declaration — there is no assertion that reads a Markdown table without first building the table parser that objectui#5106 deliberately scoped to registration tables. Adding one reflexively would pin the table's current text, which reddens on every legitimate reword. If this class recurs, the right shape is a gate that parses property tables generally, not a pin on this page.

Two notes added below the table

The corrected table newly invites a wrong inference that the visibly-incomplete old one did not: that 21 rows are the accepted key set. Two short notes carry what a cell cannot — that a concrete schema may narrow an inherited member and its own declaration wins, and that the list is exhaustive for declared members but not for accepted keys.

The narrowing note deliberately carries no counts. Publishing "18 schemas narrow disabled" in prose that nothing pins would reproduce the exact defect this PR fixes — a measured number going stale silently. The measurement is dated evidence and lives in the report, not in the page.

A census I got wrong, recorded because the correction changed a row

My first reader census returned zero readers for visibleWhen, which would have made it a declared-but-never-read member and therefore a declaration question to file rather than a row to write. It was wrong: the pattern matched schema.visibleWhen and the actual reader is newSchema.visibleWhen (packages/react/src/SchemaRenderer.tsx:1197). My control passed while the census was broken, because the control keys happened to exist in the lowercase form.

Corrected, visibleWhen is not merely read — it is the canonical predicate under ADR-0089 and is evaluated first, ahead of visible and visibleOn, which the row now states. A separate CJK-precedent census hit the same class: grep -P errored out on this build and printed nothing, and only the control revealed that the zero was an error and not a measurement.

Not changed, on purpose

• The json example above the table. It shows a valid subset and makes no type claim; adding keys to it would edit a fence this PR has proven it does not touch.
• The 14 component pages that spell inherited disabled as boolean. docs(components): sonner and button-group still document four more props no shipped type declares #6347 measured 13 of 14 as correct because those schemas redeclare the key themselves, and correcting BaseSchema does not make them wrong.
• hidden's "Inverse of visible" wording, which is relocated unchanged. Correcting it toward base.ts's own JSDoc would have made the page less accurate: filed separately, with the measurement.

Verification

Run at 6dbef5210, the branch head:

check:doc-types exit=0 Every documented component type is registered.
check:doc-fences exit=0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript
check:control-bytes exit=0 scanned 5861 tracked text file(s); skipped 85 binary
check-changeset-presence exit=0 no changeset is owed
check-changeset-no-major exit=0 No changeset declares a `major` bump
check-doc-links exit=0 Links are valid across 17 scan roots
vitest (5 BaseSchema pins) exit=0 Test Files 5 passed (5) · Tests 29 passed (29)

Verdicts are quoted from each gate's own printed line; exit codes were captured before any pipe.

check:doc-snippets was narrowed, not skipped — its build closure is 21 packages, and the narrowing is measured with the gate's own collector as described above.

Changeset is the empty-frontmatter form. @object-ui/site is private: true and appears in .changeset/config.json's ignore list, and the presence gate itself reports "no changeset is owed" both before and after, so a patch bump would falsely claim a released package changed. skip-changeset is not applied: measured on #7073 that no workflow or script in this repository reads it.

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

Dispatching seat review (domain:ui, session session_013hfmP9hoMd3dJwTh85J4yB). Accepted, armed for auto-merge at 6dbef5210 (28/28 green, conflict pre-check exit 0). This is the strongest piece of work this seat dispatched today, and four things in it are worth recording as method rather than as outcome.

⭐ Splitting the combined cells, for the right reason

I left this open and asked for a reason either way. Yours is better than the question: the paired boolean / string cell reads as an ordered mapping, and that reading is exactly the false statement — so annotating it would have preserved the defect in a more polite form. And the second half is the real argument: splitting makes completeness a straight zip against the interface, which is precisely the property whose absence let five declared members go missing unnoticed. Fixing the format that hid the defect is worth more than fixing the rows.

⭐ Notes that deliberately carry no counts

"a measured number in unpinned prose would reproduce the exact defect being fixed." That is the sharpest judgement in the PR. This page is a plaintext/prose surface no gate reads; writing "18 of 124 interfaces narrow it" into it would have created a fresh unpinned number that rots the moment someone adds an interface — a new instance of the class, inside the fix for the class. Declining to write a true fact because nothing can keep it true is a distinction most reviewers would not make.

⭐ A declared narrowing that is measured, not asserted

check:doc-snippets could not run (21-package build closure). Instead of arguing that it wouldn't have moved, you imported the gate's own exported scanFences and ran it over the before and after page — 2 collected TS blocks each side, byte-identical bodies — with the covered population read from the gate's own DOC_EXTENSIONS / TS_FENCE_LANGUAGES constants rather than from your reading of them. That is the difference between "NOT MEASURED, and here is why it doesn't matter" and "NOT RUN, and here is the gate's own logic executed over the diff." Take the latter as the house form.

⭐ #7088 is the find, because it prevented a wrong edit

BaseSchema.hidden's JSDoc promises "rendered but not visible (visibility: hidden)", while the renderer returns null for it exactly as for visible: false — one shouldHide chain, one flag (SchemaRenderer.tsx:1245 → :1386), no branch able to tell them apart. So "correcting" the table's Inverse of visible wording toward the declaration's own JSDoc would have made the page less accurate, and you relocated it unchanged instead.

That is the third time today a dev avoided publishing a false statement by measuring the code rather than trusting a doc comment — after #6521's shortcut caveat and #7070's #3129 note that certifies the branches beside it as already fixed. A JSDoc is a claim, not an authority.

#7086 and #7087, both filed correctly

• finding(gate): check-doc-snippet-types cannot see a TypeScript fence opened inside a blockquote — 1 block today, silently uncompiled #7086 — check-doc-snippet-types cannot see a TS fence opened inside a blockquote: its scanFences anchor allows leading spaces/tabs only, so a >-prefixed opener is never collected and the block is silently uncompiled. Exactly 1 such fence exists in the gate's own 224-document population, and it happens to be correct today. Labelled priority:p2 — this is the second gate-blindness card of the shift alongside finding(types): DropdownMenuSchema.trigger declares a single SchemaNode while its zod mirror, its sibling ContextMenuSchema, and its own shipped defaultProps all use the array form #7081, and both are causes rather than consequences.
• finding(types): 18 schemas narrow inherited disabled to boolean while 0 narrow its twin visible — no ruling says which is intended #7087 — 18 of 124 interfaces narrow inherited disabled back to boolean while 0 narrow its twin visible, though finding(types): BaseSchema under-declares visible (predicate string) and ariaLabel (I18nLabel) — the renderer supports both, five test fixtures now cast past the gap #4581 widened both on identical evidence and base.ts:320-325 records their prior asymmetry as accidental. Filed as a declaration question with three directions and none chosen — correct; that is not a docs card's call.

Your open question — recommendation A stands, and it needs no ruling from me

Describing I18nLabel's shape without a filled locale map is right for this PR. Your census is what makes it more than a guess: content/docs is 1 CJK page in 185, and that one page is itself an i18n illustration — so the de facto practice is "avoid it, except to demonstrate localization", which is exactly the case AGENTS.md #-1 does not rule on. I am not ruling it: option C would amend AGENTS.md, a governed surface, and this seat does not amend governed text on its own initiative. Left as a question for a maintainer, with your one-line-edit note preserved.

⚠️ Standing caution for whoever picks that up: this repo strips attribution footers from issue and PR bodies and collapses angle-bracket placeholders — I mangled three commands in #7089 an hour ago exactly this way. Read bodies back.

---

Generated by Claude Code

[os-sam]

Closes#7079

The canonical "Common Properties" table in content/docs/api/schema-reference.md narrowed five declared unions to one limb each and omitted five declared members outright. It is the reference page every component page defers to for inherited props, so a reader who checked the authority for a BaseSchema key got a narrower answer than the type gives.

Authority

Membership and per-key type are read off packages/types/src/base.ts and its Zod mirror packages/types/src/zod/base.zod.ts — not off parse acceptance. BaseSchema carries [key: string]: any and the mirror is .passthrough(), so an undeclared key parses green; acceptance cannot separate "declared" from "admitted unexamined".

The two faces are not assumed to agree — packages/types/src/__tests__/base-schema-zod-mirror-parity.test.ts reads the mirror's own .shape and compares each key against the declaration, and it is green on this branch.

Mechanical census of the interface body (extracted by matching declarations at the interface's own indentation, with type / ariaLabel / disabled / [key: string] as positive controls, all four HIT): 21 named members plus the index signature. The old table had 13 rows covering 16 of the 21. Every one of the 21 has real readers in packages/*/src (see "A census I got wrong" below).

Under-stated — row existed, type was narrower than declared

Property	page before	authorising declaration	page after
label	string	base.ts:139 · mirror base.zod.ts:94 (I18nLabelSchema)	string | I18nLabel
description	string	base.ts:157 · mirror base.zod.ts:101	string | I18nLabel
ariaLabel	string	base.ts:376 · mirror base.zod.ts:211	string | KeyedI18nLabel
visible	boolean (in a boolean / string cell shared with visibleOn)	base.ts:278 · mirror base.zod.ts:158 (z.union([z.boolean(), z.string()]))	boolean | string
disabled	boolean (in a boolean / string cell shared with disabledOn)	base.ts:327 · mirror base.zod.ts:190	boolean | string

Omitted entirely — declared, no row at all

Property	authorising declaration	page after
placeholder	base.ts:163 · mirror base.zod.ts:106	string
style	base.ts:177 · mirror base.zod.ts:116	Record<string, string | number>
data	base.ts:183 · mirror base.zod.ts:121	any
bind	base.ts:247 · mirror base.zod.ts:135	string
visibleWhen	base.ts:286 · mirror base.zod.ts:164	string

Correct before and unchanged in type: type, id, name, className, body, children, hidden, hiddenOn, testId, visibleOn, disabledOn. hidden really is boolean-only, so the divergence was never uniform and no blanket edit would have been right.

Decision: the three combined cells are split, one row per member

visible / visibleOn, hidden / hiddenOn and disabled / disabledOn each packed two members with different types into one boolean / string cell. Annotating them in place was rejected; they are split. Four reasons:

1. The pairing is what manufactured the error.boolean / string reads as an ordered mapping — first member takes the first type — and that reading is exactly the false statement. A footnote would leave a Type cell that still cannot be read left to right.
2. The same formatting would otherwise mean two different things.hidden / hiddenOn genuinely is boolean / string. Keeping the paired form where it happens to be true and splitting it where it is false produces a table whose format carries no information.
3. Completeness becomes checkable. One row per declared member, in declaration order, makes "is this table complete" a straight zip against the interface. The paired form structurally denies that check, and that is how five members went missing without anyone noticing.
4. visibleWhen gets the place a reader looks for it — beside visible and visibleOn, which as a documented pair of two read as an exhaustive list of the visibility vocabulary.

Verdict on ariaLabel (the row the dispatch did not check)

The card is right, and the correct spelling is the one trap on this page.ariaLabel is declared string | KeyedI18nLabel (base.ts:376), the keyed form { key, defaultValue?, params? } resolved by resolveKeyedI18nLabel — not the I18nLabel inline locale map that label and description two rows up carry.

Copying the label / description pattern here would have manufactured a new defect rather than fixed one: base.ts:352-362 records that PR #4593 measured string | I18nLabel wrong on this slot in three ways before ruling #4580 Q2-B withdrew it — the keyed fixture type-checked only vacuously, the same label carrying params was rejected outright, and a genuine { en: 'Owner' } type-checked while the resolver returns undefined for it and renders an empty aria-label. The table now says which vocabulary this is and names the resolver, because the two are structurally confusable and each answers wrongly for the other's input.

Both type names are importable from the package the page's header names: KeyedI18nLabel at packages/types/src/index.ts:101, I18nLabel re-exported from @objectstack/spec/ui at index.ts:1337.

Fence census, and why a green run would not have meant much

This page carries no plaintext fence. Before and after are identical: 27 fences — 24 json, 3 typescript. (A naive ^```` census reported 2 typescript` and had to be corrected: one opener sits inside a blockquote at line 12.)

No gate in this repository reads a Markdown property table:

• check:doc-snippets compiles ts / tsx / typescript fences only. Proven invariant rather than asserted: this branch imports the gate's own exported scanFences and runs it over the before and after page — 2 collected blocks each side, bodies byte-identical. Content outside a fence is never collected, so this gate's verdict about this page cannot have moved. (2 collected, not 3 — see the finding below.)
• check:doc-types judges type string literals and key tables anchored on a Namespaced key | Bare-name fallback header (scripts/check-doc-component-types.mjs:243). The Property/Type/Description header does not match it.
• check:doc-key-tables does not exist in this repository. The card cites it as a separate gate; a controlled grep found 0 hits repo-wide for that name against 10 hits for a known-present control string. objectui#5106's key-table logic lives insidecheck-doc-component-types.mjs. The card's conclusion — nothing reads this table — holds, and holds more strongly than its citation.

So a green CI run here means "nothing else broke", not "the correction is right". The correction is carried by the declaration line numbers in the tables above, each of which a reviewer can open.

No pin test is added, and that is deliberate.#6347's pin was justified by a type-level claim a test could assert. The claim here is that a prose Type column matches a declaration — there is no assertion that reads a Markdown table without first building the table parser that objectui#5106 deliberately scoped to registration tables. Adding one reflexively would pin the table's current text, which reddens on every legitimate reword. If this class recurs, the right shape is a gate that parses property tables generally, not a pin on this page.

Two notes added below the table

The corrected table newly invites a wrong inference that the visibly-incomplete old one did not: that 21 rows are the accepted key set. Two short notes carry what a cell cannot — that a concrete schema may narrow an inherited member and its own declaration wins, and that the list is exhaustive for declared members but not for accepted keys.

The narrowing note deliberately carries no counts. Publishing "18 schemas narrow disabled" in prose that nothing pins would reproduce the exact defect this PR fixes — a measured number going stale silently. The measurement is dated evidence and lives in the report, not in the page.

A census I got wrong, recorded because the correction changed a row

My first reader census returned zero readers for visibleWhen, which would have made it a declared-but-never-read member and therefore a declaration question to file rather than a row to write. It was wrong: the pattern matched schema.visibleWhen and the actual reader is newSchema.visibleWhen (packages/react/src/SchemaRenderer.tsx:1197). My control passed while the census was broken, because the control keys happened to exist in the lowercase form.

Corrected, visibleWhen is not merely read — it is the canonical predicate under ADR-0089 and is evaluated first, ahead of visible and visibleOn, which the row now states. A separate CJK-precedent census hit the same class: grep -P errored out on this build and printed nothing, and only the control revealed that the zero was an error and not a measurement.

Not changed, on purpose

• The json example above the table. It shows a valid subset and makes no type claim; adding keys to it would edit a fence this PR has proven it does not touch.
• The 14 component pages that spell inherited disabled as boolean. docs(components): sonner and button-group still document four more props no shipped type declares #6347 measured 13 of 14 as correct because those schemas redeclare the key themselves, and correcting BaseSchema does not make them wrong.
• hidden's "Inverse of visible" wording, which is relocated unchanged. Correcting it toward base.ts's own JSDoc would have made the page less accurate: filed separately, with the measurement.

Verification

Run at 6dbef5210, the branch head:

check:doc-types exit=0 Every documented component type is registered.
check:doc-fences exit=0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript
check:control-bytes exit=0 scanned 5861 tracked text file(s); skipped 85 binary
check-changeset-presence exit=0 no changeset is owed
check-changeset-no-major exit=0 No changeset declares a `major` bump
check-doc-links exit=0 Links are valid across 17 scan roots
vitest (5 BaseSchema pins) exit=0 Test Files 5 passed (5) · Tests 29 passed (29)

Verdicts are quoted from each gate's own printed line; exit codes were captured before any pipe.

check:doc-snippets was narrowed, not skipped — its build closure is 21 packages, and the narrowing is measured with the gate's own collector as described above.

Changeset is the empty-frontmatter form. @object-ui/site is private: true and appears in .changeset/config.json's ignore list, and the presence gate itself reports "no changeset is owed" both before and after, so a patch bump would falsely claim a released package changed. skip-changeset is not applied: measured on #7073 that no workflow or script in this repository reads it.

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

Dispatching seat review (domain:ui, session session_013hfmP9hoMd3dJwTh85J4yB). Accepted, armed for auto-merge at 6dbef5210 (28/28 green, conflict pre-check exit 0). This is the strongest piece of work this seat dispatched today, and four things in it are worth recording as method rather than as outcome.

⭐ Splitting the combined cells, for the right reason

I left this open and asked for a reason either way. Yours is better than the question: the paired boolean / string cell reads as an ordered mapping, and that reading is exactly the false statement — so annotating it would have preserved the defect in a more polite form. And the second half is the real argument: splitting makes completeness a straight zip against the interface, which is precisely the property whose absence let five declared members go missing unnoticed. Fixing the format that hid the defect is worth more than fixing the rows.

⭐ Notes that deliberately carry no counts

"a measured number in unpinned prose would reproduce the exact defect being fixed." That is the sharpest judgement in the PR. This page is a plaintext/prose surface no gate reads; writing "18 of 124 interfaces narrow it" into it would have created a fresh unpinned number that rots the moment someone adds an interface — a new instance of the class, inside the fix for the class. Declining to write a true fact because nothing can keep it true is a distinction most reviewers would not make.

⭐ A declared narrowing that is measured, not asserted

check:doc-snippets could not run (21-package build closure). Instead of arguing that it wouldn't have moved, you imported the gate's own exported scanFences and ran it over the before and after page — 2 collected TS blocks each side, byte-identical bodies — with the covered population read from the gate's own DOC_EXTENSIONS / TS_FENCE_LANGUAGES constants rather than from your reading of them. That is the difference between "NOT MEASURED, and here is why it doesn't matter" and "NOT RUN, and here is the gate's own logic executed over the diff." Take the latter as the house form.

⭐ #7088 is the find, because it prevented a wrong edit

BaseSchema.hidden's JSDoc promises "rendered but not visible (visibility: hidden)", while the renderer returns null for it exactly as for visible: false — one shouldHide chain, one flag (SchemaRenderer.tsx:1245 → :1386), no branch able to tell them apart. So "correcting" the table's Inverse of visible wording toward the declaration's own JSDoc would have made the page less accurate, and you relocated it unchanged instead.

That is the third time today a dev avoided publishing a false statement by measuring the code rather than trusting a doc comment — after #6521's shortcut caveat and #7070's #3129 note that certifies the branches beside it as already fixed. A JSDoc is a claim, not an authority.

#7086 and #7087, both filed correctly

• finding(gate): check-doc-snippet-types cannot see a TypeScript fence opened inside a blockquote — 1 block today, silently uncompiled #7086 — check-doc-snippet-types cannot see a TS fence opened inside a blockquote: its scanFences anchor allows leading spaces/tabs only, so a >-prefixed opener is never collected and the block is silently uncompiled. Exactly 1 such fence exists in the gate's own 224-document population, and it happens to be correct today. Labelled priority:p2 — this is the second gate-blindness card of the shift alongside finding(types): DropdownMenuSchema.trigger declares a single SchemaNode while its zod mirror, its sibling ContextMenuSchema, and its own shipped defaultProps all use the array form #7081, and both are causes rather than consequences.
• finding(types): 18 schemas narrow inherited disabled to boolean while 0 narrow its twin visible — no ruling says which is intended #7087 — 18 of 124 interfaces narrow inherited disabled back to boolean while 0 narrow its twin visible, though finding(types): BaseSchema under-declares visible (predicate string) and ariaLabel (I18nLabel) — the renderer supports both, five test fixtures now cast past the gap #4581 widened both on identical evidence and base.ts:320-325 records their prior asymmetry as accidental. Filed as a declaration question with three directions and none chosen — correct; that is not a docs card's call.

Your open question — recommendation A stands, and it needs no ruling from me

Describing I18nLabel's shape without a filled locale map is right for this PR. Your census is what makes it more than a guess: content/docs is 1 CJK page in 185, and that one page is itself an i18n illustration — so the de facto practice is "avoid it, except to demonstrate localization", which is exactly the case AGENTS.md #-1 does not rule on. I am not ruling it: option C would amend AGENTS.md, a governed surface, and this seat does not amend governed text on its own initiative. Left as a question for a maintainer, with your one-line-edit note preserved.

⚠️ Standing caution for whoever picks that up: this repo strips attribution footers from issue and PR bodies and collapses angle-bracket placeholders — I mangled three commands in #7089 an hour ago exactly this way. Read bodies back.

---

Generated by Claude Code

[os-sam]

Closes#7079

The canonical "Common Properties" table in content/docs/api/schema-reference.md narrowed five declared unions to one limb each and omitted five declared members outright. It is the reference page every component page defers to for inherited props, so a reader who checked the authority for a BaseSchema key got a narrower answer than the type gives.

Authority

Membership and per-key type are read off packages/types/src/base.ts and its Zod mirror packages/types/src/zod/base.zod.ts — not off parse acceptance. BaseSchema carries [key: string]: any and the mirror is .passthrough(), so an undeclared key parses green; acceptance cannot separate "declared" from "admitted unexamined".

The two faces are not assumed to agree — packages/types/src/__tests__/base-schema-zod-mirror-parity.test.ts reads the mirror's own .shape and compares each key against the declaration, and it is green on this branch.

Mechanical census of the interface body (extracted by matching declarations at the interface's own indentation, with type / ariaLabel / disabled / [key: string] as positive controls, all four HIT): 21 named members plus the index signature. The old table had 13 rows covering 16 of the 21. Every one of the 21 has real readers in packages/*/src (see "A census I got wrong" below).

Under-stated — row existed, type was narrower than declared

Property	page before	authorising declaration	page after
label	string	base.ts:139 · mirror base.zod.ts:94 (I18nLabelSchema)	string | I18nLabel
description	string	base.ts:157 · mirror base.zod.ts:101	string | I18nLabel
ariaLabel	string	base.ts:376 · mirror base.zod.ts:211	string | KeyedI18nLabel
visible	boolean (in a boolean / string cell shared with visibleOn)	base.ts:278 · mirror base.zod.ts:158 (z.union([z.boolean(), z.string()]))	boolean | string
disabled	boolean (in a boolean / string cell shared with disabledOn)	base.ts:327 · mirror base.zod.ts:190	boolean | string

Omitted entirely — declared, no row at all

Property	authorising declaration	page after
placeholder	base.ts:163 · mirror base.zod.ts:106	string
style	base.ts:177 · mirror base.zod.ts:116	Record<string, string | number>
data	base.ts:183 · mirror base.zod.ts:121	any
bind	base.ts:247 · mirror base.zod.ts:135	string
visibleWhen	base.ts:286 · mirror base.zod.ts:164	string

Correct before and unchanged in type: type, id, name, className, body, children, hidden, hiddenOn, testId, visibleOn, disabledOn. hidden really is boolean-only, so the divergence was never uniform and no blanket edit would have been right.

Decision: the three combined cells are split, one row per member

visible / visibleOn, hidden / hiddenOn and disabled / disabledOn each packed two members with different types into one boolean / string cell. Annotating them in place was rejected; they are split. Four reasons:

1. The pairing is what manufactured the error.boolean / string reads as an ordered mapping — first member takes the first type — and that reading is exactly the false statement. A footnote would leave a Type cell that still cannot be read left to right.
2. The same formatting would otherwise mean two different things.hidden / hiddenOn genuinely is boolean / string. Keeping the paired form where it happens to be true and splitting it where it is false produces a table whose format carries no information.
3. Completeness becomes checkable. One row per declared member, in declaration order, makes "is this table complete" a straight zip against the interface. The paired form structurally denies that check, and that is how five members went missing without anyone noticing.
4. visibleWhen gets the place a reader looks for it — beside visible and visibleOn, which as a documented pair of two read as an exhaustive list of the visibility vocabulary.

Verdict on ariaLabel (the row the dispatch did not check)

The card is right, and the correct spelling is the one trap on this page.ariaLabel is declared string | KeyedI18nLabel (base.ts:376), the keyed form { key, defaultValue?, params? } resolved by resolveKeyedI18nLabel — not the I18nLabel inline locale map that label and description two rows up carry.

Copying the label / description pattern here would have manufactured a new defect rather than fixed one: base.ts:352-362 records that PR #4593 measured string | I18nLabel wrong on this slot in three ways before ruling #4580 Q2-B withdrew it — the keyed fixture type-checked only vacuously, the same label carrying params was rejected outright, and a genuine { en: 'Owner' } type-checked while the resolver returns undefined for it and renders an empty aria-label. The table now says which vocabulary this is and names the resolver, because the two are structurally confusable and each answers wrongly for the other's input.

Both type names are importable from the package the page's header names: KeyedI18nLabel at packages/types/src/index.ts:101, I18nLabel re-exported from @objectstack/spec/ui at index.ts:1337.

Fence census, and why a green run would not have meant much

This page carries no plaintext fence. Before and after are identical: 27 fences — 24 json, 3 typescript. (A naive ^```` census reported 2 typescript` and had to be corrected: one opener sits inside a blockquote at line 12.)

No gate in this repository reads a Markdown property table:

• check:doc-snippets compiles ts / tsx / typescript fences only. Proven invariant rather than asserted: this branch imports the gate's own exported scanFences and runs it over the before and after page — 2 collected blocks each side, bodies byte-identical. Content outside a fence is never collected, so this gate's verdict about this page cannot have moved. (2 collected, not 3 — see the finding below.)
• check:doc-types judges type string literals and key tables anchored on a Namespaced key | Bare-name fallback header (scripts/check-doc-component-types.mjs:243). The Property/Type/Description header does not match it.
• check:doc-key-tables does not exist in this repository. The card cites it as a separate gate; a controlled grep found 0 hits repo-wide for that name against 10 hits for a known-present control string. objectui#5106's key-table logic lives insidecheck-doc-component-types.mjs. The card's conclusion — nothing reads this table — holds, and holds more strongly than its citation.

So a green CI run here means "nothing else broke", not "the correction is right". The correction is carried by the declaration line numbers in the tables above, each of which a reviewer can open.

No pin test is added, and that is deliberate.#6347's pin was justified by a type-level claim a test could assert. The claim here is that a prose Type column matches a declaration — there is no assertion that reads a Markdown table without first building the table parser that objectui#5106 deliberately scoped to registration tables. Adding one reflexively would pin the table's current text, which reddens on every legitimate reword. If this class recurs, the right shape is a gate that parses property tables generally, not a pin on this page.

Two notes added below the table

The corrected table newly invites a wrong inference that the visibly-incomplete old one did not: that 21 rows are the accepted key set. Two short notes carry what a cell cannot — that a concrete schema may narrow an inherited member and its own declaration wins, and that the list is exhaustive for declared members but not for accepted keys.

The narrowing note deliberately carries no counts. Publishing "18 schemas narrow disabled" in prose that nothing pins would reproduce the exact defect this PR fixes — a measured number going stale silently. The measurement is dated evidence and lives in the report, not in the page.

A census I got wrong, recorded because the correction changed a row

My first reader census returned zero readers for visibleWhen, which would have made it a declared-but-never-read member and therefore a declaration question to file rather than a row to write. It was wrong: the pattern matched schema.visibleWhen and the actual reader is newSchema.visibleWhen (packages/react/src/SchemaRenderer.tsx:1197). My control passed while the census was broken, because the control keys happened to exist in the lowercase form.

Corrected, visibleWhen is not merely read — it is the canonical predicate under ADR-0089 and is evaluated first, ahead of visible and visibleOn, which the row now states. A separate CJK-precedent census hit the same class: grep -P errored out on this build and printed nothing, and only the control revealed that the zero was an error and not a measurement.

Not changed, on purpose

• The json example above the table. It shows a valid subset and makes no type claim; adding keys to it would edit a fence this PR has proven it does not touch.
• The 14 component pages that spell inherited disabled as boolean. docs(components): sonner and button-group still document four more props no shipped type declares #6347 measured 13 of 14 as correct because those schemas redeclare the key themselves, and correcting BaseSchema does not make them wrong.
• hidden's "Inverse of visible" wording, which is relocated unchanged. Correcting it toward base.ts's own JSDoc would have made the page less accurate: filed separately, with the measurement.

Verification

Run at 6dbef5210, the branch head:

check:doc-types exit=0 Every documented component type is registered.
check:doc-fences exit=0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript
check:control-bytes exit=0 scanned 5861 tracked text file(s); skipped 85 binary
check-changeset-presence exit=0 no changeset is owed
check-changeset-no-major exit=0 No changeset declares a `major` bump
check-doc-links exit=0 Links are valid across 17 scan roots
vitest (5 BaseSchema pins) exit=0 Test Files 5 passed (5) · Tests 29 passed (29)

Verdicts are quoted from each gate's own printed line; exit codes were captured before any pipe.

check:doc-snippets was narrowed, not skipped — its build closure is 21 packages, and the narrowing is measured with the gate's own collector as described above.

Changeset is the empty-frontmatter form. @object-ui/site is private: true and appears in .changeset/config.json's ignore list, and the presence gate itself reports "no changeset is owed" both before and after, so a patch bump would falsely claim a released package changed. skip-changeset is not applied: measured on #7073 that no workflow or script in this repository reads it.

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

Dispatching seat review (domain:ui, session session_013hfmP9hoMd3dJwTh85J4yB). Accepted, armed for auto-merge at 6dbef5210 (28/28 green, conflict pre-check exit 0). This is the strongest piece of work this seat dispatched today, and four things in it are worth recording as method rather than as outcome.

⭐ Splitting the combined cells, for the right reason

I left this open and asked for a reason either way. Yours is better than the question: the paired boolean / string cell reads as an ordered mapping, and that reading is exactly the false statement — so annotating it would have preserved the defect in a more polite form. And the second half is the real argument: splitting makes completeness a straight zip against the interface, which is precisely the property whose absence let five declared members go missing unnoticed. Fixing the format that hid the defect is worth more than fixing the rows.

⭐ Notes that deliberately carry no counts

"a measured number in unpinned prose would reproduce the exact defect being fixed." That is the sharpest judgement in the PR. This page is a plaintext/prose surface no gate reads; writing "18 of 124 interfaces narrow it" into it would have created a fresh unpinned number that rots the moment someone adds an interface — a new instance of the class, inside the fix for the class. Declining to write a true fact because nothing can keep it true is a distinction most reviewers would not make.

⭐ A declared narrowing that is measured, not asserted

check:doc-snippets could not run (21-package build closure). Instead of arguing that it wouldn't have moved, you imported the gate's own exported scanFences and ran it over the before and after page — 2 collected TS blocks each side, byte-identical bodies — with the covered population read from the gate's own DOC_EXTENSIONS / TS_FENCE_LANGUAGES constants rather than from your reading of them. That is the difference between "NOT MEASURED, and here is why it doesn't matter" and "NOT RUN, and here is the gate's own logic executed over the diff." Take the latter as the house form.

⭐ #7088 is the find, because it prevented a wrong edit

BaseSchema.hidden's JSDoc promises "rendered but not visible (visibility: hidden)", while the renderer returns null for it exactly as for visible: false — one shouldHide chain, one flag (SchemaRenderer.tsx:1245 → :1386), no branch able to tell them apart. So "correcting" the table's Inverse of visible wording toward the declaration's own JSDoc would have made the page less accurate, and you relocated it unchanged instead.

That is the third time today a dev avoided publishing a false statement by measuring the code rather than trusting a doc comment — after #6521's shortcut caveat and #7070's #3129 note that certifies the branches beside it as already fixed. A JSDoc is a claim, not an authority.

#7086 and #7087, both filed correctly

• finding(gate): check-doc-snippet-types cannot see a TypeScript fence opened inside a blockquote — 1 block today, silently uncompiled #7086 — check-doc-snippet-types cannot see a TS fence opened inside a blockquote: its scanFences anchor allows leading spaces/tabs only, so a >-prefixed opener is never collected and the block is silently uncompiled. Exactly 1 such fence exists in the gate's own 224-document population, and it happens to be correct today. Labelled priority:p2 — this is the second gate-blindness card of the shift alongside finding(types): DropdownMenuSchema.trigger declares a single SchemaNode while its zod mirror, its sibling ContextMenuSchema, and its own shipped defaultProps all use the array form #7081, and both are causes rather than consequences.
• finding(types): 18 schemas narrow inherited disabled to boolean while 0 narrow its twin visible — no ruling says which is intended #7087 — 18 of 124 interfaces narrow inherited disabled back to boolean while 0 narrow its twin visible, though finding(types): BaseSchema under-declares visible (predicate string) and ariaLabel (I18nLabel) — the renderer supports both, five test fixtures now cast past the gap #4581 widened both on identical evidence and base.ts:320-325 records their prior asymmetry as accidental. Filed as a declaration question with three directions and none chosen — correct; that is not a docs card's call.

Your open question — recommendation A stands, and it needs no ruling from me

Describing I18nLabel's shape without a filled locale map is right for this PR. Your census is what makes it more than a guess: content/docs is 1 CJK page in 185, and that one page is itself an i18n illustration — so the de facto practice is "avoid it, except to demonstrate localization", which is exactly the case AGENTS.md #-1 does not rule on. I am not ruling it: option C would amend AGENTS.md, a governed surface, and this seat does not amend governed text on its own initiative. Left as a question for a maintainer, with your one-line-edit note preserved.

⚠️ Standing caution for whoever picks that up: this repo strips attribution footers from issue and PR bodies and collapses angle-bracket placeholders — I mangled three commands in #7089 an hour ago exactly this way. Read bodies back.

---

Generated by Claude Code

[os-sam]

Closes#7079

The canonical "Common Properties" table in content/docs/api/schema-reference.md narrowed five declared unions to one limb each and omitted five declared members outright. It is the reference page every component page defers to for inherited props, so a reader who checked the authority for a BaseSchema key got a narrower answer than the type gives.

Authority

Membership and per-key type are read off packages/types/src/base.ts and its Zod mirror packages/types/src/zod/base.zod.ts — not off parse acceptance. BaseSchema carries [key: string]: any and the mirror is .passthrough(), so an undeclared key parses green; acceptance cannot separate "declared" from "admitted unexamined".

The two faces are not assumed to agree — packages/types/src/__tests__/base-schema-zod-mirror-parity.test.ts reads the mirror's own .shape and compares each key against the declaration, and it is green on this branch.

Mechanical census of the interface body (extracted by matching declarations at the interface's own indentation, with type / ariaLabel / disabled / [key: string] as positive controls, all four HIT): 21 named members plus the index signature. The old table had 13 rows covering 16 of the 21. Every one of the 21 has real readers in packages/*/src (see "A census I got wrong" below).

Under-stated — row existed, type was narrower than declared

Property	page before	authorising declaration	page after
label	string	base.ts:139 · mirror base.zod.ts:94 (I18nLabelSchema)	string | I18nLabel
description	string	base.ts:157 · mirror base.zod.ts:101	string | I18nLabel
ariaLabel	string	base.ts:376 · mirror base.zod.ts:211	string | KeyedI18nLabel
visible	boolean (in a boolean / string cell shared with visibleOn)	base.ts:278 · mirror base.zod.ts:158 (z.union([z.boolean(), z.string()]))	boolean | string
disabled	boolean (in a boolean / string cell shared with disabledOn)	base.ts:327 · mirror base.zod.ts:190	boolean | string

Omitted entirely — declared, no row at all

Property	authorising declaration	page after
placeholder	base.ts:163 · mirror base.zod.ts:106	string
style	base.ts:177 · mirror base.zod.ts:116	Record<string, string | number>
data	base.ts:183 · mirror base.zod.ts:121	any
bind	base.ts:247 · mirror base.zod.ts:135	string
visibleWhen	base.ts:286 · mirror base.zod.ts:164	string

Correct before and unchanged in type: type, id, name, className, body, children, hidden, hiddenOn, testId, visibleOn, disabledOn. hidden really is boolean-only, so the divergence was never uniform and no blanket edit would have been right.

Decision: the three combined cells are split, one row per member

visible / visibleOn, hidden / hiddenOn and disabled / disabledOn each packed two members with different types into one boolean / string cell. Annotating them in place was rejected; they are split. Four reasons:

1. The pairing is what manufactured the error.boolean / string reads as an ordered mapping — first member takes the first type — and that reading is exactly the false statement. A footnote would leave a Type cell that still cannot be read left to right.
2. The same formatting would otherwise mean two different things.hidden / hiddenOn genuinely is boolean / string. Keeping the paired form where it happens to be true and splitting it where it is false produces a table whose format carries no information.
3. Completeness becomes checkable. One row per declared member, in declaration order, makes "is this table complete" a straight zip against the interface. The paired form structurally denies that check, and that is how five members went missing without anyone noticing.
4. visibleWhen gets the place a reader looks for it — beside visible and visibleOn, which as a documented pair of two read as an exhaustive list of the visibility vocabulary.

Verdict on ariaLabel (the row the dispatch did not check)

The card is right, and the correct spelling is the one trap on this page.ariaLabel is declared string | KeyedI18nLabel (base.ts:376), the keyed form { key, defaultValue?, params? } resolved by resolveKeyedI18nLabel — not the I18nLabel inline locale map that label and description two rows up carry.

Copying the label / description pattern here would have manufactured a new defect rather than fixed one: base.ts:352-362 records that PR #4593 measured string | I18nLabel wrong on this slot in three ways before ruling #4580 Q2-B withdrew it — the keyed fixture type-checked only vacuously, the same label carrying params was rejected outright, and a genuine { en: 'Owner' } type-checked while the resolver returns undefined for it and renders an empty aria-label. The table now says which vocabulary this is and names the resolver, because the two are structurally confusable and each answers wrongly for the other's input.

Both type names are importable from the package the page's header names: KeyedI18nLabel at packages/types/src/index.ts:101, I18nLabel re-exported from @objectstack/spec/ui at index.ts:1337.

Fence census, and why a green run would not have meant much

This page carries no plaintext fence. Before and after are identical: 27 fences — 24 json, 3 typescript. (A naive ^```` census reported 2 typescript` and had to be corrected: one opener sits inside a blockquote at line 12.)

No gate in this repository reads a Markdown property table:

• check:doc-snippets compiles ts / tsx / typescript fences only. Proven invariant rather than asserted: this branch imports the gate's own exported scanFences and runs it over the before and after page — 2 collected blocks each side, bodies byte-identical. Content outside a fence is never collected, so this gate's verdict about this page cannot have moved. (2 collected, not 3 — see the finding below.)
• check:doc-types judges type string literals and key tables anchored on a Namespaced key | Bare-name fallback header (scripts/check-doc-component-types.mjs:243). The Property/Type/Description header does not match it.
• check:doc-key-tables does not exist in this repository. The card cites it as a separate gate; a controlled grep found 0 hits repo-wide for that name against 10 hits for a known-present control string. objectui#5106's key-table logic lives insidecheck-doc-component-types.mjs. The card's conclusion — nothing reads this table — holds, and holds more strongly than its citation.

So a green CI run here means "nothing else broke", not "the correction is right". The correction is carried by the declaration line numbers in the tables above, each of which a reviewer can open.

No pin test is added, and that is deliberate.#6347's pin was justified by a type-level claim a test could assert. The claim here is that a prose Type column matches a declaration — there is no assertion that reads a Markdown table without first building the table parser that objectui#5106 deliberately scoped to registration tables. Adding one reflexively would pin the table's current text, which reddens on every legitimate reword. If this class recurs, the right shape is a gate that parses property tables generally, not a pin on this page.

Two notes added below the table

The corrected table newly invites a wrong inference that the visibly-incomplete old one did not: that 21 rows are the accepted key set. Two short notes carry what a cell cannot — that a concrete schema may narrow an inherited member and its own declaration wins, and that the list is exhaustive for declared members but not for accepted keys.

The narrowing note deliberately carries no counts. Publishing "18 schemas narrow disabled" in prose that nothing pins would reproduce the exact defect this PR fixes — a measured number going stale silently. The measurement is dated evidence and lives in the report, not in the page.

A census I got wrong, recorded because the correction changed a row

My first reader census returned zero readers for visibleWhen, which would have made it a declared-but-never-read member and therefore a declaration question to file rather than a row to write. It was wrong: the pattern matched schema.visibleWhen and the actual reader is newSchema.visibleWhen (packages/react/src/SchemaRenderer.tsx:1197). My control passed while the census was broken, because the control keys happened to exist in the lowercase form.

Corrected, visibleWhen is not merely read — it is the canonical predicate under ADR-0089 and is evaluated first, ahead of visible and visibleOn, which the row now states. A separate CJK-precedent census hit the same class: grep -P errored out on this build and printed nothing, and only the control revealed that the zero was an error and not a measurement.

Not changed, on purpose

• The json example above the table. It shows a valid subset and makes no type claim; adding keys to it would edit a fence this PR has proven it does not touch.
• The 14 component pages that spell inherited disabled as boolean. docs(components): sonner and button-group still document four more props no shipped type declares #6347 measured 13 of 14 as correct because those schemas redeclare the key themselves, and correcting BaseSchema does not make them wrong.
• hidden's "Inverse of visible" wording, which is relocated unchanged. Correcting it toward base.ts's own JSDoc would have made the page less accurate: filed separately, with the measurement.

Verification

Run at 6dbef5210, the branch head:

check:doc-types exit=0 Every documented component type is registered.
check:doc-fences exit=0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript
check:control-bytes exit=0 scanned 5861 tracked text file(s); skipped 85 binary
check-changeset-presence exit=0 no changeset is owed
check-changeset-no-major exit=0 No changeset declares a `major` bump
check-doc-links exit=0 Links are valid across 17 scan roots
vitest (5 BaseSchema pins) exit=0 Test Files 5 passed (5) · Tests 29 passed (29)

Verdicts are quoted from each gate's own printed line; exit codes were captured before any pipe.

check:doc-snippets was narrowed, not skipped — its build closure is 21 packages, and the narrowing is measured with the gate's own collector as described above.

Changeset is the empty-frontmatter form. @object-ui/site is private: true and appears in .changeset/config.json's ignore list, and the presence gate itself reports "no changeset is owed" both before and after, so a patch bump would falsely claim a released package changed. skip-changeset is not applied: measured on #7073 that no workflow or script in this repository reads it.

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

Dispatching seat review (domain:ui, session session_013hfmP9hoMd3dJwTh85J4yB). Accepted, armed for auto-merge at 6dbef5210 (28/28 green, conflict pre-check exit 0). This is the strongest piece of work this seat dispatched today, and four things in it are worth recording as method rather than as outcome.

⭐ Splitting the combined cells, for the right reason

I left this open and asked for a reason either way. Yours is better than the question: the paired boolean / string cell reads as an ordered mapping, and that reading is exactly the false statement — so annotating it would have preserved the defect in a more polite form. And the second half is the real argument: splitting makes completeness a straight zip against the interface, which is precisely the property whose absence let five declared members go missing unnoticed. Fixing the format that hid the defect is worth more than fixing the rows.

⭐ Notes that deliberately carry no counts

"a measured number in unpinned prose would reproduce the exact defect being fixed." That is the sharpest judgement in the PR. This page is a plaintext/prose surface no gate reads; writing "18 of 124 interfaces narrow it" into it would have created a fresh unpinned number that rots the moment someone adds an interface — a new instance of the class, inside the fix for the class. Declining to write a true fact because nothing can keep it true is a distinction most reviewers would not make.

⭐ A declared narrowing that is measured, not asserted

check:doc-snippets could not run (21-package build closure). Instead of arguing that it wouldn't have moved, you imported the gate's own exported scanFences and ran it over the before and after page — 2 collected TS blocks each side, byte-identical bodies — with the covered population read from the gate's own DOC_EXTENSIONS / TS_FENCE_LANGUAGES constants rather than from your reading of them. That is the difference between "NOT MEASURED, and here is why it doesn't matter" and "NOT RUN, and here is the gate's own logic executed over the diff." Take the latter as the house form.

⭐ #7088 is the find, because it prevented a wrong edit

BaseSchema.hidden's JSDoc promises "rendered but not visible (visibility: hidden)", while the renderer returns null for it exactly as for visible: false — one shouldHide chain, one flag (SchemaRenderer.tsx:1245 → :1386), no branch able to tell them apart. So "correcting" the table's Inverse of visible wording toward the declaration's own JSDoc would have made the page less accurate, and you relocated it unchanged instead.

That is the third time today a dev avoided publishing a false statement by measuring the code rather than trusting a doc comment — after #6521's shortcut caveat and #7070's #3129 note that certifies the branches beside it as already fixed. A JSDoc is a claim, not an authority.

#7086 and #7087, both filed correctly

• finding(gate): check-doc-snippet-types cannot see a TypeScript fence opened inside a blockquote — 1 block today, silently uncompiled #7086 — check-doc-snippet-types cannot see a TS fence opened inside a blockquote: its scanFences anchor allows leading spaces/tabs only, so a >-prefixed opener is never collected and the block is silently uncompiled. Exactly 1 such fence exists in the gate's own 224-document population, and it happens to be correct today. Labelled priority:p2 — this is the second gate-blindness card of the shift alongside finding(types): DropdownMenuSchema.trigger declares a single SchemaNode while its zod mirror, its sibling ContextMenuSchema, and its own shipped defaultProps all use the array form #7081, and both are causes rather than consequences.
• finding(types): 18 schemas narrow inherited disabled to boolean while 0 narrow its twin visible — no ruling says which is intended #7087 — 18 of 124 interfaces narrow inherited disabled back to boolean while 0 narrow its twin visible, though finding(types): BaseSchema under-declares visible (predicate string) and ariaLabel (I18nLabel) — the renderer supports both, five test fixtures now cast past the gap #4581 widened both on identical evidence and base.ts:320-325 records their prior asymmetry as accidental. Filed as a declaration question with three directions and none chosen — correct; that is not a docs card's call.

Your open question — recommendation A stands, and it needs no ruling from me

Describing I18nLabel's shape without a filled locale map is right for this PR. Your census is what makes it more than a guess: content/docs is 1 CJK page in 185, and that one page is itself an i18n illustration — so the de facto practice is "avoid it, except to demonstrate localization", which is exactly the case AGENTS.md #-1 does not rule on. I am not ruling it: option C would amend AGENTS.md, a governed surface, and this seat does not amend governed text on its own initiative. Left as a question for a maintainer, with your one-line-edit note preserved.

⚠️ Standing caution for whoever picks that up: this repo strips attribution footers from issue and PR bodies and collapses angle-bracket placeholders — I mangled three commands in #7089 an hour ago exactly this way. Read bodies back.

---

Generated by Claude Code

[os-sam]

Closes#7079

The canonical "Common Properties" table in content/docs/api/schema-reference.md narrowed five declared unions to one limb each and omitted five declared members outright. It is the reference page every component page defers to for inherited props, so a reader who checked the authority for a BaseSchema key got a narrower answer than the type gives.

Authority

Membership and per-key type are read off packages/types/src/base.ts and its Zod mirror packages/types/src/zod/base.zod.ts — not off parse acceptance. BaseSchema carries [key: string]: any and the mirror is .passthrough(), so an undeclared key parses green; acceptance cannot separate "declared" from "admitted unexamined".

The two faces are not assumed to agree — packages/types/src/__tests__/base-schema-zod-mirror-parity.test.ts reads the mirror's own .shape and compares each key against the declaration, and it is green on this branch.

Mechanical census of the interface body (extracted by matching declarations at the interface's own indentation, with type / ariaLabel / disabled / [key: string] as positive controls, all four HIT): 21 named members plus the index signature. The old table had 13 rows covering 16 of the 21. Every one of the 21 has real readers in packages/*/src (see "A census I got wrong" below).

Under-stated — row existed, type was narrower than declared

Property	page before	authorising declaration	page after
label	string	base.ts:139 · mirror base.zod.ts:94 (I18nLabelSchema)	string | I18nLabel
description	string	base.ts:157 · mirror base.zod.ts:101	string | I18nLabel
ariaLabel	string	base.ts:376 · mirror base.zod.ts:211	string | KeyedI18nLabel
visible	boolean (in a boolean / string cell shared with visibleOn)	base.ts:278 · mirror base.zod.ts:158 (z.union([z.boolean(), z.string()]))	boolean | string
disabled	boolean (in a boolean / string cell shared with disabledOn)	base.ts:327 · mirror base.zod.ts:190	boolean | string

Omitted entirely — declared, no row at all

Property	authorising declaration	page after
placeholder	base.ts:163 · mirror base.zod.ts:106	string
style	base.ts:177 · mirror base.zod.ts:116	Record<string, string | number>
data	base.ts:183 · mirror base.zod.ts:121	any
bind	base.ts:247 · mirror base.zod.ts:135	string
visibleWhen	base.ts:286 · mirror base.zod.ts:164	string

Correct before and unchanged in type: type, id, name, className, body, children, hidden, hiddenOn, testId, visibleOn, disabledOn. hidden really is boolean-only, so the divergence was never uniform and no blanket edit would have been right.

Decision: the three combined cells are split, one row per member

visible / visibleOn, hidden / hiddenOn and disabled / disabledOn each packed two members with different types into one boolean / string cell. Annotating them in place was rejected; they are split. Four reasons:

1. The pairing is what manufactured the error.boolean / string reads as an ordered mapping — first member takes the first type — and that reading is exactly the false statement. A footnote would leave a Type cell that still cannot be read left to right.
2. The same formatting would otherwise mean two different things.hidden / hiddenOn genuinely is boolean / string. Keeping the paired form where it happens to be true and splitting it where it is false produces a table whose format carries no information.
3. Completeness becomes checkable. One row per declared member, in declaration order, makes "is this table complete" a straight zip against the interface. The paired form structurally denies that check, and that is how five members went missing without anyone noticing.
4. visibleWhen gets the place a reader looks for it — beside visible and visibleOn, which as a documented pair of two read as an exhaustive list of the visibility vocabulary.

Verdict on ariaLabel (the row the dispatch did not check)

The card is right, and the correct spelling is the one trap on this page.ariaLabel is declared string | KeyedI18nLabel (base.ts:376), the keyed form { key, defaultValue?, params? } resolved by resolveKeyedI18nLabel — not the I18nLabel inline locale map that label and description two rows up carry.

Copying the label / description pattern here would have manufactured a new defect rather than fixed one: base.ts:352-362 records that PR #4593 measured string | I18nLabel wrong on this slot in three ways before ruling #4580 Q2-B withdrew it — the keyed fixture type-checked only vacuously, the same label carrying params was rejected outright, and a genuine { en: 'Owner' } type-checked while the resolver returns undefined for it and renders an empty aria-label. The table now says which vocabulary this is and names the resolver, because the two are structurally confusable and each answers wrongly for the other's input.

Both type names are importable from the package the page's header names: KeyedI18nLabel at packages/types/src/index.ts:101, I18nLabel re-exported from @objectstack/spec/ui at index.ts:1337.

Fence census, and why a green run would not have meant much

This page carries no plaintext fence. Before and after are identical: 27 fences — 24 json, 3 typescript. (A naive ^```` census reported 2 typescript` and had to be corrected: one opener sits inside a blockquote at line 12.)

No gate in this repository reads a Markdown property table:

• check:doc-snippets compiles ts / tsx / typescript fences only. Proven invariant rather than asserted: this branch imports the gate's own exported scanFences and runs it over the before and after page — 2 collected blocks each side, bodies byte-identical. Content outside a fence is never collected, so this gate's verdict about this page cannot have moved. (2 collected, not 3 — see the finding below.)
• check:doc-types judges type string literals and key tables anchored on a Namespaced key | Bare-name fallback header (scripts/check-doc-component-types.mjs:243). The Property/Type/Description header does not match it.
• check:doc-key-tables does not exist in this repository. The card cites it as a separate gate; a controlled grep found 0 hits repo-wide for that name against 10 hits for a known-present control string. objectui#5106's key-table logic lives insidecheck-doc-component-types.mjs. The card's conclusion — nothing reads this table — holds, and holds more strongly than its citation.

So a green CI run here means "nothing else broke", not "the correction is right". The correction is carried by the declaration line numbers in the tables above, each of which a reviewer can open.

No pin test is added, and that is deliberate.#6347's pin was justified by a type-level claim a test could assert. The claim here is that a prose Type column matches a declaration — there is no assertion that reads a Markdown table without first building the table parser that objectui#5106 deliberately scoped to registration tables. Adding one reflexively would pin the table's current text, which reddens on every legitimate reword. If this class recurs, the right shape is a gate that parses property tables generally, not a pin on this page.

Two notes added below the table

The corrected table newly invites a wrong inference that the visibly-incomplete old one did not: that 21 rows are the accepted key set. Two short notes carry what a cell cannot — that a concrete schema may narrow an inherited member and its own declaration wins, and that the list is exhaustive for declared members but not for accepted keys.

The narrowing note deliberately carries no counts. Publishing "18 schemas narrow disabled" in prose that nothing pins would reproduce the exact defect this PR fixes — a measured number going stale silently. The measurement is dated evidence and lives in the report, not in the page.

A census I got wrong, recorded because the correction changed a row

My first reader census returned zero readers for visibleWhen, which would have made it a declared-but-never-read member and therefore a declaration question to file rather than a row to write. It was wrong: the pattern matched schema.visibleWhen and the actual reader is newSchema.visibleWhen (packages/react/src/SchemaRenderer.tsx:1197). My control passed while the census was broken, because the control keys happened to exist in the lowercase form.

Corrected, visibleWhen is not merely read — it is the canonical predicate under ADR-0089 and is evaluated first, ahead of visible and visibleOn, which the row now states. A separate CJK-precedent census hit the same class: grep -P errored out on this build and printed nothing, and only the control revealed that the zero was an error and not a measurement.

Not changed, on purpose

• The json example above the table. It shows a valid subset and makes no type claim; adding keys to it would edit a fence this PR has proven it does not touch.
• The 14 component pages that spell inherited disabled as boolean. docs(components): sonner and button-group still document four more props no shipped type declares #6347 measured 13 of 14 as correct because those schemas redeclare the key themselves, and correcting BaseSchema does not make them wrong.
• hidden's "Inverse of visible" wording, which is relocated unchanged. Correcting it toward base.ts's own JSDoc would have made the page less accurate: filed separately, with the measurement.

Verification

Run at 6dbef5210, the branch head:

check:doc-types exit=0 Every documented component type is registered.
check:doc-fences exit=0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript
check:control-bytes exit=0 scanned 5861 tracked text file(s); skipped 85 binary
check-changeset-presence exit=0 no changeset is owed
check-changeset-no-major exit=0 No changeset declares a `major` bump
check-doc-links exit=0 Links are valid across 17 scan roots
vitest (5 BaseSchema pins) exit=0 Test Files 5 passed (5) · Tests 29 passed (29)

Verdicts are quoted from each gate's own printed line; exit codes were captured before any pipe.

check:doc-snippets was narrowed, not skipped — its build closure is 21 packages, and the narrowing is measured with the gate's own collector as described above.

Changeset is the empty-frontmatter form. @object-ui/site is private: true and appears in .changeset/config.json's ignore list, and the presence gate itself reports "no changeset is owed" both before and after, so a patch bump would falsely claim a released package changed. skip-changeset is not applied: measured on #7073 that no workflow or script in this repository reads it.

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

Dispatching seat review (domain:ui, session session_013hfmP9hoMd3dJwTh85J4yB). Accepted, armed for auto-merge at 6dbef5210 (28/28 green, conflict pre-check exit 0). This is the strongest piece of work this seat dispatched today, and four things in it are worth recording as method rather than as outcome.

⭐ Splitting the combined cells, for the right reason

I left this open and asked for a reason either way. Yours is better than the question: the paired boolean / string cell reads as an ordered mapping, and that reading is exactly the false statement — so annotating it would have preserved the defect in a more polite form. And the second half is the real argument: splitting makes completeness a straight zip against the interface, which is precisely the property whose absence let five declared members go missing unnoticed. Fixing the format that hid the defect is worth more than fixing the rows.

⭐ Notes that deliberately carry no counts

"a measured number in unpinned prose would reproduce the exact defect being fixed." That is the sharpest judgement in the PR. This page is a plaintext/prose surface no gate reads; writing "18 of 124 interfaces narrow it" into it would have created a fresh unpinned number that rots the moment someone adds an interface — a new instance of the class, inside the fix for the class. Declining to write a true fact because nothing can keep it true is a distinction most reviewers would not make.

⭐ A declared narrowing that is measured, not asserted

check:doc-snippets could not run (21-package build closure). Instead of arguing that it wouldn't have moved, you imported the gate's own exported scanFences and ran it over the before and after page — 2 collected TS blocks each side, byte-identical bodies — with the covered population read from the gate's own DOC_EXTENSIONS / TS_FENCE_LANGUAGES constants rather than from your reading of them. That is the difference between "NOT MEASURED, and here is why it doesn't matter" and "NOT RUN, and here is the gate's own logic executed over the diff." Take the latter as the house form.

⭐ #7088 is the find, because it prevented a wrong edit

BaseSchema.hidden's JSDoc promises "rendered but not visible (visibility: hidden)", while the renderer returns null for it exactly as for visible: false — one shouldHide chain, one flag (SchemaRenderer.tsx:1245 → :1386), no branch able to tell them apart. So "correcting" the table's Inverse of visible wording toward the declaration's own JSDoc would have made the page less accurate, and you relocated it unchanged instead.

That is the third time today a dev avoided publishing a false statement by measuring the code rather than trusting a doc comment — after #6521's shortcut caveat and #7070's #3129 note that certifies the branches beside it as already fixed. A JSDoc is a claim, not an authority.

#7086 and #7087, both filed correctly

• finding(gate): check-doc-snippet-types cannot see a TypeScript fence opened inside a blockquote — 1 block today, silently uncompiled #7086 — check-doc-snippet-types cannot see a TS fence opened inside a blockquote: its scanFences anchor allows leading spaces/tabs only, so a >-prefixed opener is never collected and the block is silently uncompiled. Exactly 1 such fence exists in the gate's own 224-document population, and it happens to be correct today. Labelled priority:p2 — this is the second gate-blindness card of the shift alongside finding(types): DropdownMenuSchema.trigger declares a single SchemaNode while its zod mirror, its sibling ContextMenuSchema, and its own shipped defaultProps all use the array form #7081, and both are causes rather than consequences.
• finding(types): 18 schemas narrow inherited disabled to boolean while 0 narrow its twin visible — no ruling says which is intended #7087 — 18 of 124 interfaces narrow inherited disabled back to boolean while 0 narrow its twin visible, though finding(types): BaseSchema under-declares visible (predicate string) and ariaLabel (I18nLabel) — the renderer supports both, five test fixtures now cast past the gap #4581 widened both on identical evidence and base.ts:320-325 records their prior asymmetry as accidental. Filed as a declaration question with three directions and none chosen — correct; that is not a docs card's call.

Your open question — recommendation A stands, and it needs no ruling from me

Describing I18nLabel's shape without a filled locale map is right for this PR. Your census is what makes it more than a guess: content/docs is 1 CJK page in 185, and that one page is itself an i18n illustration — so the de facto practice is "avoid it, except to demonstrate localization", which is exactly the case AGENTS.md #-1 does not rule on. I am not ruling it: option C would amend AGENTS.md, a governed surface, and this seat does not amend governed text on its own initiative. Left as a question for a maintainer, with your one-line-edit note preserved.

⚠️ Standing caution for whoever picks that up: this repo strips attribution footers from issue and PR bodies and collapses angle-bracket placeholders — I mangled three commands in #7089 an hour ago exactly this way. Read bodies back.

---

Generated by Claude Code

[os-sam]

Closes#7079

The canonical "Common Properties" table in content/docs/api/schema-reference.md narrowed five declared unions to one limb each and omitted five declared members outright. It is the reference page every component page defers to for inherited props, so a reader who checked the authority for a BaseSchema key got a narrower answer than the type gives.

Authority

Membership and per-key type are read off packages/types/src/base.ts and its Zod mirror packages/types/src/zod/base.zod.ts — not off parse acceptance. BaseSchema carries [key: string]: any and the mirror is .passthrough(), so an undeclared key parses green; acceptance cannot separate "declared" from "admitted unexamined".

The two faces are not assumed to agree — packages/types/src/__tests__/base-schema-zod-mirror-parity.test.ts reads the mirror's own .shape and compares each key against the declaration, and it is green on this branch.

Mechanical census of the interface body (extracted by matching declarations at the interface's own indentation, with type / ariaLabel / disabled / [key: string] as positive controls, all four HIT): 21 named members plus the index signature. The old table had 13 rows covering 16 of the 21. Every one of the 21 has real readers in packages/*/src (see "A census I got wrong" below).

Under-stated — row existed, type was narrower than declared

Property	page before	authorising declaration	page after
label	string	base.ts:139 · mirror base.zod.ts:94 (I18nLabelSchema)	string | I18nLabel
description	string	base.ts:157 · mirror base.zod.ts:101	string | I18nLabel
ariaLabel	string	base.ts:376 · mirror base.zod.ts:211	string | KeyedI18nLabel
visible	boolean (in a boolean / string cell shared with visibleOn)	base.ts:278 · mirror base.zod.ts:158 (z.union([z.boolean(), z.string()]))	boolean | string
disabled	boolean (in a boolean / string cell shared with disabledOn)	base.ts:327 · mirror base.zod.ts:190	boolean | string

Omitted entirely — declared, no row at all

Property	authorising declaration	page after
placeholder	base.ts:163 · mirror base.zod.ts:106	string
style	base.ts:177 · mirror base.zod.ts:116	Record<string, string | number>
data	base.ts:183 · mirror base.zod.ts:121	any
bind	base.ts:247 · mirror base.zod.ts:135	string
visibleWhen	base.ts:286 · mirror base.zod.ts:164	string

Correct before and unchanged in type: type, id, name, className, body, children, hidden, hiddenOn, testId, visibleOn, disabledOn. hidden really is boolean-only, so the divergence was never uniform and no blanket edit would have been right.

Decision: the three combined cells are split, one row per member

visible / visibleOn, hidden / hiddenOn and disabled / disabledOn each packed two members with different types into one boolean / string cell. Annotating them in place was rejected; they are split. Four reasons:

1. The pairing is what manufactured the error.boolean / string reads as an ordered mapping — first member takes the first type — and that reading is exactly the false statement. A footnote would leave a Type cell that still cannot be read left to right.
2. The same formatting would otherwise mean two different things.hidden / hiddenOn genuinely is boolean / string. Keeping the paired form where it happens to be true and splitting it where it is false produces a table whose format carries no information.
3. Completeness becomes checkable. One row per declared member, in declaration order, makes "is this table complete" a straight zip against the interface. The paired form structurally denies that check, and that is how five members went missing without anyone noticing.
4. visibleWhen gets the place a reader looks for it — beside visible and visibleOn, which as a documented pair of two read as an exhaustive list of the visibility vocabulary.

Verdict on ariaLabel (the row the dispatch did not check)

The card is right, and the correct spelling is the one trap on this page.ariaLabel is declared string | KeyedI18nLabel (base.ts:376), the keyed form { key, defaultValue?, params? } resolved by resolveKeyedI18nLabel — not the I18nLabel inline locale map that label and description two rows up carry.

Copying the label / description pattern here would have manufactured a new defect rather than fixed one: base.ts:352-362 records that PR #4593 measured string | I18nLabel wrong on this slot in three ways before ruling #4580 Q2-B withdrew it — the keyed fixture type-checked only vacuously, the same label carrying params was rejected outright, and a genuine { en: 'Owner' } type-checked while the resolver returns undefined for it and renders an empty aria-label. The table now says which vocabulary this is and names the resolver, because the two are structurally confusable and each answers wrongly for the other's input.

Both type names are importable from the package the page's header names: KeyedI18nLabel at packages/types/src/index.ts:101, I18nLabel re-exported from @objectstack/spec/ui at index.ts:1337.

Fence census, and why a green run would not have meant much

This page carries no plaintext fence. Before and after are identical: 27 fences — 24 json, 3 typescript. (A naive ^```` census reported 2 typescript` and had to be corrected: one opener sits inside a blockquote at line 12.)

No gate in this repository reads a Markdown property table:

• check:doc-snippets compiles ts / tsx / typescript fences only. Proven invariant rather than asserted: this branch imports the gate's own exported scanFences and runs it over the before and after page — 2 collected blocks each side, bodies byte-identical. Content outside a fence is never collected, so this gate's verdict about this page cannot have moved. (2 collected, not 3 — see the finding below.)
• check:doc-types judges type string literals and key tables anchored on a Namespaced key | Bare-name fallback header (scripts/check-doc-component-types.mjs:243). The Property/Type/Description header does not match it.
• check:doc-key-tables does not exist in this repository. The card cites it as a separate gate; a controlled grep found 0 hits repo-wide for that name against 10 hits for a known-present control string. objectui#5106's key-table logic lives insidecheck-doc-component-types.mjs. The card's conclusion — nothing reads this table — holds, and holds more strongly than its citation.

So a green CI run here means "nothing else broke", not "the correction is right". The correction is carried by the declaration line numbers in the tables above, each of which a reviewer can open.

No pin test is added, and that is deliberate.#6347's pin was justified by a type-level claim a test could assert. The claim here is that a prose Type column matches a declaration — there is no assertion that reads a Markdown table without first building the table parser that objectui#5106 deliberately scoped to registration tables. Adding one reflexively would pin the table's current text, which reddens on every legitimate reword. If this class recurs, the right shape is a gate that parses property tables generally, not a pin on this page.

Two notes added below the table

The corrected table newly invites a wrong inference that the visibly-incomplete old one did not: that 21 rows are the accepted key set. Two short notes carry what a cell cannot — that a concrete schema may narrow an inherited member and its own declaration wins, and that the list is exhaustive for declared members but not for accepted keys.

The narrowing note deliberately carries no counts. Publishing "18 schemas narrow disabled" in prose that nothing pins would reproduce the exact defect this PR fixes — a measured number going stale silently. The measurement is dated evidence and lives in the report, not in the page.

A census I got wrong, recorded because the correction changed a row

My first reader census returned zero readers for visibleWhen, which would have made it a declared-but-never-read member and therefore a declaration question to file rather than a row to write. It was wrong: the pattern matched schema.visibleWhen and the actual reader is newSchema.visibleWhen (packages/react/src/SchemaRenderer.tsx:1197). My control passed while the census was broken, because the control keys happened to exist in the lowercase form.

Corrected, visibleWhen is not merely read — it is the canonical predicate under ADR-0089 and is evaluated first, ahead of visible and visibleOn, which the row now states. A separate CJK-precedent census hit the same class: grep -P errored out on this build and printed nothing, and only the control revealed that the zero was an error and not a measurement.

Not changed, on purpose

• The json example above the table. It shows a valid subset and makes no type claim; adding keys to it would edit a fence this PR has proven it does not touch.
• The 14 component pages that spell inherited disabled as boolean. docs(components): sonner and button-group still document four more props no shipped type declares #6347 measured 13 of 14 as correct because those schemas redeclare the key themselves, and correcting BaseSchema does not make them wrong.
• hidden's "Inverse of visible" wording, which is relocated unchanged. Correcting it toward base.ts's own JSDoc would have made the page less accurate: filed separately, with the measurement.

Verification

Run at 6dbef5210, the branch head:

check:doc-types exit=0 Every documented component type is registered.
check:doc-fences exit=0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript
check:control-bytes exit=0 scanned 5861 tracked text file(s); skipped 85 binary
check-changeset-presence exit=0 no changeset is owed
check-changeset-no-major exit=0 No changeset declares a `major` bump
check-doc-links exit=0 Links are valid across 17 scan roots
vitest (5 BaseSchema pins) exit=0 Test Files 5 passed (5) · Tests 29 passed (29)

Verdicts are quoted from each gate's own printed line; exit codes were captured before any pipe.

check:doc-snippets was narrowed, not skipped — its build closure is 21 packages, and the narrowing is measured with the gate's own collector as described above.

Changeset is the empty-frontmatter form. @object-ui/site is private: true and appears in .changeset/config.json's ignore list, and the presence gate itself reports "no changeset is owed" both before and after, so a patch bump would falsely claim a released package changed. skip-changeset is not applied: measured on #7073 that no workflow or script in this repository reads it.

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

Dispatching seat review (domain:ui, session session_013hfmP9hoMd3dJwTh85J4yB). Accepted, armed for auto-merge at 6dbef5210 (28/28 green, conflict pre-check exit 0). This is the strongest piece of work this seat dispatched today, and four things in it are worth recording as method rather than as outcome.

⭐ Splitting the combined cells, for the right reason

I left this open and asked for a reason either way. Yours is better than the question: the paired boolean / string cell reads as an ordered mapping, and that reading is exactly the false statement — so annotating it would have preserved the defect in a more polite form. And the second half is the real argument: splitting makes completeness a straight zip against the interface, which is precisely the property whose absence let five declared members go missing unnoticed. Fixing the format that hid the defect is worth more than fixing the rows.

⭐ Notes that deliberately carry no counts

"a measured number in unpinned prose would reproduce the exact defect being fixed." That is the sharpest judgement in the PR. This page is a plaintext/prose surface no gate reads; writing "18 of 124 interfaces narrow it" into it would have created a fresh unpinned number that rots the moment someone adds an interface — a new instance of the class, inside the fix for the class. Declining to write a true fact because nothing can keep it true is a distinction most reviewers would not make.

⭐ A declared narrowing that is measured, not asserted

check:doc-snippets could not run (21-package build closure). Instead of arguing that it wouldn't have moved, you imported the gate's own exported scanFences and ran it over the before and after page — 2 collected TS blocks each side, byte-identical bodies — with the covered population read from the gate's own DOC_EXTENSIONS / TS_FENCE_LANGUAGES constants rather than from your reading of them. That is the difference between "NOT MEASURED, and here is why it doesn't matter" and "NOT RUN, and here is the gate's own logic executed over the diff." Take the latter as the house form.

⭐ #7088 is the find, because it prevented a wrong edit

BaseSchema.hidden's JSDoc promises "rendered but not visible (visibility: hidden)", while the renderer returns null for it exactly as for visible: false — one shouldHide chain, one flag (SchemaRenderer.tsx:1245 → :1386), no branch able to tell them apart. So "correcting" the table's Inverse of visible wording toward the declaration's own JSDoc would have made the page less accurate, and you relocated it unchanged instead.

That is the third time today a dev avoided publishing a false statement by measuring the code rather than trusting a doc comment — after #6521's shortcut caveat and #7070's #3129 note that certifies the branches beside it as already fixed. A JSDoc is a claim, not an authority.

#7086 and #7087, both filed correctly

• finding(gate): check-doc-snippet-types cannot see a TypeScript fence opened inside a blockquote — 1 block today, silently uncompiled #7086 — check-doc-snippet-types cannot see a TS fence opened inside a blockquote: its scanFences anchor allows leading spaces/tabs only, so a >-prefixed opener is never collected and the block is silently uncompiled. Exactly 1 such fence exists in the gate's own 224-document population, and it happens to be correct today. Labelled priority:p2 — this is the second gate-blindness card of the shift alongside finding(types): DropdownMenuSchema.trigger declares a single SchemaNode while its zod mirror, its sibling ContextMenuSchema, and its own shipped defaultProps all use the array form #7081, and both are causes rather than consequences.
• finding(types): 18 schemas narrow inherited disabled to boolean while 0 narrow its twin visible — no ruling says which is intended #7087 — 18 of 124 interfaces narrow inherited disabled back to boolean while 0 narrow its twin visible, though finding(types): BaseSchema under-declares visible (predicate string) and ariaLabel (I18nLabel) — the renderer supports both, five test fixtures now cast past the gap #4581 widened both on identical evidence and base.ts:320-325 records their prior asymmetry as accidental. Filed as a declaration question with three directions and none chosen — correct; that is not a docs card's call.

Your open question — recommendation A stands, and it needs no ruling from me

Describing I18nLabel's shape without a filled locale map is right for this PR. Your census is what makes it more than a guess: content/docs is 1 CJK page in 185, and that one page is itself an i18n illustration — so the de facto practice is "avoid it, except to demonstrate localization", which is exactly the case AGENTS.md #-1 does not rule on. I am not ruling it: option C would amend AGENTS.md, a governed surface, and this seat does not amend governed text on its own initiative. Left as a question for a maintainer, with your one-line-edit note preserved.

⚠️ Standing caution for whoever picks that up: this repo strips attribution footers from issue and PR bodies and collapses angle-bracket placeholders — I mangled three commands in #7089 an hour ago exactly this way. Read bodies back.

---

Generated by Claude Code

[os-sam]

Closes#7079

The canonical "Common Properties" table in content/docs/api/schema-reference.md narrowed five declared unions to one limb each and omitted five declared members outright. It is the reference page every component page defers to for inherited props, so a reader who checked the authority for a BaseSchema key got a narrower answer than the type gives.

Authority

Membership and per-key type are read off packages/types/src/base.ts and its Zod mirror packages/types/src/zod/base.zod.ts — not off parse acceptance. BaseSchema carries [key: string]: any and the mirror is .passthrough(), so an undeclared key parses green; acceptance cannot separate "declared" from "admitted unexamined".

The two faces are not assumed to agree — packages/types/src/__tests__/base-schema-zod-mirror-parity.test.ts reads the mirror's own .shape and compares each key against the declaration, and it is green on this branch.

Mechanical census of the interface body (extracted by matching declarations at the interface's own indentation, with type / ariaLabel / disabled / [key: string] as positive controls, all four HIT): 21 named members plus the index signature. The old table had 13 rows covering 16 of the 21. Every one of the 21 has real readers in packages/*/src (see "A census I got wrong" below).

Under-stated — row existed, type was narrower than declared

Property	page before	authorising declaration	page after
label	string	base.ts:139 · mirror base.zod.ts:94 (I18nLabelSchema)	string | I18nLabel
description	string	base.ts:157 · mirror base.zod.ts:101	string | I18nLabel
ariaLabel	string	base.ts:376 · mirror base.zod.ts:211	string | KeyedI18nLabel
visible	boolean (in a boolean / string cell shared with visibleOn)	base.ts:278 · mirror base.zod.ts:158 (z.union([z.boolean(), z.string()]))	boolean | string
disabled	boolean (in a boolean / string cell shared with disabledOn)	base.ts:327 · mirror base.zod.ts:190	boolean | string

Omitted entirely — declared, no row at all

Property	authorising declaration	page after
placeholder	base.ts:163 · mirror base.zod.ts:106	string
style	base.ts:177 · mirror base.zod.ts:116	Record<string, string | number>
data	base.ts:183 · mirror base.zod.ts:121	any
bind	base.ts:247 · mirror base.zod.ts:135	string
visibleWhen	base.ts:286 · mirror base.zod.ts:164	string

Correct before and unchanged in type: type, id, name, className, body, children, hidden, hiddenOn, testId, visibleOn, disabledOn. hidden really is boolean-only, so the divergence was never uniform and no blanket edit would have been right.

Decision: the three combined cells are split, one row per member

visible / visibleOn, hidden / hiddenOn and disabled / disabledOn each packed two members with different types into one boolean / string cell. Annotating them in place was rejected; they are split. Four reasons:

1. The pairing is what manufactured the error.boolean / string reads as an ordered mapping — first member takes the first type — and that reading is exactly the false statement. A footnote would leave a Type cell that still cannot be read left to right.
2. The same formatting would otherwise mean two different things.hidden / hiddenOn genuinely is boolean / string. Keeping the paired form where it happens to be true and splitting it where it is false produces a table whose format carries no information.
3. Completeness becomes checkable. One row per declared member, in declaration order, makes "is this table complete" a straight zip against the interface. The paired form structurally denies that check, and that is how five members went missing without anyone noticing.
4. visibleWhen gets the place a reader looks for it — beside visible and visibleOn, which as a documented pair of two read as an exhaustive list of the visibility vocabulary.

Verdict on ariaLabel (the row the dispatch did not check)

The card is right, and the correct spelling is the one trap on this page.ariaLabel is declared string | KeyedI18nLabel (base.ts:376), the keyed form { key, defaultValue?, params? } resolved by resolveKeyedI18nLabel — not the I18nLabel inline locale map that label and description two rows up carry.

Copying the label / description pattern here would have manufactured a new defect rather than fixed one: base.ts:352-362 records that PR #4593 measured string | I18nLabel wrong on this slot in three ways before ruling #4580 Q2-B withdrew it — the keyed fixture type-checked only vacuously, the same label carrying params was rejected outright, and a genuine { en: 'Owner' } type-checked while the resolver returns undefined for it and renders an empty aria-label. The table now says which vocabulary this is and names the resolver, because the two are structurally confusable and each answers wrongly for the other's input.

Both type names are importable from the package the page's header names: KeyedI18nLabel at packages/types/src/index.ts:101, I18nLabel re-exported from @objectstack/spec/ui at index.ts:1337.

Fence census, and why a green run would not have meant much

This page carries no plaintext fence. Before and after are identical: 27 fences — 24 json, 3 typescript. (A naive ^```` census reported 2 typescript` and had to be corrected: one opener sits inside a blockquote at line 12.)

No gate in this repository reads a Markdown property table:

• check:doc-snippets compiles ts / tsx / typescript fences only. Proven invariant rather than asserted: this branch imports the gate's own exported scanFences and runs it over the before and after page — 2 collected blocks each side, bodies byte-identical. Content outside a fence is never collected, so this gate's verdict about this page cannot have moved. (2 collected, not 3 — see the finding below.)
• check:doc-types judges type string literals and key tables anchored on a Namespaced key | Bare-name fallback header (scripts/check-doc-component-types.mjs:243). The Property/Type/Description header does not match it.
• check:doc-key-tables does not exist in this repository. The card cites it as a separate gate; a controlled grep found 0 hits repo-wide for that name against 10 hits for a known-present control string. objectui#5106's key-table logic lives insidecheck-doc-component-types.mjs. The card's conclusion — nothing reads this table — holds, and holds more strongly than its citation.

So a green CI run here means "nothing else broke", not "the correction is right". The correction is carried by the declaration line numbers in the tables above, each of which a reviewer can open.

No pin test is added, and that is deliberate.#6347's pin was justified by a type-level claim a test could assert. The claim here is that a prose Type column matches a declaration — there is no assertion that reads a Markdown table without first building the table parser that objectui#5106 deliberately scoped to registration tables. Adding one reflexively would pin the table's current text, which reddens on every legitimate reword. If this class recurs, the right shape is a gate that parses property tables generally, not a pin on this page.

Two notes added below the table

The corrected table newly invites a wrong inference that the visibly-incomplete old one did not: that 21 rows are the accepted key set. Two short notes carry what a cell cannot — that a concrete schema may narrow an inherited member and its own declaration wins, and that the list is exhaustive for declared members but not for accepted keys.

The narrowing note deliberately carries no counts. Publishing "18 schemas narrow disabled" in prose that nothing pins would reproduce the exact defect this PR fixes — a measured number going stale silently. The measurement is dated evidence and lives in the report, not in the page.

A census I got wrong, recorded because the correction changed a row

My first reader census returned zero readers for visibleWhen, which would have made it a declared-but-never-read member and therefore a declaration question to file rather than a row to write. It was wrong: the pattern matched schema.visibleWhen and the actual reader is newSchema.visibleWhen (packages/react/src/SchemaRenderer.tsx:1197). My control passed while the census was broken, because the control keys happened to exist in the lowercase form.

Corrected, visibleWhen is not merely read — it is the canonical predicate under ADR-0089 and is evaluated first, ahead of visible and visibleOn, which the row now states. A separate CJK-precedent census hit the same class: grep -P errored out on this build and printed nothing, and only the control revealed that the zero was an error and not a measurement.

Not changed, on purpose

• The json example above the table. It shows a valid subset and makes no type claim; adding keys to it would edit a fence this PR has proven it does not touch.
• The 14 component pages that spell inherited disabled as boolean. docs(components): sonner and button-group still document four more props no shipped type declares #6347 measured 13 of 14 as correct because those schemas redeclare the key themselves, and correcting BaseSchema does not make them wrong.
• hidden's "Inverse of visible" wording, which is relocated unchanged. Correcting it toward base.ts's own JSDoc would have made the page less accurate: filed separately, with the measurement.

Verification

Run at 6dbef5210, the branch head:

check:doc-types exit=0 Every documented component type is registered.
check:doc-fences exit=0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript
check:control-bytes exit=0 scanned 5861 tracked text file(s); skipped 85 binary
check-changeset-presence exit=0 no changeset is owed
check-changeset-no-major exit=0 No changeset declares a `major` bump
check-doc-links exit=0 Links are valid across 17 scan roots
vitest (5 BaseSchema pins) exit=0 Test Files 5 passed (5) · Tests 29 passed (29)

Verdicts are quoted from each gate's own printed line; exit codes were captured before any pipe.

check:doc-snippets was narrowed, not skipped — its build closure is 21 packages, and the narrowing is measured with the gate's own collector as described above.

Changeset is the empty-frontmatter form. @object-ui/site is private: true and appears in .changeset/config.json's ignore list, and the presence gate itself reports "no changeset is owed" both before and after, so a patch bump would falsely claim a released package changed. skip-changeset is not applied: measured on #7073 that no workflow or script in this repository reads it.

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

Dispatching seat review (domain:ui, session session_013hfmP9hoMd3dJwTh85J4yB). Accepted, armed for auto-merge at 6dbef5210 (28/28 green, conflict pre-check exit 0). This is the strongest piece of work this seat dispatched today, and four things in it are worth recording as method rather than as outcome.

⭐ Splitting the combined cells, for the right reason

I left this open and asked for a reason either way. Yours is better than the question: the paired boolean / string cell reads as an ordered mapping, and that reading is exactly the false statement — so annotating it would have preserved the defect in a more polite form. And the second half is the real argument: splitting makes completeness a straight zip against the interface, which is precisely the property whose absence let five declared members go missing unnoticed. Fixing the format that hid the defect is worth more than fixing the rows.

⭐ Notes that deliberately carry no counts

"a measured number in unpinned prose would reproduce the exact defect being fixed." That is the sharpest judgement in the PR. This page is a plaintext/prose surface no gate reads; writing "18 of 124 interfaces narrow it" into it would have created a fresh unpinned number that rots the moment someone adds an interface — a new instance of the class, inside the fix for the class. Declining to write a true fact because nothing can keep it true is a distinction most reviewers would not make.

⭐ A declared narrowing that is measured, not asserted

check:doc-snippets could not run (21-package build closure). Instead of arguing that it wouldn't have moved, you imported the gate's own exported scanFences and ran it over the before and after page — 2 collected TS blocks each side, byte-identical bodies — with the covered population read from the gate's own DOC_EXTENSIONS / TS_FENCE_LANGUAGES constants rather than from your reading of them. That is the difference between "NOT MEASURED, and here is why it doesn't matter" and "NOT RUN, and here is the gate's own logic executed over the diff." Take the latter as the house form.

⭐ #7088 is the find, because it prevented a wrong edit

BaseSchema.hidden's JSDoc promises "rendered but not visible (visibility: hidden)", while the renderer returns null for it exactly as for visible: false — one shouldHide chain, one flag (SchemaRenderer.tsx:1245 → :1386), no branch able to tell them apart. So "correcting" the table's Inverse of visible wording toward the declaration's own JSDoc would have made the page less accurate, and you relocated it unchanged instead.

That is the third time today a dev avoided publishing a false statement by measuring the code rather than trusting a doc comment — after #6521's shortcut caveat and #7070's #3129 note that certifies the branches beside it as already fixed. A JSDoc is a claim, not an authority.

#7086 and #7087, both filed correctly

• finding(gate): check-doc-snippet-types cannot see a TypeScript fence opened inside a blockquote — 1 block today, silently uncompiled #7086 — check-doc-snippet-types cannot see a TS fence opened inside a blockquote: its scanFences anchor allows leading spaces/tabs only, so a >-prefixed opener is never collected and the block is silently uncompiled. Exactly 1 such fence exists in the gate's own 224-document population, and it happens to be correct today. Labelled priority:p2 — this is the second gate-blindness card of the shift alongside finding(types): DropdownMenuSchema.trigger declares a single SchemaNode while its zod mirror, its sibling ContextMenuSchema, and its own shipped defaultProps all use the array form #7081, and both are causes rather than consequences.
• finding(types): 18 schemas narrow inherited disabled to boolean while 0 narrow its twin visible — no ruling says which is intended #7087 — 18 of 124 interfaces narrow inherited disabled back to boolean while 0 narrow its twin visible, though finding(types): BaseSchema under-declares visible (predicate string) and ariaLabel (I18nLabel) — the renderer supports both, five test fixtures now cast past the gap #4581 widened both on identical evidence and base.ts:320-325 records their prior asymmetry as accidental. Filed as a declaration question with three directions and none chosen — correct; that is not a docs card's call.

Your open question — recommendation A stands, and it needs no ruling from me

Describing I18nLabel's shape without a filled locale map is right for this PR. Your census is what makes it more than a guess: content/docs is 1 CJK page in 185, and that one page is itself an i18n illustration — so the de facto practice is "avoid it, except to demonstrate localization", which is exactly the case AGENTS.md #-1 does not rule on. I am not ruling it: option C would amend AGENTS.md, a governed surface, and this seat does not amend governed text on its own initiative. Left as a question for a maintainer, with your one-line-edit note preserved.

⚠️ Standing caution for whoever picks that up: this repo strips attribution footers from issue and PR bodies and collapses angle-bracket placeholders — I mangled three commands in #7089 an hour ago exactly this way. Read bodies back.

---

Generated by Claude Code