Zum Inhalt

Datenbank-Gegencheck UC00 – Schritt 6: Abgleich uc00-spezifikation.md

Stand: 01.08.2026 14:55 Branch: docs/einheitliche-kopfbereiche Status: Schritt 6 durchgeführt

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

Quellen:

  • docs/developer/uc00/uc00-spezifikation.md
  • backend/prisma/schema.prisma
  • backend/prisma/prisma-schema-diff.md
  • docs/developer/uc00/db-schema-istaufnahme-schritt-1.md
  • docs/developer/uc00/db-schema-abgleich-schritt-2.md
  • docs/developer/uc00/db-schema-abgleich-schritt-3-database-readme.md
  • docs/developer/uc00/db-schema-abgleich-schritt-4-prisma-schema-diff.md
  • docs/developer/uc00/db-schema-abgleich-schritt-5-supabase-rls-strategy.md

Ziel von Schritt 6

Ziel dieses Schritts ist der Abgleich der UC00-Spezifikation gegen das aktuelle Prisma-Schema und gegen die bisherigen Datenbank-Befunde aus Schritt 1 bis 5.

Der Fokus liegt auf:

  • Tabellenbezug,
  • Statusmodell,
  • Tenant-Onboarding,
  • InvitationToken-Struktur,
  • Recovery-Codes,
  • Notification-Templates,
  • Auth- und Log-Bezug,
  • Konsistenz der dokumentierten Datenmodell-Entscheide.

1. Pfadklärung

Der ursprünglich in der Prüfliste genannte Pfad:

docs/developer/uc00-spezifikation.md

ist im Branch stabilize-uc00-backend nicht mehr vorhanden.

Die aktuelle Datei liegt unter:

docs/developer/uc00/uc00-spezifikation.md

Bewertung:

  • Die Re-Strukturierung nach docs/developer/uc00/ ist umgesetzt.
  • Die Prüfliste sollte den neuen Pfad verwenden.
  • Alte Verweise auf docs/developer/uc00-spezifikation.md sollten geprüft und nachgezogen werden.

2. Kurzfazit

Die UC00-Spezifikation ist fachlich ausführlich und beschreibt den Tenant-Onboarding-Prozess sehr detailliert.

Gegenüber dem aktuellen Prisma-Schema bestehen aber mehrere harte Datenmodell-Abweichungen.

Besonders relevant sind:

  • Die UC00-Spezifikation erklärt Schritt 3 „Datenmodell“ als abgeschlossen.
  • Sie nennt recovery_codes und notification_templates als validiert.
  • Beide Tabellen existieren im aktuellen Prisma-Schema nicht.
  • Die UC00-Spezifikation verwendet weiterhin invitation_tokens.token_type.
  • token_type existiert im aktuellen Prisma-Schema nicht.
  • Die UC00-Spezifikation verweist teilweise auf ältere Datenbankannahmen, obwohl die Feldnamen bei Tenant/User teilweise bereits auf das neue Statusmodell angepasst wurden.

Damit ist die UC00-Spezifikation aktuell teilweise modernisiert, aber nicht vollständig konsistent mit backend/prisma/schema.prisma.

3. Konsistente Punkte

Folgende Punkte passen grundsätzlich zum aktuellen Prisma-Schema:

UC00-Spezifikation Prisma-Schema Bewertung
Tenant-Onboarding über tenants Tenant vorhanden Konsistent
Tenant-Admin über users User vorhanden Konsistent
Status Tenant.status = pending/active/deactivated TenantStatus vorhanden weitgehend konsistent
Status User.status = invited/active UserStatus vorhanden konsistent, Schema enthält zusätzlich suspended/deactivated
Rolle tenant_admin UserRole.tenant_admin vorhanden Konsistent
auth_log für Login-/2FA-Ereignisse AuthLog vorhanden Konsistent
audit_log für Änderungen AuditLog vorhanden Konsistent
system_log für E-Mail-Fehler SystemLog vorhanden Konsistent
invitation_tokens.user_id InvitationToken.userId vorhanden Konsistent
invitation_tokens.used_at InvitationToken.usedAt vorhanden Konsistent
invitation_tokens.revoked_at für erneute Einladung plausibel InvitationToken.revokedAt vorhanden Konsistent
Schulprofil-Felder in tenants viele Felder vorhanden grundsätzlich konsistent

