Found by the objectui#7313 dev while landing the calendar half of that card (PR #7777) — the calendar page's two static-data blocks were annotated as that card's completion signal, and the gantt page turns out to carry the same hole. Filed unassigned, observation class; not fixed in PR #7777 because plugin-gantt.mdx is outside that dispatch's scope. Written by an agent session (session_01BAZFhALsQsGqxui8sNqM8s); attribution is in this sentence on purpose.
What
content/docs/plugins/plugin-gantt.mdx on origin/main at 16a725f9 has FOUR object-gantt schema literals declared as bare const NAME = { … } with no type annotation and no doc-snippet: fragment marker:
:79 const schema = { type: 'object-gantt', staticData: […], … } (the "With Static Data" section):238 const valueProviderGantt = { type: 'object-gantt', staticData: […], … } ("Value Provider (Static)"):255 const apiProviderGantt = { type: 'object-gantt', data: { provider: 'api', … }, … } ("API Provider"):354 const campaignGantt = { type: 'object-gantt', staticData: […], … }
Six sibling blocks on the same page (:63, :157, :223, :321, :339 and the block after :319) are annotated const NAME: ObjectGanttSchema = { … } with import type { ObjectGanttSchema } from '@object-ui/types'.
Why it is a hole now, and was not before
The four were left bare by the objectui#5174 batch-6 pass deliberately: annotating them produced TS2741: Property 'objectName' is missing, because ObjectGanttSchema.objectName was required and none of these routes authors it (objectui#7313's body records that decision). PR #7471 (77cb489b, objectui#6939 group 6) made objectName optional on both faces and declared data; since then every one of the four is assignable to ObjectGanttSchema, and the reason for leaving them bare is gone. Bare, they "compile and are counted, but their keys are unchecked" (the batch-6 wording) — a typo in staticData or a wrong-typed data on those blocks is invisible to check:doc-snippets.
Suggested repair (small, docs only)
Annotate the four with ObjectGanttSchema and add the page's existing type import above each, exactly as PR #7777 did for the calendar page's two blocks (plugin-calendar.mdx :210, :310). The apiProviderGantt block is typed against the declared data?: ViewData, so it also becomes a real check that the documented api-provider config matches the spec's ViewData. No prose changes. CI's Doc Snippet Type Check is the measurement.
Not measured here (⛔ not a claim): whether all four compile clean once annotated — :255's data block may carry keys the spec's ViewDataSchema refuses; if so that is a documentation defect the annotation would surface, which is the point.
Related: objectui#7313 (parent — the calendar half, PR #7777), objectui#6939 / PR #7471 (the type change that removed the reason), objectui#7470 (registration inputs still declaring objectName required — a different face of the same class).
Found by the objectui#7313 dev while landing the calendar half of that card (PR #7777) — the calendar page's two static-data blocks were annotated as that card's completion signal, and the gantt page turns out to carry the same hole. Filed unassigned, observation class; not fixed in PR #7777 because
plugin-gantt.mdxis outside that dispatch's scope. Written by an agent session (session_01BAZFhALsQsGqxui8sNqM8s); attribution is in this sentence on purpose.What
content/docs/plugins/plugin-gantt.mdxonorigin/mainat16a725f9has FOURobject-ganttschema literals declared as bareconst NAME = { … }with no type annotation and nodoc-snippet: fragmentmarker::79const schema = { type: 'object-gantt', staticData: […], … }(the "With Static Data" section):238const valueProviderGantt = { type: 'object-gantt', staticData: […], … }("Value Provider (Static)"):255const apiProviderGantt = { type: 'object-gantt', data: { provider: 'api', … }, … }("API Provider"):354const campaignGantt = { type: 'object-gantt', staticData: […], … }Six sibling blocks on the same page (
:63,:157,:223,:321,:339and the block after:319) are annotatedconst NAME: ObjectGanttSchema = { … }withimport type { ObjectGanttSchema } from '@object-ui/types'.Why it is a hole now, and was not before
The four were left bare by the objectui#5174 batch-6 pass deliberately: annotating them produced
TS2741: Property 'objectName' is missing, becauseObjectGanttSchema.objectNamewas required and none of these routes authors it (objectui#7313's body records that decision). PR #7471 (77cb489b, objectui#6939 group 6) madeobjectNameoptional on both faces and declareddata; since then every one of the four is assignable toObjectGanttSchema, and the reason for leaving them bare is gone. Bare, they "compile and are counted, but their keys are unchecked" (the batch-6 wording) — a typo instaticDataor a wrong-typeddataon those blocks is invisible tocheck:doc-snippets.Suggested repair (small, docs only)
Annotate the four with
ObjectGanttSchemaand add the page's existing type import above each, exactly as PR #7777 did for the calendar page's two blocks (plugin-calendar.mdx:210,:310). TheapiProviderGanttblock is typed against the declareddata?: ViewData, so it also becomes a real check that the documented api-provider config matches the spec'sViewData. No prose changes. CI'sDoc Snippet Type Checkis the measurement.Not measured here (⛔ not a claim): whether all four compile clean once annotated —
:255'sdatablock may carry keys the spec'sViewDataSchemarefuses; if so that is a documentation defect the annotation would surface, which is the point.Related: objectui#7313 (parent — the calendar half, PR #7777), objectui#6939 / PR #7471 (the type change that removed the reason), objectui#7470 (registration
inputsstill declaringobjectNamerequired — a different face of the same class).