Docs samples dereference access-controlled reads without a null check, so they break for exactly the denied user

[borisno2]

The problem

Documentation samples dereference the result of an access-controlled read without checking it for null.

This breaks the stack's most basic documented rule. An access-controlled operation returns null for a single record, or [] for many, when access is denied — deliberately, so that a denial is indistinguishable from a missing row and leaks nothing. The project's own guidance says to always check for null afterwards, precisely because the denial and the absence look the same.

A sample that ignores it does not merely fail to compile under strict — at runtime it raises a TypeError for exactly the user whose access was denied. So it works in development, where the author is usually privileged, and breaks for the restricted user it was supposed to protect.

Known instances, found while fixing the same defect in the RAG documentation:

• docs/content/concepts/field-types.md:632
• docs/content/reference/fields-api.md:1663 and :1718
• and others across the documentation site

Two were already fixed and are not part of this issue: packages/rag/CLAUDE.md:540, and one in a pending changeset which was corrected because it publishes as a release note.

What to do

Sweep the documentation for reads through context.db whose result is dereferenced without a null check, and fix each. Both spellings matter: a single-record read returning null, and a first-or-null read.

Where a sample is deliberately showing the unchecked form to make a point, say so in its prose.

The check that would prevent recurrence

Nothing catches this: Markdown is not typechecked, and the docs link-check validates only internal links. Under strict these are TS18047 and TS18049 — a compiler catches them for free.

PR #1324 adds a checker that extracts every fenced TypeScript block and compiles it. It currently runs over a listed set of files. Extending that list to the whole documentation tree would catch this class permanently, and #1301 and #1317 along with it.

Context

• fix(rag): say that embedding generation runs, and test it through context.db (#1128, #1272) #1332 — where the class was found and the RAG instances fixed.
• ci: typecheck the documented TypeScript blocks, with the shadowing check repaired #1324 — the checker. Docs samples import from subpaths the packages do not export, and nothing checks them #1301, Documentation config samples do not compile: db.url, prismaClientConstructor, timestamp db options and access.filter #1317 — the same category of missing check.
• Spec: Examples, scaffolder, docs and agent guidance on Prisma 8 #1129 — build spec 9, which owns the documentation on Prisma 8.

---

_Generated by Claude Code

[borisno2]

Delivered by PR #1379, merged to prisma-8. (Merges into a non-default branch do not close linked issues, so closing by hand.)

🤖 Generated with Claude Code