# Repository Guidelines

## Project Structure & Module Organization
- `backend/` contains the unified Node/Express server (`backend/unified-server.js`) and core backend modules in `backend/src/` (`services/`, `routes/`, `middleware/`, `graphql/`).
- `frontend/` is the React app; primary code lives in `frontend/src/`, and production artifacts are generated in `frontend/build/`.
- `backend/__tests__/` holds backend Jest tests. Cross-stack UI/API checks live in `tests/` (`*.spec.js` for Playwright, Selenium scripts under `tests/selenium/`).
- `database/` and `backend/migrations/` contain schema and seed/migration data. `docs/` stores architecture and operational notes.

## Build, Test, and Development Commands
- Install dependencies per package:
  - `npm ci`
  - `cd backend && npm ci`
  - `cd frontend && npm ci`
  - `cd tests && npm ci`
- Run backend locally: `cd backend && npm run dev` (nodemon) or `cd backend && npm start`.
- Run frontend locally: `cd frontend && npm run dev`.
- Build frontend: `cd frontend && npm run build`.
- Backend tests with coverage: `cd backend && npm test -- --coverage --passWithNoTests`.
- Playwright E2E (local): `cd tests && PLAYWRIGHT_BASE_URL=http://localhost:4032 npx playwright test`.

## Coding Style & Naming Conventions
- Use JavaScript/React with 2-space indentation and existing semicolon style.
- Prefer `async/await`; keep route handlers thin and push business logic into `backend/src/services/`.
- Naming: `camelCase` for variables/functions, `PascalCase` for React components, kebab/camel names aligned to existing files.
- Test naming: Jest files as `*.test.js`; Playwright files as `*.spec.js`.
- Frontend linting follows `react-scripts` ESLint defaults (`react-app` config).

## Testing Guidelines
- Primary frameworks: Jest (+ Supertest) for backend and Playwright for E2E. Selenium is available for supplemental UI checks.
- Add or update backend tests for any API/service change; add Playwright coverage for user-facing flow changes.
- Include happy-path and failure-path assertions. For new modules, target at least ~80% coverage.

## Commit & Pull Request Guidelines
- Follow Conventional Commit style seen in history (`feat:`, `fix:`, `chore:`, `docs:`, optional scopes like `chore(docs):`).
- Keep commits focused and include related migration/test updates.
- PRs should include: concise summary, linked issue (if applicable), test commands run + outcomes, and screenshots for UI changes.
- Ensure CI checks pass before merge (backend tests, frontend build, and security scan).

## Security & Configuration Tips
- Never commit plaintext secrets. Runtime secrets belong in `/mnt/HC_Volume_103713257/tilbudsgivern-data`; `backend/.env` must be a symlink to the environment file there. Use encrypted env files where supported.
- Integrationer må kun referere til miljøvariabler som `OSTICKET_API_KEY`, `SUPPORT_WORKLIST_API_KEY`, `ORDRESTYRING_API_TOKEN` og `ORDRESTYRING_API_KEY`; værdierne må kun ligge i den eksterne data-mappes environment-fil og må ikke kopieres til kode, dokumentation eller `system_settings`.
- Do not commit logs, test artifacts, or DB backups (`logs/`, `tests/test-results/`, `tests/playwright-report/`, `backups/`).

## Obsidian Documentation Vault
- Before planning or implementing behavior changes, search `obsidian-vault/00 Start/Dokumentindeks.md` for relevant project decisions, guides, status reports, and prior implementations.
- Treat files under `obsidian-vault/10 Dokumenter/` as generated, read-only copies. Use `obsidian-vault/00 Start/Kildemanifest.tsv` to locate the original repository file and edit that source instead.
- After adding or changing repository Markdown, run `./scripts/sync-obsidian-vault.sh` and include the synchronized vault copy in the same change.
- Put new hand-written Obsidian notes outside `10 Dokumenter/`, preferably in `obsidian-vault/20 Arbejdsnoter/`, and never include secrets or customer uploads.