Zum Inhalt

DiveLogix360 – UC00-Prisma-v4-Zielschema

Stand: 10.08.2026 20:00 Branch: main Status: Aktiv

Datum, Uhrzeit Version Änderung Autor
10.08.2026 20:00 1.5 Sicheren UC00-Merge-Stand nach main übernommen und Branch-Nachführung ergänzt Codex
10.08.2026 19:46 1.4 Erfolgreichen Backend-Build, AWS-KMS-TOTP-Pfad und kontrolliert ausgerollte Vertragskontaktmigration nachgeführt Codex
09.08.2026 17:32 1.3 E-Mail-Identitätsmigration und global eindeutige offene Einladungsadresse als ausgerollten PostgreSQL-Schutz nachgeführt Codex
09.08.2026 16:25 1.2 Erfolgreichen Entwicklungsdatenbank-Rollout, Basis-Seed und grundlegende RLS-Laufzeitprüfung nachgeführt Codex
09.08.2026 15:22 1.1 Tenantkonsistente Relationen, initiale Migration, PostgreSQL-Schutzmigration und statischen Prüfnachweis ergänzt Codex
09.08.2026 14:41 1.0 Fachlich und technisch abgestimmtes UC00-Zielschema sowie verbleibende Durchsetzungsregeln dokumentiert Codex

Zweck: Nachweis der Herleitung, Abdeckung und technischen Validierung des Prisma-v4-Zielschemas für UC00.
Abgrenzung: Das Dokument bestätigt das eingecheckte Anwendungsmodell und fasst den technischen Prüfstand zusammen. Der reproduzierbare Ausführungsnachweis für Entwicklungsdatenbank, Seed und grundlegende Row-Level Security steht getrennt im UC00-Datenbank-Iststand; Backend, Produktion, Infrastruktur und vollständige Tests sind damit nicht freigegeben.

1. Führende Grundlagen

Das Zielschema wurde aus folgenden verbindlichen Quellen abgeleitet:

Die technische Wahrheit des Anwendungsmodells ist backend/prisma/schema.prisma. Dieses Dokument erläutert dessen UC00-Abdeckung, dupliziert aber nicht sämtliche Felder.

2. Modellbereiche

Bereich Zentrale Modelle und Enums Abgedeckte Regelbereiche
Tenant und Benutzer Tenant, User, TenantStatus, UserStatus, UserRole Globale Benutzeridentität, rechtliche Tenant-Daten, Lifecycle, verschlüsseltes TOTP-Geheimnis und Aufbewahrung
Operatives Schulprofil TenantProfile, CurrencyCode Trennung von Vertragsdaten und operativem Profil, einzeln deaktivierte Veröffentlichungsfreigaben und fortsetzbare Entwürfe
Onboarding TenantOnboarding, OnboardingStep, OnboardingStepKey, OnboardingStepStatus Persistente Gesamt- und Schrittstatus für school_profile, contact_details, first_employee und confirmation
Vertrag TenantContract, ContractAcceptanceToken, ContractDocument und Vertragsenums Parteiensnapshot, Versionierung, sechs Statuswerte, elektronische und externe Abschlüsse, Hash, Objektschlüssel, Scan und Prüfung
Authentifizierung InvitationToken, RefreshToken, RecoveryCode, TwoFactorSession Nur gehashte Token und Codes, Widerruf, Ablauf, zentrale kurzlebige Zwei-Faktor-Sitzungen und Aufbewahrungsklassen
Offboarding TenantOffboarding, TenantExport, LegalHold Sofortige Sperrung, 30 Tage Exportzugang, operative Löschung spätestens nach 90 Tagen und begründete Aufbewahrungssperren
Protokollierung AuthLog, AuditLog, AccessLog, SystemLog, DeletionLog, NotificationLog, AuditSeal Getrennte Kontexte, standardisierte Ergebnisse und Schweregrade, Datenminimierung, Korrelations-IDs und tägliche Sammelnachweise
Support und Löschung SupportAccessGrant, RetentionRun, RetentionClass Zeitbegrenzte Support- und Notfallzugriffe sowie kontrollierte, nachvollziehbare Löschläufe für RF-01 bis RF-22

