docs(plugins,utilities): clear three more .mdx pages off the doc-snippet ledger (#5174 batch 6)

[yinlianghui]

Part of #5174

Batch 6 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 41 blocks, 33 compile against the built dist, 8 carry a FRAGMENT_MARKER with a written, measured reason. 74 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 5 (#7294) landed while this was in flight; origin/main was merged (never rebased) and the two ledger hunks are disjoint removals, as predicted.

Pages taken, and how each block reached zero

All counts produced with the gate's own scanFences, not a hand grep.

page	blocks	compile	declared	diagnostics cleared	real defects found, and the shipped type each was checked against
content/docs/plugins/plugin-calendar.mdx	15	12	3	28 (19 syntax, 9 semantic)	calendar.descriptionField is fabricated — not a member of @objectstack/spec's CalendarConfigSchema (which is $strict and holds exactly startDateField, endDateField, titleField, colorField) and read at zero sites in packages/plugin-calendar; ObjectCalendar.tsx:420 destructures exactly those four. Removed from the "Appointment Scheduler" example and from the published CalendarConfig reference. The "TypeScript Support" section annotated an object-calendar node as ObjectGridSchema — an annotation that cannot hold, since ObjectGridSchema.type is the literal 'object-grid'; repointed to the real ObjectCalendarSchema.
content/docs/utilities/data-objectstack.mdx	14	11	3	17 (0 syntax, 17 semantic)	No fabricated API. Eight blocks were unrunnable as written — a reader copying one got Cannot find name 'createObjectStackAdapter' / 'User' / 'dataSource' / 'mySchema' — and were made self-contained against packages/data-objectstack/dist/index.d.ts. The factory's config signature block was verified member-for-member against the shipped createObjectStackAdapter declaration, and the ElementDataSource restatement member-for-member against ElementDataSourceSchema in the installed @objectstack/spec: both accurate.
content/docs/plugins/plugin-gantt.mdx	12	10	2	29 (26 syntax, 3 semantic)	No fabricated key surfaced. The "Task Click" example rendered ObjectGantt with neither the component nor dataSource in scope — a copy-paste example broken at its first line; rewritten as a real component taking a typed DataSource prop. Six bare object literals became annotated ObjectGanttSchema declarations, which puts their gantt: { … } blocks under GanttConfig for the first time.

Ledger 40 → 37 (6 .mdx + 31 README). Covered documents 184 → 187 — strictly grows. Covered blocks 440 → 481; compiled 312 → 345; declared fragments 128 → 136. The three per-page splits (12+11+10 = 33 compile, 3+3+2 = 8 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — git diff origin/main -- scripts/check-doc-snippet-types.mjs is 0 additions, 6 deletions.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, origin/main vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batch 5 recorded.
• Covered count strictly grows — 184 → 187, ungated 40 → 37.
• Every page taken is off the ledger and every block resolves the two honest ways — compile, or a FRAGMENT_MARKER whose reason names the measured diagnostics. No third route, no UNGATED_DOCS addition, no fence re-labelled to duck the gate.

Before / after, both at a fully built tree, exit codes captured by redirect-then-$? and never through a pipe:

BEFORE (origin/main dd5b01b59 content for the four files, swapped in under an
EXIT/INT/TERM trap; restore proved by an empty `git diff HEAD`)
Scanned 224 document(s): 184 covered (83 hold a ts/tsx block), 40 ungated
Covered blocks: 440 — 312 to compile, 128 declared fragment(s)
Semantic phase: 312 of 312 block(s) judged, 0 failed exit 0
AFTER (355dd8daa)
Scanned 224 document(s): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0

The lid check, per page — including the negative results

Resolving an unresolved name can uncover diagnostics the first error was hiding. Run on all three:

• plugin-gantt.mdx — NEGATIVE. Clearing 26 parse failures and the ObjectGantt / dataSource undefined names exposed nothing underneath: the re-run was clean. Reported as a negative result.
• data-objectstack.mdx — NEGATIVE. Eight blocks' worth of TS2304 resolved and the re-run was clean. The two prose blocks that survive as declared fragments were then checked by hand against the shipped declaration and against @objectstack/spec, and both are accurate.
• plugin-calendar.mdx — POSITIVE, once. With the block's own names resolved, ObjectCalendarComponentProps.schema turned out to be typed ObjectGridSchema | CalendarSchema, and no object-calendar node is assignable to either — ObjectGridSchema.type is the literal 'object-grid' and CalendarSchema is the form date picker (type: 'calendar'). Filed as finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311, not cast around.

The read-site grep — what the compiler structurally cannot see

BaseSchema carries [key: string]: any, so a wrong TOP-LEVEL key on any schema literal is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites, and that is what caught the descriptionField defect: zero read sites anywhere in packages/plugin-calendar, while the page taught it twice. The check found nothing further on the gantt or data-objectstack literals.

What the green does not mean

Stated because a green run must not be read as more than it is, and each limit below was measured on these pages by planting a probe, running the gate, and restoring from HEAD under a trap:

1. A misspelled top-level key on a schema literal is not caught. Probe: ganttt: 'typo-probe' added to an annotated ObjectGanttSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside gantt: { … } is not caught either. Probe: startDateFeild inside the gantt block. Gate stayed green — GanttConfig is SpecGanttConfig & { … } and the spec's GanttConfigSchema is z.core.$loose, so the intersection admits unknown keys. (Note the asymmetry with the authoring surface: the spec's CalendarConfigSchema is $strict, so the same typo in a calendar block would be rejected at parse time even though this gate cannot see it.)
3. calendar: { … } is wholly unchecked.ObjectCalendarSchema does not declare a calendar member — unlike ObjectGanttSchema, which does declare gantt — so that block lands on the index signature. The four keys used on this page were validated by read-site grep instead.
4. What IS checked, proved rather than assumed. Two probes went red, so the annotations are live and not no-ops: viewMode: 'century' on the gantt literal → TS2322: Type '"century"' is not assignable to type '"month" | "week" | "day" | "quarter" | "year" | undefined'; defaultView: 'agenda' on the calendar literal → TS2322: Type '"agenda"' is not assignable to type '"month" | "week" | "day" | undefined'. A third, type: 'object-calendar' under an ObjectGridSchema annotation on the data-objectstack page, also went red. Declared members are checked; undeclared keys are not.
5. The gate answers only "does this snippet compile against the published types". Schema-key validity under safeParse, whether a type literal names a registered component, and whether a shell example runs are three other questions with three other answers.

Type gaps found and filed, not fixed here

packages/* source is out of this PR's surface, so both were filed unassigned after a targeted dedupe search, and the blocks they affect ship declared rather than deleted:

• finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311 — ObjectCalendarComponentProps.schema is ObjectGridSchema | CalendarSchema, so the page's own Direct Component Usage section cannot type-check. ObjectCalendar.tsx reaches the node through (schema as any).calendar and the registered renderer passes an object-calendar node to it, so the runtime path is real and the declaration is the stale half — the same shape already fixed for the map (ObjectMapSchema(types)声明的键几乎与 ObjectMap 实际读的键无交集:map 块整体未建模,组件 props 类型写的是 ObjectGridSchema,每处 map 读取都走 as any #5018) and the gantt (ObjectGantt reads 11 top-level schema keys that ObjectGanttSchema does not declare — all via as any, so nothing connects read to declaration #5903). That block carries a FRAGMENT_MARKER naming the card; it becomes a compiling block the day the prop names ObjectCalendarSchema.
• finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 — objectName is declared required on ObjectGanttSchema and ObjectCalendarSchema, while both renderers' getDataConfig tries data, then staticData, then objectName. The documented static-data and api-provider routes are therefore supported paths the type rejects (TS2741). Those four blocks ship as plain const declarations with no annotation — they compile and are counted, but their keys are unchecked — rather than inventing an objectName the route does not use. Same shape as finding(types): ObjectMapSchema.objectName is declared REQUIRED but ObjectMap treats it as optional — the documented static-data route cannot be annotated #7296 on ObjectMapSchema; filed separately because that card is scoped to the map by title and body.

Gate verdict lines

Everything below at 355dd8daa, the final commit, with the closure built first under the shared verify lock (VERDICT command-exit 0) and dist/index.d.ts presence confirmed on disk in this worktree before any gate result was trusted — turbo replays cached logs naming other worktrees' paths.

check:doc-snippets exit 0 Semantic phase: 345 of 345 block(s) judged, 0 failed.
Every covered documentation snippet compiles against the built types.
check:doc-fences exit 0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript …
check:doc-types exit 0 Every documented component type is registered.
docs:check-links exit 0 Links are valid across 17 scan roots.
check:control-bytes exit 0 scanned 6010 tracked text file(s); skipped 85 binary
check:readme-exports exit 0 386 self-imports judged (386 real, 0 wrong-path, 0 fabricated)
check-changeset-presence exit 0 No source or published contract of a released package changed in
this range, so no changeset is owed.
vitest (repo root) exit 0 Test Files 7 passed (7) · Tests 177 passed (177)

The seven vitest files are every file git grep -l check-doc-snippet-types -- '*.test.ts' '*.test.tsx' names — the two obvious ones plus five pin suites in examples/schema-catalog, plugin-gantt, react and types that an edit to this script could have hijacked. Run from the repo root with --maxWorkers=2, never through pnpm --filter.

check:readme-exports first read NOT MEASURED, not red: it exited 1 with three findings, all three the string its type entry ./dist/index.d.ts is not on disk -- run pnpm build first for plugin-ai, and none naming a file in this diff. Building that closure made it a real measurement, and it is genuinely green.

Declared narrowing

Repo-wide pnpm lint was narrowed to the four changed files, and the narrowing is a measurement rather than a skip:

1. Population read from ESLint's own config, not from a guess: npx eslint --no-inline-config --format json on the four files reports the three .mdx pages as File ignored because no matching configuration was supplied — they are not in ESLint's population at all.
2. File count read from the JSON output: 4 files judged, 1 of them actually linted (scripts/check-doc-snippet-types.mjs), 0 errors, 0 warnings.
3. Config invariance for untouched files: eslint.config.js sets no project, projectService or tsconfigRootDir, so type-aware linting is not enabled and nothing in this diff can move the verdict on a file it does not touch.

A control-byte self-scan (grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]') over the four changed files returns no hits, beside the repo-wide gate above.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01BGMDbrVa8JjZcCQ7DWYH1b

---

Generated by Claude Code

[yinlianghui]

Part of #5174

Batch 6 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 41 blocks, 33 compile against the built dist, 8 carry a FRAGMENT_MARKER with a written, measured reason. 74 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 5 (#7294) landed while this was in flight; origin/main was merged (never rebased) and the two ledger hunks are disjoint removals, as predicted.

Pages taken, and how each block reached zero

All counts produced with the gate's own scanFences, not a hand grep.

page	blocks	compile	declared	diagnostics cleared	real defects found, and the shipped type each was checked against
content/docs/plugins/plugin-calendar.mdx	15	12	3	28 (19 syntax, 9 semantic)	calendar.descriptionField is fabricated — not a member of @objectstack/spec's CalendarConfigSchema (which is $strict and holds exactly startDateField, endDateField, titleField, colorField) and read at zero sites in packages/plugin-calendar; ObjectCalendar.tsx:420 destructures exactly those four. Removed from the "Appointment Scheduler" example and from the published CalendarConfig reference. The "TypeScript Support" section annotated an object-calendar node as ObjectGridSchema — an annotation that cannot hold, since ObjectGridSchema.type is the literal 'object-grid'; repointed to the real ObjectCalendarSchema.
content/docs/utilities/data-objectstack.mdx	14	11	3	17 (0 syntax, 17 semantic)	No fabricated API. Eight blocks were unrunnable as written — a reader copying one got Cannot find name 'createObjectStackAdapter' / 'User' / 'dataSource' / 'mySchema' — and were made self-contained against packages/data-objectstack/dist/index.d.ts. The factory's config signature block was verified member-for-member against the shipped createObjectStackAdapter declaration, and the ElementDataSource restatement member-for-member against ElementDataSourceSchema in the installed @objectstack/spec: both accurate.
content/docs/plugins/plugin-gantt.mdx	12	10	2	29 (26 syntax, 3 semantic)	No fabricated key surfaced. The "Task Click" example rendered ObjectGantt with neither the component nor dataSource in scope — a copy-paste example broken at its first line; rewritten as a real component taking a typed DataSource prop. Six bare object literals became annotated ObjectGanttSchema declarations, which puts their gantt: { … } blocks under GanttConfig for the first time.

Ledger 40 → 37 (6 .mdx + 31 README). Covered documents 184 → 187 — strictly grows. Covered blocks 440 → 481; compiled 312 → 345; declared fragments 128 → 136. The three per-page splits (12+11+10 = 33 compile, 3+3+2 = 8 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — git diff origin/main -- scripts/check-doc-snippet-types.mjs is 0 additions, 6 deletions.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, origin/main vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batch 5 recorded.
• Covered count strictly grows — 184 → 187, ungated 40 → 37.
• Every page taken is off the ledger and every block resolves the two honest ways — compile, or a FRAGMENT_MARKER whose reason names the measured diagnostics. No third route, no UNGATED_DOCS addition, no fence re-labelled to duck the gate.

Before / after, both at a fully built tree, exit codes captured by redirect-then-$? and never through a pipe:

BEFORE (origin/main dd5b01b59 content for the four files, swapped in under an
EXIT/INT/TERM trap; restore proved by an empty `git diff HEAD`)
Scanned 224 document(s): 184 covered (83 hold a ts/tsx block), 40 ungated
Covered blocks: 440 — 312 to compile, 128 declared fragment(s)
Semantic phase: 312 of 312 block(s) judged, 0 failed exit 0
AFTER (355dd8daa)
Scanned 224 document(s): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0

The lid check, per page — including the negative results

Resolving an unresolved name can uncover diagnostics the first error was hiding. Run on all three:

• plugin-gantt.mdx — NEGATIVE. Clearing 26 parse failures and the ObjectGantt / dataSource undefined names exposed nothing underneath: the re-run was clean. Reported as a negative result.
• data-objectstack.mdx — NEGATIVE. Eight blocks' worth of TS2304 resolved and the re-run was clean. The two prose blocks that survive as declared fragments were then checked by hand against the shipped declaration and against @objectstack/spec, and both are accurate.
• plugin-calendar.mdx — POSITIVE, once. With the block's own names resolved, ObjectCalendarComponentProps.schema turned out to be typed ObjectGridSchema | CalendarSchema, and no object-calendar node is assignable to either — ObjectGridSchema.type is the literal 'object-grid' and CalendarSchema is the form date picker (type: 'calendar'). Filed as finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311, not cast around.

The read-site grep — what the compiler structurally cannot see

BaseSchema carries [key: string]: any, so a wrong TOP-LEVEL key on any schema literal is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites, and that is what caught the descriptionField defect: zero read sites anywhere in packages/plugin-calendar, while the page taught it twice. The check found nothing further on the gantt or data-objectstack literals.

What the green does not mean

Stated because a green run must not be read as more than it is, and each limit below was measured on these pages by planting a probe, running the gate, and restoring from HEAD under a trap:

1. A misspelled top-level key on a schema literal is not caught. Probe: ganttt: 'typo-probe' added to an annotated ObjectGanttSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside gantt: { … } is not caught either. Probe: startDateFeild inside the gantt block. Gate stayed green — GanttConfig is SpecGanttConfig & { … } and the spec's GanttConfigSchema is z.core.$loose, so the intersection admits unknown keys. (Note the asymmetry with the authoring surface: the spec's CalendarConfigSchema is $strict, so the same typo in a calendar block would be rejected at parse time even though this gate cannot see it.)
3. calendar: { … } is wholly unchecked.ObjectCalendarSchema does not declare a calendar member — unlike ObjectGanttSchema, which does declare gantt — so that block lands on the index signature. The four keys used on this page were validated by read-site grep instead.
4. What IS checked, proved rather than assumed. Two probes went red, so the annotations are live and not no-ops: viewMode: 'century' on the gantt literal → TS2322: Type '"century"' is not assignable to type '"month" | "week" | "day" | "quarter" | "year" | undefined'; defaultView: 'agenda' on the calendar literal → TS2322: Type '"agenda"' is not assignable to type '"month" | "week" | "day" | undefined'. A third, type: 'object-calendar' under an ObjectGridSchema annotation on the data-objectstack page, also went red. Declared members are checked; undeclared keys are not.
5. The gate answers only "does this snippet compile against the published types". Schema-key validity under safeParse, whether a type literal names a registered component, and whether a shell example runs are three other questions with three other answers.

Type gaps found and filed, not fixed here

packages/* source is out of this PR's surface, so both were filed unassigned after a targeted dedupe search, and the blocks they affect ship declared rather than deleted:

• finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311 — ObjectCalendarComponentProps.schema is ObjectGridSchema | CalendarSchema, so the page's own Direct Component Usage section cannot type-check. ObjectCalendar.tsx reaches the node through (schema as any).calendar and the registered renderer passes an object-calendar node to it, so the runtime path is real and the declaration is the stale half — the same shape already fixed for the map (ObjectMapSchema(types)声明的键几乎与 ObjectMap 实际读的键无交集:map 块整体未建模,组件 props 类型写的是 ObjectGridSchema,每处 map 读取都走 as any #5018) and the gantt (ObjectGantt reads 11 top-level schema keys that ObjectGanttSchema does not declare — all via as any, so nothing connects read to declaration #5903). That block carries a FRAGMENT_MARKER naming the card; it becomes a compiling block the day the prop names ObjectCalendarSchema.
• finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 — objectName is declared required on ObjectGanttSchema and ObjectCalendarSchema, while both renderers' getDataConfig tries data, then staticData, then objectName. The documented static-data and api-provider routes are therefore supported paths the type rejects (TS2741). Those four blocks ship as plain const declarations with no annotation — they compile and are counted, but their keys are unchecked — rather than inventing an objectName the route does not use. Same shape as finding(types): ObjectMapSchema.objectName is declared REQUIRED but ObjectMap treats it as optional — the documented static-data route cannot be annotated #7296 on ObjectMapSchema; filed separately because that card is scoped to the map by title and body.

Gate verdict lines

Everything below at 355dd8daa, the final commit, with the closure built first under the shared verify lock (VERDICT command-exit 0) and dist/index.d.ts presence confirmed on disk in this worktree before any gate result was trusted — turbo replays cached logs naming other worktrees' paths.

check:doc-snippets exit 0 Semantic phase: 345 of 345 block(s) judged, 0 failed.
Every covered documentation snippet compiles against the built types.
check:doc-fences exit 0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript …
check:doc-types exit 0 Every documented component type is registered.
docs:check-links exit 0 Links are valid across 17 scan roots.
check:control-bytes exit 0 scanned 6010 tracked text file(s); skipped 85 binary
check:readme-exports exit 0 386 self-imports judged (386 real, 0 wrong-path, 0 fabricated)
check-changeset-presence exit 0 No source or published contract of a released package changed in
this range, so no changeset is owed.
vitest (repo root) exit 0 Test Files 7 passed (7) · Tests 177 passed (177)

The seven vitest files are every file git grep -l check-doc-snippet-types -- '*.test.ts' '*.test.tsx' names — the two obvious ones plus five pin suites in examples/schema-catalog, plugin-gantt, react and types that an edit to this script could have hijacked. Run from the repo root with --maxWorkers=2, never through pnpm --filter.

check:readme-exports first read NOT MEASURED, not red: it exited 1 with three findings, all three the string its type entry ./dist/index.d.ts is not on disk -- run pnpm build first for plugin-ai, and none naming a file in this diff. Building that closure made it a real measurement, and it is genuinely green.

Declared narrowing

Repo-wide pnpm lint was narrowed to the four changed files, and the narrowing is a measurement rather than a skip:

1. Population read from ESLint's own config, not from a guess: npx eslint --no-inline-config --format json on the four files reports the three .mdx pages as File ignored because no matching configuration was supplied — they are not in ESLint's population at all.
2. File count read from the JSON output: 4 files judged, 1 of them actually linted (scripts/check-doc-snippet-types.mjs), 0 errors, 0 warnings.
3. Config invariance for untouched files: eslint.config.js sets no project, projectService or tsconfigRootDir, so type-aware linting is not enabled and nothing in this diff can move the verdict on a file it does not touch.

A control-byte self-scan (grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]') over the four changed files returns no hits, beside the repo-wide gate above.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01BGMDbrVa8JjZcCQ7DWYH1b

---

Generated by Claude Code

[yinlianghui]

Part of #5174

Batch 6 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 41 blocks, 33 compile against the built dist, 8 carry a FRAGMENT_MARKER with a written, measured reason. 74 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 5 (#7294) landed while this was in flight; origin/main was merged (never rebased) and the two ledger hunks are disjoint removals, as predicted.

Pages taken, and how each block reached zero

All counts produced with the gate's own scanFences, not a hand grep.

page	blocks	compile	declared	diagnostics cleared	real defects found, and the shipped type each was checked against
content/docs/plugins/plugin-calendar.mdx	15	12	3	28 (19 syntax, 9 semantic)	calendar.descriptionField is fabricated — not a member of @objectstack/spec's CalendarConfigSchema (which is $strict and holds exactly startDateField, endDateField, titleField, colorField) and read at zero sites in packages/plugin-calendar; ObjectCalendar.tsx:420 destructures exactly those four. Removed from the "Appointment Scheduler" example and from the published CalendarConfig reference. The "TypeScript Support" section annotated an object-calendar node as ObjectGridSchema — an annotation that cannot hold, since ObjectGridSchema.type is the literal 'object-grid'; repointed to the real ObjectCalendarSchema.
content/docs/utilities/data-objectstack.mdx	14	11	3	17 (0 syntax, 17 semantic)	No fabricated API. Eight blocks were unrunnable as written — a reader copying one got Cannot find name 'createObjectStackAdapter' / 'User' / 'dataSource' / 'mySchema' — and were made self-contained against packages/data-objectstack/dist/index.d.ts. The factory's config signature block was verified member-for-member against the shipped createObjectStackAdapter declaration, and the ElementDataSource restatement member-for-member against ElementDataSourceSchema in the installed @objectstack/spec: both accurate.
content/docs/plugins/plugin-gantt.mdx	12	10	2	29 (26 syntax, 3 semantic)	No fabricated key surfaced. The "Task Click" example rendered ObjectGantt with neither the component nor dataSource in scope — a copy-paste example broken at its first line; rewritten as a real component taking a typed DataSource prop. Six bare object literals became annotated ObjectGanttSchema declarations, which puts their gantt: { … } blocks under GanttConfig for the first time.

Ledger 40 → 37 (6 .mdx + 31 README). Covered documents 184 → 187 — strictly grows. Covered blocks 440 → 481; compiled 312 → 345; declared fragments 128 → 136. The three per-page splits (12+11+10 = 33 compile, 3+3+2 = 8 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — git diff origin/main -- scripts/check-doc-snippet-types.mjs is 0 additions, 6 deletions.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, origin/main vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batch 5 recorded.
• Covered count strictly grows — 184 → 187, ungated 40 → 37.
• Every page taken is off the ledger and every block resolves the two honest ways — compile, or a FRAGMENT_MARKER whose reason names the measured diagnostics. No third route, no UNGATED_DOCS addition, no fence re-labelled to duck the gate.

Before / after, both at a fully built tree, exit codes captured by redirect-then-$? and never through a pipe:

BEFORE (origin/main dd5b01b59 content for the four files, swapped in under an
EXIT/INT/TERM trap; restore proved by an empty `git diff HEAD`)
Scanned 224 document(s): 184 covered (83 hold a ts/tsx block), 40 ungated
Covered blocks: 440 — 312 to compile, 128 declared fragment(s)
Semantic phase: 312 of 312 block(s) judged, 0 failed exit 0
AFTER (355dd8daa)
Scanned 224 document(s): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0

The lid check, per page — including the negative results

Resolving an unresolved name can uncover diagnostics the first error was hiding. Run on all three:

• plugin-gantt.mdx — NEGATIVE. Clearing 26 parse failures and the ObjectGantt / dataSource undefined names exposed nothing underneath: the re-run was clean. Reported as a negative result.
• data-objectstack.mdx — NEGATIVE. Eight blocks' worth of TS2304 resolved and the re-run was clean. The two prose blocks that survive as declared fragments were then checked by hand against the shipped declaration and against @objectstack/spec, and both are accurate.
• plugin-calendar.mdx — POSITIVE, once. With the block's own names resolved, ObjectCalendarComponentProps.schema turned out to be typed ObjectGridSchema | CalendarSchema, and no object-calendar node is assignable to either — ObjectGridSchema.type is the literal 'object-grid' and CalendarSchema is the form date picker (type: 'calendar'). Filed as finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311, not cast around.

The read-site grep — what the compiler structurally cannot see

BaseSchema carries [key: string]: any, so a wrong TOP-LEVEL key on any schema literal is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites, and that is what caught the descriptionField defect: zero read sites anywhere in packages/plugin-calendar, while the page taught it twice. The check found nothing further on the gantt or data-objectstack literals.

What the green does not mean

Stated because a green run must not be read as more than it is, and each limit below was measured on these pages by planting a probe, running the gate, and restoring from HEAD under a trap:

1. A misspelled top-level key on a schema literal is not caught. Probe: ganttt: 'typo-probe' added to an annotated ObjectGanttSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside gantt: { … } is not caught either. Probe: startDateFeild inside the gantt block. Gate stayed green — GanttConfig is SpecGanttConfig & { … } and the spec's GanttConfigSchema is z.core.$loose, so the intersection admits unknown keys. (Note the asymmetry with the authoring surface: the spec's CalendarConfigSchema is $strict, so the same typo in a calendar block would be rejected at parse time even though this gate cannot see it.)
3. calendar: { … } is wholly unchecked.ObjectCalendarSchema does not declare a calendar member — unlike ObjectGanttSchema, which does declare gantt — so that block lands on the index signature. The four keys used on this page were validated by read-site grep instead.
4. What IS checked, proved rather than assumed. Two probes went red, so the annotations are live and not no-ops: viewMode: 'century' on the gantt literal → TS2322: Type '"century"' is not assignable to type '"month" | "week" | "day" | "quarter" | "year" | undefined'; defaultView: 'agenda' on the calendar literal → TS2322: Type '"agenda"' is not assignable to type '"month" | "week" | "day" | undefined'. A third, type: 'object-calendar' under an ObjectGridSchema annotation on the data-objectstack page, also went red. Declared members are checked; undeclared keys are not.
5. The gate answers only "does this snippet compile against the published types". Schema-key validity under safeParse, whether a type literal names a registered component, and whether a shell example runs are three other questions with three other answers.

Type gaps found and filed, not fixed here

packages/* source is out of this PR's surface, so both were filed unassigned after a targeted dedupe search, and the blocks they affect ship declared rather than deleted:

• finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311 — ObjectCalendarComponentProps.schema is ObjectGridSchema | CalendarSchema, so the page's own Direct Component Usage section cannot type-check. ObjectCalendar.tsx reaches the node through (schema as any).calendar and the registered renderer passes an object-calendar node to it, so the runtime path is real and the declaration is the stale half — the same shape already fixed for the map (ObjectMapSchema(types)声明的键几乎与 ObjectMap 实际读的键无交集:map 块整体未建模,组件 props 类型写的是 ObjectGridSchema,每处 map 读取都走 as any #5018) and the gantt (ObjectGantt reads 11 top-level schema keys that ObjectGanttSchema does not declare — all via as any, so nothing connects read to declaration #5903). That block carries a FRAGMENT_MARKER naming the card; it becomes a compiling block the day the prop names ObjectCalendarSchema.
• finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 — objectName is declared required on ObjectGanttSchema and ObjectCalendarSchema, while both renderers' getDataConfig tries data, then staticData, then objectName. The documented static-data and api-provider routes are therefore supported paths the type rejects (TS2741). Those four blocks ship as plain const declarations with no annotation — they compile and are counted, but their keys are unchecked — rather than inventing an objectName the route does not use. Same shape as finding(types): ObjectMapSchema.objectName is declared REQUIRED but ObjectMap treats it as optional — the documented static-data route cannot be annotated #7296 on ObjectMapSchema; filed separately because that card is scoped to the map by title and body.

Gate verdict lines

Everything below at 355dd8daa, the final commit, with the closure built first under the shared verify lock (VERDICT command-exit 0) and dist/index.d.ts presence confirmed on disk in this worktree before any gate result was trusted — turbo replays cached logs naming other worktrees' paths.

check:doc-snippets exit 0 Semantic phase: 345 of 345 block(s) judged, 0 failed.
Every covered documentation snippet compiles against the built types.
check:doc-fences exit 0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript …
check:doc-types exit 0 Every documented component type is registered.
docs:check-links exit 0 Links are valid across 17 scan roots.
check:control-bytes exit 0 scanned 6010 tracked text file(s); skipped 85 binary
check:readme-exports exit 0 386 self-imports judged (386 real, 0 wrong-path, 0 fabricated)
check-changeset-presence exit 0 No source or published contract of a released package changed in
this range, so no changeset is owed.
vitest (repo root) exit 0 Test Files 7 passed (7) · Tests 177 passed (177)

The seven vitest files are every file git grep -l check-doc-snippet-types -- '*.test.ts' '*.test.tsx' names — the two obvious ones plus five pin suites in examples/schema-catalog, plugin-gantt, react and types that an edit to this script could have hijacked. Run from the repo root with --maxWorkers=2, never through pnpm --filter.

check:readme-exports first read NOT MEASURED, not red: it exited 1 with three findings, all three the string its type entry ./dist/index.d.ts is not on disk -- run pnpm build first for plugin-ai, and none naming a file in this diff. Building that closure made it a real measurement, and it is genuinely green.

Declared narrowing

Repo-wide pnpm lint was narrowed to the four changed files, and the narrowing is a measurement rather than a skip:

1. Population read from ESLint's own config, not from a guess: npx eslint --no-inline-config --format json on the four files reports the three .mdx pages as File ignored because no matching configuration was supplied — they are not in ESLint's population at all.
2. File count read from the JSON output: 4 files judged, 1 of them actually linted (scripts/check-doc-snippet-types.mjs), 0 errors, 0 warnings.
3. Config invariance for untouched files: eslint.config.js sets no project, projectService or tsconfigRootDir, so type-aware linting is not enabled and nothing in this diff can move the verdict on a file it does not touch.

A control-byte self-scan (grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]') over the four changed files returns no hits, beside the repo-wide gate above.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01BGMDbrVa8JjZcCQ7DWYH1b

---

Generated by Claude Code

[yinlianghui]

Part of #5174

Batch 6 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 41 blocks, 33 compile against the built dist, 8 carry a FRAGMENT_MARKER with a written, measured reason. 74 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 5 (#7294) landed while this was in flight; origin/main was merged (never rebased) and the two ledger hunks are disjoint removals, as predicted.

Pages taken, and how each block reached zero

All counts produced with the gate's own scanFences, not a hand grep.

page	blocks	compile	declared	diagnostics cleared	real defects found, and the shipped type each was checked against
content/docs/plugins/plugin-calendar.mdx	15	12	3	28 (19 syntax, 9 semantic)	calendar.descriptionField is fabricated — not a member of @objectstack/spec's CalendarConfigSchema (which is $strict and holds exactly startDateField, endDateField, titleField, colorField) and read at zero sites in packages/plugin-calendar; ObjectCalendar.tsx:420 destructures exactly those four. Removed from the "Appointment Scheduler" example and from the published CalendarConfig reference. The "TypeScript Support" section annotated an object-calendar node as ObjectGridSchema — an annotation that cannot hold, since ObjectGridSchema.type is the literal 'object-grid'; repointed to the real ObjectCalendarSchema.
content/docs/utilities/data-objectstack.mdx	14	11	3	17 (0 syntax, 17 semantic)	No fabricated API. Eight blocks were unrunnable as written — a reader copying one got Cannot find name 'createObjectStackAdapter' / 'User' / 'dataSource' / 'mySchema' — and were made self-contained against packages/data-objectstack/dist/index.d.ts. The factory's config signature block was verified member-for-member against the shipped createObjectStackAdapter declaration, and the ElementDataSource restatement member-for-member against ElementDataSourceSchema in the installed @objectstack/spec: both accurate.
content/docs/plugins/plugin-gantt.mdx	12	10	2	29 (26 syntax, 3 semantic)	No fabricated key surfaced. The "Task Click" example rendered ObjectGantt with neither the component nor dataSource in scope — a copy-paste example broken at its first line; rewritten as a real component taking a typed DataSource prop. Six bare object literals became annotated ObjectGanttSchema declarations, which puts their gantt: { … } blocks under GanttConfig for the first time.

Ledger 40 → 37 (6 .mdx + 31 README). Covered documents 184 → 187 — strictly grows. Covered blocks 440 → 481; compiled 312 → 345; declared fragments 128 → 136. The three per-page splits (12+11+10 = 33 compile, 3+3+2 = 8 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — git diff origin/main -- scripts/check-doc-snippet-types.mjs is 0 additions, 6 deletions.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, origin/main vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batch 5 recorded.
• Covered count strictly grows — 184 → 187, ungated 40 → 37.
• Every page taken is off the ledger and every block resolves the two honest ways — compile, or a FRAGMENT_MARKER whose reason names the measured diagnostics. No third route, no UNGATED_DOCS addition, no fence re-labelled to duck the gate.

Before / after, both at a fully built tree, exit codes captured by redirect-then-$? and never through a pipe:

BEFORE (origin/main dd5b01b59 content for the four files, swapped in under an
EXIT/INT/TERM trap; restore proved by an empty `git diff HEAD`)
Scanned 224 document(s): 184 covered (83 hold a ts/tsx block), 40 ungated
Covered blocks: 440 — 312 to compile, 128 declared fragment(s)
Semantic phase: 312 of 312 block(s) judged, 0 failed exit 0
AFTER (355dd8daa)
Scanned 224 document(s): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0

The lid check, per page — including the negative results

Resolving an unresolved name can uncover diagnostics the first error was hiding. Run on all three:

• plugin-gantt.mdx — NEGATIVE. Clearing 26 parse failures and the ObjectGantt / dataSource undefined names exposed nothing underneath: the re-run was clean. Reported as a negative result.
• data-objectstack.mdx — NEGATIVE. Eight blocks' worth of TS2304 resolved and the re-run was clean. The two prose blocks that survive as declared fragments were then checked by hand against the shipped declaration and against @objectstack/spec, and both are accurate.
• plugin-calendar.mdx — POSITIVE, once. With the block's own names resolved, ObjectCalendarComponentProps.schema turned out to be typed ObjectGridSchema | CalendarSchema, and no object-calendar node is assignable to either — ObjectGridSchema.type is the literal 'object-grid' and CalendarSchema is the form date picker (type: 'calendar'). Filed as finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311, not cast around.

The read-site grep — what the compiler structurally cannot see

BaseSchema carries [key: string]: any, so a wrong TOP-LEVEL key on any schema literal is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites, and that is what caught the descriptionField defect: zero read sites anywhere in packages/plugin-calendar, while the page taught it twice. The check found nothing further on the gantt or data-objectstack literals.

What the green does not mean

Stated because a green run must not be read as more than it is, and each limit below was measured on these pages by planting a probe, running the gate, and restoring from HEAD under a trap:

1. A misspelled top-level key on a schema literal is not caught. Probe: ganttt: 'typo-probe' added to an annotated ObjectGanttSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside gantt: { … } is not caught either. Probe: startDateFeild inside the gantt block. Gate stayed green — GanttConfig is SpecGanttConfig & { … } and the spec's GanttConfigSchema is z.core.$loose, so the intersection admits unknown keys. (Note the asymmetry with the authoring surface: the spec's CalendarConfigSchema is $strict, so the same typo in a calendar block would be rejected at parse time even though this gate cannot see it.)
3. calendar: { … } is wholly unchecked.ObjectCalendarSchema does not declare a calendar member — unlike ObjectGanttSchema, which does declare gantt — so that block lands on the index signature. The four keys used on this page were validated by read-site grep instead.
4. What IS checked, proved rather than assumed. Two probes went red, so the annotations are live and not no-ops: viewMode: 'century' on the gantt literal → TS2322: Type '"century"' is not assignable to type '"month" | "week" | "day" | "quarter" | "year" | undefined'; defaultView: 'agenda' on the calendar literal → TS2322: Type '"agenda"' is not assignable to type '"month" | "week" | "day" | undefined'. A third, type: 'object-calendar' under an ObjectGridSchema annotation on the data-objectstack page, also went red. Declared members are checked; undeclared keys are not.
5. The gate answers only "does this snippet compile against the published types". Schema-key validity under safeParse, whether a type literal names a registered component, and whether a shell example runs are three other questions with three other answers.

Type gaps found and filed, not fixed here

packages/* source is out of this PR's surface, so both were filed unassigned after a targeted dedupe search, and the blocks they affect ship declared rather than deleted:

• finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311 — ObjectCalendarComponentProps.schema is ObjectGridSchema | CalendarSchema, so the page's own Direct Component Usage section cannot type-check. ObjectCalendar.tsx reaches the node through (schema as any).calendar and the registered renderer passes an object-calendar node to it, so the runtime path is real and the declaration is the stale half — the same shape already fixed for the map (ObjectMapSchema(types)声明的键几乎与 ObjectMap 实际读的键无交集:map 块整体未建模,组件 props 类型写的是 ObjectGridSchema,每处 map 读取都走 as any #5018) and the gantt (ObjectGantt reads 11 top-level schema keys that ObjectGanttSchema does not declare — all via as any, so nothing connects read to declaration #5903). That block carries a FRAGMENT_MARKER naming the card; it becomes a compiling block the day the prop names ObjectCalendarSchema.
• finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 — objectName is declared required on ObjectGanttSchema and ObjectCalendarSchema, while both renderers' getDataConfig tries data, then staticData, then objectName. The documented static-data and api-provider routes are therefore supported paths the type rejects (TS2741). Those four blocks ship as plain const declarations with no annotation — they compile and are counted, but their keys are unchecked — rather than inventing an objectName the route does not use. Same shape as finding(types): ObjectMapSchema.objectName is declared REQUIRED but ObjectMap treats it as optional — the documented static-data route cannot be annotated #7296 on ObjectMapSchema; filed separately because that card is scoped to the map by title and body.

Gate verdict lines

Everything below at 355dd8daa, the final commit, with the closure built first under the shared verify lock (VERDICT command-exit 0) and dist/index.d.ts presence confirmed on disk in this worktree before any gate result was trusted — turbo replays cached logs naming other worktrees' paths.

check:doc-snippets exit 0 Semantic phase: 345 of 345 block(s) judged, 0 failed.
Every covered documentation snippet compiles against the built types.
check:doc-fences exit 0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript …
check:doc-types exit 0 Every documented component type is registered.
docs:check-links exit 0 Links are valid across 17 scan roots.
check:control-bytes exit 0 scanned 6010 tracked text file(s); skipped 85 binary
check:readme-exports exit 0 386 self-imports judged (386 real, 0 wrong-path, 0 fabricated)
check-changeset-presence exit 0 No source or published contract of a released package changed in
this range, so no changeset is owed.
vitest (repo root) exit 0 Test Files 7 passed (7) · Tests 177 passed (177)

The seven vitest files are every file git grep -l check-doc-snippet-types -- '*.test.ts' '*.test.tsx' names — the two obvious ones plus five pin suites in examples/schema-catalog, plugin-gantt, react and types that an edit to this script could have hijacked. Run from the repo root with --maxWorkers=2, never through pnpm --filter.

check:readme-exports first read NOT MEASURED, not red: it exited 1 with three findings, all three the string its type entry ./dist/index.d.ts is not on disk -- run pnpm build first for plugin-ai, and none naming a file in this diff. Building that closure made it a real measurement, and it is genuinely green.

Declared narrowing

Repo-wide pnpm lint was narrowed to the four changed files, and the narrowing is a measurement rather than a skip:

1. Population read from ESLint's own config, not from a guess: npx eslint --no-inline-config --format json on the four files reports the three .mdx pages as File ignored because no matching configuration was supplied — they are not in ESLint's population at all.
2. File count read from the JSON output: 4 files judged, 1 of them actually linted (scripts/check-doc-snippet-types.mjs), 0 errors, 0 warnings.
3. Config invariance for untouched files: eslint.config.js sets no project, projectService or tsconfigRootDir, so type-aware linting is not enabled and nothing in this diff can move the verdict on a file it does not touch.

A control-byte self-scan (grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]') over the four changed files returns no hits, beside the repo-wide gate above.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01BGMDbrVa8JjZcCQ7DWYH1b

---

Generated by Claude Code

[yinlianghui]

Part of #5174

Batch 6 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 41 blocks, 33 compile against the built dist, 8 carry a FRAGMENT_MARKER with a written, measured reason. 74 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 5 (#7294) landed while this was in flight; origin/main was merged (never rebased) and the two ledger hunks are disjoint removals, as predicted.

Pages taken, and how each block reached zero

All counts produced with the gate's own scanFences, not a hand grep.

page	blocks	compile	declared	diagnostics cleared	real defects found, and the shipped type each was checked against
content/docs/plugins/plugin-calendar.mdx	15	12	3	28 (19 syntax, 9 semantic)	calendar.descriptionField is fabricated — not a member of @objectstack/spec's CalendarConfigSchema (which is $strict and holds exactly startDateField, endDateField, titleField, colorField) and read at zero sites in packages/plugin-calendar; ObjectCalendar.tsx:420 destructures exactly those four. Removed from the "Appointment Scheduler" example and from the published CalendarConfig reference. The "TypeScript Support" section annotated an object-calendar node as ObjectGridSchema — an annotation that cannot hold, since ObjectGridSchema.type is the literal 'object-grid'; repointed to the real ObjectCalendarSchema.
content/docs/utilities/data-objectstack.mdx	14	11	3	17 (0 syntax, 17 semantic)	No fabricated API. Eight blocks were unrunnable as written — a reader copying one got Cannot find name 'createObjectStackAdapter' / 'User' / 'dataSource' / 'mySchema' — and were made self-contained against packages/data-objectstack/dist/index.d.ts. The factory's config signature block was verified member-for-member against the shipped createObjectStackAdapter declaration, and the ElementDataSource restatement member-for-member against ElementDataSourceSchema in the installed @objectstack/spec: both accurate.
content/docs/plugins/plugin-gantt.mdx	12	10	2	29 (26 syntax, 3 semantic)	No fabricated key surfaced. The "Task Click" example rendered ObjectGantt with neither the component nor dataSource in scope — a copy-paste example broken at its first line; rewritten as a real component taking a typed DataSource prop. Six bare object literals became annotated ObjectGanttSchema declarations, which puts their gantt: { … } blocks under GanttConfig for the first time.

Ledger 40 → 37 (6 .mdx + 31 README). Covered documents 184 → 187 — strictly grows. Covered blocks 440 → 481; compiled 312 → 345; declared fragments 128 → 136. The three per-page splits (12+11+10 = 33 compile, 3+3+2 = 8 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — git diff origin/main -- scripts/check-doc-snippet-types.mjs is 0 additions, 6 deletions.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, origin/main vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batch 5 recorded.
• Covered count strictly grows — 184 → 187, ungated 40 → 37.
• Every page taken is off the ledger and every block resolves the two honest ways — compile, or a FRAGMENT_MARKER whose reason names the measured diagnostics. No third route, no UNGATED_DOCS addition, no fence re-labelled to duck the gate.

Before / after, both at a fully built tree, exit codes captured by redirect-then-$? and never through a pipe:

BEFORE (origin/main dd5b01b59 content for the four files, swapped in under an
EXIT/INT/TERM trap; restore proved by an empty `git diff HEAD`)
Scanned 224 document(s): 184 covered (83 hold a ts/tsx block), 40 ungated
Covered blocks: 440 — 312 to compile, 128 declared fragment(s)
Semantic phase: 312 of 312 block(s) judged, 0 failed exit 0
AFTER (355dd8daa)
Scanned 224 document(s): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0

The lid check, per page — including the negative results

Resolving an unresolved name can uncover diagnostics the first error was hiding. Run on all three:

• plugin-gantt.mdx — NEGATIVE. Clearing 26 parse failures and the ObjectGantt / dataSource undefined names exposed nothing underneath: the re-run was clean. Reported as a negative result.
• data-objectstack.mdx — NEGATIVE. Eight blocks' worth of TS2304 resolved and the re-run was clean. The two prose blocks that survive as declared fragments were then checked by hand against the shipped declaration and against @objectstack/spec, and both are accurate.
• plugin-calendar.mdx — POSITIVE, once. With the block's own names resolved, ObjectCalendarComponentProps.schema turned out to be typed ObjectGridSchema | CalendarSchema, and no object-calendar node is assignable to either — ObjectGridSchema.type is the literal 'object-grid' and CalendarSchema is the form date picker (type: 'calendar'). Filed as finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311, not cast around.

The read-site grep — what the compiler structurally cannot see

BaseSchema carries [key: string]: any, so a wrong TOP-LEVEL key on any schema literal is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites, and that is what caught the descriptionField defect: zero read sites anywhere in packages/plugin-calendar, while the page taught it twice. The check found nothing further on the gantt or data-objectstack literals.

What the green does not mean

Stated because a green run must not be read as more than it is, and each limit below was measured on these pages by planting a probe, running the gate, and restoring from HEAD under a trap:

1. A misspelled top-level key on a schema literal is not caught. Probe: ganttt: 'typo-probe' added to an annotated ObjectGanttSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside gantt: { … } is not caught either. Probe: startDateFeild inside the gantt block. Gate stayed green — GanttConfig is SpecGanttConfig & { … } and the spec's GanttConfigSchema is z.core.$loose, so the intersection admits unknown keys. (Note the asymmetry with the authoring surface: the spec's CalendarConfigSchema is $strict, so the same typo in a calendar block would be rejected at parse time even though this gate cannot see it.)
3. calendar: { … } is wholly unchecked.ObjectCalendarSchema does not declare a calendar member — unlike ObjectGanttSchema, which does declare gantt — so that block lands on the index signature. The four keys used on this page were validated by read-site grep instead.
4. What IS checked, proved rather than assumed. Two probes went red, so the annotations are live and not no-ops: viewMode: 'century' on the gantt literal → TS2322: Type '"century"' is not assignable to type '"month" | "week" | "day" | "quarter" | "year" | undefined'; defaultView: 'agenda' on the calendar literal → TS2322: Type '"agenda"' is not assignable to type '"month" | "week" | "day" | undefined'. A third, type: 'object-calendar' under an ObjectGridSchema annotation on the data-objectstack page, also went red. Declared members are checked; undeclared keys are not.
5. The gate answers only "does this snippet compile against the published types". Schema-key validity under safeParse, whether a type literal names a registered component, and whether a shell example runs are three other questions with three other answers.

Type gaps found and filed, not fixed here

packages/* source is out of this PR's surface, so both were filed unassigned after a targeted dedupe search, and the blocks they affect ship declared rather than deleted:

• finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311 — ObjectCalendarComponentProps.schema is ObjectGridSchema | CalendarSchema, so the page's own Direct Component Usage section cannot type-check. ObjectCalendar.tsx reaches the node through (schema as any).calendar and the registered renderer passes an object-calendar node to it, so the runtime path is real and the declaration is the stale half — the same shape already fixed for the map (ObjectMapSchema(types)声明的键几乎与 ObjectMap 实际读的键无交集:map 块整体未建模,组件 props 类型写的是 ObjectGridSchema,每处 map 读取都走 as any #5018) and the gantt (ObjectGantt reads 11 top-level schema keys that ObjectGanttSchema does not declare — all via as any, so nothing connects read to declaration #5903). That block carries a FRAGMENT_MARKER naming the card; it becomes a compiling block the day the prop names ObjectCalendarSchema.
• finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 — objectName is declared required on ObjectGanttSchema and ObjectCalendarSchema, while both renderers' getDataConfig tries data, then staticData, then objectName. The documented static-data and api-provider routes are therefore supported paths the type rejects (TS2741). Those four blocks ship as plain const declarations with no annotation — they compile and are counted, but their keys are unchecked — rather than inventing an objectName the route does not use. Same shape as finding(types): ObjectMapSchema.objectName is declared REQUIRED but ObjectMap treats it as optional — the documented static-data route cannot be annotated #7296 on ObjectMapSchema; filed separately because that card is scoped to the map by title and body.

Gate verdict lines

Everything below at 355dd8daa, the final commit, with the closure built first under the shared verify lock (VERDICT command-exit 0) and dist/index.d.ts presence confirmed on disk in this worktree before any gate result was trusted — turbo replays cached logs naming other worktrees' paths.

check:doc-snippets exit 0 Semantic phase: 345 of 345 block(s) judged, 0 failed.
Every covered documentation snippet compiles against the built types.
check:doc-fences exit 0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript …
check:doc-types exit 0 Every documented component type is registered.
docs:check-links exit 0 Links are valid across 17 scan roots.
check:control-bytes exit 0 scanned 6010 tracked text file(s); skipped 85 binary
check:readme-exports exit 0 386 self-imports judged (386 real, 0 wrong-path, 0 fabricated)
check-changeset-presence exit 0 No source or published contract of a released package changed in
this range, so no changeset is owed.
vitest (repo root) exit 0 Test Files 7 passed (7) · Tests 177 passed (177)

The seven vitest files are every file git grep -l check-doc-snippet-types -- '*.test.ts' '*.test.tsx' names — the two obvious ones plus five pin suites in examples/schema-catalog, plugin-gantt, react and types that an edit to this script could have hijacked. Run from the repo root with --maxWorkers=2, never through pnpm --filter.

check:readme-exports first read NOT MEASURED, not red: it exited 1 with three findings, all three the string its type entry ./dist/index.d.ts is not on disk -- run pnpm build first for plugin-ai, and none naming a file in this diff. Building that closure made it a real measurement, and it is genuinely green.

Declared narrowing

Repo-wide pnpm lint was narrowed to the four changed files, and the narrowing is a measurement rather than a skip:

1. Population read from ESLint's own config, not from a guess: npx eslint --no-inline-config --format json on the four files reports the three .mdx pages as File ignored because no matching configuration was supplied — they are not in ESLint's population at all.
2. File count read from the JSON output: 4 files judged, 1 of them actually linted (scripts/check-doc-snippet-types.mjs), 0 errors, 0 warnings.
3. Config invariance for untouched files: eslint.config.js sets no project, projectService or tsconfigRootDir, so type-aware linting is not enabled and nothing in this diff can move the verdict on a file it does not touch.

A control-byte self-scan (grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]') over the four changed files returns no hits, beside the repo-wide gate above.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01BGMDbrVa8JjZcCQ7DWYH1b

---

Generated by Claude Code

[yinlianghui]

Part of #5174

Batch 6 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 41 blocks, 33 compile against the built dist, 8 carry a FRAGMENT_MARKER with a written, measured reason. 74 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 5 (#7294) landed while this was in flight; origin/main was merged (never rebased) and the two ledger hunks are disjoint removals, as predicted.

Pages taken, and how each block reached zero

All counts produced with the gate's own scanFences, not a hand grep.

page	blocks	compile	declared	diagnostics cleared	real defects found, and the shipped type each was checked against
content/docs/plugins/plugin-calendar.mdx	15	12	3	28 (19 syntax, 9 semantic)	calendar.descriptionField is fabricated — not a member of @objectstack/spec's CalendarConfigSchema (which is $strict and holds exactly startDateField, endDateField, titleField, colorField) and read at zero sites in packages/plugin-calendar; ObjectCalendar.tsx:420 destructures exactly those four. Removed from the "Appointment Scheduler" example and from the published CalendarConfig reference. The "TypeScript Support" section annotated an object-calendar node as ObjectGridSchema — an annotation that cannot hold, since ObjectGridSchema.type is the literal 'object-grid'; repointed to the real ObjectCalendarSchema.
content/docs/utilities/data-objectstack.mdx	14	11	3	17 (0 syntax, 17 semantic)	No fabricated API. Eight blocks were unrunnable as written — a reader copying one got Cannot find name 'createObjectStackAdapter' / 'User' / 'dataSource' / 'mySchema' — and were made self-contained against packages/data-objectstack/dist/index.d.ts. The factory's config signature block was verified member-for-member against the shipped createObjectStackAdapter declaration, and the ElementDataSource restatement member-for-member against ElementDataSourceSchema in the installed @objectstack/spec: both accurate.
content/docs/plugins/plugin-gantt.mdx	12	10	2	29 (26 syntax, 3 semantic)	No fabricated key surfaced. The "Task Click" example rendered ObjectGantt with neither the component nor dataSource in scope — a copy-paste example broken at its first line; rewritten as a real component taking a typed DataSource prop. Six bare object literals became annotated ObjectGanttSchema declarations, which puts their gantt: { … } blocks under GanttConfig for the first time.

Ledger 40 → 37 (6 .mdx + 31 README). Covered documents 184 → 187 — strictly grows. Covered blocks 440 → 481; compiled 312 → 345; declared fragments 128 → 136. The three per-page splits (12+11+10 = 33 compile, 3+3+2 = 8 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — git diff origin/main -- scripts/check-doc-snippet-types.mjs is 0 additions, 6 deletions.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, origin/main vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batch 5 recorded.
• Covered count strictly grows — 184 → 187, ungated 40 → 37.
• Every page taken is off the ledger and every block resolves the two honest ways — compile, or a FRAGMENT_MARKER whose reason names the measured diagnostics. No third route, no UNGATED_DOCS addition, no fence re-labelled to duck the gate.

Before / after, both at a fully built tree, exit codes captured by redirect-then-$? and never through a pipe:

BEFORE (origin/main dd5b01b59 content for the four files, swapped in under an
EXIT/INT/TERM trap; restore proved by an empty `git diff HEAD`)
Scanned 224 document(s): 184 covered (83 hold a ts/tsx block), 40 ungated
Covered blocks: 440 — 312 to compile, 128 declared fragment(s)
Semantic phase: 312 of 312 block(s) judged, 0 failed exit 0
AFTER (355dd8daa)
Scanned 224 document(s): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0

The lid check, per page — including the negative results

Resolving an unresolved name can uncover diagnostics the first error was hiding. Run on all three:

• plugin-gantt.mdx — NEGATIVE. Clearing 26 parse failures and the ObjectGantt / dataSource undefined names exposed nothing underneath: the re-run was clean. Reported as a negative result.
• data-objectstack.mdx — NEGATIVE. Eight blocks' worth of TS2304 resolved and the re-run was clean. The two prose blocks that survive as declared fragments were then checked by hand against the shipped declaration and against @objectstack/spec, and both are accurate.
• plugin-calendar.mdx — POSITIVE, once. With the block's own names resolved, ObjectCalendarComponentProps.schema turned out to be typed ObjectGridSchema | CalendarSchema, and no object-calendar node is assignable to either — ObjectGridSchema.type is the literal 'object-grid' and CalendarSchema is the form date picker (type: 'calendar'). Filed as finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311, not cast around.

The read-site grep — what the compiler structurally cannot see

BaseSchema carries [key: string]: any, so a wrong TOP-LEVEL key on any schema literal is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites, and that is what caught the descriptionField defect: zero read sites anywhere in packages/plugin-calendar, while the page taught it twice. The check found nothing further on the gantt or data-objectstack literals.

What the green does not mean

Stated because a green run must not be read as more than it is, and each limit below was measured on these pages by planting a probe, running the gate, and restoring from HEAD under a trap:

1. A misspelled top-level key on a schema literal is not caught. Probe: ganttt: 'typo-probe' added to an annotated ObjectGanttSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside gantt: { … } is not caught either. Probe: startDateFeild inside the gantt block. Gate stayed green — GanttConfig is SpecGanttConfig & { … } and the spec's GanttConfigSchema is z.core.$loose, so the intersection admits unknown keys. (Note the asymmetry with the authoring surface: the spec's CalendarConfigSchema is $strict, so the same typo in a calendar block would be rejected at parse time even though this gate cannot see it.)
3. calendar: { … } is wholly unchecked.ObjectCalendarSchema does not declare a calendar member — unlike ObjectGanttSchema, which does declare gantt — so that block lands on the index signature. The four keys used on this page were validated by read-site grep instead.
4. What IS checked, proved rather than assumed. Two probes went red, so the annotations are live and not no-ops: viewMode: 'century' on the gantt literal → TS2322: Type '"century"' is not assignable to type '"month" | "week" | "day" | "quarter" | "year" | undefined'; defaultView: 'agenda' on the calendar literal → TS2322: Type '"agenda"' is not assignable to type '"month" | "week" | "day" | undefined'. A third, type: 'object-calendar' under an ObjectGridSchema annotation on the data-objectstack page, also went red. Declared members are checked; undeclared keys are not.
5. The gate answers only "does this snippet compile against the published types". Schema-key validity under safeParse, whether a type literal names a registered component, and whether a shell example runs are three other questions with three other answers.

Type gaps found and filed, not fixed here

packages/* source is out of this PR's surface, so both were filed unassigned after a targeted dedupe search, and the blocks they affect ship declared rather than deleted:

• finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311 — ObjectCalendarComponentProps.schema is ObjectGridSchema | CalendarSchema, so the page's own Direct Component Usage section cannot type-check. ObjectCalendar.tsx reaches the node through (schema as any).calendar and the registered renderer passes an object-calendar node to it, so the runtime path is real and the declaration is the stale half — the same shape already fixed for the map (ObjectMapSchema(types)声明的键几乎与 ObjectMap 实际读的键无交集:map 块整体未建模,组件 props 类型写的是 ObjectGridSchema,每处 map 读取都走 as any #5018) and the gantt (ObjectGantt reads 11 top-level schema keys that ObjectGanttSchema does not declare — all via as any, so nothing connects read to declaration #5903). That block carries a FRAGMENT_MARKER naming the card; it becomes a compiling block the day the prop names ObjectCalendarSchema.
• finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 — objectName is declared required on ObjectGanttSchema and ObjectCalendarSchema, while both renderers' getDataConfig tries data, then staticData, then objectName. The documented static-data and api-provider routes are therefore supported paths the type rejects (TS2741). Those four blocks ship as plain const declarations with no annotation — they compile and are counted, but their keys are unchecked — rather than inventing an objectName the route does not use. Same shape as finding(types): ObjectMapSchema.objectName is declared REQUIRED but ObjectMap treats it as optional — the documented static-data route cannot be annotated #7296 on ObjectMapSchema; filed separately because that card is scoped to the map by title and body.

Gate verdict lines

Everything below at 355dd8daa, the final commit, with the closure built first under the shared verify lock (VERDICT command-exit 0) and dist/index.d.ts presence confirmed on disk in this worktree before any gate result was trusted — turbo replays cached logs naming other worktrees' paths.

check:doc-snippets exit 0 Semantic phase: 345 of 345 block(s) judged, 0 failed.
Every covered documentation snippet compiles against the built types.
check:doc-fences exit 0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript …
check:doc-types exit 0 Every documented component type is registered.
docs:check-links exit 0 Links are valid across 17 scan roots.
check:control-bytes exit 0 scanned 6010 tracked text file(s); skipped 85 binary
check:readme-exports exit 0 386 self-imports judged (386 real, 0 wrong-path, 0 fabricated)
check-changeset-presence exit 0 No source or published contract of a released package changed in
this range, so no changeset is owed.
vitest (repo root) exit 0 Test Files 7 passed (7) · Tests 177 passed (177)

The seven vitest files are every file git grep -l check-doc-snippet-types -- '*.test.ts' '*.test.tsx' names — the two obvious ones plus five pin suites in examples/schema-catalog, plugin-gantt, react and types that an edit to this script could have hijacked. Run from the repo root with --maxWorkers=2, never through pnpm --filter.

check:readme-exports first read NOT MEASURED, not red: it exited 1 with three findings, all three the string its type entry ./dist/index.d.ts is not on disk -- run pnpm build first for plugin-ai, and none naming a file in this diff. Building that closure made it a real measurement, and it is genuinely green.

Declared narrowing

Repo-wide pnpm lint was narrowed to the four changed files, and the narrowing is a measurement rather than a skip:

1. Population read from ESLint's own config, not from a guess: npx eslint --no-inline-config --format json on the four files reports the three .mdx pages as File ignored because no matching configuration was supplied — they are not in ESLint's population at all.
2. File count read from the JSON output: 4 files judged, 1 of them actually linted (scripts/check-doc-snippet-types.mjs), 0 errors, 0 warnings.
3. Config invariance for untouched files: eslint.config.js sets no project, projectService or tsconfigRootDir, so type-aware linting is not enabled and nothing in this diff can move the verdict on a file it does not touch.

A control-byte self-scan (grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]') over the four changed files returns no hits, beside the repo-wide gate above.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01BGMDbrVa8JjZcCQ7DWYH1b

---

Generated by Claude Code

[yinlianghui]

Part of #5174

Batch 6 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 41 blocks, 33 compile against the built dist, 8 carry a FRAGMENT_MARKER with a written, measured reason. 74 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 5 (#7294) landed while this was in flight; origin/main was merged (never rebased) and the two ledger hunks are disjoint removals, as predicted.

Pages taken, and how each block reached zero

All counts produced with the gate's own scanFences, not a hand grep.

page	blocks	compile	declared	diagnostics cleared	real defects found, and the shipped type each was checked against
content/docs/plugins/plugin-calendar.mdx	15	12	3	28 (19 syntax, 9 semantic)	calendar.descriptionField is fabricated — not a member of @objectstack/spec's CalendarConfigSchema (which is $strict and holds exactly startDateField, endDateField, titleField, colorField) and read at zero sites in packages/plugin-calendar; ObjectCalendar.tsx:420 destructures exactly those four. Removed from the "Appointment Scheduler" example and from the published CalendarConfig reference. The "TypeScript Support" section annotated an object-calendar node as ObjectGridSchema — an annotation that cannot hold, since ObjectGridSchema.type is the literal 'object-grid'; repointed to the real ObjectCalendarSchema.
content/docs/utilities/data-objectstack.mdx	14	11	3	17 (0 syntax, 17 semantic)	No fabricated API. Eight blocks were unrunnable as written — a reader copying one got Cannot find name 'createObjectStackAdapter' / 'User' / 'dataSource' / 'mySchema' — and were made self-contained against packages/data-objectstack/dist/index.d.ts. The factory's config signature block was verified member-for-member against the shipped createObjectStackAdapter declaration, and the ElementDataSource restatement member-for-member against ElementDataSourceSchema in the installed @objectstack/spec: both accurate.
content/docs/plugins/plugin-gantt.mdx	12	10	2	29 (26 syntax, 3 semantic)	No fabricated key surfaced. The "Task Click" example rendered ObjectGantt with neither the component nor dataSource in scope — a copy-paste example broken at its first line; rewritten as a real component taking a typed DataSource prop. Six bare object literals became annotated ObjectGanttSchema declarations, which puts their gantt: { … } blocks under GanttConfig for the first time.

Ledger 40 → 37 (6 .mdx + 31 README). Covered documents 184 → 187 — strictly grows. Covered blocks 440 → 481; compiled 312 → 345; declared fragments 128 → 136. The three per-page splits (12+11+10 = 33 compile, 3+3+2 = 8 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — git diff origin/main -- scripts/check-doc-snippet-types.mjs is 0 additions, 6 deletions.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, origin/main vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batch 5 recorded.
• Covered count strictly grows — 184 → 187, ungated 40 → 37.
• Every page taken is off the ledger and every block resolves the two honest ways — compile, or a FRAGMENT_MARKER whose reason names the measured diagnostics. No third route, no UNGATED_DOCS addition, no fence re-labelled to duck the gate.

Before / after, both at a fully built tree, exit codes captured by redirect-then-$? and never through a pipe:

BEFORE (origin/main dd5b01b59 content for the four files, swapped in under an
EXIT/INT/TERM trap; restore proved by an empty `git diff HEAD`)
Scanned 224 document(s): 184 covered (83 hold a ts/tsx block), 40 ungated
Covered blocks: 440 — 312 to compile, 128 declared fragment(s)
Semantic phase: 312 of 312 block(s) judged, 0 failed exit 0
AFTER (355dd8daa)
Scanned 224 document(s): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0

The lid check, per page — including the negative results

Resolving an unresolved name can uncover diagnostics the first error was hiding. Run on all three:

• plugin-gantt.mdx — NEGATIVE. Clearing 26 parse failures and the ObjectGantt / dataSource undefined names exposed nothing underneath: the re-run was clean. Reported as a negative result.
• data-objectstack.mdx — NEGATIVE. Eight blocks' worth of TS2304 resolved and the re-run was clean. The two prose blocks that survive as declared fragments were then checked by hand against the shipped declaration and against @objectstack/spec, and both are accurate.
• plugin-calendar.mdx — POSITIVE, once. With the block's own names resolved, ObjectCalendarComponentProps.schema turned out to be typed ObjectGridSchema | CalendarSchema, and no object-calendar node is assignable to either — ObjectGridSchema.type is the literal 'object-grid' and CalendarSchema is the form date picker (type: 'calendar'). Filed as finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311, not cast around.

The read-site grep — what the compiler structurally cannot see

BaseSchema carries [key: string]: any, so a wrong TOP-LEVEL key on any schema literal is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites, and that is what caught the descriptionField defect: zero read sites anywhere in packages/plugin-calendar, while the page taught it twice. The check found nothing further on the gantt or data-objectstack literals.

What the green does not mean

Stated because a green run must not be read as more than it is, and each limit below was measured on these pages by planting a probe, running the gate, and restoring from HEAD under a trap:

1. A misspelled top-level key on a schema literal is not caught. Probe: ganttt: 'typo-probe' added to an annotated ObjectGanttSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside gantt: { … } is not caught either. Probe: startDateFeild inside the gantt block. Gate stayed green — GanttConfig is SpecGanttConfig & { … } and the spec's GanttConfigSchema is z.core.$loose, so the intersection admits unknown keys. (Note the asymmetry with the authoring surface: the spec's CalendarConfigSchema is $strict, so the same typo in a calendar block would be rejected at parse time even though this gate cannot see it.)
3. calendar: { … } is wholly unchecked.ObjectCalendarSchema does not declare a calendar member — unlike ObjectGanttSchema, which does declare gantt — so that block lands on the index signature. The four keys used on this page were validated by read-site grep instead.
4. What IS checked, proved rather than assumed. Two probes went red, so the annotations are live and not no-ops: viewMode: 'century' on the gantt literal → TS2322: Type '"century"' is not assignable to type '"month" | "week" | "day" | "quarter" | "year" | undefined'; defaultView: 'agenda' on the calendar literal → TS2322: Type '"agenda"' is not assignable to type '"month" | "week" | "day" | undefined'. A third, type: 'object-calendar' under an ObjectGridSchema annotation on the data-objectstack page, also went red. Declared members are checked; undeclared keys are not.
5. The gate answers only "does this snippet compile against the published types". Schema-key validity under safeParse, whether a type literal names a registered component, and whether a shell example runs are three other questions with three other answers.

Type gaps found and filed, not fixed here

packages/* source is out of this PR's surface, so both were filed unassigned after a targeted dedupe search, and the blocks they affect ship declared rather than deleted:

• finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311 — ObjectCalendarComponentProps.schema is ObjectGridSchema | CalendarSchema, so the page's own Direct Component Usage section cannot type-check. ObjectCalendar.tsx reaches the node through (schema as any).calendar and the registered renderer passes an object-calendar node to it, so the runtime path is real and the declaration is the stale half — the same shape already fixed for the map (ObjectMapSchema(types)声明的键几乎与 ObjectMap 实际读的键无交集:map 块整体未建模,组件 props 类型写的是 ObjectGridSchema,每处 map 读取都走 as any #5018) and the gantt (ObjectGantt reads 11 top-level schema keys that ObjectGanttSchema does not declare — all via as any, so nothing connects read to declaration #5903). That block carries a FRAGMENT_MARKER naming the card; it becomes a compiling block the day the prop names ObjectCalendarSchema.
• finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 — objectName is declared required on ObjectGanttSchema and ObjectCalendarSchema, while both renderers' getDataConfig tries data, then staticData, then objectName. The documented static-data and api-provider routes are therefore supported paths the type rejects (TS2741). Those four blocks ship as plain const declarations with no annotation — they compile and are counted, but their keys are unchecked — rather than inventing an objectName the route does not use. Same shape as finding(types): ObjectMapSchema.objectName is declared REQUIRED but ObjectMap treats it as optional — the documented static-data route cannot be annotated #7296 on ObjectMapSchema; filed separately because that card is scoped to the map by title and body.

Gate verdict lines

Everything below at 355dd8daa, the final commit, with the closure built first under the shared verify lock (VERDICT command-exit 0) and dist/index.d.ts presence confirmed on disk in this worktree before any gate result was trusted — turbo replays cached logs naming other worktrees' paths.

check:doc-snippets exit 0 Semantic phase: 345 of 345 block(s) judged, 0 failed.
Every covered documentation snippet compiles against the built types.
check:doc-fences exit 0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript …
check:doc-types exit 0 Every documented component type is registered.
docs:check-links exit 0 Links are valid across 17 scan roots.
check:control-bytes exit 0 scanned 6010 tracked text file(s); skipped 85 binary
check:readme-exports exit 0 386 self-imports judged (386 real, 0 wrong-path, 0 fabricated)
check-changeset-presence exit 0 No source or published contract of a released package changed in
this range, so no changeset is owed.
vitest (repo root) exit 0 Test Files 7 passed (7) · Tests 177 passed (177)

The seven vitest files are every file git grep -l check-doc-snippet-types -- '*.test.ts' '*.test.tsx' names — the two obvious ones plus five pin suites in examples/schema-catalog, plugin-gantt, react and types that an edit to this script could have hijacked. Run from the repo root with --maxWorkers=2, never through pnpm --filter.

check:readme-exports first read NOT MEASURED, not red: it exited 1 with three findings, all three the string its type entry ./dist/index.d.ts is not on disk -- run pnpm build first for plugin-ai, and none naming a file in this diff. Building that closure made it a real measurement, and it is genuinely green.

Declared narrowing

Repo-wide pnpm lint was narrowed to the four changed files, and the narrowing is a measurement rather than a skip:

1. Population read from ESLint's own config, not from a guess: npx eslint --no-inline-config --format json on the four files reports the three .mdx pages as File ignored because no matching configuration was supplied — they are not in ESLint's population at all.
2. File count read from the JSON output: 4 files judged, 1 of them actually linted (scripts/check-doc-snippet-types.mjs), 0 errors, 0 warnings.
3. Config invariance for untouched files: eslint.config.js sets no project, projectService or tsconfigRootDir, so type-aware linting is not enabled and nothing in this diff can move the verdict on a file it does not touch.

A control-byte self-scan (grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]') over the four changed files returns no hits, beside the repo-wide gate above.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01BGMDbrVa8JjZcCQ7DWYH1b

---

Generated by Claude Code

[yinlianghui]

Part of #5174

Batch 6 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 41 blocks, 33 compile against the built dist, 8 carry a FRAGMENT_MARKER with a written, measured reason. 74 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 5 (#7294) landed while this was in flight; origin/main was merged (never rebased) and the two ledger hunks are disjoint removals, as predicted.

Pages taken, and how each block reached zero

All counts produced with the gate's own scanFences, not a hand grep.

page	blocks	compile	declared	diagnostics cleared	real defects found, and the shipped type each was checked against
content/docs/plugins/plugin-calendar.mdx	15	12	3	28 (19 syntax, 9 semantic)	calendar.descriptionField is fabricated — not a member of @objectstack/spec's CalendarConfigSchema (which is $strict and holds exactly startDateField, endDateField, titleField, colorField) and read at zero sites in packages/plugin-calendar; ObjectCalendar.tsx:420 destructures exactly those four. Removed from the "Appointment Scheduler" example and from the published CalendarConfig reference. The "TypeScript Support" section annotated an object-calendar node as ObjectGridSchema — an annotation that cannot hold, since ObjectGridSchema.type is the literal 'object-grid'; repointed to the real ObjectCalendarSchema.
content/docs/utilities/data-objectstack.mdx	14	11	3	17 (0 syntax, 17 semantic)	No fabricated API. Eight blocks were unrunnable as written — a reader copying one got Cannot find name 'createObjectStackAdapter' / 'User' / 'dataSource' / 'mySchema' — and were made self-contained against packages/data-objectstack/dist/index.d.ts. The factory's config signature block was verified member-for-member against the shipped createObjectStackAdapter declaration, and the ElementDataSource restatement member-for-member against ElementDataSourceSchema in the installed @objectstack/spec: both accurate.
content/docs/plugins/plugin-gantt.mdx	12	10	2	29 (26 syntax, 3 semantic)	No fabricated key surfaced. The "Task Click" example rendered ObjectGantt with neither the component nor dataSource in scope — a copy-paste example broken at its first line; rewritten as a real component taking a typed DataSource prop. Six bare object literals became annotated ObjectGanttSchema declarations, which puts their gantt: { … } blocks under GanttConfig for the first time.

Ledger 40 → 37 (6 .mdx + 31 README). Covered documents 184 → 187 — strictly grows. Covered blocks 440 → 481; compiled 312 → 345; declared fragments 128 → 136. The three per-page splits (12+11+10 = 33 compile, 3+3+2 = 8 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — git diff origin/main -- scripts/check-doc-snippet-types.mjs is 0 additions, 6 deletions.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, origin/main vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batch 5 recorded.
• Covered count strictly grows — 184 → 187, ungated 40 → 37.
• Every page taken is off the ledger and every block resolves the two honest ways — compile, or a FRAGMENT_MARKER whose reason names the measured diagnostics. No third route, no UNGATED_DOCS addition, no fence re-labelled to duck the gate.

Before / after, both at a fully built tree, exit codes captured by redirect-then-$? and never through a pipe:

BEFORE (origin/main dd5b01b59 content for the four files, swapped in under an
EXIT/INT/TERM trap; restore proved by an empty `git diff HEAD`)
Scanned 224 document(s): 184 covered (83 hold a ts/tsx block), 40 ungated
Covered blocks: 440 — 312 to compile, 128 declared fragment(s)
Semantic phase: 312 of 312 block(s) judged, 0 failed exit 0
AFTER (355dd8daa)
Scanned 224 document(s): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0

The lid check, per page — including the negative results

Resolving an unresolved name can uncover diagnostics the first error was hiding. Run on all three:

• plugin-gantt.mdx — NEGATIVE. Clearing 26 parse failures and the ObjectGantt / dataSource undefined names exposed nothing underneath: the re-run was clean. Reported as a negative result.
• data-objectstack.mdx — NEGATIVE. Eight blocks' worth of TS2304 resolved and the re-run was clean. The two prose blocks that survive as declared fragments were then checked by hand against the shipped declaration and against @objectstack/spec, and both are accurate.
• plugin-calendar.mdx — POSITIVE, once. With the block's own names resolved, ObjectCalendarComponentProps.schema turned out to be typed ObjectGridSchema | CalendarSchema, and no object-calendar node is assignable to either — ObjectGridSchema.type is the literal 'object-grid' and CalendarSchema is the form date picker (type: 'calendar'). Filed as finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311, not cast around.

The read-site grep — what the compiler structurally cannot see

BaseSchema carries [key: string]: any, so a wrong TOP-LEVEL key on any schema literal is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites, and that is what caught the descriptionField defect: zero read sites anywhere in packages/plugin-calendar, while the page taught it twice. The check found nothing further on the gantt or data-objectstack literals.

What the green does not mean

Stated because a green run must not be read as more than it is, and each limit below was measured on these pages by planting a probe, running the gate, and restoring from HEAD under a trap:

1. A misspelled top-level key on a schema literal is not caught. Probe: ganttt: 'typo-probe' added to an annotated ObjectGanttSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside gantt: { … } is not caught either. Probe: startDateFeild inside the gantt block. Gate stayed green — GanttConfig is SpecGanttConfig & { … } and the spec's GanttConfigSchema is z.core.$loose, so the intersection admits unknown keys. (Note the asymmetry with the authoring surface: the spec's CalendarConfigSchema is $strict, so the same typo in a calendar block would be rejected at parse time even though this gate cannot see it.)
3. calendar: { … } is wholly unchecked.ObjectCalendarSchema does not declare a calendar member — unlike ObjectGanttSchema, which does declare gantt — so that block lands on the index signature. The four keys used on this page were validated by read-site grep instead.
4. What IS checked, proved rather than assumed. Two probes went red, so the annotations are live and not no-ops: viewMode: 'century' on the gantt literal → TS2322: Type '"century"' is not assignable to type '"month" | "week" | "day" | "quarter" | "year" | undefined'; defaultView: 'agenda' on the calendar literal → TS2322: Type '"agenda"' is not assignable to type '"month" | "week" | "day" | undefined'. A third, type: 'object-calendar' under an ObjectGridSchema annotation on the data-objectstack page, also went red. Declared members are checked; undeclared keys are not.
5. The gate answers only "does this snippet compile against the published types". Schema-key validity under safeParse, whether a type literal names a registered component, and whether a shell example runs are three other questions with three other answers.

Type gaps found and filed, not fixed here

packages/* source is out of this PR's surface, so both were filed unassigned after a targeted dedupe search, and the blocks they affect ship declared rather than deleted:

• finding(plugin-calendar): ObjectCalendarComponentProps.schema is typed ObjectGridSchema | CalendarSchema, so no object-calendar node is assignable — the documented direct-React usage cannot compile #7311 — ObjectCalendarComponentProps.schema is ObjectGridSchema | CalendarSchema, so the page's own Direct Component Usage section cannot type-check. ObjectCalendar.tsx reaches the node through (schema as any).calendar and the registered renderer passes an object-calendar node to it, so the runtime path is real and the declaration is the stale half — the same shape already fixed for the map (ObjectMapSchema(types)声明的键几乎与 ObjectMap 实际读的键无交集:map 块整体未建模,组件 props 类型写的是 ObjectGridSchema,每处 map 读取都走 as any #5018) and the gantt (ObjectGantt reads 11 top-level schema keys that ObjectGanttSchema does not declare — all via as any, so nothing connects read to declaration #5903). That block carries a FRAGMENT_MARKER naming the card; it becomes a compiling block the day the prop names ObjectCalendarSchema.
• finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 — objectName is declared required on ObjectGanttSchema and ObjectCalendarSchema, while both renderers' getDataConfig tries data, then staticData, then objectName. The documented static-data and api-provider routes are therefore supported paths the type rejects (TS2741). Those four blocks ship as plain const declarations with no annotation — they compile and are counted, but their keys are unchecked — rather than inventing an objectName the route does not use. Same shape as finding(types): ObjectMapSchema.objectName is declared REQUIRED but ObjectMap treats it as optional — the documented static-data route cannot be annotated #7296 on ObjectMapSchema; filed separately because that card is scoped to the map by title and body.

Gate verdict lines

Everything below at 355dd8daa, the final commit, with the closure built first under the shared verify lock (VERDICT command-exit 0) and dist/index.d.ts presence confirmed on disk in this worktree before any gate result was trusted — turbo replays cached logs naming other worktrees' paths.

check:doc-snippets exit 0 Semantic phase: 345 of 345 block(s) judged, 0 failed.
Every covered documentation snippet compiles against the built types.
check:doc-fences exit 0 every TypeScript block in 224 document(s) is fenced ts/tsx/typescript …
check:doc-types exit 0 Every documented component type is registered.
docs:check-links exit 0 Links are valid across 17 scan roots.
check:control-bytes exit 0 scanned 6010 tracked text file(s); skipped 85 binary
check:readme-exports exit 0 386 self-imports judged (386 real, 0 wrong-path, 0 fabricated)
check-changeset-presence exit 0 No source or published contract of a released package changed in
this range, so no changeset is owed.
vitest (repo root) exit 0 Test Files 7 passed (7) · Tests 177 passed (177)

The seven vitest files are every file git grep -l check-doc-snippet-types -- '*.test.ts' '*.test.tsx' names — the two obvious ones plus five pin suites in examples/schema-catalog, plugin-gantt, react and types that an edit to this script could have hijacked. Run from the repo root with --maxWorkers=2, never through pnpm --filter.

check:readme-exports first read NOT MEASURED, not red: it exited 1 with three findings, all three the string its type entry ./dist/index.d.ts is not on disk -- run pnpm build first for plugin-ai, and none naming a file in this diff. Building that closure made it a real measurement, and it is genuinely green.

Declared narrowing

Repo-wide pnpm lint was narrowed to the four changed files, and the narrowing is a measurement rather than a skip:

1. Population read from ESLint's own config, not from a guess: npx eslint --no-inline-config --format json on the four files reports the three .mdx pages as File ignored because no matching configuration was supplied — they are not in ESLint's population at all.
2. File count read from the JSON output: 4 files judged, 1 of them actually linted (scripts/check-doc-snippet-types.mjs), 0 errors, 0 warnings.
3. Config invariance for untouched files: eslint.config.js sets no project, projectService or tsconfigRootDir, so type-aware linting is not enabled and nothing in this diff can move the verdict on a file it does not touch.

A control-byte self-scan (grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]') over the four changed files returns no hits, beside the repo-wide gate above.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01BGMDbrVa8JjZcCQ7DWYH1b

---

Generated by Claude Code