Every factual claim in documentation—links, API endpoints, default behaviors, required vs. optional settings, supported capabilities, and setup commands—must be verified against the actual running system (built site, source code, or live execution) before publishing, not assumed. Precisely scope statements to the environment or configuration they apply to, since behavior often differs (e.g., on-prem vs. cloud deployments, local files vs. remote URLs, rootless vs. standard Docker). Concretely:
/img/... and not a literal pathname://... string; confirm TypeDoc-generated pages resolve to /reference/ and not /reference/README)./api/version with a currentVersion field over /version, which can fall through to a SPA catch-all and return HTTP 200 without confirming anything.service_tier as mandatory).FilesystemBlobStorageProvider), it does not keep everything “in the database,” so persistence/backup guidance must reflect that.mkdir -p before chown), and call out edge cases such as rootless Docker or user-namespace remapping that change expected values.outputPath format-detection rules apply to local files; remote destinations like Google Sheets URLs behave differently and should be documented separately).Treat documentation inaccuracies as bugs: reproduce the documented command/link/config against the real system and correct the text to match observed behavior, not the other way around.