4. Harte Abweichungen zum Prisma-Schema

4.1 recovery_codes ist in UC00 dokumentiert, aber nicht im Prisma-Schema vorhanden

Die UC00-Spezifikation fordert und beschreibt recovery_codes mehrfach:

  • Nachbedingung N5: Recovery-Codes wurden generiert und angezeigt.
  • Happy Path Schritt 10: 8 Recovery-Codes werden generiert und als bcrypt-Hash in recovery_codes gespeichert.
  • Geschäftsregeln G10 und G11 beschreiben Recovery-Code-Speicherung und Einmalanzeige.
  • Tabelle „Betroffene Datenbank-Tabellen“ enthält recovery_codes mit INSERT und UPDATE.
  • Schema-Delta Abschnitt 7 meldet recovery_codes als angelegt und validiert.
  • Testing enthält mehrere Recovery-Code-Testfälle.

Im aktuellen Prisma-Schema existiert jedoch kein Model RecoveryCode und keine Tabelle recovery_codes.

Bewertung:

  • Harte Inkonsistenz.
  • Entweder ist das Prisma-Schema unvollständig oder die UC00-Spezifikation ist veraltet.
  • Da Schritt 4 prisma-schema-diff.md recovery_codes nicht als aktuelle Prisma-Änderung enthält, ist eine fachliche Entscheidung nötig.

4.2 notification_templates ist in UC00 dokumentiert, aber nicht im Prisma-Schema vorhanden

Die UC00-Spezifikation fordert und beschreibt notification_templates mehrfach:

  • Geschäftsregel G14: E-Mail-Templates sind in der DB hinterlegt.
  • Betroffene Datenbank-Tabellen: notification_templates READ.
  • Offene Entscheide OE3: notification_templates-Tabelle, V1 nur DE, Migration ausgeführt.
  • Schema-Delta Abschnitt 7: notification_templates aktiv mit Templates.
  • Änderungshistorie v0.5: Datenmodell validiert.

Im aktuellen Prisma-Schema existiert kein Model NotificationTemplate und keine Tabelle notification_templates.

Bewertung:

  • Harte Inkonsistenz.
  • Diese Abweichung wurde bereits in Schritt 2 sichtbar und durch Schritt 6 bestätigt.
  • Es ist eine Entscheidung nötig: Tabelle in Prisma ergänzen oder UC00-Spezifikation korrigieren.

4.3 invitation_tokens.token_type ist in UC00 dokumentiert, aber nicht im Prisma-Schema vorhanden

Die UC00-Spezifikation nennt token_type mehrfach:

  • Happy Path Schritt 4: invitation_token (token_type = 'admin')
  • Betroffene Datenbank-Tabellen: token_type = 'admin'
  • Offene Frage OE1: invitation_tokens: nullable + token_type
  • Schema-Delta Abschnitt 7: +token_type

Im aktuellen Prisma-Schema enthält InvitationToken kein Feld tokenType und keine Zuordnung token_type.

Das aktuelle Prisma-Schema enthält stattdessen:

  • tenantId
  • userId
  • token
  • invitedById
  • invitedEmail
  • invitedFirstName
  • invitedLastName
  • invitedRole
  • status
  • expiresAt
  • usedAt
  • revokedAt
  • createdAt

Bewertung:

  • Harte Inkonsistenz.
  • prisma-schema-diff.md dokumentiert die InvitationToken-Korrektur ohne token_type.
  • UC00-Spezifikation sollte hier nachgezogen oder Prisma bewusst erweitert werden.

4.4 Status „Datenmodell abgeschlossen“ ist nicht haltbar

Die UC00-Spezifikation setzt in der Status-Übersicht:

  • Schritt 3 Datenmodell: abgeschlossen
  • Kommentar: recovery_codes + notification_templates validiert

Da beide Tabellen im aktuellen Prisma-Schema fehlen, ist dieser Status aus Sicht des Prisma-Gegenchecks nicht belastbar.