3. Wesentliche Modellregeln

  • User.email bleibt global eindeutig. Die Anwendung speichert ausschliesslich die getrimmte und kleingeschriebene Adresse.
  • Ein Benutzer gehört in V1 höchstens einem Tenant an; ein Superadmin besitzt keinen Tenant.
  • Die vorbereitende Tenant-Anlage beginnt mit contract_pending. onboarding ist erst nach akzeptiertem oder kontrolliert erfasstem Vertrag zulässig.
  • Rechtliche Vertragsparteidaten verbleiben im Tenant; operative und veröffentlichbare Angaben liegen ausschliesslich im Eins-zu-eins-Modell TenantProfile.
  • Unvollständige Profilentwürfe sind speicherbar. Pflichtfelder und Schrittfolge werden beim Schrittabschluss serverseitig geprüft.
  • Vertragsversionen und Dokumentmetadaten sind getrennt modelliert. Vollständige PDF-Inhalte werden nicht in SQL gespeichert.
  • Eine vorherige Vertragsversion erhält superseded erst nach erfolgreicher Annahme der Nachfolgeversion.
  • Einladungs-, Vertrags-, Refresh- und Zwei-Faktor-Sitzungstoken sowie Wiederherstellungscodes werden nur als Hash gespeichert.
  • Das TOTP-Geheimnis für zeitbasierte Einmalpasswörter wird nur verschlüsselt zusammen mit der Schlüsselversion gespeichert; der Schlüssel liegt ausserhalb der SQL-Datenbank.
  • Protokolle enthalten nur positiv gelistete Metadaten. Löschprotokolle enthalten keinen Snapshot gelöschter Daten; Versandprotokolle enthalten weder Nachrichtentext noch Empfängeradresse im Klartext.
  • Aufbewahrungsklassen verwenden die verbindlichen IDs RF-01 bis RF-22. LegalHold dokumentiert begründete Ausnahmen; RetentionRun dokumentiert Löschläufe.
  • Direkte Beziehungen zwischen Tenant-Objekten verwenden soweit modellierbar zusammengesetzte Fremdschlüssel aus Objekt-ID und tenant_id. Dadurch kann beispielsweise ein Vertragsdokument, Equipmentdetail oder Workflow nicht auf ein Objekt eines anderen Tenants verweisen.

4. Ausserhalb von Prisma durchzusetzende Regeln

Prisma beschreibt Modelle, Relationen und portable Constraints. Folgende Regeln benötigen zusätzlich Migrationen, Backend oder Infrastruktur:

Regel Durchsetzung
E-Mail-Normalform und globale Konfliktantwort Datenbank-Check, globaler Benutzerindex und partieller Eindeutigkeitsindex für offene Einladungen sind migriert; Backend und kontrollierte Konfliktantwort umgesetzt, vollständige End-to-End-Tests offen
Superadmin ohne Tenant und Tenant-Benutzer mit Tenant Datenbank-Check ist migriert; Autorisierungslogik und Tests bleiben offen
Höchstens ein aktueller akzeptierter Vertrag je Tenant Partieller eindeutiger PostgreSQL-Index ist migriert; transaktionaler Statuswechsel und Tests bleiben offen
Vertragssperre vor Tenant-Admin-Einladung Backend-Transaktion und OpenAPI-Fehler 409 contract_not_accepted
Tokenlaufzeiten von sieben Tagen beziehungsweise 72 Stunden Datenbank-Checks sind migriert; Backend-Erzeugung, Ablaufprüfung und Tests bleiben offen
PDF-Grenze, Quarantäne, Malware-Prüfung und verschlüsselte Objektablage PDF-, 10-MB-, Hash- und Scanstatus-Checks sind migriert; Uploaddienst, ClamAV, Hetzner Object Storage und AWS Key Management Service bleiben offen
Schrittfolge, Pflichtfelder, Draft-Wiederaufnahme und idempotenter Abschluss Backend-Service und Integrationsprüfungen
Row-Level Security (RLS, zeilenbasierte Zugriffskontrolle) Rollen, Grants, Kontextfunktionen, Indizes und befehlsbezogene Policies sind ausgerollt; acht grundlegende Laufzeitprüfungen waren nach der dritten Migration erfolgreich, die Wiederholung nach der vierten sowie vollständige Ressourcen-, Pooling- und Sicherheitstests bleiben offen
Append-only-Protokolle und eingeschränkte Löschung Runtime-UPDATE ist entzogen; harte Plattformlöschung benötigt Retention- und Request-Kontext; Laufzeittests bleiben offen
Fristberechnung und koordinierte Löschung Täglicher Retention-Job, Objektspeicher- und Providerintegration
Verschlüsselung und Schlüsselrotation Anwendungsdienst, AWS Key Management Service und Betriebsnachweise

