Troubleshooting section exists
Why it matters
When the same question surfaces repeatedly in GitHub issues, Discord, or Stack Overflow and never lands in your docs, every maintainer hour spent re-answering it is a recurring tax. Users who hit a setup error without a troubleshooting entry either open a duplicate issue (inflating support load) or abandon the project silently. Documented troubleshooting converts recurring pain points into self-service, reducing issue volume and improving time-to-first-success for new users.
Severity rationale
Low because absent troubleshooting scales support cost but does not block a careful user.
Remediation
Add a ## Troubleshooting section to README.md or create docs/troubleshooting.md covering the top 3 to 5 recurring issues from your issue tracker. Each entry should name the symptom, cause, and fix. Example:
### "Module not found" after installation
**Symptom:** `Cannot find module 'your-package'` on import.
**Cause:** Stale `node_modules` or wrong install directory.
**Fix:**
\`\`\`bash
rm -rf node_modules package-lock.json && npm install
\`\`\`
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