Bewertung:

  • Der Status sollte mindestens auf „offen“, „in Prüfung“ oder „abweichend“ geändert werden, bis die Entscheidung zu den fehlenden Tabellen getroffen ist.

5. Teilweise Abweichungen oder Prüfkandidaten

5.1 Plan-Typen

Die Vorbedingungen nennen Plan-Typen:

  • Starter
  • Professional
  • Enterprise

Das aktuelle Prisma-Schema enthält zusätzlich:

  • test

Die Wireframe-Entscheide OE7 nennen bereits Plan-Kacheln mit:

  • Test
  • Starter
  • Professional
  • Enterprise

Bewertung:

  • Teilweise konsistent.
  • Abschnitt 1.3 Vorbedingungen sollte test entweder bewusst ausschliessen oder ergänzen.

5.2 Tenant-Status

Die Spezifikation nutzt:

  • pending
  • active
  • deactivated

Das Prisma-Schema enthält:

  • pending
  • active
  • suspended
  • deactivated

Bewertung:

  • Für UC00 grundsätzlich ausreichend.
  • suspended sollte entweder als nicht für UC00 relevant dokumentiert oder in Statusregeln ergänzt werden.

5.3 User-Status

Die Spezifikation nutzt:

  • invited
  • active

Das Prisma-Schema enthält:

  • invited
  • active
  • suspended
  • deactivated

Bewertung:

  • Für UC00 grundsätzlich ausreichend.
  • suspended und deactivated sollten als ausserhalb Happy Path oder spätere Verwaltungsfälle dokumentiert werden.

5.4 Schulprofil-Felder

Die Spezifikation fordert:

  • Schulname
  • Strasse
  • PLZ
  • Stadt
  • Telefon fest oder mobil
  • Kontaktperson
  • Kontakt-E-Mail
  • Standard-Währung
  • optional MwSt-Nummer
  • optional Logo

Das aktuelle Prisma-Model Tenant enthält entsprechende Felder:

  • name
  • address
  • postalCode
  • city
  • contactPhoneFixed
  • contactPhoneMobile
  • contactPerson
  • contactEmail
  • defaultCurrency
  • vatNumber
  • logoPath

Bewertung:

  • Grundsätzlich konsistent.
  • Die Spezifikation sollte bei Feldnamen konsequent die aktuellen DB-Feldnamen verwenden.

5.5 E-Mail-Eindeutigkeit

Geschäftsregel G1 sagt:

  • Jede E-Mail-Adresse kann nur einmal als Tenant-Admin registriert werden.

Das Prisma-Schema setzt User.email global eindeutig.

Bewertung:

  • Für G1 konsistent.
  • Die weitergehende Folge ist aber: E-Mail-Adressen sind systemweit eindeutig, nicht nur für Tenant-Admins.
  • Diese Architekturentscheidung sollte ausdrücklich dokumentiert werden.

6. Abgleich der betroffenen Tabellen aus Abschnitt 4 der UC00-Spezifikation

Tabelle aus UC00 Prisma-Model vorhanden? Bewertung
tenants Ja vorhanden, Felder weitgehend passend
users Ja vorhanden, Statusmodell passend
invitation_tokens Ja vorhanden, aber token_type fehlt in Prisma
recovery_codes Nein harte Abweichung
notification_templates Nein harte Abweichung
auth_log Ja vorhanden
audit_log Ja vorhanden
system_log Ja vorhanden

7. Auswirkungen auf UC00-Umsetzung

7.1 Ohne recovery_codes

Folgende UC00-Funktionen sind mit dem aktuellen Prisma-Schema nicht vollständig abbildbar:

  • Generierung von 8 Recovery-Codes pro Tenant-Admin
  • Speicherung der Recovery-Codes als Hash
  • einmalige Einlösung eines Recovery-Codes
  • Testfälle T03 und T07
  • Fehlerfall F8
  • Alternative Pfade A5 und A6 teilweise

7.2 Ohne notification_templates

