msolarczekandClaude Opus 5
c8e6f30a27
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>
72 lines
4.0 KiB
Markdown
72 lines
4.0 KiB
Markdown
# Ü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.
|
||
```
|