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

[yinlianghui]

Part of #5174

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

Batch 6 (#7314) landed while this was in flight; origin/main was merged (never rebased). The two ledger hunks conflicted textually because they are adjacent lines in one sorted object, and the conflict was resolved as the union of both removal sets — everything either side took out stays out. create-plugin.mdx, the only entry inside the conflict region that neither batch claimed, is the only one that survives it.

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	what was actually wrong
content/docs/plugins/plugin-timeline.mdx	9	9	0	1 (1 syntax, 0 semantic)	No fabricated key — every key the page documents has read sites. The page's real problem was that it verified nothing: eight blocks were unannotated literals, and the two "Date Formatting" / "Time Scales" fences held bare { dateFormat: 'short' } objects that TypeScript parses as block statements containing labelled expressions — { dateFormatt: 'short' } was equally green. Five schema literals now carry the TimelineSchema annotation the page's own prose already claims ("Every key above is declared on the exported TimelineSchema, so … a wrong value is a type error"), and the two value-list fences became indexed-access declarations. items: [...] in "Custom Colors" was the one parse failure.
content/docs/plugins/plugin-kanban.mdx	8	8	0	14 (6 syntax, 8 semantic)	The eight semantic diagnostics were TS7006 on onCardMove's four parameters, twice — the callback was untyped because the literal was unannotated, while KanbanSchema declares it as taking four typed parameters. Five literals now carry KanbanSchema / KanbanCard / KanbanColumn. Three parse failures: a bare object-kanban literal, cards: [...], and an "Event Handling" block with columns: [...], a top-level await in a void-returning callback, and three ambient names — rewritten as a real hook. One type gap found and filed (#7322), not fixed here.
content/docs/utilities/runner.mdx	8	3	5	11 (5 syntax, 6 semantic)	No fabricated API. Five blocks genuinely cannot compile here and are declared with measured reasons: four name @object-ui/plugin-yourplugin / -myplugin / ./components/MyComponent — the package or file the reader is being walked through creating — and one is a single property out of resolve.alias. Two real repairs: the Error Boundaries example imported SchemaErrorBoundary but rendered SchemaRenderer with neither the component nor schema in scope, so a reader copying it got two TS2304s; and defineConfig was called with no import. Two fences holding JSX were labelled typescript and are now tsx — a mislabel, corrected rather than declared. One fence held two files (a TS side-effect import and a JSON page document); the JSON half is a mislabel and now has its own json fence.

Ledger 37 → 34 (3 .mdx + 31 README). Covered documents 187 → 190 — strictly grows. Covered blocks 481 → 506; compiled 345 → 365; declared fragments 136 → 141. The per-page splits (9+8+3 = 20 compile, 0+0+5 = 5 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — 3 entry keys deleted, 0 added.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, merged base ad3d4029a vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batches 5 and 6 recorded.
• Covered count strictly grows — 187 → 190, ungated 37 → 34.
• 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. The two fence-language corrections go the other way: both blocks stay in the collected ts/tsx population, and the JSON document that leaves it was never TypeScript.

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

BEFORE (merged base ad3d4029a 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): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0
AFTER (9d6e6f5a7)
Scanned 224 document(s): 190 covered (89 hold a ts/tsx block), 34 ungated
Covered blocks: 506 — 365 to compile, 141 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 365 of 365 block(s) judged, 0 failed exit 0

The branch point d717e8bc3 was measured the same way before the merge (184 covered / 40 ungated / 440 blocks, exit 0), which is batch 6's own BEFORE — the two agree.

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, each planted and restored from HEAD under a trap:

• plugin-kanban.mdx — POSITIVE, and it is the finding. The row-cap example is an object-kanban node. Annotated with ObjectKanbanSchema: TS2741: Property 'groupField' is missing … but required. Annotated with KanbanSchema, which is what ObjectKanbanComponentProps.schema actually declares: TS2322: Type '"object-kanban"' is not assignable to type '"kanban"'. Neither declared type accepts the shape the renderer reads. Note what the first diagnostic does not say — groupBy and limit raised nothing at all, because BaseSchema's index signature absorbed them. Filed as finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322; the block ships as a plain const with no annotation.
• plugin-timeline.mdx — NEGATIVE. The single parse failure (items: [...]) had kept that block out of the semantic phase entirely. With it resolved and five literals newly annotated, the re-run exposed nothing underneath. Reported as a negative result.
• runner.mdx — NEGATIVE, twice. The declared fragments hide their contents from the gate, so both were probed with the fictional specifier shimmed to a real one: "Plugin Not Loading" with @object-ui/plugin-yourplugin swapped for @object-ui/plugin-markdown, and the ComponentRegistry.register block with ./components/MyComponent replaced by a local declaration. Both came back clean — the declared blocks are correct documentation the gate cannot reach, not defects in hiding.

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

BaseSchema carries [key: string]: any, and KanbanCard carries one of its own, so a wrong key on either is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites:

• Timeline — variant, items, dateFormat, scale, rowLabel, minDate, maxDate, className all read in plugin-timeline/src/renderer.tsx; the item keys time, title, description, variant, icon, content, className, startDate, endDate and the gantt row's label likewise. Nothing fabricated.
• Kanban — card id / title / description / badges, badge label / variant, column id / title / cards / limit / className all read in KanbanImpl.tsx and KanbanEnhanced.tsx. Nothing fabricated.
• object-kanban — this is where it paid. schema.groupBy is read at nine sites in ObjectKanban.tsx and schema.limit at two, while groupField — the key ObjectKanbanSchema marks required — has zero read sites in packages/plugin-kanban. The package's own test suite writes { type: 'object-kanban', objectName, groupBy, limit }, the documented shape. The page is right and the declaration is the stale half.

What the green does not mean

Stated because a green run must not be read as more than it is. Each limit below was measured on these pages by planting a probe, proving it reached the disk by counting the injected and removed text, running the gate, and restoring from HEAD under a trap with the restore proved by an empty git diff HEAD and a blob hash matching the HEAD blob.

Three probes stayed GREEN — these are real blind spots:

1. A misspelled top-level key on an annotated schema literal is not caught. Probe: dateFormatt: 'long' added to the annotated TimelineSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside items is not caught either. Probe: titlee on a timeline item. Gate stayed green — TimelineSchema.items is declared any[], deliberately, because the two element shapes are discriminated by variant and read dynamically. The item vocabulary this page documents in full is verified by read-site grep and by nothing else.
3. A misspelled key on a KanbanCard is not caught. Probe: descriptionn on the annotated card literal. Gate stayed green — KanbanCard carries its own [key: string]: any, for the runtime-synthesized card keys.

Two probes went RED — so the annotations are live, not no-ops:

4. variant: 'diagonal' on the annotated TimelineSchema literal produced TS2322: Type '"diagonal"' is not assignable to type '"horizontal" | "vertical" | "gantt" | undefined'.
5. variant: 'critical' on a KanbanCard badge produced TS2322: Type '"critical"' is not assignable to type '"default" | "outline" | "destructive" | "secondary" | undefined' — the badge object is sealed even though its parent card is not.

So the boundary on these pages is exactly this: declared members with closed unions are genuinely checked; anything reaching an index signature, and everything inside items, is not. That is why the read-site grep above is not optional decoration — it is the only thing covering the second half.

6. 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 gap found and filed, not fixed here

packages/* source is out of this PR's surface, so it was filed unassigned after a targeted dedupe search (which returned the same-family cards #7311, #7313, #5903 and #6973, so it was live rather than silently empty; none is this defect):

• finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 — ObjectKanbanSchema requires groupField, a key with zero read sites in packages/plugin-kanban, and declares neither groupBy nor limit, the two keys ObjectKanban.tsx actually reads. Separately, ObjectKanbanComponentProps.schema is typed KanbanSchema, whose type is the literal 'kanban', so no object-kanban node is assignable to it either; ObjectKanbanRenderer types its own prop as any, so nothing connects the registered node to either declaration. The row-cap block therefore ships as a plain const with no annotation — it compiles and is counted, but its keys are unchecked — rather than inventing a groupField the renderer does not read. Same family 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 and 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.

Header prose corrected, and why it is a rewrite rather than a new number

Batch 6 recorded, without filing, that the ledger docblock's sentence "what remains here is 12 .mdx pages and 32 package READMEs" had drifted. Batch 7's dispatch authorised fixing it now that the ledger surface is being edited for its own sake.

It is corrected by removing the count, not by writing a fresh one. Both halves were already wrong (the README count has been 31 since #5259; the .mdx count moves with every batch), and any number written there would have been stale again within the hour — batch 6 landed mid-run and moved it. The sentence now points at the entries below it, which are re-derived every run and shrink-only, so the names in the list are the count. Nothing mechanical fails on a stale number in a comment, which is precisely why it should not carry one.

This edit is header prose, above the fence-scanning banner, so the strictness proof above is unaffected and still holds byte-for-byte.

Gate verdict lines

Everything below at 9d6e6f5a7, 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 for all 25 filters before any gate result was trusted — turbo replayed cached logs naming another worktree's path (objectui-issue-5174-b6) on the first build, so this was checked rather than assumed.

check:doc-snippets exit 0 Semantic phase: 365 of 365 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,
except 80 declared file(s) carrying 90 block(s) of #5867's population
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 6015 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:doc-fences is unmoved by this PR: plugin-timeline.mdx and plugin-kanban.mdx each carry one entry in #5867's shrink-only ledger for their plaintext-fenced "TypeScript Support" blocks, and those blocks are untouched here — that axis belongs to #5867.

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

One process note worth recording: the probe harness's first disk-proof step was itself defective — it used grep -cF on multi-line strings, which counts matching lines rather than occurrences, and reported a false "no-op mutation". It failed closed: the harness aborted and the trap restored before any gate ran, so no reading was taken from it. The proof step was corrected to count the full multi-line strings, and every probe above was then run and recorded once.

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, 3 ignored by config, 1 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 over the C0 range plus DEL) across 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 7 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 25 blocks, 20 compile against the built dist, 5 carry a FRAGMENT_MARKER with a written, measured reason. 26 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 6 (#7314) landed while this was in flight; origin/main was merged (never rebased). The two ledger hunks conflicted textually because they are adjacent lines in one sorted object, and the conflict was resolved as the union of both removal sets — everything either side took out stays out. create-plugin.mdx, the only entry inside the conflict region that neither batch claimed, is the only one that survives it.

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	what was actually wrong
content/docs/plugins/plugin-timeline.mdx	9	9	0	1 (1 syntax, 0 semantic)	No fabricated key — every key the page documents has read sites. The page's real problem was that it verified nothing: eight blocks were unannotated literals, and the two "Date Formatting" / "Time Scales" fences held bare { dateFormat: 'short' } objects that TypeScript parses as block statements containing labelled expressions — { dateFormatt: 'short' } was equally green. Five schema literals now carry the TimelineSchema annotation the page's own prose already claims ("Every key above is declared on the exported TimelineSchema, so … a wrong value is a type error"), and the two value-list fences became indexed-access declarations. items: [...] in "Custom Colors" was the one parse failure.
content/docs/plugins/plugin-kanban.mdx	8	8	0	14 (6 syntax, 8 semantic)	The eight semantic diagnostics were TS7006 on onCardMove's four parameters, twice — the callback was untyped because the literal was unannotated, while KanbanSchema declares it as taking four typed parameters. Five literals now carry KanbanSchema / KanbanCard / KanbanColumn. Three parse failures: a bare object-kanban literal, cards: [...], and an "Event Handling" block with columns: [...], a top-level await in a void-returning callback, and three ambient names — rewritten as a real hook. One type gap found and filed (#7322), not fixed here.
content/docs/utilities/runner.mdx	8	3	5	11 (5 syntax, 6 semantic)	No fabricated API. Five blocks genuinely cannot compile here and are declared with measured reasons: four name @object-ui/plugin-yourplugin / -myplugin / ./components/MyComponent — the package or file the reader is being walked through creating — and one is a single property out of resolve.alias. Two real repairs: the Error Boundaries example imported SchemaErrorBoundary but rendered SchemaRenderer with neither the component nor schema in scope, so a reader copying it got two TS2304s; and defineConfig was called with no import. Two fences holding JSX were labelled typescript and are now tsx — a mislabel, corrected rather than declared. One fence held two files (a TS side-effect import and a JSON page document); the JSON half is a mislabel and now has its own json fence.

Ledger 37 → 34 (3 .mdx + 31 README). Covered documents 187 → 190 — strictly grows. Covered blocks 481 → 506; compiled 345 → 365; declared fragments 136 → 141. The per-page splits (9+8+3 = 20 compile, 0+0+5 = 5 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — 3 entry keys deleted, 0 added.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, merged base ad3d4029a vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batches 5 and 6 recorded.
• Covered count strictly grows — 187 → 190, ungated 37 → 34.
• 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. The two fence-language corrections go the other way: both blocks stay in the collected ts/tsx population, and the JSON document that leaves it was never TypeScript.

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

BEFORE (merged base ad3d4029a 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): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0
AFTER (9d6e6f5a7)
Scanned 224 document(s): 190 covered (89 hold a ts/tsx block), 34 ungated
Covered blocks: 506 — 365 to compile, 141 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 365 of 365 block(s) judged, 0 failed exit 0

The branch point d717e8bc3 was measured the same way before the merge (184 covered / 40 ungated / 440 blocks, exit 0), which is batch 6's own BEFORE — the two agree.

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, each planted and restored from HEAD under a trap:

• plugin-kanban.mdx — POSITIVE, and it is the finding. The row-cap example is an object-kanban node. Annotated with ObjectKanbanSchema: TS2741: Property 'groupField' is missing … but required. Annotated with KanbanSchema, which is what ObjectKanbanComponentProps.schema actually declares: TS2322: Type '"object-kanban"' is not assignable to type '"kanban"'. Neither declared type accepts the shape the renderer reads. Note what the first diagnostic does not say — groupBy and limit raised nothing at all, because BaseSchema's index signature absorbed them. Filed as finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322; the block ships as a plain const with no annotation.
• plugin-timeline.mdx — NEGATIVE. The single parse failure (items: [...]) had kept that block out of the semantic phase entirely. With it resolved and five literals newly annotated, the re-run exposed nothing underneath. Reported as a negative result.
• runner.mdx — NEGATIVE, twice. The declared fragments hide their contents from the gate, so both were probed with the fictional specifier shimmed to a real one: "Plugin Not Loading" with @object-ui/plugin-yourplugin swapped for @object-ui/plugin-markdown, and the ComponentRegistry.register block with ./components/MyComponent replaced by a local declaration. Both came back clean — the declared blocks are correct documentation the gate cannot reach, not defects in hiding.

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

BaseSchema carries [key: string]: any, and KanbanCard carries one of its own, so a wrong key on either is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites:

• Timeline — variant, items, dateFormat, scale, rowLabel, minDate, maxDate, className all read in plugin-timeline/src/renderer.tsx; the item keys time, title, description, variant, icon, content, className, startDate, endDate and the gantt row's label likewise. Nothing fabricated.
• Kanban — card id / title / description / badges, badge label / variant, column id / title / cards / limit / className all read in KanbanImpl.tsx and KanbanEnhanced.tsx. Nothing fabricated.
• object-kanban — this is where it paid. schema.groupBy is read at nine sites in ObjectKanban.tsx and schema.limit at two, while groupField — the key ObjectKanbanSchema marks required — has zero read sites in packages/plugin-kanban. The package's own test suite writes { type: 'object-kanban', objectName, groupBy, limit }, the documented shape. The page is right and the declaration is the stale half.

What the green does not mean

Stated because a green run must not be read as more than it is. Each limit below was measured on these pages by planting a probe, proving it reached the disk by counting the injected and removed text, running the gate, and restoring from HEAD under a trap with the restore proved by an empty git diff HEAD and a blob hash matching the HEAD blob.

Three probes stayed GREEN — these are real blind spots:

1. A misspelled top-level key on an annotated schema literal is not caught. Probe: dateFormatt: 'long' added to the annotated TimelineSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside items is not caught either. Probe: titlee on a timeline item. Gate stayed green — TimelineSchema.items is declared any[], deliberately, because the two element shapes are discriminated by variant and read dynamically. The item vocabulary this page documents in full is verified by read-site grep and by nothing else.
3. A misspelled key on a KanbanCard is not caught. Probe: descriptionn on the annotated card literal. Gate stayed green — KanbanCard carries its own [key: string]: any, for the runtime-synthesized card keys.

Two probes went RED — so the annotations are live, not no-ops:

4. variant: 'diagonal' on the annotated TimelineSchema literal produced TS2322: Type '"diagonal"' is not assignable to type '"horizontal" | "vertical" | "gantt" | undefined'.
5. variant: 'critical' on a KanbanCard badge produced TS2322: Type '"critical"' is not assignable to type '"default" | "outline" | "destructive" | "secondary" | undefined' — the badge object is sealed even though its parent card is not.

So the boundary on these pages is exactly this: declared members with closed unions are genuinely checked; anything reaching an index signature, and everything inside items, is not. That is why the read-site grep above is not optional decoration — it is the only thing covering the second half.

6. 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 gap found and filed, not fixed here

packages/* source is out of this PR's surface, so it was filed unassigned after a targeted dedupe search (which returned the same-family cards #7311, #7313, #5903 and #6973, so it was live rather than silently empty; none is this defect):

• finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 — ObjectKanbanSchema requires groupField, a key with zero read sites in packages/plugin-kanban, and declares neither groupBy nor limit, the two keys ObjectKanban.tsx actually reads. Separately, ObjectKanbanComponentProps.schema is typed KanbanSchema, whose type is the literal 'kanban', so no object-kanban node is assignable to it either; ObjectKanbanRenderer types its own prop as any, so nothing connects the registered node to either declaration. The row-cap block therefore ships as a plain const with no annotation — it compiles and is counted, but its keys are unchecked — rather than inventing a groupField the renderer does not read. Same family 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 and 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.

Header prose corrected, and why it is a rewrite rather than a new number

Batch 6 recorded, without filing, that the ledger docblock's sentence "what remains here is 12 .mdx pages and 32 package READMEs" had drifted. Batch 7's dispatch authorised fixing it now that the ledger surface is being edited for its own sake.

It is corrected by removing the count, not by writing a fresh one. Both halves were already wrong (the README count has been 31 since #5259; the .mdx count moves with every batch), and any number written there would have been stale again within the hour — batch 6 landed mid-run and moved it. The sentence now points at the entries below it, which are re-derived every run and shrink-only, so the names in the list are the count. Nothing mechanical fails on a stale number in a comment, which is precisely why it should not carry one.

This edit is header prose, above the fence-scanning banner, so the strictness proof above is unaffected and still holds byte-for-byte.

Gate verdict lines

Everything below at 9d6e6f5a7, 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 for all 25 filters before any gate result was trusted — turbo replayed cached logs naming another worktree's path (objectui-issue-5174-b6) on the first build, so this was checked rather than assumed.

check:doc-snippets exit 0 Semantic phase: 365 of 365 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,
except 80 declared file(s) carrying 90 block(s) of #5867's population
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 6015 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:doc-fences is unmoved by this PR: plugin-timeline.mdx and plugin-kanban.mdx each carry one entry in #5867's shrink-only ledger for their plaintext-fenced "TypeScript Support" blocks, and those blocks are untouched here — that axis belongs to #5867.

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

One process note worth recording: the probe harness's first disk-proof step was itself defective — it used grep -cF on multi-line strings, which counts matching lines rather than occurrences, and reported a false "no-op mutation". It failed closed: the harness aborted and the trap restored before any gate ran, so no reading was taken from it. The proof step was corrected to count the full multi-line strings, and every probe above was then run and recorded once.

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, 3 ignored by config, 1 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 over the C0 range plus DEL) across 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 7 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 25 blocks, 20 compile against the built dist, 5 carry a FRAGMENT_MARKER with a written, measured reason. 26 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 6 (#7314) landed while this was in flight; origin/main was merged (never rebased). The two ledger hunks conflicted textually because they are adjacent lines in one sorted object, and the conflict was resolved as the union of both removal sets — everything either side took out stays out. create-plugin.mdx, the only entry inside the conflict region that neither batch claimed, is the only one that survives it.

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	what was actually wrong
content/docs/plugins/plugin-timeline.mdx	9	9	0	1 (1 syntax, 0 semantic)	No fabricated key — every key the page documents has read sites. The page's real problem was that it verified nothing: eight blocks were unannotated literals, and the two "Date Formatting" / "Time Scales" fences held bare { dateFormat: 'short' } objects that TypeScript parses as block statements containing labelled expressions — { dateFormatt: 'short' } was equally green. Five schema literals now carry the TimelineSchema annotation the page's own prose already claims ("Every key above is declared on the exported TimelineSchema, so … a wrong value is a type error"), and the two value-list fences became indexed-access declarations. items: [...] in "Custom Colors" was the one parse failure.
content/docs/plugins/plugin-kanban.mdx	8	8	0	14 (6 syntax, 8 semantic)	The eight semantic diagnostics were TS7006 on onCardMove's four parameters, twice — the callback was untyped because the literal was unannotated, while KanbanSchema declares it as taking four typed parameters. Five literals now carry KanbanSchema / KanbanCard / KanbanColumn. Three parse failures: a bare object-kanban literal, cards: [...], and an "Event Handling" block with columns: [...], a top-level await in a void-returning callback, and three ambient names — rewritten as a real hook. One type gap found and filed (#7322), not fixed here.
content/docs/utilities/runner.mdx	8	3	5	11 (5 syntax, 6 semantic)	No fabricated API. Five blocks genuinely cannot compile here and are declared with measured reasons: four name @object-ui/plugin-yourplugin / -myplugin / ./components/MyComponent — the package or file the reader is being walked through creating — and one is a single property out of resolve.alias. Two real repairs: the Error Boundaries example imported SchemaErrorBoundary but rendered SchemaRenderer with neither the component nor schema in scope, so a reader copying it got two TS2304s; and defineConfig was called with no import. Two fences holding JSX were labelled typescript and are now tsx — a mislabel, corrected rather than declared. One fence held two files (a TS side-effect import and a JSON page document); the JSON half is a mislabel and now has its own json fence.

Ledger 37 → 34 (3 .mdx + 31 README). Covered documents 187 → 190 — strictly grows. Covered blocks 481 → 506; compiled 345 → 365; declared fragments 136 → 141. The per-page splits (9+8+3 = 20 compile, 0+0+5 = 5 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — 3 entry keys deleted, 0 added.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, merged base ad3d4029a vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batches 5 and 6 recorded.
• Covered count strictly grows — 187 → 190, ungated 37 → 34.
• 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. The two fence-language corrections go the other way: both blocks stay in the collected ts/tsx population, and the JSON document that leaves it was never TypeScript.

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

BEFORE (merged base ad3d4029a 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): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0
AFTER (9d6e6f5a7)
Scanned 224 document(s): 190 covered (89 hold a ts/tsx block), 34 ungated
Covered blocks: 506 — 365 to compile, 141 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 365 of 365 block(s) judged, 0 failed exit 0

The branch point d717e8bc3 was measured the same way before the merge (184 covered / 40 ungated / 440 blocks, exit 0), which is batch 6's own BEFORE — the two agree.

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, each planted and restored from HEAD under a trap:

• plugin-kanban.mdx — POSITIVE, and it is the finding. The row-cap example is an object-kanban node. Annotated with ObjectKanbanSchema: TS2741: Property 'groupField' is missing … but required. Annotated with KanbanSchema, which is what ObjectKanbanComponentProps.schema actually declares: TS2322: Type '"object-kanban"' is not assignable to type '"kanban"'. Neither declared type accepts the shape the renderer reads. Note what the first diagnostic does not say — groupBy and limit raised nothing at all, because BaseSchema's index signature absorbed them. Filed as finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322; the block ships as a plain const with no annotation.
• plugin-timeline.mdx — NEGATIVE. The single parse failure (items: [...]) had kept that block out of the semantic phase entirely. With it resolved and five literals newly annotated, the re-run exposed nothing underneath. Reported as a negative result.
• runner.mdx — NEGATIVE, twice. The declared fragments hide their contents from the gate, so both were probed with the fictional specifier shimmed to a real one: "Plugin Not Loading" with @object-ui/plugin-yourplugin swapped for @object-ui/plugin-markdown, and the ComponentRegistry.register block with ./components/MyComponent replaced by a local declaration. Both came back clean — the declared blocks are correct documentation the gate cannot reach, not defects in hiding.

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

BaseSchema carries [key: string]: any, and KanbanCard carries one of its own, so a wrong key on either is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites:

• Timeline — variant, items, dateFormat, scale, rowLabel, minDate, maxDate, className all read in plugin-timeline/src/renderer.tsx; the item keys time, title, description, variant, icon, content, className, startDate, endDate and the gantt row's label likewise. Nothing fabricated.
• Kanban — card id / title / description / badges, badge label / variant, column id / title / cards / limit / className all read in KanbanImpl.tsx and KanbanEnhanced.tsx. Nothing fabricated.
• object-kanban — this is where it paid. schema.groupBy is read at nine sites in ObjectKanban.tsx and schema.limit at two, while groupField — the key ObjectKanbanSchema marks required — has zero read sites in packages/plugin-kanban. The package's own test suite writes { type: 'object-kanban', objectName, groupBy, limit }, the documented shape. The page is right and the declaration is the stale half.

What the green does not mean

Stated because a green run must not be read as more than it is. Each limit below was measured on these pages by planting a probe, proving it reached the disk by counting the injected and removed text, running the gate, and restoring from HEAD under a trap with the restore proved by an empty git diff HEAD and a blob hash matching the HEAD blob.

Three probes stayed GREEN — these are real blind spots:

1. A misspelled top-level key on an annotated schema literal is not caught. Probe: dateFormatt: 'long' added to the annotated TimelineSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside items is not caught either. Probe: titlee on a timeline item. Gate stayed green — TimelineSchema.items is declared any[], deliberately, because the two element shapes are discriminated by variant and read dynamically. The item vocabulary this page documents in full is verified by read-site grep and by nothing else.
3. A misspelled key on a KanbanCard is not caught. Probe: descriptionn on the annotated card literal. Gate stayed green — KanbanCard carries its own [key: string]: any, for the runtime-synthesized card keys.

Two probes went RED — so the annotations are live, not no-ops:

4. variant: 'diagonal' on the annotated TimelineSchema literal produced TS2322: Type '"diagonal"' is not assignable to type '"horizontal" | "vertical" | "gantt" | undefined'.
5. variant: 'critical' on a KanbanCard badge produced TS2322: Type '"critical"' is not assignable to type '"default" | "outline" | "destructive" | "secondary" | undefined' — the badge object is sealed even though its parent card is not.

So the boundary on these pages is exactly this: declared members with closed unions are genuinely checked; anything reaching an index signature, and everything inside items, is not. That is why the read-site grep above is not optional decoration — it is the only thing covering the second half.

6. 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 gap found and filed, not fixed here

packages/* source is out of this PR's surface, so it was filed unassigned after a targeted dedupe search (which returned the same-family cards #7311, #7313, #5903 and #6973, so it was live rather than silently empty; none is this defect):

• finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 — ObjectKanbanSchema requires groupField, a key with zero read sites in packages/plugin-kanban, and declares neither groupBy nor limit, the two keys ObjectKanban.tsx actually reads. Separately, ObjectKanbanComponentProps.schema is typed KanbanSchema, whose type is the literal 'kanban', so no object-kanban node is assignable to it either; ObjectKanbanRenderer types its own prop as any, so nothing connects the registered node to either declaration. The row-cap block therefore ships as a plain const with no annotation — it compiles and is counted, but its keys are unchecked — rather than inventing a groupField the renderer does not read. Same family 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 and 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.

Header prose corrected, and why it is a rewrite rather than a new number

Batch 6 recorded, without filing, that the ledger docblock's sentence "what remains here is 12 .mdx pages and 32 package READMEs" had drifted. Batch 7's dispatch authorised fixing it now that the ledger surface is being edited for its own sake.

It is corrected by removing the count, not by writing a fresh one. Both halves were already wrong (the README count has been 31 since #5259; the .mdx count moves with every batch), and any number written there would have been stale again within the hour — batch 6 landed mid-run and moved it. The sentence now points at the entries below it, which are re-derived every run and shrink-only, so the names in the list are the count. Nothing mechanical fails on a stale number in a comment, which is precisely why it should not carry one.

This edit is header prose, above the fence-scanning banner, so the strictness proof above is unaffected and still holds byte-for-byte.

Gate verdict lines

Everything below at 9d6e6f5a7, 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 for all 25 filters before any gate result was trusted — turbo replayed cached logs naming another worktree's path (objectui-issue-5174-b6) on the first build, so this was checked rather than assumed.

check:doc-snippets exit 0 Semantic phase: 365 of 365 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,
except 80 declared file(s) carrying 90 block(s) of #5867's population
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 6015 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:doc-fences is unmoved by this PR: plugin-timeline.mdx and plugin-kanban.mdx each carry one entry in #5867's shrink-only ledger for their plaintext-fenced "TypeScript Support" blocks, and those blocks are untouched here — that axis belongs to #5867.

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

One process note worth recording: the probe harness's first disk-proof step was itself defective — it used grep -cF on multi-line strings, which counts matching lines rather than occurrences, and reported a false "no-op mutation". It failed closed: the harness aborted and the trap restored before any gate ran, so no reading was taken from it. The proof step was corrected to count the full multi-line strings, and every probe above was then run and recorded once.

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, 3 ignored by config, 1 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 over the C0 range plus DEL) across 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 7 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 25 blocks, 20 compile against the built dist, 5 carry a FRAGMENT_MARKER with a written, measured reason. 26 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 6 (#7314) landed while this was in flight; origin/main was merged (never rebased). The two ledger hunks conflicted textually because they are adjacent lines in one sorted object, and the conflict was resolved as the union of both removal sets — everything either side took out stays out. create-plugin.mdx, the only entry inside the conflict region that neither batch claimed, is the only one that survives it.

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	what was actually wrong
content/docs/plugins/plugin-timeline.mdx	9	9	0	1 (1 syntax, 0 semantic)	No fabricated key — every key the page documents has read sites. The page's real problem was that it verified nothing: eight blocks were unannotated literals, and the two "Date Formatting" / "Time Scales" fences held bare { dateFormat: 'short' } objects that TypeScript parses as block statements containing labelled expressions — { dateFormatt: 'short' } was equally green. Five schema literals now carry the TimelineSchema annotation the page's own prose already claims ("Every key above is declared on the exported TimelineSchema, so … a wrong value is a type error"), and the two value-list fences became indexed-access declarations. items: [...] in "Custom Colors" was the one parse failure.
content/docs/plugins/plugin-kanban.mdx	8	8	0	14 (6 syntax, 8 semantic)	The eight semantic diagnostics were TS7006 on onCardMove's four parameters, twice — the callback was untyped because the literal was unannotated, while KanbanSchema declares it as taking four typed parameters. Five literals now carry KanbanSchema / KanbanCard / KanbanColumn. Three parse failures: a bare object-kanban literal, cards: [...], and an "Event Handling" block with columns: [...], a top-level await in a void-returning callback, and three ambient names — rewritten as a real hook. One type gap found and filed (#7322), not fixed here.
content/docs/utilities/runner.mdx	8	3	5	11 (5 syntax, 6 semantic)	No fabricated API. Five blocks genuinely cannot compile here and are declared with measured reasons: four name @object-ui/plugin-yourplugin / -myplugin / ./components/MyComponent — the package or file the reader is being walked through creating — and one is a single property out of resolve.alias. Two real repairs: the Error Boundaries example imported SchemaErrorBoundary but rendered SchemaRenderer with neither the component nor schema in scope, so a reader copying it got two TS2304s; and defineConfig was called with no import. Two fences holding JSX were labelled typescript and are now tsx — a mislabel, corrected rather than declared. One fence held two files (a TS side-effect import and a JSON page document); the JSON half is a mislabel and now has its own json fence.

Ledger 37 → 34 (3 .mdx + 31 README). Covered documents 187 → 190 — strictly grows. Covered blocks 481 → 506; compiled 345 → 365; declared fragments 136 → 141. The per-page splits (9+8+3 = 20 compile, 0+0+5 = 5 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — 3 entry keys deleted, 0 added.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, merged base ad3d4029a vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batches 5 and 6 recorded.
• Covered count strictly grows — 187 → 190, ungated 37 → 34.
• 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. The two fence-language corrections go the other way: both blocks stay in the collected ts/tsx population, and the JSON document that leaves it was never TypeScript.

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

BEFORE (merged base ad3d4029a 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): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0
AFTER (9d6e6f5a7)
Scanned 224 document(s): 190 covered (89 hold a ts/tsx block), 34 ungated
Covered blocks: 506 — 365 to compile, 141 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 365 of 365 block(s) judged, 0 failed exit 0

The branch point d717e8bc3 was measured the same way before the merge (184 covered / 40 ungated / 440 blocks, exit 0), which is batch 6's own BEFORE — the two agree.

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, each planted and restored from HEAD under a trap:

• plugin-kanban.mdx — POSITIVE, and it is the finding. The row-cap example is an object-kanban node. Annotated with ObjectKanbanSchema: TS2741: Property 'groupField' is missing … but required. Annotated with KanbanSchema, which is what ObjectKanbanComponentProps.schema actually declares: TS2322: Type '"object-kanban"' is not assignable to type '"kanban"'. Neither declared type accepts the shape the renderer reads. Note what the first diagnostic does not say — groupBy and limit raised nothing at all, because BaseSchema's index signature absorbed them. Filed as finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322; the block ships as a plain const with no annotation.
• plugin-timeline.mdx — NEGATIVE. The single parse failure (items: [...]) had kept that block out of the semantic phase entirely. With it resolved and five literals newly annotated, the re-run exposed nothing underneath. Reported as a negative result.
• runner.mdx — NEGATIVE, twice. The declared fragments hide their contents from the gate, so both were probed with the fictional specifier shimmed to a real one: "Plugin Not Loading" with @object-ui/plugin-yourplugin swapped for @object-ui/plugin-markdown, and the ComponentRegistry.register block with ./components/MyComponent replaced by a local declaration. Both came back clean — the declared blocks are correct documentation the gate cannot reach, not defects in hiding.

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

BaseSchema carries [key: string]: any, and KanbanCard carries one of its own, so a wrong key on either is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites:

• Timeline — variant, items, dateFormat, scale, rowLabel, minDate, maxDate, className all read in plugin-timeline/src/renderer.tsx; the item keys time, title, description, variant, icon, content, className, startDate, endDate and the gantt row's label likewise. Nothing fabricated.
• Kanban — card id / title / description / badges, badge label / variant, column id / title / cards / limit / className all read in KanbanImpl.tsx and KanbanEnhanced.tsx. Nothing fabricated.
• object-kanban — this is where it paid. schema.groupBy is read at nine sites in ObjectKanban.tsx and schema.limit at two, while groupField — the key ObjectKanbanSchema marks required — has zero read sites in packages/plugin-kanban. The package's own test suite writes { type: 'object-kanban', objectName, groupBy, limit }, the documented shape. The page is right and the declaration is the stale half.

What the green does not mean

Stated because a green run must not be read as more than it is. Each limit below was measured on these pages by planting a probe, proving it reached the disk by counting the injected and removed text, running the gate, and restoring from HEAD under a trap with the restore proved by an empty git diff HEAD and a blob hash matching the HEAD blob.

Three probes stayed GREEN — these are real blind spots:

1. A misspelled top-level key on an annotated schema literal is not caught. Probe: dateFormatt: 'long' added to the annotated TimelineSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside items is not caught either. Probe: titlee on a timeline item. Gate stayed green — TimelineSchema.items is declared any[], deliberately, because the two element shapes are discriminated by variant and read dynamically. The item vocabulary this page documents in full is verified by read-site grep and by nothing else.
3. A misspelled key on a KanbanCard is not caught. Probe: descriptionn on the annotated card literal. Gate stayed green — KanbanCard carries its own [key: string]: any, for the runtime-synthesized card keys.

Two probes went RED — so the annotations are live, not no-ops:

4. variant: 'diagonal' on the annotated TimelineSchema literal produced TS2322: Type '"diagonal"' is not assignable to type '"horizontal" | "vertical" | "gantt" | undefined'.
5. variant: 'critical' on a KanbanCard badge produced TS2322: Type '"critical"' is not assignable to type '"default" | "outline" | "destructive" | "secondary" | undefined' — the badge object is sealed even though its parent card is not.

So the boundary on these pages is exactly this: declared members with closed unions are genuinely checked; anything reaching an index signature, and everything inside items, is not. That is why the read-site grep above is not optional decoration — it is the only thing covering the second half.

6. 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 gap found and filed, not fixed here

packages/* source is out of this PR's surface, so it was filed unassigned after a targeted dedupe search (which returned the same-family cards #7311, #7313, #5903 and #6973, so it was live rather than silently empty; none is this defect):

• finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 — ObjectKanbanSchema requires groupField, a key with zero read sites in packages/plugin-kanban, and declares neither groupBy nor limit, the two keys ObjectKanban.tsx actually reads. Separately, ObjectKanbanComponentProps.schema is typed KanbanSchema, whose type is the literal 'kanban', so no object-kanban node is assignable to it either; ObjectKanbanRenderer types its own prop as any, so nothing connects the registered node to either declaration. The row-cap block therefore ships as a plain const with no annotation — it compiles and is counted, but its keys are unchecked — rather than inventing a groupField the renderer does not read. Same family 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 and 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.

Header prose corrected, and why it is a rewrite rather than a new number

Batch 6 recorded, without filing, that the ledger docblock's sentence "what remains here is 12 .mdx pages and 32 package READMEs" had drifted. Batch 7's dispatch authorised fixing it now that the ledger surface is being edited for its own sake.

It is corrected by removing the count, not by writing a fresh one. Both halves were already wrong (the README count has been 31 since #5259; the .mdx count moves with every batch), and any number written there would have been stale again within the hour — batch 6 landed mid-run and moved it. The sentence now points at the entries below it, which are re-derived every run and shrink-only, so the names in the list are the count. Nothing mechanical fails on a stale number in a comment, which is precisely why it should not carry one.

This edit is header prose, above the fence-scanning banner, so the strictness proof above is unaffected and still holds byte-for-byte.

Gate verdict lines

Everything below at 9d6e6f5a7, 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 for all 25 filters before any gate result was trusted — turbo replayed cached logs naming another worktree's path (objectui-issue-5174-b6) on the first build, so this was checked rather than assumed.

check:doc-snippets exit 0 Semantic phase: 365 of 365 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,
except 80 declared file(s) carrying 90 block(s) of #5867's population
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 6015 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:doc-fences is unmoved by this PR: plugin-timeline.mdx and plugin-kanban.mdx each carry one entry in #5867's shrink-only ledger for their plaintext-fenced "TypeScript Support" blocks, and those blocks are untouched here — that axis belongs to #5867.

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

One process note worth recording: the probe harness's first disk-proof step was itself defective — it used grep -cF on multi-line strings, which counts matching lines rather than occurrences, and reported a false "no-op mutation". It failed closed: the harness aborted and the trap restored before any gate ran, so no reading was taken from it. The proof step was corrected to count the full multi-line strings, and every probe above was then run and recorded once.

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, 3 ignored by config, 1 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 over the C0 range plus DEL) across 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 7 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 25 blocks, 20 compile against the built dist, 5 carry a FRAGMENT_MARKER with a written, measured reason. 26 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 6 (#7314) landed while this was in flight; origin/main was merged (never rebased). The two ledger hunks conflicted textually because they are adjacent lines in one sorted object, and the conflict was resolved as the union of both removal sets — everything either side took out stays out. create-plugin.mdx, the only entry inside the conflict region that neither batch claimed, is the only one that survives it.

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	what was actually wrong
content/docs/plugins/plugin-timeline.mdx	9	9	0	1 (1 syntax, 0 semantic)	No fabricated key — every key the page documents has read sites. The page's real problem was that it verified nothing: eight blocks were unannotated literals, and the two "Date Formatting" / "Time Scales" fences held bare { dateFormat: 'short' } objects that TypeScript parses as block statements containing labelled expressions — { dateFormatt: 'short' } was equally green. Five schema literals now carry the TimelineSchema annotation the page's own prose already claims ("Every key above is declared on the exported TimelineSchema, so … a wrong value is a type error"), and the two value-list fences became indexed-access declarations. items: [...] in "Custom Colors" was the one parse failure.
content/docs/plugins/plugin-kanban.mdx	8	8	0	14 (6 syntax, 8 semantic)	The eight semantic diagnostics were TS7006 on onCardMove's four parameters, twice — the callback was untyped because the literal was unannotated, while KanbanSchema declares it as taking four typed parameters. Five literals now carry KanbanSchema / KanbanCard / KanbanColumn. Three parse failures: a bare object-kanban literal, cards: [...], and an "Event Handling" block with columns: [...], a top-level await in a void-returning callback, and three ambient names — rewritten as a real hook. One type gap found and filed (#7322), not fixed here.
content/docs/utilities/runner.mdx	8	3	5	11 (5 syntax, 6 semantic)	No fabricated API. Five blocks genuinely cannot compile here and are declared with measured reasons: four name @object-ui/plugin-yourplugin / -myplugin / ./components/MyComponent — the package or file the reader is being walked through creating — and one is a single property out of resolve.alias. Two real repairs: the Error Boundaries example imported SchemaErrorBoundary but rendered SchemaRenderer with neither the component nor schema in scope, so a reader copying it got two TS2304s; and defineConfig was called with no import. Two fences holding JSX were labelled typescript and are now tsx — a mislabel, corrected rather than declared. One fence held two files (a TS side-effect import and a JSON page document); the JSON half is a mislabel and now has its own json fence.

Ledger 37 → 34 (3 .mdx + 31 README). Covered documents 187 → 190 — strictly grows. Covered blocks 481 → 506; compiled 345 → 365; declared fragments 136 → 141. The per-page splits (9+8+3 = 20 compile, 0+0+5 = 5 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — 3 entry keys deleted, 0 added.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, merged base ad3d4029a vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batches 5 and 6 recorded.
• Covered count strictly grows — 187 → 190, ungated 37 → 34.
• 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. The two fence-language corrections go the other way: both blocks stay in the collected ts/tsx population, and the JSON document that leaves it was never TypeScript.

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

BEFORE (merged base ad3d4029a 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): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0
AFTER (9d6e6f5a7)
Scanned 224 document(s): 190 covered (89 hold a ts/tsx block), 34 ungated
Covered blocks: 506 — 365 to compile, 141 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 365 of 365 block(s) judged, 0 failed exit 0

The branch point d717e8bc3 was measured the same way before the merge (184 covered / 40 ungated / 440 blocks, exit 0), which is batch 6's own BEFORE — the two agree.

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, each planted and restored from HEAD under a trap:

• plugin-kanban.mdx — POSITIVE, and it is the finding. The row-cap example is an object-kanban node. Annotated with ObjectKanbanSchema: TS2741: Property 'groupField' is missing … but required. Annotated with KanbanSchema, which is what ObjectKanbanComponentProps.schema actually declares: TS2322: Type '"object-kanban"' is not assignable to type '"kanban"'. Neither declared type accepts the shape the renderer reads. Note what the first diagnostic does not say — groupBy and limit raised nothing at all, because BaseSchema's index signature absorbed them. Filed as finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322; the block ships as a plain const with no annotation.
• plugin-timeline.mdx — NEGATIVE. The single parse failure (items: [...]) had kept that block out of the semantic phase entirely. With it resolved and five literals newly annotated, the re-run exposed nothing underneath. Reported as a negative result.
• runner.mdx — NEGATIVE, twice. The declared fragments hide their contents from the gate, so both were probed with the fictional specifier shimmed to a real one: "Plugin Not Loading" with @object-ui/plugin-yourplugin swapped for @object-ui/plugin-markdown, and the ComponentRegistry.register block with ./components/MyComponent replaced by a local declaration. Both came back clean — the declared blocks are correct documentation the gate cannot reach, not defects in hiding.

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

BaseSchema carries [key: string]: any, and KanbanCard carries one of its own, so a wrong key on either is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites:

• Timeline — variant, items, dateFormat, scale, rowLabel, minDate, maxDate, className all read in plugin-timeline/src/renderer.tsx; the item keys time, title, description, variant, icon, content, className, startDate, endDate and the gantt row's label likewise. Nothing fabricated.
• Kanban — card id / title / description / badges, badge label / variant, column id / title / cards / limit / className all read in KanbanImpl.tsx and KanbanEnhanced.tsx. Nothing fabricated.
• object-kanban — this is where it paid. schema.groupBy is read at nine sites in ObjectKanban.tsx and schema.limit at two, while groupField — the key ObjectKanbanSchema marks required — has zero read sites in packages/plugin-kanban. The package's own test suite writes { type: 'object-kanban', objectName, groupBy, limit }, the documented shape. The page is right and the declaration is the stale half.

What the green does not mean

Stated because a green run must not be read as more than it is. Each limit below was measured on these pages by planting a probe, proving it reached the disk by counting the injected and removed text, running the gate, and restoring from HEAD under a trap with the restore proved by an empty git diff HEAD and a blob hash matching the HEAD blob.

Three probes stayed GREEN — these are real blind spots:

1. A misspelled top-level key on an annotated schema literal is not caught. Probe: dateFormatt: 'long' added to the annotated TimelineSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside items is not caught either. Probe: titlee on a timeline item. Gate stayed green — TimelineSchema.items is declared any[], deliberately, because the two element shapes are discriminated by variant and read dynamically. The item vocabulary this page documents in full is verified by read-site grep and by nothing else.
3. A misspelled key on a KanbanCard is not caught. Probe: descriptionn on the annotated card literal. Gate stayed green — KanbanCard carries its own [key: string]: any, for the runtime-synthesized card keys.

Two probes went RED — so the annotations are live, not no-ops:

4. variant: 'diagonal' on the annotated TimelineSchema literal produced TS2322: Type '"diagonal"' is not assignable to type '"horizontal" | "vertical" | "gantt" | undefined'.
5. variant: 'critical' on a KanbanCard badge produced TS2322: Type '"critical"' is not assignable to type '"default" | "outline" | "destructive" | "secondary" | undefined' — the badge object is sealed even though its parent card is not.

So the boundary on these pages is exactly this: declared members with closed unions are genuinely checked; anything reaching an index signature, and everything inside items, is not. That is why the read-site grep above is not optional decoration — it is the only thing covering the second half.

6. 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 gap found and filed, not fixed here

packages/* source is out of this PR's surface, so it was filed unassigned after a targeted dedupe search (which returned the same-family cards #7311, #7313, #5903 and #6973, so it was live rather than silently empty; none is this defect):

• finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 — ObjectKanbanSchema requires groupField, a key with zero read sites in packages/plugin-kanban, and declares neither groupBy nor limit, the two keys ObjectKanban.tsx actually reads. Separately, ObjectKanbanComponentProps.schema is typed KanbanSchema, whose type is the literal 'kanban', so no object-kanban node is assignable to it either; ObjectKanbanRenderer types its own prop as any, so nothing connects the registered node to either declaration. The row-cap block therefore ships as a plain const with no annotation — it compiles and is counted, but its keys are unchecked — rather than inventing a groupField the renderer does not read. Same family 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 and 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.

Header prose corrected, and why it is a rewrite rather than a new number

Batch 6 recorded, without filing, that the ledger docblock's sentence "what remains here is 12 .mdx pages and 32 package READMEs" had drifted. Batch 7's dispatch authorised fixing it now that the ledger surface is being edited for its own sake.

It is corrected by removing the count, not by writing a fresh one. Both halves were already wrong (the README count has been 31 since #5259; the .mdx count moves with every batch), and any number written there would have been stale again within the hour — batch 6 landed mid-run and moved it. The sentence now points at the entries below it, which are re-derived every run and shrink-only, so the names in the list are the count. Nothing mechanical fails on a stale number in a comment, which is precisely why it should not carry one.

This edit is header prose, above the fence-scanning banner, so the strictness proof above is unaffected and still holds byte-for-byte.

Gate verdict lines

Everything below at 9d6e6f5a7, 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 for all 25 filters before any gate result was trusted — turbo replayed cached logs naming another worktree's path (objectui-issue-5174-b6) on the first build, so this was checked rather than assumed.

check:doc-snippets exit 0 Semantic phase: 365 of 365 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,
except 80 declared file(s) carrying 90 block(s) of #5867's population
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 6015 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:doc-fences is unmoved by this PR: plugin-timeline.mdx and plugin-kanban.mdx each carry one entry in #5867's shrink-only ledger for their plaintext-fenced "TypeScript Support" blocks, and those blocks are untouched here — that axis belongs to #5867.

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

One process note worth recording: the probe harness's first disk-proof step was itself defective — it used grep -cF on multi-line strings, which counts matching lines rather than occurrences, and reported a false "no-op mutation". It failed closed: the harness aborted and the trap restored before any gate ran, so no reading was taken from it. The proof step was corrected to count the full multi-line strings, and every probe above was then run and recorded once.

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, 3 ignored by config, 1 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 over the C0 range plus DEL) across 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 7 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 25 blocks, 20 compile against the built dist, 5 carry a FRAGMENT_MARKER with a written, measured reason. 26 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 6 (#7314) landed while this was in flight; origin/main was merged (never rebased). The two ledger hunks conflicted textually because they are adjacent lines in one sorted object, and the conflict was resolved as the union of both removal sets — everything either side took out stays out. create-plugin.mdx, the only entry inside the conflict region that neither batch claimed, is the only one that survives it.

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	what was actually wrong
content/docs/plugins/plugin-timeline.mdx	9	9	0	1 (1 syntax, 0 semantic)	No fabricated key — every key the page documents has read sites. The page's real problem was that it verified nothing: eight blocks were unannotated literals, and the two "Date Formatting" / "Time Scales" fences held bare { dateFormat: 'short' } objects that TypeScript parses as block statements containing labelled expressions — { dateFormatt: 'short' } was equally green. Five schema literals now carry the TimelineSchema annotation the page's own prose already claims ("Every key above is declared on the exported TimelineSchema, so … a wrong value is a type error"), and the two value-list fences became indexed-access declarations. items: [...] in "Custom Colors" was the one parse failure.
content/docs/plugins/plugin-kanban.mdx	8	8	0	14 (6 syntax, 8 semantic)	The eight semantic diagnostics were TS7006 on onCardMove's four parameters, twice — the callback was untyped because the literal was unannotated, while KanbanSchema declares it as taking four typed parameters. Five literals now carry KanbanSchema / KanbanCard / KanbanColumn. Three parse failures: a bare object-kanban literal, cards: [...], and an "Event Handling" block with columns: [...], a top-level await in a void-returning callback, and three ambient names — rewritten as a real hook. One type gap found and filed (#7322), not fixed here.
content/docs/utilities/runner.mdx	8	3	5	11 (5 syntax, 6 semantic)	No fabricated API. Five blocks genuinely cannot compile here and are declared with measured reasons: four name @object-ui/plugin-yourplugin / -myplugin / ./components/MyComponent — the package or file the reader is being walked through creating — and one is a single property out of resolve.alias. Two real repairs: the Error Boundaries example imported SchemaErrorBoundary but rendered SchemaRenderer with neither the component nor schema in scope, so a reader copying it got two TS2304s; and defineConfig was called with no import. Two fences holding JSX were labelled typescript and are now tsx — a mislabel, corrected rather than declared. One fence held two files (a TS side-effect import and a JSON page document); the JSON half is a mislabel and now has its own json fence.

Ledger 37 → 34 (3 .mdx + 31 README). Covered documents 187 → 190 — strictly grows. Covered blocks 481 → 506; compiled 345 → 365; declared fragments 136 → 141. The per-page splits (9+8+3 = 20 compile, 0+0+5 = 5 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — 3 entry keys deleted, 0 added.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, merged base ad3d4029a vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batches 5 and 6 recorded.
• Covered count strictly grows — 187 → 190, ungated 37 → 34.
• 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. The two fence-language corrections go the other way: both blocks stay in the collected ts/tsx population, and the JSON document that leaves it was never TypeScript.

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

BEFORE (merged base ad3d4029a 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): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0
AFTER (9d6e6f5a7)
Scanned 224 document(s): 190 covered (89 hold a ts/tsx block), 34 ungated
Covered blocks: 506 — 365 to compile, 141 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 365 of 365 block(s) judged, 0 failed exit 0

The branch point d717e8bc3 was measured the same way before the merge (184 covered / 40 ungated / 440 blocks, exit 0), which is batch 6's own BEFORE — the two agree.

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, each planted and restored from HEAD under a trap:

• plugin-kanban.mdx — POSITIVE, and it is the finding. The row-cap example is an object-kanban node. Annotated with ObjectKanbanSchema: TS2741: Property 'groupField' is missing … but required. Annotated with KanbanSchema, which is what ObjectKanbanComponentProps.schema actually declares: TS2322: Type '"object-kanban"' is not assignable to type '"kanban"'. Neither declared type accepts the shape the renderer reads. Note what the first diagnostic does not say — groupBy and limit raised nothing at all, because BaseSchema's index signature absorbed them. Filed as finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322; the block ships as a plain const with no annotation.
• plugin-timeline.mdx — NEGATIVE. The single parse failure (items: [...]) had kept that block out of the semantic phase entirely. With it resolved and five literals newly annotated, the re-run exposed nothing underneath. Reported as a negative result.
• runner.mdx — NEGATIVE, twice. The declared fragments hide their contents from the gate, so both were probed with the fictional specifier shimmed to a real one: "Plugin Not Loading" with @object-ui/plugin-yourplugin swapped for @object-ui/plugin-markdown, and the ComponentRegistry.register block with ./components/MyComponent replaced by a local declaration. Both came back clean — the declared blocks are correct documentation the gate cannot reach, not defects in hiding.

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

BaseSchema carries [key: string]: any, and KanbanCard carries one of its own, so a wrong key on either is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites:

• Timeline — variant, items, dateFormat, scale, rowLabel, minDate, maxDate, className all read in plugin-timeline/src/renderer.tsx; the item keys time, title, description, variant, icon, content, className, startDate, endDate and the gantt row's label likewise. Nothing fabricated.
• Kanban — card id / title / description / badges, badge label / variant, column id / title / cards / limit / className all read in KanbanImpl.tsx and KanbanEnhanced.tsx. Nothing fabricated.
• object-kanban — this is where it paid. schema.groupBy is read at nine sites in ObjectKanban.tsx and schema.limit at two, while groupField — the key ObjectKanbanSchema marks required — has zero read sites in packages/plugin-kanban. The package's own test suite writes { type: 'object-kanban', objectName, groupBy, limit }, the documented shape. The page is right and the declaration is the stale half.

What the green does not mean

Stated because a green run must not be read as more than it is. Each limit below was measured on these pages by planting a probe, proving it reached the disk by counting the injected and removed text, running the gate, and restoring from HEAD under a trap with the restore proved by an empty git diff HEAD and a blob hash matching the HEAD blob.

Three probes stayed GREEN — these are real blind spots:

1. A misspelled top-level key on an annotated schema literal is not caught. Probe: dateFormatt: 'long' added to the annotated TimelineSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside items is not caught either. Probe: titlee on a timeline item. Gate stayed green — TimelineSchema.items is declared any[], deliberately, because the two element shapes are discriminated by variant and read dynamically. The item vocabulary this page documents in full is verified by read-site grep and by nothing else.
3. A misspelled key on a KanbanCard is not caught. Probe: descriptionn on the annotated card literal. Gate stayed green — KanbanCard carries its own [key: string]: any, for the runtime-synthesized card keys.

Two probes went RED — so the annotations are live, not no-ops:

4. variant: 'diagonal' on the annotated TimelineSchema literal produced TS2322: Type '"diagonal"' is not assignable to type '"horizontal" | "vertical" | "gantt" | undefined'.
5. variant: 'critical' on a KanbanCard badge produced TS2322: Type '"critical"' is not assignable to type '"default" | "outline" | "destructive" | "secondary" | undefined' — the badge object is sealed even though its parent card is not.

So the boundary on these pages is exactly this: declared members with closed unions are genuinely checked; anything reaching an index signature, and everything inside items, is not. That is why the read-site grep above is not optional decoration — it is the only thing covering the second half.

6. 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 gap found and filed, not fixed here

packages/* source is out of this PR's surface, so it was filed unassigned after a targeted dedupe search (which returned the same-family cards #7311, #7313, #5903 and #6973, so it was live rather than silently empty; none is this defect):

• finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 — ObjectKanbanSchema requires groupField, a key with zero read sites in packages/plugin-kanban, and declares neither groupBy nor limit, the two keys ObjectKanban.tsx actually reads. Separately, ObjectKanbanComponentProps.schema is typed KanbanSchema, whose type is the literal 'kanban', so no object-kanban node is assignable to it either; ObjectKanbanRenderer types its own prop as any, so nothing connects the registered node to either declaration. The row-cap block therefore ships as a plain const with no annotation — it compiles and is counted, but its keys are unchecked — rather than inventing a groupField the renderer does not read. Same family 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 and 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.

Header prose corrected, and why it is a rewrite rather than a new number

Batch 6 recorded, without filing, that the ledger docblock's sentence "what remains here is 12 .mdx pages and 32 package READMEs" had drifted. Batch 7's dispatch authorised fixing it now that the ledger surface is being edited for its own sake.

It is corrected by removing the count, not by writing a fresh one. Both halves were already wrong (the README count has been 31 since #5259; the .mdx count moves with every batch), and any number written there would have been stale again within the hour — batch 6 landed mid-run and moved it. The sentence now points at the entries below it, which are re-derived every run and shrink-only, so the names in the list are the count. Nothing mechanical fails on a stale number in a comment, which is precisely why it should not carry one.

This edit is header prose, above the fence-scanning banner, so the strictness proof above is unaffected and still holds byte-for-byte.

Gate verdict lines

Everything below at 9d6e6f5a7, 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 for all 25 filters before any gate result was trusted — turbo replayed cached logs naming another worktree's path (objectui-issue-5174-b6) on the first build, so this was checked rather than assumed.

check:doc-snippets exit 0 Semantic phase: 365 of 365 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,
except 80 declared file(s) carrying 90 block(s) of #5867's population
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 6015 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:doc-fences is unmoved by this PR: plugin-timeline.mdx and plugin-kanban.mdx each carry one entry in #5867's shrink-only ledger for their plaintext-fenced "TypeScript Support" blocks, and those blocks are untouched here — that axis belongs to #5867.

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

One process note worth recording: the probe harness's first disk-proof step was itself defective — it used grep -cF on multi-line strings, which counts matching lines rather than occurrences, and reported a false "no-op mutation". It failed closed: the harness aborted and the trap restored before any gate ran, so no reading was taken from it. The proof step was corrected to count the full multi-line strings, and every probe above was then run and recorded once.

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, 3 ignored by config, 1 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 over the C0 range plus DEL) across 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 7 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 25 blocks, 20 compile against the built dist, 5 carry a FRAGMENT_MARKER with a written, measured reason. 26 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 6 (#7314) landed while this was in flight; origin/main was merged (never rebased). The two ledger hunks conflicted textually because they are adjacent lines in one sorted object, and the conflict was resolved as the union of both removal sets — everything either side took out stays out. create-plugin.mdx, the only entry inside the conflict region that neither batch claimed, is the only one that survives it.

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	what was actually wrong
content/docs/plugins/plugin-timeline.mdx	9	9	0	1 (1 syntax, 0 semantic)	No fabricated key — every key the page documents has read sites. The page's real problem was that it verified nothing: eight blocks were unannotated literals, and the two "Date Formatting" / "Time Scales" fences held bare { dateFormat: 'short' } objects that TypeScript parses as block statements containing labelled expressions — { dateFormatt: 'short' } was equally green. Five schema literals now carry the TimelineSchema annotation the page's own prose already claims ("Every key above is declared on the exported TimelineSchema, so … a wrong value is a type error"), and the two value-list fences became indexed-access declarations. items: [...] in "Custom Colors" was the one parse failure.
content/docs/plugins/plugin-kanban.mdx	8	8	0	14 (6 syntax, 8 semantic)	The eight semantic diagnostics were TS7006 on onCardMove's four parameters, twice — the callback was untyped because the literal was unannotated, while KanbanSchema declares it as taking four typed parameters. Five literals now carry KanbanSchema / KanbanCard / KanbanColumn. Three parse failures: a bare object-kanban literal, cards: [...], and an "Event Handling" block with columns: [...], a top-level await in a void-returning callback, and three ambient names — rewritten as a real hook. One type gap found and filed (#7322), not fixed here.
content/docs/utilities/runner.mdx	8	3	5	11 (5 syntax, 6 semantic)	No fabricated API. Five blocks genuinely cannot compile here and are declared with measured reasons: four name @object-ui/plugin-yourplugin / -myplugin / ./components/MyComponent — the package or file the reader is being walked through creating — and one is a single property out of resolve.alias. Two real repairs: the Error Boundaries example imported SchemaErrorBoundary but rendered SchemaRenderer with neither the component nor schema in scope, so a reader copying it got two TS2304s; and defineConfig was called with no import. Two fences holding JSX were labelled typescript and are now tsx — a mislabel, corrected rather than declared. One fence held two files (a TS side-effect import and a JSON page document); the JSON half is a mislabel and now has its own json fence.

Ledger 37 → 34 (3 .mdx + 31 README). Covered documents 187 → 190 — strictly grows. Covered blocks 481 → 506; compiled 345 → 365; declared fragments 136 → 141. The per-page splits (9+8+3 = 20 compile, 0+0+5 = 5 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — 3 entry keys deleted, 0 added.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, merged base ad3d4029a vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batches 5 and 6 recorded.
• Covered count strictly grows — 187 → 190, ungated 37 → 34.
• 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. The two fence-language corrections go the other way: both blocks stay in the collected ts/tsx population, and the JSON document that leaves it was never TypeScript.

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

BEFORE (merged base ad3d4029a 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): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0
AFTER (9d6e6f5a7)
Scanned 224 document(s): 190 covered (89 hold a ts/tsx block), 34 ungated
Covered blocks: 506 — 365 to compile, 141 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 365 of 365 block(s) judged, 0 failed exit 0

The branch point d717e8bc3 was measured the same way before the merge (184 covered / 40 ungated / 440 blocks, exit 0), which is batch 6's own BEFORE — the two agree.

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, each planted and restored from HEAD under a trap:

• plugin-kanban.mdx — POSITIVE, and it is the finding. The row-cap example is an object-kanban node. Annotated with ObjectKanbanSchema: TS2741: Property 'groupField' is missing … but required. Annotated with KanbanSchema, which is what ObjectKanbanComponentProps.schema actually declares: TS2322: Type '"object-kanban"' is not assignable to type '"kanban"'. Neither declared type accepts the shape the renderer reads. Note what the first diagnostic does not say — groupBy and limit raised nothing at all, because BaseSchema's index signature absorbed them. Filed as finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322; the block ships as a plain const with no annotation.
• plugin-timeline.mdx — NEGATIVE. The single parse failure (items: [...]) had kept that block out of the semantic phase entirely. With it resolved and five literals newly annotated, the re-run exposed nothing underneath. Reported as a negative result.
• runner.mdx — NEGATIVE, twice. The declared fragments hide their contents from the gate, so both were probed with the fictional specifier shimmed to a real one: "Plugin Not Loading" with @object-ui/plugin-yourplugin swapped for @object-ui/plugin-markdown, and the ComponentRegistry.register block with ./components/MyComponent replaced by a local declaration. Both came back clean — the declared blocks are correct documentation the gate cannot reach, not defects in hiding.

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

BaseSchema carries [key: string]: any, and KanbanCard carries one of its own, so a wrong key on either is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites:

• Timeline — variant, items, dateFormat, scale, rowLabel, minDate, maxDate, className all read in plugin-timeline/src/renderer.tsx; the item keys time, title, description, variant, icon, content, className, startDate, endDate and the gantt row's label likewise. Nothing fabricated.
• Kanban — card id / title / description / badges, badge label / variant, column id / title / cards / limit / className all read in KanbanImpl.tsx and KanbanEnhanced.tsx. Nothing fabricated.
• object-kanban — this is where it paid. schema.groupBy is read at nine sites in ObjectKanban.tsx and schema.limit at two, while groupField — the key ObjectKanbanSchema marks required — has zero read sites in packages/plugin-kanban. The package's own test suite writes { type: 'object-kanban', objectName, groupBy, limit }, the documented shape. The page is right and the declaration is the stale half.

What the green does not mean

Stated because a green run must not be read as more than it is. Each limit below was measured on these pages by planting a probe, proving it reached the disk by counting the injected and removed text, running the gate, and restoring from HEAD under a trap with the restore proved by an empty git diff HEAD and a blob hash matching the HEAD blob.

Three probes stayed GREEN — these are real blind spots:

1. A misspelled top-level key on an annotated schema literal is not caught. Probe: dateFormatt: 'long' added to the annotated TimelineSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside items is not caught either. Probe: titlee on a timeline item. Gate stayed green — TimelineSchema.items is declared any[], deliberately, because the two element shapes are discriminated by variant and read dynamically. The item vocabulary this page documents in full is verified by read-site grep and by nothing else.
3. A misspelled key on a KanbanCard is not caught. Probe: descriptionn on the annotated card literal. Gate stayed green — KanbanCard carries its own [key: string]: any, for the runtime-synthesized card keys.

Two probes went RED — so the annotations are live, not no-ops:

4. variant: 'diagonal' on the annotated TimelineSchema literal produced TS2322: Type '"diagonal"' is not assignable to type '"horizontal" | "vertical" | "gantt" | undefined'.
5. variant: 'critical' on a KanbanCard badge produced TS2322: Type '"critical"' is not assignable to type '"default" | "outline" | "destructive" | "secondary" | undefined' — the badge object is sealed even though its parent card is not.

So the boundary on these pages is exactly this: declared members with closed unions are genuinely checked; anything reaching an index signature, and everything inside items, is not. That is why the read-site grep above is not optional decoration — it is the only thing covering the second half.

6. 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 gap found and filed, not fixed here

packages/* source is out of this PR's surface, so it was filed unassigned after a targeted dedupe search (which returned the same-family cards #7311, #7313, #5903 and #6973, so it was live rather than silently empty; none is this defect):

• finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 — ObjectKanbanSchema requires groupField, a key with zero read sites in packages/plugin-kanban, and declares neither groupBy nor limit, the two keys ObjectKanban.tsx actually reads. Separately, ObjectKanbanComponentProps.schema is typed KanbanSchema, whose type is the literal 'kanban', so no object-kanban node is assignable to it either; ObjectKanbanRenderer types its own prop as any, so nothing connects the registered node to either declaration. The row-cap block therefore ships as a plain const with no annotation — it compiles and is counted, but its keys are unchecked — rather than inventing a groupField the renderer does not read. Same family 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 and 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.

Header prose corrected, and why it is a rewrite rather than a new number

Batch 6 recorded, without filing, that the ledger docblock's sentence "what remains here is 12 .mdx pages and 32 package READMEs" had drifted. Batch 7's dispatch authorised fixing it now that the ledger surface is being edited for its own sake.

It is corrected by removing the count, not by writing a fresh one. Both halves were already wrong (the README count has been 31 since #5259; the .mdx count moves with every batch), and any number written there would have been stale again within the hour — batch 6 landed mid-run and moved it. The sentence now points at the entries below it, which are re-derived every run and shrink-only, so the names in the list are the count. Nothing mechanical fails on a stale number in a comment, which is precisely why it should not carry one.

This edit is header prose, above the fence-scanning banner, so the strictness proof above is unaffected and still holds byte-for-byte.

Gate verdict lines

Everything below at 9d6e6f5a7, 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 for all 25 filters before any gate result was trusted — turbo replayed cached logs naming another worktree's path (objectui-issue-5174-b6) on the first build, so this was checked rather than assumed.

check:doc-snippets exit 0 Semantic phase: 365 of 365 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,
except 80 declared file(s) carrying 90 block(s) of #5867's population
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 6015 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:doc-fences is unmoved by this PR: plugin-timeline.mdx and plugin-kanban.mdx each carry one entry in #5867's shrink-only ledger for their plaintext-fenced "TypeScript Support" blocks, and those blocks are untouched here — that axis belongs to #5867.

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

One process note worth recording: the probe harness's first disk-proof step was itself defective — it used grep -cF on multi-line strings, which counts matching lines rather than occurrences, and reported a false "no-op mutation". It failed closed: the harness aborted and the trap restored before any gate ran, so no reading was taken from it. The proof step was corrected to count the full multi-line strings, and every probe above was then run and recorded once.

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, 3 ignored by config, 1 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 over the C0 range plus DEL) across 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 7 of the UNGATED_DOCS burn-down. Takes the next three .mdx entries by fence density and delivers all three whole: 25 blocks, 20 compile against the built dist, 5 carry a FRAGMENT_MARKER with a written, measured reason. 26 diagnostics cleared. Nothing about the gate's strictness moved.

Batch 6 (#7314) landed while this was in flight; origin/main was merged (never rebased). The two ledger hunks conflicted textually because they are adjacent lines in one sorted object, and the conflict was resolved as the union of both removal sets — everything either side took out stays out. create-plugin.mdx, the only entry inside the conflict region that neither batch claimed, is the only one that survives it.

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	what was actually wrong
content/docs/plugins/plugin-timeline.mdx	9	9	0	1 (1 syntax, 0 semantic)	No fabricated key — every key the page documents has read sites. The page's real problem was that it verified nothing: eight blocks were unannotated literals, and the two "Date Formatting" / "Time Scales" fences held bare { dateFormat: 'short' } objects that TypeScript parses as block statements containing labelled expressions — { dateFormatt: 'short' } was equally green. Five schema literals now carry the TimelineSchema annotation the page's own prose already claims ("Every key above is declared on the exported TimelineSchema, so … a wrong value is a type error"), and the two value-list fences became indexed-access declarations. items: [...] in "Custom Colors" was the one parse failure.
content/docs/plugins/plugin-kanban.mdx	8	8	0	14 (6 syntax, 8 semantic)	The eight semantic diagnostics were TS7006 on onCardMove's four parameters, twice — the callback was untyped because the literal was unannotated, while KanbanSchema declares it as taking four typed parameters. Five literals now carry KanbanSchema / KanbanCard / KanbanColumn. Three parse failures: a bare object-kanban literal, cards: [...], and an "Event Handling" block with columns: [...], a top-level await in a void-returning callback, and three ambient names — rewritten as a real hook. One type gap found and filed (#7322), not fixed here.
content/docs/utilities/runner.mdx	8	3	5	11 (5 syntax, 6 semantic)	No fabricated API. Five blocks genuinely cannot compile here and are declared with measured reasons: four name @object-ui/plugin-yourplugin / -myplugin / ./components/MyComponent — the package or file the reader is being walked through creating — and one is a single property out of resolve.alias. Two real repairs: the Error Boundaries example imported SchemaErrorBoundary but rendered SchemaRenderer with neither the component nor schema in scope, so a reader copying it got two TS2304s; and defineConfig was called with no import. Two fences holding JSX were labelled typescript and are now tsx — a mislabel, corrected rather than declared. One fence held two files (a TS side-effect import and a JSON page document); the JSON half is a mislabel and now has its own json fence.

Ledger 37 → 34 (3 .mdx + 31 README). Covered documents 187 → 190 — strictly grows. Covered blocks 481 → 506; compiled 345 → 365; declared fragments 136 → 141. The per-page splits (9+8+3 = 20 compile, 0+0+5 = 5 declared) reconcile exactly with those deltas.

Invariants, each measured rather than asserted

• The ledger hunk is removals only — 3 entry keys deleted, 0 added.
• Gate strictness byte-identical, from the fence-scanning banner to EOF, merged base ad3d4029a vs this branch:
  sha256 b87e347626a6cbab30b904eaf7d3eb72f6804122505bdf9ec8f2f2c8136e95a3 — the same value on both sides, and the same value batches 5 and 6 recorded.
• Covered count strictly grows — 187 → 190, ungated 37 → 34.
• 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. The two fence-language corrections go the other way: both blocks stay in the collected ts/tsx population, and the JSON document that leaves it was never TypeScript.

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

BEFORE (merged base ad3d4029a 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): 187 covered (86 hold a ts/tsx block), 37 ungated
Covered blocks: 481 — 345 to compile, 136 declared fragment(s)
Semantic phase: 345 of 345 block(s) judged, 0 failed exit 0
AFTER (9d6e6f5a7)
Scanned 224 document(s): 190 covered (89 hold a ts/tsx block), 34 ungated
Covered blocks: 506 — 365 to compile, 141 declared fragment(s)
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 365 of 365 block(s) judged, 0 failed exit 0

The branch point d717e8bc3 was measured the same way before the merge (184 covered / 40 ungated / 440 blocks, exit 0), which is batch 6's own BEFORE — the two agree.

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, each planted and restored from HEAD under a trap:

• plugin-kanban.mdx — POSITIVE, and it is the finding. The row-cap example is an object-kanban node. Annotated with ObjectKanbanSchema: TS2741: Property 'groupField' is missing … but required. Annotated with KanbanSchema, which is what ObjectKanbanComponentProps.schema actually declares: TS2322: Type '"object-kanban"' is not assignable to type '"kanban"'. Neither declared type accepts the shape the renderer reads. Note what the first diagnostic does not say — groupBy and limit raised nothing at all, because BaseSchema's index signature absorbed them. Filed as finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322; the block ships as a plain const with no annotation.
• plugin-timeline.mdx — NEGATIVE. The single parse failure (items: [...]) had kept that block out of the semantic phase entirely. With it resolved and five literals newly annotated, the re-run exposed nothing underneath. Reported as a negative result.
• runner.mdx — NEGATIVE, twice. The declared fragments hide their contents from the gate, so both were probed with the fictional specifier shimmed to a real one: "Plugin Not Loading" with @object-ui/plugin-yourplugin swapped for @object-ui/plugin-markdown, and the ComponentRegistry.register block with ./components/MyComponent replaced by a local declaration. Both came back clean — the declared blocks are correct documentation the gate cannot reach, not defects in hiding.

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

BaseSchema carries [key: string]: any, and KanbanCard carries one of its own, so a wrong key on either is invisible to this gate. Every schema literal touched here was therefore also grepped for read sites:

• Timeline — variant, items, dateFormat, scale, rowLabel, minDate, maxDate, className all read in plugin-timeline/src/renderer.tsx; the item keys time, title, description, variant, icon, content, className, startDate, endDate and the gantt row's label likewise. Nothing fabricated.
• Kanban — card id / title / description / badges, badge label / variant, column id / title / cards / limit / className all read in KanbanImpl.tsx and KanbanEnhanced.tsx. Nothing fabricated.
• object-kanban — this is where it paid. schema.groupBy is read at nine sites in ObjectKanban.tsx and schema.limit at two, while groupField — the key ObjectKanbanSchema marks required — has zero read sites in packages/plugin-kanban. The package's own test suite writes { type: 'object-kanban', objectName, groupBy, limit }, the documented shape. The page is right and the declaration is the stale half.

What the green does not mean

Stated because a green run must not be read as more than it is. Each limit below was measured on these pages by planting a probe, proving it reached the disk by counting the injected and removed text, running the gate, and restoring from HEAD under a trap with the restore proved by an empty git diff HEAD and a blob hash matching the HEAD blob.

Three probes stayed GREEN — these are real blind spots:

1. A misspelled top-level key on an annotated schema literal is not caught. Probe: dateFormatt: 'long' added to the annotated TimelineSchema literal. Gate stayed green — BaseSchema's index signature absorbs it.
2. A misspelled key inside items is not caught either. Probe: titlee on a timeline item. Gate stayed green — TimelineSchema.items is declared any[], deliberately, because the two element shapes are discriminated by variant and read dynamically. The item vocabulary this page documents in full is verified by read-site grep and by nothing else.
3. A misspelled key on a KanbanCard is not caught. Probe: descriptionn on the annotated card literal. Gate stayed green — KanbanCard carries its own [key: string]: any, for the runtime-synthesized card keys.

Two probes went RED — so the annotations are live, not no-ops:

4. variant: 'diagonal' on the annotated TimelineSchema literal produced TS2322: Type '"diagonal"' is not assignable to type '"horizontal" | "vertical" | "gantt" | undefined'.
5. variant: 'critical' on a KanbanCard badge produced TS2322: Type '"critical"' is not assignable to type '"default" | "outline" | "destructive" | "secondary" | undefined' — the badge object is sealed even though its parent card is not.

So the boundary on these pages is exactly this: declared members with closed unions are genuinely checked; anything reaching an index signature, and everything inside items, is not. That is why the read-site grep above is not optional decoration — it is the only thing covering the second half.

6. 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 gap found and filed, not fixed here

packages/* source is out of this PR's surface, so it was filed unassigned after a targeted dedupe search (which returned the same-family cards #7311, #7313, #5903 and #6973, so it was live rather than silently empty; none is this defect):

• finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 — ObjectKanbanSchema requires groupField, a key with zero read sites in packages/plugin-kanban, and declares neither groupBy nor limit, the two keys ObjectKanban.tsx actually reads. Separately, ObjectKanbanComponentProps.schema is typed KanbanSchema, whose type is the literal 'kanban', so no object-kanban node is assignable to it either; ObjectKanbanRenderer types its own prop as any, so nothing connects the registered node to either declaration. The row-cap block therefore ships as a plain const with no annotation — it compiles and is counted, but its keys are unchecked — rather than inventing a groupField the renderer does not read. Same family 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 and 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.

Header prose corrected, and why it is a rewrite rather than a new number

Batch 6 recorded, without filing, that the ledger docblock's sentence "what remains here is 12 .mdx pages and 32 package READMEs" had drifted. Batch 7's dispatch authorised fixing it now that the ledger surface is being edited for its own sake.

It is corrected by removing the count, not by writing a fresh one. Both halves were already wrong (the README count has been 31 since #5259; the .mdx count moves with every batch), and any number written there would have been stale again within the hour — batch 6 landed mid-run and moved it. The sentence now points at the entries below it, which are re-derived every run and shrink-only, so the names in the list are the count. Nothing mechanical fails on a stale number in a comment, which is precisely why it should not carry one.

This edit is header prose, above the fence-scanning banner, so the strictness proof above is unaffected and still holds byte-for-byte.

Gate verdict lines

Everything below at 9d6e6f5a7, 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 for all 25 filters before any gate result was trusted — turbo replayed cached logs naming another worktree's path (objectui-issue-5174-b6) on the first build, so this was checked rather than assumed.

check:doc-snippets exit 0 Semantic phase: 365 of 365 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,
except 80 declared file(s) carrying 90 block(s) of #5867's population
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 6015 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:doc-fences is unmoved by this PR: plugin-timeline.mdx and plugin-kanban.mdx each carry one entry in #5867's shrink-only ledger for their plaintext-fenced "TypeScript Support" blocks, and those blocks are untouched here — that axis belongs to #5867.

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

One process note worth recording: the probe harness's first disk-proof step was itself defective — it used grep -cF on multi-line strings, which counts matching lines rather than occurrences, and reported a false "no-op mutation". It failed closed: the harness aborted and the trap restored before any gate ran, so no reading was taken from it. The proof step was corrected to count the full multi-line strings, and every probe above was then run and recorded once.

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, 3 ignored by config, 1 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 over the C0 range plus DEL) across 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