Observation, filed unassigned while correcting the BaseSchema common-props table for #7079. Not a live defect today — the single affected block is currently correct. Filed because the failure is silent and the mechanism is general.
What was measured
scripts/check-doc-snippet-types.mjs collects blocks with scanFences, whose fence-opening anchor is
const open = /^([ \t]*)(`{3,})(.*)$/.exec(lines[i]);
(scanFences, around line 590.) The pattern allows leading spaces and tabs only. A fence opened inside a blockquote is prefixed > , so the regex does not match, the block is never collected, and the gate compiles nothing for it. There is no diagnostic: the page is reported as covered, and its uncollected block simply does not appear in any count.
Census over the gate's own document population — every .mdx and .md under content/docs plus every packages/*/README.md, 224 documents:
|
count |
blockquoted ts / tsx / typescript fences (invisible to the collector) |
1 |
| documents affected |
1 |
The one block is in content/docs/api/schema-reference.md, lines 12-14, in the page's import callout:
> **Import:** All types are available from `@object-ui/types`.
>
> (typescript fence)
> import type { PageNodeSchema, FormSchema, TableSchema, /* ... */ } from '@object-ui/types';
Three controls, all passing: the census hits the known blockquoted fence on that page; the gate regex does not match a > opener; the gate regex does match a plain opener. Independently confirmed end-to-end by importing the gate's exported scanFences and running it over that page — it returns 2 collected blocks while the page carries 3 typescript fences.
Why it is worth a card at population 1
The affected snippet is correct right now: PageNodeSchema, FormSchema and TableSchema are all exported from packages/types/src/index.ts (a bogus control symbol returns 0). So nothing is broken today.
What is broken is the signal. A callout is a natural place to put an import example, which is exactly the kind of snippet that rots when an export is renamed — and that is the single class this gate exists to catch. The next blockquoted snippet, or a rename touching this one, fails silently and looks covered.
Relationship to the existing fence family
Sibling of #5867, not a duplicate. #5867 tracks TypeScript examples fenced with the wrong language (plaintext), which check:doc-fences sees and holds shrink-only. This one is a correctly-fenced typescript block whose opener position puts it out of the collector's reach — a different mechanism, and one no current gate reports.
Not decided here
Whether the fix is to widen the collector's anchor to tolerate a blockquote prefix (and strip it before compiling), or to unindent this page's callout, or to declare blockquoted fences out of scope explicitly so the blind spot is at least written down. Widening the anchor is the only one that also covers the next occurrence, but it changes a gate's collection surface and may pull previously-invisible blocks into the compiled population, which is a ledger movement rather than a one-line edit.
Refs #7079 · #5867 · #5174.
Generated by Claude Code
Observation, filed unassigned while correcting the
BaseSchemacommon-props table for #7079. Not a live defect today — the single affected block is currently correct. Filed because the failure is silent and the mechanism is general.What was measured
scripts/check-doc-snippet-types.mjscollects blocks withscanFences, whose fence-opening anchor is(
scanFences, around line 590.) The pattern allows leading spaces and tabs only. A fence opened inside a blockquote is prefixed>, so the regex does not match, the block is never collected, and the gate compiles nothing for it. There is no diagnostic: the page is reported as covered, and its uncollected block simply does not appear in any count.Census over the gate's own document population — every
.mdxand.mdundercontent/docsplus everypackages/*/README.md, 224 documents:ts/tsx/typescriptfences (invisible to the collector)The one block is in
content/docs/api/schema-reference.md, lines 12-14, in the page's import callout:Three controls, all passing: the census hits the known blockquoted fence on that page; the gate regex does not match a
>opener; the gate regex does match a plain opener. Independently confirmed end-to-end by importing the gate's exportedscanFencesand running it over that page — it returns 2 collected blocks while the page carries 3typescriptfences.Why it is worth a card at population 1
The affected snippet is correct right now:
PageNodeSchema,FormSchemaandTableSchemaare all exported frompackages/types/src/index.ts(a bogus control symbol returns 0). So nothing is broken today.What is broken is the signal. A callout is a natural place to put an import example, which is exactly the kind of snippet that rots when an export is renamed — and that is the single class this gate exists to catch. The next blockquoted snippet, or a rename touching this one, fails silently and looks covered.
Relationship to the existing fence family
Sibling of #5867, not a duplicate. #5867 tracks TypeScript examples fenced with the wrong language (
plaintext), whichcheck:doc-fencessees and holds shrink-only. This one is a correctly-fencedtypescriptblock whose opener position puts it out of the collector's reach — a different mechanism, and one no current gate reports.Not decided here
Whether the fix is to widen the collector's anchor to tolerate a blockquote prefix (and strip it before compiling), or to unindent this page's callout, or to declare blockquoted fences out of scope explicitly so the blind spot is at least written down. Widening the anchor is the only one that also covers the next occurrence, but it changes a gate's collection surface and may pull previously-invisible blocks into the compiled population, which is a ledger movement rather than a one-line edit.
Refs #7079 · #5867 · #5174.
Generated by Claude Code