msolarczekandClaude Opus 5
cadaedc6cc
- docker-compose.coolify(.prebuilt).yml: Service craftvia-worker (Target worker, Chromium, shm_size 1gb, gleiche Härtung), Craftvia-Variablen für app und worker. - Dockerfile: worker-Stage mit HOME=/home/app (Chromium-Profil für non-root); lokaler docker build der Targets runner und worker erfolgreich, PDF-Erzeugung im Image geprüft. - .env.example/.env.prod.example/.env.coolify.example: alle Craftvia-Variablen inkl. RLS, KI-Provider, PDF_CHROMIUM_PATH, OFFLINE_MAX_DAYS, API_RATE_LIMIT_*, AI_GENERATION_RETENTION_DAYS, AI_MONTHLY_TOKEN_LIMIT. - CI (.github, .gitea): Job gate mit Postgres (pgvector) und Redis als Service: migrate deploy, seed, Passwort für craftvia_app, tsc, lint, build, npm run test. - docs/craftvia/DEPLOY.md (aus den Certvia-Deploy-Docs abgeleitet): Architektur, Domains, Secrets, Worker, Migrationen, RLS-Aktivierung, Backup/Restore, KI, Rate Limits, Aufbewahrung, Smoke, Update/Rollback. build-and-push-images.sh baut craftvia-worker. - Certvia-/ISMS-Dokumente aus docs/ nach docs/_certvia-archiv/ (mit README); Verweise in README.md und Skript-Kommentaren angepasst. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
39 lines
3.8 KiB
Markdown
39 lines
3.8 KiB
Markdown
# Übergabe — Umbau „Zentrale Identität + Mandanten-Mitgliedschaften" (certvia)
|
||
|
||
> Kurzübergabe für Team-Lead + PM + neue Entwickler. Produkt: **certvia** (ISMS-Tool). Branch: **`feature/identity-mandanten`**.
|
||
|
||
## Worum es geht
|
||
Eine Person soll sich mit **einem** Login/Passwort/MFA anmelden und danach wählen, in **welchem Mandanten** sie arbeitet — mit je Mandant unterschiedlichen Rollen. Heute ist jeder Nutzer fest an genau einen Mandanten gebunden (eigenes Passwort/MFA je Mandant). Umbau nach **Option C**: globale `Identity` (Anmeldung) + bestehende per-Mandant-`User`-Zeilen als „Mitgliedschaften".
|
||
|
||
## Die zwei Dokumente
|
||
1. [KONZEPT-identity-mandanten.md](KONZEPT-identity-mandanten.md) — **Entscheidungsvorlage** (fachlich, warum/was). Enthält die getroffenen Entscheidungen A–E, Two-Step-Login, Passphrasen, MFA-Matrix, die vier Anlage-Flows, Sicherheitsbetrachtung.
|
||
2. [FEINDESIGN-identity-mandanten.md](FEINDESIGN-identity-mandanten.md) — **umsetzbarer Bauplan** (technisch): Zieldatenmodell, Session-Shape, Flows, 7 Workstreams, 6 Meilensteine, Risiken, DoD, Onboarding, Aufwand (≈ 47–73 PT / ≈ 5–7 Wochen).
|
||
|
||
## Getroffene Entscheidungen (fix)
|
||
| A | B | C | D | E |
|
||
|---|---|---|---|---|
|
||
| MFA **beim Login** (2-stufig: erst Passwort, dann MFA) | Reset-Hoheit → Self-Service + Plattform (Mandanten-Admin verliert MFA-/Passwort-Reset) | **Einladung** als Standard-Anlage | **Migration entfällt** (nur Testdaten → Reseed) | Plattform-Admins **getrennt** (`platform_admins`) |
|
||
|
||
## Womit das Team startet (M0 → M1)
|
||
1. **Onboarding:** Pflichtlektüre `docs/HANDOVER-DEV.md` → `docs/SPEC.md` → `docs/STAND-dev-branch.md` → FEINDESIGN → KONZEPT. Dev-Setup + Gate (§10 im FEINDESIGN).
|
||
2. **WS0 Fundament als Pairing** (Lead + je 1 Dev): `Identity`-Modell, Schema-Recut, Migration, `TENANT_MODELS`, Reseed. Blocker für fast alles Weitere.
|
||
3. Danach parallel: WS1 (Auth-Kern), WS3 (Einladung), WS4 (Passwort/MFA an Identity), WS6 (Seed).
|
||
|
||
## Die 5 „Goldenen Regeln" (nicht verhandelbar)
|
||
1. `User.id` = Mitgliedschaft, **stabil lassen**; Auth-Felder leben auf `Identity`.
|
||
2. `Identity` ist **global**, **nicht** in `TENANT_MODELS`, kein `tenant_id`, keine RLS-Policy.
|
||
3. Genau **ein** aktiver Mandant pro Session; server-autoritativ; bei Wechsel re-validieren.
|
||
4. **Keine** „Passwort direkt setzen"-Anlage mehr — nur Einladung.
|
||
5. MFA/Passwort gehören der Identity — **kein** Mandanten-Admin-Reset.
|
||
|
||
## Warum der Umbau überschaubar bleibt
|
||
Weil `User.id` **und** die Semantik von `session.user.tenantId` (= aktiver Mandant) erhalten bleiben, sind **~356 `dbForTenant()`-Stellen, alle 6 Owner-FKs und das RLS-Modell unberührt**. Der Umbau konzentriert sich auf Login, Session-Aufbau, Mandantenauswahl und Nutzer-Lifecycle.
|
||
|
||
## Koordination mit laufender Arbeit
|
||
- **Richtlinien-Upload im Adminportal** (parallel in Arbeit) ist **funktional nicht betroffen**: er hängt nur an `moduleGuard("policies")`, `session.user.tenantId`, `session.user.id`, `dbForTenant()` und `requirePlatformFullAdmin` — alles stabile Flächen. **Ein** Berührungspunkt: die geteilte Datei `src/app/(platform)/admin/[id]/page.tsx` (Policy-Upload an der Module-Karte, Identity-Umbau an der Benutzerverwaltung) → nur Merge-Koordination, kein funktionaler Konflikt. Empfehlung: WS3/WS-UI und der Policy-Upload-Stream stimmen Reihenfolge auf dieser Datei ab.
|
||
- **DevOps:** Feature-Branch → `git merge --no-ff` nach `dev` → Gate grün (tsc/lint/build + alle `scripts/test-*.ts`) → Push auf **beide** Remotes (`origin` git.certvia.de + `local-gitea`) → `docs/STAND-dev-branch.md` pflegen.
|
||
|
||
## Offen für PM-Entscheidung (kein Blocker fürs Feindesign)
|
||
- Team-Besetzung/Startdatum, Sprint-Zuschnitt entlang M1–M6.
|
||
- Phase-2-Punkte (per-Mandant „immer Step-up", E-Mail-Änderung als Identity-Op, evtl. PlatformAdmin-Konsolidierung) — bewusst zurückgestellt.
|