Code examples use real imports and are runnable
Why it matters
Non-runnable code examples are an AI-slop hallmark: imports that point at fictitious packages, function names that never existed, parameter signatures that drifted two versions ago. When a developer pastes your example and it throws Module not found or TypeError: x is not a function, they lose trust in every other claim in your docs. This is a reference-integrity defect that wastes evaluator time and signals an unmaintained project, tanking adoption and inviting support tickets for problems your docs created.
Severity rationale
High because broken examples destroy trust on first paste and block integration outright.
Remediation
Replace placeholder imports like from 'your-package' with the actual published package name, verify every function and parameter name against the current source, and run each example in a scratch file before committing. A simple validator:
node -e "const { createClient } = require('your-actual-package'); console.log(typeof createClient)"
If the import throws, the example is wrong. Wire a docs-test CI job against docs/**/*.md to catch drift before it ships.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Developer Documentation Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
Taxons
History
- 2026-04-18·v1.0.0·Initial import from developer-documentation·automated