docs(plugin-gantt): annotate the four bare object-gantt literals (objectui#7778)

[baozhoutao]

Fixes #7778

What moved

Annotated the four bare object-gantt literals on content/docs/plugins/plugin-gantt.mdx that PR #7471 (objectui#6939) left uncovered once it made ObjectGanttSchema.objectName optional and declared data — the TS2741 that forced them bare is gone, so check:doc-snippets now actually consults ObjectGanttSchema for these blocks instead of compiling them structurally with no target type.

line	name	annotated	compiles clean?
:81 (was :79)	schema ("With Static Data")	: ObjectGanttSchema + import type above	yes
:242 (was :238)	valueProviderGantt	: ObjectGanttSchema + import type above	yes
:261 (was :255)	apiProviderGantt	: ObjectGanttSchema + import type above	yes — its data: { provider: 'api', read: { url, method } } is a real check against the spec's ViewDataSchema discriminated union now, and it passes clean (no endpoint key, read shape matches HttpRequestSchema)
:362 (was :354)	campaignGantt	: ObjectGanttSchema + import type above	yes

Form matches the page's five existing annotated siblings exactly (own import type { ObjectGanttSchema } from '@object-ui/types' immediately above each const). No prose changed — git diff --stat is 12 insertions / 4 deletions on one file, all four hunks are import-line + type-annotation only.

What did NOT move, and why (premise check on the one licensed extra)

The claim seat's dispatch instructed doing the "one remaining bare literal" on plugin-calendar.mdx:160 too, described as const schema = {, same form, ObjectCalendarSchema. On origin/main today, line 158 (immediately above that fence) already carries a doc-snippet: fragment marker comment, and the block itself reads:

const schema = {
  type: 'calendar-view',
  data: events,
  allowCreate: true,
}

The marker's written reason: it is a shape excerpt continuing the "CalendarView Usage" block above, where the event array is written inline — events is the reader's own data and is not defined in this block (measured: TS2552 x1).

Two things falsify the premise: its type is 'calendar-view', not 'object-calendar' — it is a CalendarViewSchema fragment, not an ObjectCalendarSchema literal, so annotating it : ObjectCalendarSchema would be a straight type mismatch, not a completion of the same class. And it already carries a proper doc-snippet: fragment marker with a written, gate-recognized reason (events is the reader's own data, undefined in this excerpt) — it is not a hole in check:doc-snippets' accounting, it is the gate's own declared-fragment mechanism working as designed. The triage's census method (bare const NAME = { within 2 lines of a type: key) counted it without checking for a fragment marker above the fence, which is how it got flagged as a fourth completion target. Left untouched; plugin-calendar.mdx has zero diff in this PR.

Ablation (mechanism re-verification, A2)

Committed the real fix first (aa42f8035), then mutated the newly-annotated apiProviderGantt block in place — injected readOnly: 'yes' (schema declares readOnly?: boolean) — ran pnpm check:doc-snippets, and restored via git checkout HEAD -- content/docs/plugins/plugin-gantt.mdx.

• Before mutation: blob 2c6f59c…
• Mutated: blob 9663ebf… (differs, mutation landed on disk)
• Gate: exit 1, [semantic] content/docs/plugins/plugin-gantt.mdx:263:3 TS2322: Type 'string' is not assignable to type 'boolean | undefined'. — Semantic phase: 542 of 542 block(s) judged, 1 failed.
• Restore: blob 2c6f59c… again (matches before), git diff HEAD empty, git status --porcelain empty
• Re-run after restore: exit 0, Semantic phase: 542 of 542 block(s) judged, 0 failed.

Confirms the annotation is load-bearing: a wrong-typed key on the block the gate previously compiled unchecked now reds by name and line.

Gates (final HEAD aa42f8035, forced build first)

• NODE_OPTIONS=--max-old-space-size=4096 turbo run build --filter=./packages/* --concurrency=2 --force — 39/39 successful, exit 0
• pnpm check:doc-snippets — exit 0, Semantic phase: 542 of 542 block(s) judged, 0 failed
• pnpm check:doc-fences — exit 0
• pnpm check:doc-types — exit 0, every documented component type registered
• node scripts/check-doc-links.mjs — exit 0, links valid across 17 scan roots
• pnpm check:doc-example-readers — exit 0
• pnpm check:control-bytes — exit 0 (6452 tracked text files scanned); grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]' self-scan of both pages — no hits (grep exit 1)
• node scripts/check-changeset-presence.mjs — exit 0, no changeset owed (docs-only, no released package's source or contract moved)
• node scripts/check-governed-queue-guard.mjs --test content/docs/plugins/plugin-gantt.mdx content/docs/plugins/plugin-calendar.mdx — NOT GOVERNED, 0 of 2 matched
• Reader search (A3): git grep -l "plugin-gantt\.mdx" -- '*.test.*' — 0 hits, no pin names this page. plugin-calendar.mdx is named by 3 test files (unaffected — that page has zero diff here); ran all three via pnpm exec vitest run --maxWorkers=2 <files> — 3 files / 115 tests passed

Out of scope

None filed. The corpus census (36 sites) and plugin-charts.mdx's 10 are the triage's own explicit exclusions; nothing new was found while working this card. The plugin-calendar.mdx:160 question above is a premise correction, not a new finding requiring its own card — it's a correct, already-declared fragment, not a defect.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FhBNJcLRZLe8M87VcUgpKr

[baozhoutao]

Standing-down note — Live E2E (informational) is red on main and on every branch today: the upstream base-red anchored on #7990 (objectstack#16186). It is continue-on-error by design, never blocks the queue, and touches nothing this diff changes (four annotations on one doc page). Not this PR's to fix; no re-run requested. ACCEPTed on the card (#7778); flip and arming follow once the remaining checks conclude.

---

Generated by Claude Code