Zum Inhalt

DiveLogix360 – UC00-Prisma-v4-Zielschema

Stand: 14.10.2026 13:32 Branch: main Status: Aktiv

Änderungshistorie anzeigen

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 NotificationLog verweist seit ADR-024 optional und tenantgebunden auf die versendete Einladung; 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; neun Datenbankschutzprüfungen waren am 14.10.2026 nach der sechsten Migration erfolgreich; die Runtime-Logins besitzen keine direkten Rechte; 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
Einladungsverweis-Migration 20261012231500_uc00_notification_log_invitation_link Am 12.10.2026 gemäss ADR-024 erstellt: eindeutige Kombination id/tenant_id auf invitation_tokens, Feld notification_log.invitation_token_id mit tenantgebundenem Fremdschlüssel (ON DELETE SET NULL nur für den Verweis, PostgreSQL 15 oder neuer), Indizes für Provider-Message-ID und Einladungsverweis, erweiterte Prüfregel für tenantlose Einträge; prisma validate, prisma generate, Build und 30 Unit-Tests in 7 Testdateien erfolgreich; am 12.10.2026 mit prisma migrate deploy auf die Entwicklungsdatenbank angewendet
Migration gegen Entwicklungsdatenbank Alle sechs Migrationen einschliesslich 20261014111600_uc00_revoke_login_direct_privileges erfolgreich angewendet (12.10.2026)
Row-Level-Security-Prüfung Statisch erfolgreich; neun Datenbankschutzprüfungen am 14.10.2026 nach der sechsten Migration bestanden; vollständige RLS-Testmatrix bleibt 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, die additive Vertragskontaktmigration und die Einladungsverweis-Migration (ADR-024) sind erzeugt, statisch geprüft und kontrolliert gegen die Entwicklungsdatenbank ausgerollt. Der sichere Basis-Seed ist nachgewiesen; neun Datenbankschutzprüfungen waren am 14.10.2026 nach der sechsten Migration erfolgreich. 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.

Änderungshistorie

Datum, Uhrzeit Version Änderung Autor
14.10.2026 13:32 1.9 Datenbankstand nachgeführt: sechs Migrationen und neun Datenbankschutzprüfungen (14.10.2026) Claude
13.10.2026 00:34 1.8 Fünfte Migration als angewendet nachgeführt; Build, Unit-Tests und Datenbankschutzprüfungen vom 12./13.10.2026 ergänzt; Zusammenfassung in Abschnitt Nächste Schritte angepasst Claude
12.10.2026 23:10 1.7 Fünfte Migration für den Einladungsverweis im Versandprotokoll gemäss ADR-024 aufgenommen Claude
12.10.2026 09:58 1.6 Änderungshistorie ans Dokumentende verschoben und Sprunglink «Änderungshistorie anzeigen» unter dem Kopf ergänzt (einheitlicher Dokumentaufbau gemäss AGENTS.md) Claude
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