Diese Trennung ist beabsichtigt. Eine im Schema vorhandene Spalte beweist noch nicht, dass die zugehörige Fachregel im Betrieb wirksam ist.

5. Technische Prüfung

Prüfung Ergebnis
prisma format Erfolgreich am 09.08.2026
prisma validate Erfolgreich am 09.08.2026
prisma generate Erfolgreich mit Prisma Client 5.22.0 am 09.08.2026
Initiale Prisma-v4-Migration Aus leerem Stand erzeugt; 35 Tabellen, Indizes und Fremdschlüssel enthalten
PostgreSQL-Schutzmigration Rollen, 52 Fach- und Sicherheitsconstraints, RLS für 35 Tabellen, befehlsbezogene Policies und minimale Grants enthalten
E-Mail-Identitätsmigration Partieller globaler Eindeutigkeitsindex verhindert parallele offene Einladungen derselben normalisierten Adresse und erhält widerrufene beziehungsweise abgelaufene Historie
npm run prisma:migrations:validate Erfolgreich am 09.08.2026; Tabellenabdeckung, Rollen, Fristen, RLS-Schutzliste und tenantkonsistente Fremdschlüssel statisch geprüft
Backend-Build nach Client-Erzeugung Erfolgreich am 10.08.2026; die zuvor dokumentierten 17 Umstellungsfehler sind behoben
Migration gegen Entwicklungsdatenbank Alle vier Migrationen einschliesslich 20260809180000_uc00_contract_party_contact_fields erfolgreich angewendet
Row-Level-Security-Prüfung Statisch erfolgreich und acht grundlegende Laufzeitprüfungen nach der dritten Migration bestanden; Wiederholung nach der vierten Migration und vollständige RLS-Testmatrix bleiben offen
Seed Drei globale Benachrichtigungsvorlagen und vier Plan-Features erfolgreich und idempotent angelegt; keine Personen-, Tenant- oder Geheimnisdaten

Der erfolgreiche Backend-Build und die vier angewendeten Migrationen bestätigen die technische Übersetzbarkeit und den reproduzierbaren Entwicklungsdatenbankstand, aber nicht die fachliche Vollständigkeit oder Produktionsreife. Weitere Backendpfade und die vollständigen Laufzeitnachweise bleiben offen.

6. Ergebnis

Das eingecheckte Prisma-Schema ist das fachlich und technisch abgestimmte Prisma-v4-Zielschema für UC00. Die 17 Regelbereiche der Nachverfolgbarkeitsmatrix besitzen damit eine eindeutige Zielabbildung im Datenmodell oder eine ausdrücklich benannte Durchsetzung ausserhalb von Prisma.

Die initiale Prisma-v4-Migration, die getrennte PostgreSQL-Schutzmigration, die E-Mail-Identitätsmigration und die additive Vertragskontaktmigration sind erzeugt, statisch geprüft und kontrolliert gegen die Entwicklungsdatenbank ausgerollt. Der sichere Basis-Seed ist nachgewiesen; acht grundlegende Datenbank-Laufzeitprüfungen waren nach der dritten Migration erfolgreich und müssen nach der vierten Migration wiederholt werden. Getrennte Anwendungsclients, der transaktionsgebundene Datenbankkontext, die globale E-Mail- und Einladungstokenlogik sowie der AWS-KMS-TOTP-Pfad sind umgesetzt. Als Nächstes folgen Integration des sicheren Vertragsvorbereitungspakets und der vollständige Vertragsablauf.