docs(plugin-calendar): compile the Direct Component Usage block and gate it

[os-justin]

Part of #7311

The ObjectCalendar half of this page's Direct Component Usage block rode a
doc-snippet: fragment declaration, so check:doc-snippets never compiled it. That
declaration named its own repair: add the missing type: 'object-calendar'
discriminant, "not a cast".

Measured on this head, that prescription does not work — and the reason's own
framing says why without following it through. The literal is assigned to an
untyped const first. The reason notes one consequence of that (the
excess-property check does not fire, which is why the calendar member does not
error). There is a second it does not name: an untyped const also widens
type: 'object-calendar' to string, so a discriminant written there can never
satisfy a literal-typed member.

Measurements — mine, one edit at a time

node scripts/check-doc-snippet-types.mjs (= pnpm check:doc-snippets) against the
built --build-filter closure (35/35 turbo tasks successful). Exit codes captured
with redirect-then-capture, never read through a pipe.

run	tree state	exit	TS2741	TS2322
1	pristine — block still a declared fragment	0	0	0
2	fragment marker retired, no discriminant	1	1	0
3	marker retired + type: 'object-calendar'	1	0	1
4	run 3 + const schema: ObjectCalendarSchema + the block's type-only import widened	0	0	0

Run 2 reproduces the fragment reason's own numbers (TS2741 x1 / TS2322 x0) on this
head, so the reason's figures are live and correct. Run 3 is what this PR's
first premise predicted would be enough and is not — verbatim:

[semantic]  content/docs/plugins/plugin-calendar.mdx:559:7  TS2322:
  Type '{ type: string; objectName: string; calendar: {…}; }' is not assignable to type 'ObjectCalendarSchema'.
    Types of property 'type' are incompatible.
      Type 'string' is not assignable to type '"object-calendar"'.

Run 4 is what this PR ships. Re-measured end to end on the pushed tree, not
reused from the probe:

GATE_FINAL_EXIT=0
Covered blocks: 827 — 671 to compile, 156 declared fragment(s).
Semantic phase: 671 of 671 block(s) judged, 0 failed.
Every covered documentation snippet compiles against the built types.

Covered-blocks-to-compile 670 -> 671 and declared fragments 157 -> 156 is the
block moving from exempt to gated, which is the point of this change. The gate's
own controls held on that run: resolution landed on
packages/types/dist/index.d.ts, the sentinel produced its TS2305, the positive
control produced none.

Why annotate rather than leave it inferring

Not a new style for this page. Nine consts here carry the object-calendar
discriminant, and the other eight were already annotated : ObjectCalendarSchema
(fieldMappedCalendar, objectProviderCalendar, valueProviderCalendar,
eventClickCalendar, dateClickCalendar, appointmentCalendar, eventCalendar,
taskCalendar). The Direct Component Usage literal was the lone straggler; it now
joins them.

The fragment declaration is retired with no replacement prose, so the sentence
that is false at this head leaves with it. Verified absent from the committed file:
a search for not a cast over git show HEAD:content/docs/plugins/plugin-calendar.mdx
returns 0.

Scope

CalendarView's half of the block is untouched. packages/plugin-calendar/src/**
and packages/types/** are untouched. No cast, no new fragment reason, no new
UNGATED_DOCS entry — this is a narrowing in both directions.

Clause-②: no. One file changed, under content/docs/. No exported symbol moves
and no key is added to any published payload.

Other gates and pins, run on this tree

check	result
check:doc-snippets	exit 0 (above)
check:changeset-presence	exit 0 — "0 of them published source of a package the release covers … no changeset is owed". No changeset added, on the gate's own verdict.
check:control-bytes	exit 0 (7790 tracked text files)
check:doc-fences	exit 0
check:doc-example-ids	exit 0
check:new-line-citations	exit 0, 0 new citations
check-governed-queue-guard --test	NOT GOVERNED — ordinary PR route
every test declared to read content/docs (16 files)	16 passed, 617 tests

That last row is the full set scripts/markdown-test-inputs.mjs declares as reading
this page or walking content/docs/**, run from the repo root with root-relative
paths.

⚠️ One green that is not evidence

packages/types/src/__tests__/object-calendar-record-source-7313.test.ts asserts
"No bare object-calendar literal is left unannotated on the page". It was green
before this change and it is green after, and that is not evidence this change
landed: its regex is anchored at column 0, so it never could see a literal indented
inside a function, and it also requires the discriminant to be the literal's first
member. Filed as #9676 and ⛔ deliberately not touched here.

What did change is the claim underneath it. Measured on the new page: nine consts
carry the discriminant and all nine are annotated — so the pin's stated claim is
true for the first time, while the instrument that states it remains just as blind.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_012EpHzwH4wTy5sd7ibkD2yq

---

Generated by Claude Code

[github-actions]

changeset-claim-re-read

⚠️ 1 pending changeset(s) describe a file this change touches

Their bodies publish verbatim into the CHANGELOG at the next release, so this is a request to re-read them against your diff — addressed here because you are the one seat that can answer it without re-deriving anything.

⛔ Nothing here blocks, and nothing here is a verdict on your change. This gate exits 0, is not a required context, and judges name resolution, never meaning: it asked whether a pending body names a file you touched. "Is this sentence still true?" is the one question it will not answer, and the one you are being asked to answer.

.changeset/7313-object-calendar-record-source.md

• names content/docs/plugins/plugin-calendar.mdx → content/docs/plugins/plugin-calendar.mdx — edited by this change

  A widening. A node authoring staticData or data without objectName now validates (it always rendered — the read is resolveRecordSourceConfig(schema), keyed on the three). Every document that validated before still validates: objectName alone still parses, an empty one included, because presence is !== undefined. The one shape the refinement refuses (none of the three) was refused before too, at objectName. The two static-data examples in content/docs/plugins/plugin-calendar.mdx are now annotated ObjectCalendarSchema and compile under the doc-snippet gate.

Read the paragraph, not the line: both false halves of the objectui#8617 claim sat in one paragraph, and correcting either alone would have left it asserting the same wrong thing.

If a claim did go false, correct the body. That is precedented and prose-only, frontmatter untouched; check-changeset-overwrite.mjs will report the correction as its own case 2 ("correcting a declaration on purpose … legitimate"), which is the intended shape — one gate asks for the read, the other records the write.

Not covered, stated so nobody reads this as more: a claim that was born false (a changeset this change adds is excluded by construction), a claim spelled as a symbol or a package rather than a backticked file name, and a file named ambiguously.

Compared the checked-out tree with 72f55c9ec (merge-base with origin/main): 1 file(s) changed outside .changeset/, read against 1119 pending declaration(s) that publish a body (1624 pending in total). · run