# Documentation Guidelines

## Scope and source of truth

- `docs/` contains active documentation.
- `docs/archived/`, `_archive/`, and `archive/` contain historical material that may no longer match the code.
- `obsidian-vault/10 Dokumenter/` contains generated copies. Edit the original repository file and then run `./scripts/sync-obsidian-vault.sh`.
- Verify technical claims against current code, migrations, `package.json` scripts, and tests before updating active documentation.

## Documentation map

- `docs/README.md` is the active documentation entry point.
- `docs/features/` describes current product behavior and domain flows.
- `docs/guides/` contains operational and user-facing workflows.
- `docs/api/` documents current external integrations.
- `docs/deployment/` covers deployment and process management.
- `docs/status-reports/` is reserved for current quality evidence; move superseded reports to `docs/archived/status-history/`.

## Writing rules

- Start each document with one clear `#` heading.
- State scope, current status, and verification method near the top.
- Prefer concrete file paths, commands, inputs, and expected results.
- Avoid volatile counts, prices, model names, and “100% complete” claims unless dated and evidenced.
- Link related active documents with relative Markdown links.
- Preserve historical reports when useful, but archive them instead of rewriting history as current behavior.
- Use Danish terminology consistently in product documentation.

## Technical baseline

- Frontend: React in `frontend/src/`, built with `react-scripts`.
- Backend: Express in `backend/unified-server.js` and `backend/src/`.
- Database: MySQL/MariaDB through `mysql2`; local credentials belong in `backend/.env`.
- Tests: Jest/Supertest for backend and Playwright for end-to-end flows.

## Security

- Never document plaintext secrets, API keys, customer uploads, production logs, or database backups.
- Use placeholders in examples and keep secret handling aligned with `docs/ENCRYPTED_ENV_SECURITY.md`.