Org assignment history, mobile support, and a correctness pass

Data model
- employee_assignments records org placement over time (valid_from/valid_to),
  written by a trigger on `employees` rather than inside each RPC: ~70
  `update employees` statements spread over fifteen migrations mean per-call
  bookkeeping would miss paths today and again with every future RPC. A
  partial unique index enforces the one-open-interval invariant the trigger
  relies on when closing the current row.
- The Organigramm gains a Stichtag (default today). Membership comes from
  entry/exit/karenz, past placement from the new history, future placement
  projected from pending_org_changes. Placements predating the migration are
  backfilled with today's values and flagged as such in the UI, since
  employee_history only ever stored free text and cannot be reconstructed.

Correctness
- Reports and exports silently truncated at PostgREST's 1000-row cap
  (db.max_rows); employee_history is already past it at ~800 staff. Every
  whole-table read now pages explicitly.
- XLSX date cells were a day early: ExcelJS converts a Date to an Excel
  serial straight off getTime(), so a Date built at local midnight lands on
  the previous day's serial in any positive-offset zone.
- Date handling is pinned to Europe/Vienna throughout, and date-only strings
  are formatted without a Date round-trip. The dashboard's YTD window was
  built by round-tripping a local Date through toISOString(), which shifted
  it a day early and dropped 31 December entirely.
- Export routes parsed measure/group/split/eventType with unchecked `as`
  casts, so an unknown value reached column headers as `undefined` and the
  Content-Disposition filename. Parsed against the label maps now, with the
  filename slugged as a backstop.
- toXlsx keyed columns by header text, silently dropping the second of any
  two columns sharing a name — split columns take their header from data.
- The org chart tree walks had no cycle guard; nothing in the schema forbids
  a manager_id cycle, and one would hang the tab rather than misreport.
- The login page reflected ?error= verbatim, letting anyone put arbitrary
  text on the real sign-in screen; messages are looked up by code now.
- React Flow needs elementsSelectable on, or it sets pointer-events:none on
  the whole node and the expand control stops responding.

UI
- Mobile: the shell was unusable below lg — a fixed 236px margin pushed
  content off-screen with no mobile navigation at all. The sidebar is now a
  drawer, dvh replaces vh, safe-area insets are honoured, inputs are 16px so
  iOS stops zooming on focus, and form grids stack.
- Org chart nodes redesigned: per-kind accent stripes and icons, vacant
  roles called out, expand control moved to the bottom edge carrying the
  child count.
- Pagination is windowed; it previously rendered one link per page (54 for
  the employee list, unbounded for the audit log).
- Positions page reduced to open positions with a single "Besetzen" action.
- The employee Organisation tab links into the org chart focused on that
  person, reusing the chart's existing search-match highlighting.

Also included, uncommitted until now
- Dependants, HR notes, academic titles, split address fields, position
  validity and role/employment fields, with their migrations and UI.
- Docker/compose deployment setup, data-model and security-review docs.

docs/data-model.md

