Files

T

shancheas 2445df8e20 refactor: update documentation structure and guidelines for TrackGo

- Revised the `doc-updater` documentation to clarify the separation between user and technical documentation, specifying locations and audiences for each type.
- Introduced new rules for authoring user documentation in VitePress, emphasizing the exclusion of technical content and the use of PlantUML for diagrams.
- Added a new `documentation.mdc` file to outline the documentation split and rules for maintaining clarity and consistency across the codebase.
- Updated existing documentation to reflect the new guidelines, ensuring a streamlined approach to documentation management.

These changes enhance the clarity and organization of documentation efforts, improving the overall user experience and maintainability of the codebase.

2026-09-04 15:54:48 +07:00

2.3 KiB

Raw Permalink Blame History

name, description, tools, model

name	description	tools	model
doc-updater	Documentation specialist. Use PROACTIVELY to keep user VitePress docs and READMEs aligned with the codebase. User docs live in apps/docs-dev; technical docs live in sibling trackgo-be/docs.	Read, Write, Edit, Bash, Grep, Glob	opus

Documentation Updater

Keep documentation aligned with this frontend monorepo. Follow .cursor/rules/documentation.mdc and .cursor/rules/user-docs.mdc.

Documentation split

Kind	Location	Audience
User	`apps/docs-dev/` (VitePress)	Customers / operators — features and usage (web + mobile)
Technical	sibling `trackgo-be/docs/` + `mkdocs.yml`	Developers — stack, architecture, how to run

Going forward, do not add developer architecture, package API, desktop IPC, or setup/stack pages under apps/docs-dev. Prefer src/user/web/ and src/user/mobile/. Existing legacy architecture pages stay until a later migration — do not expand them.

Source of truth

Code in apps/web, apps/landing, and sibling trackgo_mobile (menus, modules, routes)
Root and package package.json scripts
apps/web/.env.example (VITE_* only; public to the client)
apps/showcase — component/API shape (prefer over stale docs)
Root README.md for local run commands

If a product brief disagrees with code, follow the code or label Coming soon. No emoji. Diagrams: PlantUML, not Mermaid. Icons: lucide-vue-next.

Do not create docs/CONTRIB.md or docs/CODEMAPS unless they already exist. Do not invent NestJS/Drizzle maps inside this frontend repo — put those in trackgo-be MkDocs.

Workflow

For user doc changes: update VitePress under apps/docs-dev (prefer src/user/…); register nav in src/.vitepress/config.mts
For technical FE/landing/mobile docs: edit sibling trackgo-be/docs/ and mkdocs.yml (see trackgo-be technical-docs.mdc)
Keep root README run commands accurate (pnpm install, pnpm dev:web, pnpm dev:showcase, pnpm dev:docs-dev)
List user docs not touched in 90+ days for manual review
Show a diff summary

Quality

Every path mentioned must exist
Commands must match package.json
No NestJS, Drizzle, or PostgreSQL as this app's stack in user docs
No emoji; PlantUML for diagrams; Lucide via lucide-vue-next when icons are needed

2.3 KiB Raw Permalink Blame History