Truthful, Platform Docs

Keep technical documentation strictly aligned with what the product/CLI actually does, and ensure examples work for the reader’s platform.

Apply:

• If a documented option/flag “has no effect,” do not keep it as “accepted but ignored.” Either (a) fix the product so it works, or (b) delete the documentation line/row until it works.
• Treat authoritative sources (e.g., --help, actual command behavior, runtime output) as the ground truth. Update docs (tables, ordering, return semantics) when behavior changes.
• Document what readers/scripts must act on. Omit status/noise fields or event types that no consumer should parse.
• For path/location examples: don’t assume Unix semantics. Either provide Windows equivalents (e.g., %USERPROFILE%/...) or explicitly explain how ~ is resolved on Windows.

Example (doc accuracy pattern):

• Prefer removing a row for an ignored option rather than writing it as “ignored,” and ensure option descriptions match what users see:
  • ✅ Keep only options that work; verify against cline --help and real outputs.
  • ❌ Don’t document CLINE_HOOKS_DIR as functional when it “has no effect” in the release.