craftvia/docs/PROMPT-lane-backup-target.md

Kickoff-Prompt — Lane Konfigurierbarer Backup-Zielspeicher (certvia)

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

Du übernimmst die Lane „Konfigurierbarer Backup-Zielspeicher" am Produkt „certvia" (ISMS-Tool,
Multi-Tenant Next.js-16 / Prisma-7 / Postgres+RLS / Auth.js-v5). Repo: ~/Projects/ISMS-Tool, Branch `dev`.

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

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

1) PFLICHTLEKTÜRE:
   - docs/HANDOVER-DEV.md, docs/SPEC.md, docs/STAND-dev-branch.md
   - docs/KONZEPT-backup-target.md      ← dein Fahrplan
   - docs/KONZEPT-backup-restore.md §9  ← Verschlüsselung/Secrets-Kohärenz
   - Bestand ansehen: src/server/storage/backup-store.ts (BackupStore, S3-/Local-Store, createBackupStore)

2) AUFTRAG:
   Den Backup-Zielspeicher im Betreiber-Portal konfigurierbar machen + lokale (persistente) Option.
   a) DATENMODELL: PlatformSetting erweitern (backupTarget local|s3, backupLocalDir, backupS3Endpoint/
      Bucket/Region/AccessKey, backupS3SecretKeyEnc). Additive Migration (nullable, Default local).
   b) FACTORY: statisches `backupStore` → `getBackupStore(): Promise<BackupStore>`, liest PlatformSetting,
      entschlüsselt den S3-Key (secret-crypto). Präzedenz DB → Env (S3_*/BACKUP_LOCAL_DIR) → lokaler
      Default `.backups`. Cachen + bei Settings-Änderung invalidieren. Die 3 Nutzer umstellen:
      src/server/backup/export.ts, restore.ts, ops.ts.
   c) UI: Seite im Plattform-Portal (z. B. /admin/backup): Ziel wählen (Lokal/S3), Config, „Verbindung
      testen" (Probe put/get/remove). Gated requirePlatformFullAdmin + MFA-Step-up. Speichern via Action
      analog setPlatformMfaRequired (platformSetting.upsert); S3-Secret VOR dem Schreiben verschlüsseln.
   d) PERSISTENZ: docker-compose.coolify.yml — persistentes Volume `backups:` (wie pgdata/miniodata) in
      app+worker mounten (Pfad = backupLocalDir, z. B. /app/.backups).
   e) TESTS: scripts/test-backup-* erweitern (Store-Auflösung DB local/s3, Präzedenz, Test-Verbindung,
      fail-secure bei unvollständiger S3-Config, Export→Restore gegen beide Backends).

3) VERBINDLICHE REGELN:
   - S3-Secret NUR verschlüsselt in der DB (src/server/secret-crypto.ts: encryptSecret/decryptSecret) — nie Klartext.
   - Fail-secure: backupTarget=s3 mit unvollständiger Config → klarer Fehler, NICHT still auf lokal fallen.
   - Env-Fallback erhalten (Rückwärtskompatibilität bestehender Deployments).
   - BACKUP_ENC_KEY (Artefakt-Verschlüsselung) bleibt GETRENNT vom Zielspeicher — nicht vermischen.
   - RLS/Mandanten-Isolation der Artefakt-Keys (`<tenantId>/backups/…`) unverändert lassen.
   - Config-Bearbeitung nur Full-Admin + Step-up, auditiert.

4) ARBEITSWEISE:
   - Gate vor JEDEM Merge: npx tsc --noEmit · npm run lint · npm run build · ALLE scripts/test-*.ts.
   - migrate reset gegen lokale DB braucht Nutzer-Zustimmung (Prisma-Guard).
   - UI im Browser verifizieren: Ziel umschalten Lokal↔S3, „Verbindung testen", Export→Restore lokal.
   - DevOps: lane-backup-target → git merge --no-ff nach dev → Gate grün → Push auf BEIDE Remotes →
     docs/STAND-dev-branch.md pflegen.

5) NICHT TUN: kein Umbau am Auth-/RLS-Kern; keine Mehrfachziele/Offsite-Profile (Phase 2); Artefakt-
   Verschlüsselung (crypto.ts) nicht anfassen.

Erste Schritte: (a) Pflichtlektüre + backup-store.ts lesen, 10-Zeilen-Zusammenfassung + Fragen,
(b) PR-Plan (Schema+Migration, getBackupStore-Refactor, UI, Compose-Volume, Tests), (c) nach Freigabe
umsetzen. Warte nach (a)/(b) auf Bestätigung.