@@ -0,0 +1,96 @@
+# Datenmodell
+
+Beschreibt das tatsächliche Supabase-Schema (siehe `supabase/migrations/`),
+nicht ein generisches HR-Schema. Quelle der Wahrheit sind immer die
+Migrationen; dieses Dokument ist eine lesbare Zusammenfassung und wird bei
+strukturellen Änderungen mitgepflegt.
+
+## Grundprinzipien
+
+- **Person ist nicht Position.** `employees` (Personen) und `positions`
+  (Planstellen/Ausschreibungen) sind getrennte Tabellen. Eine Position wird
+  bei Einstellung mit einer Person verknüpft (`filled_by_employee_id`),
+  existiert aber unabhängig davon (offene Ausschreibung).
+- **History ist append-only.** `employee_history` (Ereignisse pro Person)
+  und `audit_log` (systemweit, wer hat was wann geändert) haben keine
+  Update-/Delete-Policy — RLS erlaubt nur `select`/`insert`. Korrekturen
+  erfolgen durch einen neuen, kompensierenden Eintrag, nie durch Ändern der
+  Historie (siehe `undo_reorg`, das eine "Reorganisation rückgängig"-Zeile
+  anhängt statt die ursprünglichen Zeilen zu löschen).
+- **Audit-Log ist Pflicht bei Änderungen — und lebt in der Datenbank, nicht
+  im App-Code.** Jede mutierende SQL-Funktion (`hire_employee`,
+  `change_employee_data`, `add_employee_dependent`, `add_employee_note`, …)
+  schreibt ihren `audit_log`-Eintrag in derselben Transaktion wie die
+  eigentliche Änderung. Das ist bewusst atomar: ein fehlgeschlagener
+  Audit-Insert lässt die ganze Transaktion fehlschlagen, statt still eine
+  Änderung ohne Log zu hinterlassen. Es gibt keinen App-seitigen
+  `writeAuditLog()`-Helper und es sollte auch keinen geben — das würde eine
+  zweite, nicht-atomare Logging-Quelle neben der bestehenden schaffen.
+- **Service-Role-Zugriff ist server-only.** `lib/supabase/admin.ts` ist die
+  einzige Stelle, die den Service-Role-Key verwendet; `import "server-only"`
+  macht einen versehentlichen Client-Import zu einem Build-Fehler. Alles
+  andere läuft über den anon key + RLS.
+- **RLS ist bereits aktiv**, nicht nur für die Produktion vorgemerkt: jede
+  Tabelle hat `enable row level security` plus mindestens eine Policy
+  (siehe unten). Zusätzlich existieren explizite `grant`-Statements für
+  `anon`/`authenticated`/`service_role`
+  (`20260714120500_default_grants.sql`) — ohne die schlägt jede Query auch
+  mit korrekter RLS-Policy mit "permission denied" fehl, weil Postgres
+  Objekt-Rechte unabhängig von RLS prüft.
+
+## Zugriffsmodell
+
+Ein einziges Rollenmodell, kein Mehrfach-Rollen-System:
+
+- `profiles.role` ist per Check-Constraint auf den einzigen Wert `'hr'`
+  fixiert (Migration `20260714120000_hr_only_access.sql`).
+- `profiles.is_active` (default `false`) muss zusätzlich wahr sein.
+- Die SQL-Funktion `is_hr_user()` (SECURITY DEFINER, vermeidet RLS-Rekursion
+  auf `profiles`) prüft beides und gated praktisch jede Policy im Schema.
+- `proxy.ts` (Next.js Proxy, ehem. Middleware) spiegelt dieselbe Prüfung auf
+  App-Ebene: nicht eingeloggt → `/login`; eingeloggt aber nicht aktive
+  HR-Person → `/login` mit Fehlermeldung. Das ist bewusst nur "defense in
+  depth" — die eigentliche Schranke ist RLS, nicht die UI-Prüfung.
+- Es gibt **keine** granulareren Rollen (kein `hr_admin`/`read_only`/
+  `it_admin`-Split o. Ä.) und aktuell keinen zweiten Anwendungsfall dafür.
+  Sollte das nötig werden, ist der richtige Ansatz eine neue Migration, die
+  `is_hr_user()` um echte Rollenspalten erweitert — nicht ein
+  App-seitiges Rollenmodell, das der DB-Policy-Ebene nicht entspricht.
+
+## Kernentitäten
+
+| Tabelle | Zweck |
+|---|---|
+| `divisions` / `departments` / `teams` | Org-Hierarchie ("Bereich" 20xx / "Abteilung" 21xx / "Team" 22xx), je mit eindeutiger `org_number`. |
+| `locations` | Standorte, an ein Land gebunden (steuert die Standort-Picklist im UI). |
+| `profiles` | Ein Datensatz pro Supabase-Auth-User; Rolle + Aktivierungsstatus (siehe oben). |
+| `employees` | Zentrale Personentabelle: Stammdaten, Vertrag (Vollzeit/Teilzeit, befristet/unbefristet), Org-Zuordnung, Status (`Aktiv`/`Karenz`/`Geplant`/`Ausgetreten`), Rolle & Anstellung (Angestellte:r/Arbeiter:in, Kollektivvertrag, Arbeitstage, Betriebsrat/Dienstwagen/laterale Führung/C-Level-Flags), akademische Titel (Prefix/Suffix-Arrays). |
+| `employee_history` | Append-only Ereignis-Timeline pro Person (fester Enum: Eintritt, Beförderung, Versetzung, Karenz, Vertragsänderung, Stammdatenänderung, Austritt, Wiedereintritt, Reorganisation, Gehaltsanpassung, Rückkehr). |
+| `employee_dependents` | Angehörige (Ehepartner:in/Lebenspartner:in/Kind/Sonstige) je Mitarbeiter:in; Edit = Löschen + Neuanlage, kein In-place-Update. |
+| `employee_notes` | HR-Notizen je Mitarbeiter:in, add-only, mit optionalem "Wiedervorlage am"-Datum. Bewusst nicht autor-gescoped — jede aktive HR-Person sieht jede offene Notiz ("Meine Notizen" ist ein geteiltes Postfach, kein persönliches). |
+| `positions` | Planstellen mit eindeutiger `position_number` (^6\d{7}$), Status `open`/`filled`, `valid_from`-Gültigkeitsfenster. |
+| `hire_drafts` | Fortsetzbarer Zwischenstand des Neueinstellungs-Wizards (JSONB-Payload), eigentümer-gescoped. |
+| `saved_reports` | Gespeicherte Report-Konfigurationen, eigentümer-gescoped. |
+| `pending_org_changes` | Effective-dated (zukünftig wirksame) Änderungen — Versetzung/Beförderung/Karenz-Start/-Rückkehr/Vertragsänderung/Reorg — die erst am `effective_date` angewendet werden. Wird von `apply_due_pending_changes()` verarbeitet, aufgerufen vom Cron-Route-Handler. Entspricht dem, was in generischen HR-Schemata oft "planned_changes" heißt. |
+| `audit_log` | Systemweiter, unveränderlicher Audit-Trail (wer/wann/was/an wem). Wird ausschließlich von SQL-Funktionen beschrieben, nie direkt aus der App. |
+| `reorg_scenarios` / `reorg_moves` | Persistierte Reorg-Pläne inkl. `undo_snapshot` (Pre-Change-Zustand für die Rückgängig-Funktion). |
+
+## Cron / effective-dated changes
+
+`apply_due_pending_changes()` (SQL, `SECURITY DEFINER`) ist die einzige
+Funktion, deren Ausführungsrecht explizit auf `service_role` beschränkt ist
+(`revoke ... from public, anon, authenticated; grant ... to service_role`).
+Sie wird von `app/api/cron/apply-pending-changes/route.ts` aufgerufen —
+täglich per Vercel Cron (`vercel.json`), außerhalb von Vercel per
+Ersatz-Scheduler (siehe `DEPLOYMENT.md`, Docker-Cron-Sidecar). Die Route
+selbst authentifiziert per `CRON_SECRET`-Bearer-Token, nicht per
+Supabase-Session — es gibt keine anfragende Person, nur den Scheduler.
+
+Idempotenz: `pending_org_changes.status` läuft `pending` → `applied` (oder
+`cancelled` bei Reorg-Undo); die Auswahl-Query filtert immer auf
+`status = 'pending'`, ein zweiter Lauf wirkt daher auf bereits angewendete
+Einträge nicht erneut.
+
+## Bekannte Lücken vor Produktivbetrieb
+
+Siehe README.md → "Known TODOs" für den aktuellen Stand.

