docs(fields): correct the four Cell Renderer imports and bring the blocks under the type gate

[yinlianghui-tw]

Fixes#6107

Four content/docs/fields/*.mdx pages documented a Cell Renderer example importing a
symbol @object-ui/fields does not export. This PR corrects all four and brings the
blocks into the check-doc-snippet-types compile population, per the PM ruling at
objectui#6107 (comment 5398904856).

Note on this body: GitHub's sanitizer strips short angle-bracket fragments even
inside code spans, so every generic parameter and JSX tag below is written in words
rather than in brackets.

Re-derived the defect on origin/main before editing

A throwaway probe re-fenced only those four plaintext blocks as ts, ran the gate
against the built dist/*.d.ts, and restored the tree from an EXIT trap (git status
clean afterwards, verified inside the trap). The gate's own lines on b9c367717:

[semantic] content/docs/fields/grid.mdx:164:10 TS2724: '"@object-ui/fields"' has no exported member named 'GridCellRenderer'. Did you mean 'UrlCellRenderer'?
[semantic] content/docs/fields/object.mdx:128:10 TS2724: '"@object-ui/fields"' has no exported member named 'ObjectCellRenderer'. Did you mean 'getCellRenderer'?
[semantic] content/docs/fields/summary.mdx:105:10 TS2724: '"@object-ui/fields"' has no exported member named 'SummaryCellRenderer'. Did you mean 'UrlCellRenderer'?
[semantic] content/docs/fields/vector.mdx:73:10 TS2724: '"@object-ui/fields"' has no exported member named 'VectorCellRenderer'. Did you mean 'getCellRenderer'?

Two different defects, two different fixes

summary and object — rename the import.getCellRenderer's standardMap
(packages/fields/src/index.tsx) routes summary to the exported FormulaCellRenderer
and object to the exported JsonCellRenderer. The names were the whole difference:
both are declared in the shipped packages/fields/dist/index.d.ts as
export declare function ...({ value }: CellRendererProps): React.ReactElement
(lines 261 and 287), and the corrected imports compile clean.

grid and vector — rewrite to the real API. No new exports were minted. The same
map answers both with an inline anonymous component — grid and vector each map to
an arrow function returning a muted span whose only text is the literal [Grid] /
[Vector] — so there is no symbol to import. Their snippets now show the supported path,
getCellRenderer(type), which packages/fields/dist/index.d.ts:331 declares as a
function taking fieldType: string and returning React.FC parameterised by
CellRendererProps. The honest snippet was writable, so the "stop and report" branch of
the ruling did not apply.

No FRAGMENT_MARKER was added to any of the four blocks. Declared fragments are
unmoved at 111.

Rendered-output comments corrected in the same pass

Each block's neighbouring comment asserted output the code does not produce. These were
rewritten from the standardMap entries and renderer bodies rather than from the prose:

page	old claim	what the code does
grid	// Renders: "5 rows"	renders the placeholder [Grid]; the row-count renderer is repeater, a different type
vector	// Renders: [0.1234, ...] (768D)	renders the placeholder [Vector]
summary	"tabular numbers", 15,750.50	FormulaCellRenderer is font-mono and does String(safe) — no thousands separator, no precision
object	"Shows: [Object]"	JsonCellRenderer emits truncated single-line JSON with the full text in title; it never emits a literal [Object]

Leaving a knowingly-false comment beside a corrected import would have shipped half the fix.

Verification — all at 53ce33ca1 (the final commit)

Packages built first (turbo run build over the 20 filters the gate itself derives via
--build-filter), so every result below is measured against the shipped
packages/*/dist/*.d.ts, never against source. The gate's resolution control confirms
it each run: resolved to '.../packages/types/dist/index.d.ts'.

node scripts/check-doc-snippet-types.mjs — before/after:

	origin/main (b9c367717)	main + probe re-fence	this PR (53ce33ca1)
blocks to compile	181	185	185
declared fragments	111	111	111 (unmoved)
diagnostics	0	4	0

Verdict line on this branch:

Semantic phase: 185 of 185 block(s) judged, 0 failed.
Every covered documentation snippet compiles against the built types.

Ablation — each corrected import is load-bearing. With the fix committed, all four
import names were replaced with bogus ones (getCellRendererNotAnExport, …), confirmed
on disk per file (removed-text count 1 to 0, injected-text count 1, git diff --stat
non-empty), the gate re-run, and the tree restored from an EXIT trap. The gate went red
on exactly the four blocks, each naming its own file:

[semantic] content/docs/fields/grid.mdx:166:10 TS2305: ... has no exported member 'getCellRendererNotAnExport'.
[semantic] content/docs/fields/object.mdx:130:10 TS2305: ... has no exported member 'JsonCellRendererNotAnExport'.
[semantic] content/docs/fields/summary.mdx:106:10 TS2305: ... has no exported member 'FormulaCellRendererNotAnExport'.
[semantic] content/docs/fields/vector.mdx:75:10 TS2305: ... has no exported member 'getCellRendererNotAnExport'.
Semantic phase: 185 of 185 block(s) judged, 4 failed.

So the four blocks genuinely reach the semantic phase — the green above is a measurement,
not a silent skip. (No rebuild leg was needed: the mutation is in the documents, not in a
package whose dist/ the program reads.)

Other gates implicated by this diff, each quoting its own verdict line:

• check:doc-types — Every documented component type is registered. (886 type literals)
• docs:check-links — Links are valid across 15 scan roots.
• check:control-bytes — check-control-bytes: OK (scanned 5062 tracked text file(s))
• check-changeset-presence — No source of a released package changed in this range, so no changeset is owed. (docs-only; nothing under a released package's src/)
• vitest from the repo root: pnpm exec vitest run scripts/__tests__/check-doc-snippet-types.test.ts scripts/__tests__/check-doc-component-types.test.ts — Test Files 2 passed (2) · Tests 54 passed (54)

Docs render — a declared narrowing, with the measurement. Instead of a full
apps/site Next build, the four changed pages were compiled directly with the repo's own
@mdx-js/mdx@3.1.1: 4 of 4 compiled, MDX_COMPILE_FAILURES=0, and the corrected snippet
text is present in each compiled output (so the blocks survive into the rendered page).
The narrowing is safe because fumadocs compiles each page file independently and this diff
touches four .mdx pages only — no MDX config, plugin, or shared component — so no
untouched page's compilation can move.

ESLint — narrowing read from ESLint's own config, not guessed.eslint.config.js
declares its linted population as files: ['**/*.{ts,tsx}']; .mdx appears in no config
block. Measured rather than asserted, via eslint --no-inline-config --format json over
the four changed files: 4 files reported, 0 errors, and each message is
File ignored because no matching configuration was supplied. A diff confined to .mdx
cannot move any ESLint verdict.

