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.

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/.

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.

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.

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.