Found while compiling packages/plugin-gantt/README.md for objectui#5174 batch 18 (PR opened from claude/issue-5174-ungated-docs-batch18). Filed unassigned and NOT fixed there — that batch is barred from widening a public type, and the choice here belongs to a maintainer.
Measured
packages/plugin-gantt/src/index.tsx registers the same renderer under two keys:
ComponentRegistry.register('object-gantt', ObjectGanttRenderer, …)
ComponentRegistry.register('gantt', ObjectGanttRenderer, …) (namespaced view:gantt)
The README's own registration table teaches both spellings as schema type values, and its first Usage block authors type: 'gantt'.
The published declaration admits only one of them. packages/types/dist/objectql.d.ts:
export interface ObjectGanttSchema extends BaseSchema {
type: 'object-gantt';
grep "type: 'gantt'" packages/types/dist/*.d.ts returns nothing: no declared schema interface names the gantt spelling for a component node. So an author who annotates their node — the thing every doc gate and the CLI push people toward — cannot write the key the registry accepts, while an author who leaves the literal bare gets no checking at all (the class objectui#7778 and objectui#7972 record on other surfaces).
It is reachable through the plugin's own typed prop, not only through metadata: ObjectGanttProps.schema is ObjectGanttSchema, so passing a type: 'gantt' node to the ObjectGantt element is TS2322 — Type '"gantt"' is not assignable to type '"object-gantt"'. That is one of the 26 diagnostics the gate measured on this README, and the reason the direct-render example in it was moved to the object-gantt spelling rather than annotated. The registration table was left as it is: it describes the registry truthfully.
Why it is a decision, not a repair
Three routes, all of them a published-contract change:
- Widen
ObjectGanttSchema.type to 'object-gantt' | 'gantt' — matches the registry, but the flatteners (plugin-view/src/ObjectView.tsx, plugin-list/src/ListView.tsx) emit object-gantt, so a second accepted spelling starts a dialect the way Commandment #0.1 warns about.
- Declare a separate view-type schema for the
gantt key, if that key is meant only as a list/object VIEW type rather than a component node type.
- Rule the bare
gantt node spelling unauthorable and stop teaching it in the registration table (the registry entry can stay for the view:gantt lookup).
Nothing here is broken at runtime: the registered renderer takes schema: any, so both spellings mount and draw. The cost is that the typed surface and the documented surface disagree, and the disagreement only surfaces when someone finally annotates.
Dedup search ran first (targeted search_issues, 28 hits reviewed): objectui#6475 is the gantt BLOCK face on this schema, not the type literal; objectui#7470 is the designer-facing inputs; objectui#7778 / #7972 are bare-const literals on doc surfaces. None is this defect.
Found while compiling
packages/plugin-gantt/README.mdfor objectui#5174 batch 18 (PR opened fromclaude/issue-5174-ungated-docs-batch18). Filed unassigned and NOT fixed there — that batch is barred from widening a public type, and the choice here belongs to a maintainer.Measured
packages/plugin-gantt/src/index.tsxregisters the same renderer under two keys:ComponentRegistry.register('object-gantt', ObjectGanttRenderer, …)ComponentRegistry.register('gantt', ObjectGanttRenderer, …)(namespacedview:gantt)The README's own registration table teaches both spellings as schema
typevalues, and its first Usage block authorstype: 'gantt'.The published declaration admits only one of them.
packages/types/dist/objectql.d.ts:grep "type: 'gantt'" packages/types/dist/*.d.tsreturns nothing: no declared schema interface names theganttspelling for a component node. So an author who annotates their node — the thing every doc gate and the CLI push people toward — cannot write the key the registry accepts, while an author who leaves the literal bare gets no checking at all (the class objectui#7778 and objectui#7972 record on other surfaces).It is reachable through the plugin's own typed prop, not only through metadata:
ObjectGanttProps.schemaisObjectGanttSchema, so passing atype: 'gantt'node to theObjectGanttelement is TS2322 —Type '"gantt"' is not assignable to type '"object-gantt"'. That is one of the 26 diagnostics the gate measured on this README, and the reason the direct-render example in it was moved to theobject-ganttspelling rather than annotated. The registration table was left as it is: it describes the registry truthfully.Why it is a decision, not a repair
Three routes, all of them a published-contract change:
ObjectGanttSchema.typeto'object-gantt' | 'gantt'— matches the registry, but the flatteners (plugin-view/src/ObjectView.tsx,plugin-list/src/ListView.tsx) emitobject-gantt, so a second accepted spelling starts a dialect the way Commandment #0.1 warns about.ganttkey, if that key is meant only as a list/object VIEW type rather than a component node type.ganttnode spelling unauthorable and stop teaching it in the registration table (the registry entry can stay for theview:ganttlookup).Nothing here is broken at runtime: the registered renderer takes
schema: any, so both spellings mount and draw. The cost is that the typed surface and the documented surface disagree, and the disagreement only surfaces when someone finally annotates.Dedup search ran first (targeted
search_issues, 28 hits reviewed): objectui#6475 is theganttBLOCK face on this schema, not thetypeliteral; objectui#7470 is the designer-facinginputs; objectui#7778 / #7972 are bare-const literals on doc surfaces. None is this defect.