# Übergabe-Prompt — Auth-Umbau „Zentrale Identität + Mandanten-Mitgliedschaften"

> Diesen Prompt einem neuen Entwickler bzw. dessen Claude-Code-Agenten geben. Er bootstrapt in certvia und diese Aufgabe. Zugehörige Dokumente liegen im selben Branch.

```text
Du übernimmst Entwicklungsarbeit am Produkt „certvia" (ISMS-Tool, Multi-Tenant-
Next.js-16 / Prisma-7 / Postgres+RLS / Auth.js-v5 SaaS). Repo: ~/Projects/ISMS-Tool,
Integrationsbranch `dev`. Deine Aufgabe: den Auth-Umbau „Zentrale Identität mit
Mandanten-Mitgliedschaften" (Option C) umsetzen.

BRANCH / CHECKOUT:
   Arbeits-/Doku-Branch: `identity-mandanten`
   - origin      = https://git.certvia.de/msolarczek/certvia.git  (Branch: identity-mandanten)
   - local-gitea = interner Spiegel                                (Branch: identity-mandanten)
   Auschecken:  git fetch origin && git checkout identity-mandanten
   Die unten genannten docs/ liegen auf genau diesem Branch.

WICHTIG: certvia ist strikt getrennt von jedem anderen Produkt (insb. „visitvia").
Nichts vermischen.

1) PFLICHTLEKTÜRE — erst lesen, nicht sofort coden, in dieser Reihenfolge:
   - docs/HANDOVER-DEV.md, docs/SPEC.md  (Projektgrundlagen)
   - docs/STAND-dev-branch.md            (aktueller Entwicklungsstand)
   - docs/UEBERGABE-identity-mandanten.md (Kurzübergabe zu genau dieser Aufgabe)
   - docs/FEINDESIGN-identity-mandanten.md (der umsetzbare Bauplan — dein Fahrplan)
   - docs/KONZEPT-identity-mandanten.md    (Warum/was, getroffene Entscheidungen A–E)

2) AUFTRAG:
   Setze Option C um. Reihenfolge = die Workstreams/Meilensteine aus dem FEINDESIGN.
   Beginne mit WS0 (Fundament): neues globales `Identity`-Modell, Schema-Recut von
   `User` zur Mitgliedschaft (+identityId), Migration, `TENANT_MODELS` anpassen,
   Reseed. WS0 ist Blocker — bau es als Pairing und lass es reviewen.

3) VERBINDLICHE REGELN (aus dem FEINDESIGN, nicht verhandelbar):
   - `User.id` = Mitgliedschaft, STABIL lassen; Auth-Felder wandern auf `Identity`.
   - `Identity` ist GLOBAL: NICHT in `TENANT_MODELS`, kein tenant_id, keine RLS-Policy.
   - Genau EIN aktiver Mandant pro Session; `session.user.tenantId` = aktiver Mandant;
     server-autoritativ; bei Mandantenwechsel Membership+MFA re-validieren.
   - Nutzeranlage NUR per Einladung (kein „Passwort direkt setzen" mehr).
   - MFA/Passwort gehören der Identity — KEIN Mandanten-Admin-Reset.
   - MFA beim Login als 2. Schritt (erst E-Mail+Passwort, dann MFA); dazwischen KEINE
     volle Session (kurzlebiger MFA-pending-State).
   - Plattform-Admins (`platform_admins`) bleiben getrennt — nicht anfassen.

4) ARBEITSWEISE:
   - Validierungs-Gate vor JEDEM PR/Merge: `npx tsc --noEmit`, `npm run lint`,
     `npm run build`, und ALLE `scripts/test-*.ts` müssen grün sein. Jede Story bringt
     ihren eigenen Test mit (Identity-Login, Tenant-Switch-Isolation, MFA-Enforcement
     multi-tenant, Einladung, Two-Step-Bypass).
   - DevOps: Feature-Branch → `git merge --no-ff` nach `dev` → Gate grün →
     Push auf BEIDE Remotes (origin=git.certvia.de, local-gitea) →
     docs/STAND-dev-branch.md pflegen.
   - Definition of Done: siehe FEINDESIGN §9.

5) KOORDINATION:
   Parallel läuft „Richtlinien-Upload im Adminportal". Funktional unabhängig, ABER
   beide editieren src/app/(platform)/admin/[id]/page.tsx (Policy-Upload = Module-Karte,
   Identity-Umbau = Benutzerverwaltung). Reihenfolge auf dieser Datei abstimmen.

6) NICHT TUN:
   - Getroffene Entscheidungen A–E nicht umwerfen (bei echtem Problem eskalieren, nicht
     eigenmächtig ändern).
   - Phase-2-Punkte (per-Mandant „immer Step-up", E-Mail-Änderung als Identity-Op,
     PlatformAdmin-Konsolidierung) sind bewusst ausgeklammert — nicht mitbauen.
   - Keine Datenmigration bauen: es gibt nur Testdaten → Schema-Recut + Reseed.

Erste Schritte: (a) Pflichtlektüre lesen und mir eine 10-Zeilen-Zusammenfassung +
offene Fragen zurückgeben, (b) WS0 als PR-Plan skizzieren (Schema-Diff, Migrationen,
TENANT_MODELS-Änderung, Reseed), (c) nach Freigabe umsetzen. Warte nach (a)/(b) auf
Bestätigung, bevor du WS0 mergst.
```