Folgende UC00-Funktionen sind mit dem aktuellen Prisma-Schema nicht vollständig datenbankgestützt abbildbar:

  • Template invite_admin
  • Template 2fa_reset
  • dokumentierter DB-READ auf notification_templates
  • Geschäftsregel G14
  • OE3 und Schema-Delta Abschnitt 7

E-Mail-Versand könnte technisch auch ohne DB-Templates funktionieren, zum Beispiel mit statischen Templates im Code. Das wäre aber nicht konsistent mit der aktuellen UC00-Spezifikation.

7.3 Ohne token_type

Falls InvitationToken mehrere Token-Arten unterscheiden soll, fehlt dafür im Prisma-Schema ein explizites Feld.

Mögliche Alternativen:

  • Token-Art über invitedRole ableiten.
  • Token-Art nicht mehr fachlich unterscheiden.
  • token_type als Feld oder Enum wieder in Prisma aufnehmen.

Diese Entscheidung ist aktuell offen.

8. Bewertung Schritt 6

Ergebnis

Schritt 6 ist durchgeführt.

Die UC00-Spezifikation ist nicht vollständig konsistent mit dem aktuellen Prisma-Schema.

Schweregrad

Bereich Bewertung
Tenant- und User-Grundmodell weitgehend konsistent
Schulprofil-Felder weitgehend konsistent
Statusmodell teilweise konsistent, aber nicht vollständig erklärt
invitation_tokens teilweise abweichend wegen token_type
recovery_codes harte Abweichung
notification_templates harte Abweichung
Datenmodell-Status „abgeschlossen“ nicht haltbar gegen Prisma-Ist-Stand
Testplanung enthält Testfälle für nicht vorhandene Tabelle recovery_codes

9. Empfohlene Korrekturmassnahmen

9.1 Kurzfristig

  • [ ] Status-Übersicht Schritt 3 „Datenmodell“ in der UC00-Spezifikation korrigieren oder mit Warnhinweis versehen.
  • [ ] Entscheiden, ob recovery_codes in Prisma ergänzt oder aus UC00 entfernt / anders gelöst wird.
  • [ ] Entscheiden, ob notification_templates in Prisma ergänzt oder E-Mail-Templates codebasiert dokumentiert werden.
  • [ ] Entscheiden, ob invitation_tokens.token_type benötigt wird.
  • [ ] Abschnitt 4 „Betroffene Datenbank-Tabellen“ an das aktuelle Prisma-Schema angleichen.
  • [ ] Abschnitt 7 „Schema-Delta“ an das aktuelle Prisma-Schema angleichen.

9.2 Danach

  • [ ] Testfälle T03, T07 und F8 gegen die Entscheidung zu recovery_codes prüfen.
  • [ ] Geschäftsregeln G10, G11 und G14 prüfen.
  • [ ] OE1 und OE3 auf den tatsächlichen Prisma-Stand aktualisieren.
  • [ ] Änderungshistorie mit Hinweis auf den Datenbank-Gegencheck ergänzen.
  • [ ] Veraltete Verweise auf den alten Pfad docs/developer/uc00-spezifikation.md suchen und korrigieren.

10. Offene Entscheidungsfragen

  1. Sollen recovery_codes als eigene Tabelle ins Prisma-Schema aufgenommen werden?
  2. Sollen notification_templates als eigene Tabelle ins Prisma-Schema aufgenommen werden?
  3. Soll InvitationToken ein Feld tokenType / token_type erhalten?
  4. Falls nein: Wie wird fachlich zwischen Admin-Einladung, Kunden-Einladung und 2FA-Reset unterschieden?
  5. Ist User.email bewusst systemweit eindeutig für alle Rollen?
  6. Soll der Status „Datenmodell abgeschlossen“ zurückgenommen werden, bis diese Fragen entschieden sind?

11. Nächster empfohlener Schritt

Als nächster Prüfschritt sollte docs/developer/uc-vorentscheide/uc-kunden-vorentscheide.md geprüft werden.

Ziel:

  • prüfen, ob die dort dokumentierten Vorentscheide noch mit dem aktuellen Prisma-Schema zusammenpassen,
  • besonders in Bezug auf Kunden, Einladungen, Notification-Templates, Recovery-Codes, Tenant-Isolation und spätere UseCases.