Basis: Certvia dev@a48c5fb als Fundament für Craftvia

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>

docs/PROMPT-lane-backup.md

@@ -0,0 +1,57 @@
+# 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).
+```