Docs vs Design Relationship
Docs vs Design Relationship
Section titled “Docs vs Design Relationship”This page defines the content ownership boundary and collaboration flow between:
docs.trystpilot.xyz(source:docs/)design.trystpilot.xyz(source:design/)
Ownership Matrix
Section titled “Ownership Matrix”| Content Type | Canonical Location | Why |
|---|---|---|
| Runbooks, setup, CI/CD ops, incident response | docs/ | Operational reliability and execution guidance |
| Changelog, release/version reconciliation | docs/ | Product and deployment source-of-truth for releases |
| Architecture diagrams and visual maps | design/ | Diagram-first, design-native artifacts |
| UI/UX flows and wireframe narratives | design/ | Design intent and interaction documentation |
| Governance visual models | design/ | Access and moderation flows are maintained as diagrams |
Linking Rules
Section titled “Linking Rules”- Docs pages should link to design pages when visuals are needed.
- Design pages should link to docs pages for implementation and operational constraints.
- Duplicate long-form copies of the same content across both sites should be avoided.
- If overlap is required, designate one canonical page and mark the other as a short pointer.
Editorial Workflow
Section titled “Editorial Workflow”- Author/update content in the canonical directory (
docs/ordesign/). - Add cross-links in the counterpart site only as pointers.
- Keep roadmap/versioning/date-sensitive operational truth in docs site artifacts.
- Validate navigation consistency during PR review.