| 1 | # Documentation DOX |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | - Own human-facing documentation, screenshots, setup guides, developer guides, and documentation assets. |
| 6 | - Keep docs accurate to current source behavior and practical user workflows. |
| 7 | |
| 8 | ## Ownership |
| 9 | |
| 10 | - `README.md`, `quickstart.md`, `guides/`, and `setup/` cover user-facing setup and workflows. |
| 11 | - `developer/` covers compact developer references and source handoffs. |
| 12 | - `plans/` covers implementation plans, migration notes, and staged technical roadmaps. |
| 13 | - `res/` contains documentation images and other documentation assets. |
| 14 | |
| 15 | ## Local Contracts |
| 16 | |
| 17 | - Prefer local docs for practical workflows and direct users to DeepWiki for source-linked internals when appropriate. |
| 18 | - Do not document secrets, private deployment details, unreleased credentials, or user-specific runtime state. |
| 19 | - Screenshots and assets must be relevant to the documented UI state and should be updated when UI changes make them misleading. |
| 20 | - Keep links relative inside the docs tree unless they intentionally point to external community or reference resources. |
| 21 | |
| 22 | ## Work Guidance |
| 23 | |
| 24 | - Update docs in the same change when user-visible behavior, setup steps, settings names, plugin workflows, or UI labels change. |
| 25 | - Keep user guides task-oriented and avoid duplicating architecture contracts already owned by source-adjacent DOX files. |
| 26 | - When editing screenshots or binary assets, avoid unrelated metadata churn. |
| 27 | |
| 28 | ## Verification |
| 29 | |
| 30 | - Check changed internal links manually or with an available link checker. |
| 31 | - For setup or Docker docs, verify commands against current scripts and Docker files. |
| 32 | |
| 33 | ## Child DOX Index |
| 34 | |
| 35 | No child DOX files. |