docs/security-review.md

@@ -0,0 +1,113 @@
+# Security Review
+
+Ergebnis eines gezielten Greps über das gesamte Repository (ohne
+`node_modules`) nach neun sicherheitsrelevanten Mustern, mit Bewertung im
+jeweiligen Kontext. Stand: 2026-07-24.
+
+## `SUPABASE_SERVICE_ROLE_KEY`
+
+Referenziert in vier Dateien, alle server-seitig / lokal:
+
+- `lib/supabase/admin.ts` — die einzige App-Laufzeit-Verwendung, hinter
+  `import "server-only"`. Jetzt mit expliziter Fehlermeldung bei fehlendem
+  Wert statt eines `!`-Non-null-Assertions (siehe Änderungen).
+- `supabase/seed.ts`, `tests/integration/helpers.ts` — Node-Skripte
+  außerhalb des Next.js-Bundles (Seeding bzw. Test-Setup), lesen den Wert
+  nur aus `process.env`. Unkritisch.
+- `.scratch_make_test_hr.mjs` — lokales, nicht eingechecktes
+  Hilfsskript (liest den Key ebenfalls nur aus `process.env`, kein
+  Hardcoding). War bisher weder committet noch von `.gitignore` erfasst;
+  **behoben** — `.gitignore` schließt `.scratch_*` jetzt explizit aus, damit
+  ein künftiges `git add -A` es nicht versehentlich eincheckt.
+
+Keine Fundstelle exponiert den Key im Browser-Bundle oder in einer
+API-Response.
+
+## `service_role` (Postgres-Rolle)
+
+9 Treffer, ausschließlich in `supabase/migrations/*.sql` — Standard-Supabase-
+Muster:
+
+- `20260714120500_default_grants.sql`: explizite `grant ... to anon,
+  authenticated, service_role` (nötig, weil RLS Objekt-Rechte nur
+  einschränkt, nicht ersetzt — ohne dieses Grant schlägt jede Query auch
+  mit korrekter Policy mit "permission denied" fehl).
+- `20260714120200_effective_dating_rpcs.sql` / `20260714120600_...`:
+  `revoke execute ... from public, anon, authenticated; grant execute ...
+  to service_role` für `apply_due_pending_changes()` — das ist die
+  **korrekte** Absicherung: die Funktion darf nur vom Cron-Job (über den
+  Service-Role-Client) aufgerufen werden, nicht von einer eingeloggten
+  HR-Person, sonst könnte diese noch nicht fällige Änderungen vorzeitig
+  erzwingen.
+
+Keine problematische Fundstelle.
+
+## `localStorage`, `sessionStorage`, `document.cookie`
+
+Keine Treffer im gesamten App-Code. Sessions laufen ausschließlich über den
+von `@supabase/ssr` verwalteten Cookie-Adapter (`lib/supabase/server.ts`,
+`proxy.ts`), nicht über direkten Browser-Storage-Zugriff. Kein Risiko einer
+Token-Exponierung über clientseitigen Storage.
+
+## `dangerouslySetInnerHTML`, `innerHTML`
+
+Keine Treffer. Keine rohe HTML-Injection-Fläche im Code.
+
+## `Authorization`
+
+Einzige Fundstelle: `tests/unit/security.test.ts` (prüft den Cron-Route-
+Guard). Die Route selbst liest den Header über
+`request.headers.get("authorization")` (Kleinschreibung) — HTTP-Header sind
+case-insensitiv und `Headers.get()` behandelt sie entsprechend, das ist
+korrekt und wird bereits durch drei Tests abgedeckt (fehlender Header,
+falscher Wert, nicht konfiguriertes `CRON_SECRET`).
+
+## `audit_logs` / `planned_changes` (aus der Aufgabenstellung)
+
+Keine Treffer unter diesen exakten Namen — das reale Schema heißt
+`audit_log` (Singular) bzw. `pending_org_changes`. Siehe
+[`docs/data-model.md`](data-model.md) für die vollständige Zuordnung.
+
+**Audit-Log-Abdeckung geprüft:** Jede mutierende Server Action (`actions/
+employees.ts`, `actions/positions.ts`, `actions/reorg.ts`) ruft ausschließlich
+`supabase.rpc(...)` auf — keine einzige schreibt direkt per
+`.from(...).insert()/.update()/.delete()` auf `employees`, `positions`,
+`employee_notes`, `employee_dependents` oder `profiles`. Jede der
+dahinterliegenden SQL-Funktionen (`hire_employee`, `transfer_employee`,
+`promote_employee`, `start_karenz`, `record_karenz_return`,
+`change_employee_data`, `apply_reorg`, `undo_reorg`,
+`staff_position_internally`, `delete_position`, `add_employee_dependent`,
+`delete_employee_dependent`, `add_employee_note`,
+`complete_employee_note`) schreibt ihren `audit_log`-Eintrag in derselben
+Transaktion wie die eigentliche Datenänderung. Für die aktuell existierenden
+Mutationspfade ist damit lückenlos sichergestellt, dass keine Änderung ohne
+Audit-Eintrag möglich ist — ein fehlgeschlagener Audit-Insert lässt die
+gesamte Transaktion fehlschlagen.
+
+Ausnahme (bewusst, kein Gap): `apply_due_pending_changes()` (vom Cron-Job
+aufgerufen) schreibt beim tatsächlichen Anwenden einer fälligen Änderung
+keinen zusätzlichen `audit_log`-Eintrag — der Audit-Eintrag für diese
+Änderung wurde bereits zum Zeitpunkt der Anforderung geschrieben (von
+`transfer_employee`/`start_karenz`/etc.), datiert auf das Wirksamkeitsdatum.
+Ein zweiter Eintrag beim tatsächlichen Anwenden würde denselben
+Geschäftsvorfall doppelt loggen.
+
+## Warum hier kein neues `lib/audit/audit-log.ts` entstanden ist
+
+Eine App-seitige `writeAuditLog()`-Hilfsfunktion wäre eine zweite,
+nicht-transaktionale Logging-Quelle neben der bestehenden — sie könnte
+fehlschlagen, nachdem die eigentliche Mutation bereits committet wurde, und
+so eine Änderung ohne Audit-Spur hinterlassen. Die bestehende Lösung
+(Audit-Insert in derselben SQL-Funktion/Transaktion) ist strenger. Ein
+App-seitiger Helfer wäre daher eine Verschlechterung, kein Fix.
+
+## Offene Punkte (siehe README → "Known TODOs")
+
+- Kein Content-Security-Policy-Header (bewusst zurückgestellt, siehe
+  Kommentar in `next.config.ts` — Skript-/Style-/Connect-Quellen noch nicht
+  vollständig inventarisiert).
+- `.scratch_shots/` enthielt PNG-Screenshots einer Testsitzung mit
+  Beispiel-Notiztext ("vertrauliches Gespräch zur Verifikation" — Testdaten,
+  keine echten Personendaten identifiziert). Ordner ist jetzt über
+  `.gitignore` ausgeschlossen; Inhalt selbst wurde nicht gelöscht (siehe
+  Hinweis unten).