Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.0 KiB
4.0 KiB
Ü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.
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.