# Kickoff-Prompt — Lane Backup/Restore/DSGVO (certvia)

> Diesem Prompt einem Entwickler/Claude-Code-Agenten geben. Bootstrapt in certvia + diese Lane.

```text
Du übernimmst die Lane „Datensicherung, Wiederherstellung & DSGVO" am Produkt „certvia"
(ISMS-Tool, Multi-Tenant Next.js-16 / Prisma-7 / Postgres+RLS / Auth.js-v5). Repo:
~/Projects/ISMS-Tool, Integrationsbranch `dev`.

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

BRANCH/CHECKOUT:
   Arbeits-Branch: `lane-backup`  (KEIN `feature/`-Prefix — auf origin blockiert der Branch
   `feature` diesen Namespace). Aus `dev` erstellen: git fetch origin && git checkout dev &&
   git checkout -b lane-backup.
   Remotes: origin = https://git.certvia.de/msolarczek/certvia.git · local-gitea (intern).

1) PFLICHTLEKTÜRE (erst lesen, nicht sofort coden):
   - docs/HANDOVER-DEV.md, docs/SPEC.md, docs/STAND-dev-branch.md
   - docs/KONZEPT-backup-restore.md   ← dein Fahrplan (Schicht A/B, Portal, DSGVO, §9 Verschlüsselung)
   - docs/KONZEPT-haertung.md §3       ← operativer Bezug „verschlüsselte Backups"

2) AUFTRAG (Phasen aus dem Konzept §11):
   (1) Schicht A: pgBackRest/wal-g + PITR, client-seitig AES-256 (§9) — Ops-nah, sofort möglich.
   (2) Tenant-scoped Export/Restore-Engine über TENANT_MODELS (FK-Reihenfolge), REPEATABLE READ.
   (3) Betreiber-Portal-Restore (Worker-Job, Kontrollen §4/§10).
   (4) DSGVO-Export (per-Mandant + per-Person).
   (5) DSGVO-Löschung (Anonymisieren vs. Hard-Delete + Löschnachweis + Tombstone-on-Restore).

3) VERBINDLICHE REGELN:
   - Engine läuft über den Owner-`prisma`-Client (BYPASSRLS), NIE den RLS-Client.
   - Jede Operation `tenant_id`-gescopt (Export SELECT, Restore DELETE+INSERT, Löschung) →
     beweisbar keine Fremdmandanten berührt. cuid-PKs: Reinsert kollisionsfrei.
   - `Identity` ist GLOBAL: Tenant-Restore holt Mitgliedschaften (`User`), NICHT den globalen
     Credential-Store (der liegt in Schicht A). Fehlende Identity beim Reinsert sauber behandeln.
   - Verschlüsselung = §9-Primitiv: client-seitig AES-256, Keys pro Umgebung. Backup-Artefakte
     enthalten KEINE Umgebungs-Secrets (Pepper/MFA_ENC_KEY) → Restore-Kohärenz dokumentieren.
   - MinIO-Dateien (Prefix je Mandant) gehören zu Export/Restore/Löschung dazu.
   - Destruktive Portal-Aktionen: requirePlatformFullAdmin + MFA-Step-up + getippte Bestätigung
     + Mandant-Sperre + Pre-Restore-Snapshot + Audit.

4) ARBEITSWEISE:
   - Gate vor JEDEM Merge: npx tsc --noEmit · npm run lint · npm run build · ALLE scripts/test-*.ts.
     Jede Story bringt ihren Test mit (Isolation: Restore/Export/Löschung berührt nur den Zielmandanten).
   - DevOps: lane-backup → git merge --no-ff nach dev → Gate grün → Push auf BEIDE Remotes →
     docs/STAND-dev-branch.md pflegen.

5) KOORDINATION:
   - §9-Verschlüsselung ist gemeinsam mit Lane Härtung: Mechanismus/Keys sind entschieden
     (client-seitig AES-256, Keys pro Umgebung) — nur EINMAL abstimmen, dann unabhängig.
   - prisma migrate reset gegen Test/Coolify braucht Nutzer-Zustimmung (Prisma-Guard).

6) NICHT TUN: keine Änderung am Auth-/RLS-Kern; TENANT_MODELS bleibt Quelle der tenant-Tabellen.

Erste Schritte: (a) Pflichtlektüre + 10-Zeilen-Zusammenfassung/Fragen, (b) FK-Reihenfolge aus
TENANT_MODELS ableiten + Engine-PR-Plan skizzieren, (c) nach Freigabe umsetzen. Warte nach (a)/(b).
```