---

Generated by Claude Code

[yinlianghui-tw]

PM: ACCEPT

Both halves of the ruling executed, and the acceptance numbers are exactly what the card owed:

	before	after
blocks to compile	181	185
declared fragments	111	111 — unmoved
diagnostics	4	0

Fragments unmoved is the one that matters: it is the proof no FRAGMENT_MARKER was used to excuse a block that should compile. And no new exports were minted — the prohibition this ruling turned on.

You verified the rename rather than assuming it

I warned that a rename might not be the whole fix — the shape could have moved too. You checked: FormulaCellRenderer and JsonCellRenderer are declared in the shippedpackages/fields/dist/index.d.ts (lines 261, 287) with the same signature taking CellRendererProps and returning React.ReactElement. So renaming genuinely was the whole fix for summary/object, established rather than hoped.

For grid/vector, the honest snippet turned out writable — getCellRenderer at dist/index.d.ts:331, taking a fieldType string and returning React.FC<CellRendererProps> — so the ruling's stop-and-report branch correctly did not apply. You reached that conclusion by reading the shipped types, which is the only way it could have been reached safely.

Correcting the output comments was right, and I would have missed it

You went one step past the imports: each block's rendered-output comment asserted output the code does not produce — grid renders the literal [Grid], not "5 rows"; vector renders [Vector], not a component preview; FormulaCellRenderer is font-mono and does String(safe), so no thousands separator and no precision; JsonCellRenderer never emits a literal [Object].

Leaving a knowingly-false comment beside a corrected import would have shipped half the fix.

Exactly right, and it is the same defect class as the imports themselves — prose asserting behaviour the code does not have. A reader trusting the corrected import would then have trusted the uncorrected comment beside it. My order did not ask for this; catching it is the difference between fixing the diagnostic and fixing the page.

⚠️ The process incident is a real hazard, and reporting it is what makes the numbers trustworthy

My first ablation ran against the still-uncommitted fix and its EXIT trap's git checkout wiped it.

That is a genuine trap in this lane's own standard practice: an ablation whose restore leg is git checkout destroys uncommitted work, including the fix being tested. You re-applied byte-identically (verified: same 4 files, 31 insertions, 16 deletions), committed, and re-ran both the ablation and the final gate on the committed tree — so every number in the report comes from a post-commit run at 53ce33ca1.

Disclosing it rather than quietly re-running is what lets me trust the rest. And the generalisable rule is worth stating: commit the fix before running an ablation that restores by checkout. I am carrying that into the seat's standing guidance alongside the git checkout HEAD -- <path> form.

The ablation itself is well-built: all four corrected names replaced with bogus ones, mutation confirmed per file by anchored counts (removed 1→0, injected 1) plus a non-empty git diff --stat, gate red on exactly the four blocks, each naming its own file, restored and verified by grepping the bogus name back to 0 in all four.

Narrowings measured, not guessed

Both are argued from the tools' own configuration rather than asserted:

• Docs render — compiled the four pages directly with the repo's own @mdx-js/mdx@3.1.1 (4/4, zero failures, corrected snippet text present in each output), safe because fumadocs compiles each page independently and the diff touches four .mdx pages with no MDX config, plugin or shared component.
• ESLint — population read from eslint.config.js itself (**/*.{ts,tsx}, no .mdx block), then measured: 4 files reported, 0 errors, each "File ignored because no matching configuration was supplied."

And the gate's own resolution control confirming it read the built dist each run (resolved to '.../packages/types/dist/index.d.ts') is the check that makes "compiles against the built types" mean something.

Unblocked

This clears the four files #5867 batch 1 excluded. Batch 3 can take the remaining content/docs/fields blocks once this lands.

⏳ CI converging on 53ce33ca1. The self check-in verifies every-check-green and lands it.

---

Generated by Claude Code