Schemaentscheidungen Phase 2: UC00–UC09, UC-SA und UC18

Stand: 01.08.2026 14:55 Branch: docs/einheitliche-kopfbereiche Status: Entscheidungen für Schema-Bereinigung

Datum, Uhrzeit	Version	Änderung	Autor
01.08.2026 14:55	1.0	Kopfbereich vereinheitlicht	David Mittig

Ziel

Dieses Dokument hält die Entscheidungen fest, die vor der Aktualisierung des Prisma-Schemas getroffen wurden.

1. Grundentscheid

Entscheidung 1: Prisma ist technische Wahrheit

backend/prisma/schema.prisma wird für die Bereinigungsphase als technische Wahrheit definiert.

Konsequenz:

• Das Prisma-Schema wird gezielt erweitert.
• Dokumentation und SQL-Scripte werden danach auf Prisma ausgerichtet.
• Ältere Annahmen aus db-schema.md, database/README.md und GEM-Reviews gelten nicht mehr automatisch als führend.

2. UC00-Entscheidungen

Entscheidung 2: recovery_codes wird ergänzt

RecoveryCode wird als Prisma-Model ergänzt.

Begründung:

• UC00 fordert Recovery-Codes.
• GEM 12 und GEM 13 behandeln Recovery-Codes als sicherheitsrelevant.
• AuthService referenziert Recovery-Codes bereits.

Schemaentscheidung:

• Speicherung nur gehasht über codeHash.
• Einmalige Nutzung über usedAt.
• Tenant-Bezug über tenantId.
• User-Bezug über userId.

Entscheidung 3: notification_templates wird ergänzt

NotificationTemplate wird als Prisma-Model ergänzt.

Begründung:

• UC00 und GEM 14 beschreiben E-Mail-Templates.
• UC07 Benachrichtigungen benötigt wiederverwendbare Templates.
• Codebasierte Templates wären möglich, würden aber mehrere bestehende Dokumententscheidungen widersprechen.

Schemaentscheidung:

• Templates sind systemweit.
• V1-Sprache: de.
• Tenant-spezifische Templates bleiben V2.

Entscheidung 4: InvitationToken.tokenType wird ergänzt

InvitationToken erhält ein Feld tokenType mit Enum InvitationTokenType.

Begründung:

• UC00 unterscheidet Admin-Einladung und weitere Token-Kontexte.
• UC06 Kundenportal benötigt eine saubere Abgrenzung.
• 2FA-Reset / Recovery kann später ohne neues Tokenmodell erweitert werden.

V1-Werte:

• tenant_admin_invite
• user_invite
• customer_invite
• twofa_reset

3. Benutzer- und Kundenentscheidungen

Entscheidung 5: User.email bleibt global eindeutig

Die globale Eindeutigkeit von User.email bleibt bestehen.

Begründung:

• Das bestehende Prisma-Schema ist bereits so modelliert.
• Authentifizierung über E-Mail ist dadurch eindeutig.
• Multi-Tenant-Mitgliedschaft für Taucher kommt erst V2 über customer_tenant_map oder ein neues Mitgliedschaftsmodell.

Konsequenz:

• Backend-Prüfungen müssen global prüfen, nicht tenantbezogen.
• Dokumentation muss diesen Entscheid explizit nennen.

Entscheidung 6: Customer erhält optionale User-Verknüpfung

Customer.userId wird optional ergänzt.

Begründung:

• UC06 Kundenportal braucht eine saubere Verbindung zwischen Kundendatensatz und Login-User.
• V1 bleibt einfach: Ein Kunde kann optional einen Portal-User haben.
• V2 kann Mehrmandantenfähigkeit über customer_tenant_map erweitern.

4. UC01-Entscheidungen

Entscheidung 7: EquipmentType wird erweitert

EquipmentType wird an UC01 angenähert.

Zusätzliche Werte:

• bcd
• mask
• fins
• compass
• lamp
• weight
• smb
• unknown

Bestehende Werte bleiben aus Kompatibilitätsgründen erhalten:

• jacket
• wetsuit
• torch

Entscheidung 8: Datenqualität wird ergänzt

Equipment.dataQualityStatus wird ergänzt.

Werte:

• complete
• incomplete
• needs_review

Entscheidung 9: Zuordnungstyp wird ergänzt

Equipment.assignmentType wird ergänzt.

Werte:

• internal
• customer
• unassigned

Entscheidung 10: Inventarnummer und Anzeige-/Praxisfelder werden ergänzt

Folgende Felder werden ergänzt:

• inventoryNumber
• displayName
• location
• purchaseDate
• colorMarking
• condition

Entscheidung 11: Strukturierte Notizen und Identifier werden ergänzt

Ergänzt werden:

• EquipmentNote
• EquipmentIdentifier

Begründung:

• UC01 fordert strukturierte Notizen.
• QR-Code und spätere UC18-Prozesse benötigen stabile Identifier.

5. UC03-Entscheidungen

UC03 ist V1 und benötigt eigene Tabellen.

Ergänzt werden:

• FillSubscription
• FillCard
• FillCardTransaction

V1 bleibt bewusst einfach:

• keine vollständige Rechnungslogik,
• keine orders-Tabelle,
• keine komplexe Preisengine.

6. UC04-Entscheidung

UsecaseType wird erweitert.

Zusätzliche Werte:

• regulator_service
• inhouse_service
• fill_subscription

7. UC18-Entscheidung

UC18 bleibt V2.

Nicht ergänzt in V1:

• rental_transactions
• rental_items
• rental_condition_logs

Konsequenz:

• Kein Verleihstatus direkt in equipment.
• UC18 wird später über eigene Tabellen ergänzt.
• V1-Equipment-Core muss stabil und historisierbar bleiben.

8. Nicht entschiedene oder bewusst verschobene Punkte

• organizations bleibt V2.
• customers.organization_id wird in V1 nicht ergänzt.
• orders / bill_to bleiben ausserhalb V1.
• customer_tenant_map bleibt V2.
• vollständige Reporting-Tabellen für UC09 werden in V1 nicht ergänzt.

9. Nacharbeit nach Schemaänderung

Nach der Prisma-Aktualisierung müssen nachgezogen werden:

• docs/developer/db-schema.md,
• database/README.md,
• docs/index.md,
• docs/management/roadmap.md,
• UC00-Spezifikation,
• UC01-Spezifikation,
• UC-Vorentscheide,
• GEM-Reviews.