doc-standardslisted

# Documentation Standards (portable) Reusable document shapes and writing rules. **No project branding** — adapt to whatever repo you're in. (If a project ships its own doc conventions — a house section template, Confluence space, brand kit — that project's rules win; read its `AGENTS.md`/`CLAUDE.md` and neighbouring docs first and match them.) ## Grounding rules (non-negotiable) - **Source every claim from the code.** Endpoints, flags, env vars, status codes, behaviours — each traced to a specific file/line you read. Never invent behaviour the code doesn't have. - **No drift.** When reviewing, mark each statement Verified / Stale / Missing / Wrong with the proving reference. - **Match the project.** Mirror existing headings, tone, examples, and output format (Markdown vs Confluence storage format). Prefer editing an existing doc over creating a new one. - **Diagrams in the project's format.** Default to Mermaid for portable Markdown repos; use the project's format (draw.io, PlantUML, C4) if it already uses one. Keep diagrams source-controlled. - Active voice; second person for user guides; define acronyms on first use; concrete examples; a version/change-history where the project tracks it. ## Templates (adapt headings to the project) **Design document (HLD/LLD)** — Overview · Background/problem · Requirements (functional + non-functional) · Architecture (context, components, data model) · API/interface · Security & data handling · Testing strategy · Deployment/rollout ·