# #003 Datenmodell und Migrationen
**Status:** erledigt
**Meilenstein:** v0.1.0
**Labels:** datenbank
**Geschätzt:** 3 h   **Tatsächlich:** 0 h 10 min

## Ziel
Prisma-Schema für alle Phasen (Hosts, Gruppen, Personen, Schlüssel, Verwendungen, Host-Keys, Vorgänge, Protokoll), erste Migration, Seed.

## Aufgaben
- [x] Schema mit deutschen Bezeichnern (siehe `CLAUDE.md`)
- [x] Datenbankregeln (CHECK, Trigger) für das, was auch an der Service-Schicht vorbei gelten muss
- [x] Seed: Notfall-Admin, eingebaute Vorlagen (Demo-Daten folgen mit #008)
- [x] Test-Datenbank-Setup für Vitest

## Akzeptanzkriterien
- [x] Migration läuft auf leerer Datenbank
- [x] Tests für die Datenbankregeln

## Abhängigkeiten
#001

## Notizen / Entscheidungen
- **Protokoll-Hash in der Datenbank berechnet** (Trigger), nicht in der Anwendung: so kann niemand eine Zeile ohne Verkettung einfügen. Die ID wird erst unter einer Advisory-Sperre vergeben, sonst bricht die Kette bei gleichzeitigem Schreiben (Test mit 20 parallelen Einträgen).
- **TRUNCATE des Protokolls** nur mit `SET LOCAL sshkv.test_modus = 'ja'` – ausschließlich für die Testhilfe. Ein Datenbank-Superuser kann Trigger immer abschalten; dagegen hilft die Hash-Kette (Prüfung findet die manipulierte Zeile) und später der Syslog-Export (#027).
- **Zielbenutzer, Adresse und Private-Key-Pfad per CHECK eingeschränkt:** Diese Werte landen in Shell-Skripten auf den Hosts. Quotierung bleibt Pflicht, aber was gar nicht erst in die Datenbank kommt, kann nichts anrichten.
- **TOTP-Geheimnis mit `SSHKV_APP_SECRET` verschlüsselt,** nicht mit dem Master-Key: geprüft wird es im Webprozess, und der Master-Key bleibt im Worker.
- Ein Host-Key-Wechsel ist eine neue Zeile `AUSSTEHEND` neben der vertrauten; je Host und Algorithmus höchstens ein vertrauter Key (partieller Index).