documentation-integritylisted

# Documentation Integrity Document implemented and verified reality, not intent. A document that promises unverified behavior is a defect. ## Rules - Update the repository's existing source of truth instead of creating a competing document. If there is no obvious location, ask before adding a top-level file. - Record material architecture changes in the established ADR or design mechanism (`architecture-integrity`). - Update API contracts, examples, migration notes, operational runbooks, and configuration guidance when those surfaces change, in the same change. - Keep documentation concise, searchable, version-consistent, and explicit about invariants, ownership, failure behavior, and recovery where relevant. - Repair stale documentation encountered in the changed scope when it would mislead future maintainers; mention, do not silently rewrite, stale docs outside the scope. - Never claim capabilities, guarantees, compatibility, or performance that were not verified. Mark illustrative examples as illustrative. - Comments explain why, not what; remove comments that restate the code or that are no longer true. ## Verification Cross-check documented commands, paths, and behavior against the code or an actual run. Verify links and examples. State what was verified and what is documented from design only.