Zum Inhalt

DiveLogix360 – UC00-Datenbank-Iststand

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

Datum, Uhrzeit Version Änderung Autor
10.08.2026 20:00 1.4 Sicheren UC00-Merge-Stand nach main übernommen und Branch-Nachführung ergänzt Codex
10.08.2026 19:46 1.3 Erfolgreichen Backend-Build sowie kontrollierten Rollout und Inventarnachweis der vierten Migration nachgeführt Codex
09.08.2026 17:32 1.2 E-Mail-Schutzmigration ausgerollt, Datenbankinventur aktualisiert und globale Einladungsadresse als achte Laufzeitprüfung nachgewiesen Codex
09.08.2026 16:40 1.1 Getrennte Prisma-Runtime-Clients und Kontextwrapper als implementierten, noch nicht provisionierten Anwendungspfad abgegrenzt Codex
09.08.2026 16:25 1.0 Kontrollierten Neuaufbau der Entwicklungsdatenbank, Basis-Seed und grundlegende RLS-Laufzeitprüfung dokumentiert Codex

Zweck: Reproduzierbarer Nachweis des tatsächlich ausgerollten UC00-Datenbankstands in der Entwicklungsumgebung.
Abgrenzung: Der Nachweis bestätigt weder eine Produktionsfreigabe noch die vollständige Backend-, Sicherheits- oder RLS-Testabdeckung.

1. Geprüfte Ausgangslage

Vor der Veränderung wurde die Entwicklungsdatenbank nur lesend inventarisiert. Der alte Stand enthielt:

  • 22 Anwendungstabellen ohne Prisma-Migrationshistorie;
  • keine Tenants, Benutzer, Vertragsdokumente oder sonstigen fachlichen beziehungsweise personenbezogenen Datensätze;
  • drei globale Benachrichtigungsvorlagen und vier Plan-Features als einzige Referenzdaten.

Die sieben Referenzdatensätze entsprachen bereits eingecheckten historischen Seed-Quellen. Weil keine zu erhaltenden Fach- oder Personendaten vorlagen, war ein kontrollierter Neuaufbau aus der freigegebenen Migrationsfolge vertretbar. Der Neuaufbau wurde erst nach dieser Prüfung mit prisma migrate reset --force ausgeführt.

2. Ausgerollte Migrationsfolge

Die Supabase-Entwicklungsdatenbank verwendet PostgreSQL 17.6. Folgende eingecheckte Migrationen wurden vollständig und ohne Rollback angewendet:

Reihenfolge Migration Inhalt
1 20260809145000_uc00_prisma_v4_initial Prisma-v4-Initialschema mit 35 Fachtabellen, Relationen, Indizes und Fremdschlüsseln
2 20260809151500_uc00_database_guardrails PostgreSQL-Constraints, drei UC00-Rollen, minimale Rechte, Kontextfunktionen sowie ENABLE und FORCE ROW LEVEL SECURITY
3 20260809165000_uc00_email_identity_guardrails Partieller globaler Eindeutigkeitsindex für gültige offene Einladungen; abgelaufene Einladungen werden vor der Indexerstellung statusgerecht überführt
4 20260809180000_uc00_contract_party_contact_fields Additive Vertragskontaktfelder contract_contact_name und contract_contact_email am Tenant

prisma migrate status bestätigt am 10.08.2026, dass Datenbank und alle vier eingecheckten Migrationen übereinstimmen.

3. Basis-Seed

Der Basis-Seed wurde auf nicht personenbezogene, versionierte Referenzdaten begrenzt. Er erzeugt idempotent:

  • drei globale deutsche Benachrichtigungsvorlagen;
  • vier Plan-Features für den vorbereiteten Test-, Starter-, Professional- und Enterprise-Umfang.

Benutzer, Tenants, Passwörter, Einladungs-, Vertrags- oder Authentifizierungstoken werden nicht automatisch erzeugt. Fachliche Testdaten erhalten einen getrennten und kontrollierten Aufbau im Rahmen der vertikalen UC00-Implementierung.

4. Nachgewiesener Iststand

Merkmal Nachgewiesener Stand
Tabellen 36 einschliesslich _prisma_migrations; davon 35 Fachtabellen
Migrationshistorie 4 erfolgreich abgeschlossene Migrationen
Nicht leere Tabellen 3: Migrationshistorie, Benachrichtigungsvorlagen und Plan-Features
Datensätze 11: vier Migrationsnachweise und sieben Referenzdatensätze
UC00-Rollen dlx_migrator, dlx_app_tenant, dlx_app_platform
Row-Level Security (RLS, zeilenbasierte Zugriffskontrolle) Auf allen 35 Fachtabellen aktiviert und erzwungen
Automatische Verwaltungszuweisung Für die Migrationsverbindung mit ADMIN, aber ohne INHERIT und ohne SET; daher keine automatische Nutzung als Anwendungsrolle
Fach- oder Personendaten Keine

PostgreSQL 17 verwaltet ADMIN, INHERIT und SET bei Rollenzuweisungen getrennt. Die sichere Ausgangskonfiguration wurde vor und nach der Laufzeitprüfung exakt verglichen. Grundlagen: PostgreSQL-Rollenattribute, SET ROLE und REVOKE.

5. Grundlegende RLS-Laufzeitprüfung

npm run prisma:guards:test führt acht grundlegende Datenbankschutzprüfungen aus. Der letzte erfolgreiche Gesamtlauf erfolgte nach der dritten Migration:

ID Prüfung Ergebnis
DB-RLS-B01 SET-Berechtigung nur innerhalb des Tests und vollständige Wiederherstellung Erfolgreich
DB-RLS-B02 Standardverweigerung der Tenant-Rolle ohne Tenant-Kontext Erfolgreich
DB-RLS-B03 Tenant A kann Tenant B nicht lesen Erfolgreich
DB-RLS-B04 Tenantgebundene Schreib- und Leseoperation für das eigene Profil Erfolgreich
DB-RLS-B05 Kontextwechsel blendet Daten des vorherigen Tenants vollständig aus Erfolgreich
DB-RLS-B06 Globale Benachrichtigungsvorlagen sind tenantseitig lesbar Erfolgreich
DB-RLS-B07 Getrennte Plattformrolle besitzt die vorgesehene tenantübergreifende Sicht Erfolgreich
DB-RLS-B08 Dieselbe normalisierte E-Mail kann tenantübergreifend nur eine offene Einladung besitzen; widerrufene Historie bleibt zulässig Erfolgreich

Alle temporären Testdaten und Rollenerweiterungen liegen in einer absichtlich zurückgerollten Transaktion. Eine anschliessende Inventur bestätigte damals wieder genau zehn Datensätze sowie die unveränderten sicheren Rollenoptionen. Nach Anwendung der vierten additiven Migration bestätigen prisma migrate status und die Inventur den aktuellen Datenbankstand mit elf Datensätzen. Der erneute Schutzprüfungslauf erreichte die konfigurierte Runtime-Verbindung nicht und ist deshalb weiterhin nachzuholen.

6. Reproduzierbare Prüfungen

Die folgenden Befehle wurden im Verzeichnis backend für den aktuellen Stand erfolgreich ausgeführt:

npm.cmd run prisma:migrate:status
npm.cmd run prisma:migrations:validate
npm.cmd exec -- prisma validate
npm.cmd run prisma:seed
npm.cmd run prisma:inventory -- --summary

npm.cmd run prisma:guards:test war zuletzt nach der dritten Migration erfolgreich. Der Wiederholungslauf nach der vierten Migration scheiterte vor Ausführung der Prüfungen an der nicht erreichbaren Runtime-Verbindung.

Der Backend-Build ist davon getrennt zu bewerten. Nach erneuter Prisma-Client-Erzeugung ist er am 10.08.2026 erfolgreich. Dies ändert den hier nachgewiesenen Datenbank-Iststand nicht.

7. Verbleibende Grenzen

Der Entwicklungsdatenbank-Rollout und die grundlegende RLS-Wirksamkeit sind nachgewiesen. Weiterhin offen bleiben insbesondere:

  • Provisionierung und echter Datenbanknachweis der getrennt konfigurierten, nicht administrativen Login-Rollen für Tenant- und Plattformverkehr;
  • Umstellung aller betroffenen Backend-Dienste auf die implementierten Prisma-Runtime-Clients und den transaktionsgebundenen Tenant-, Benutzer- und Request-Kontext;
  • vollständige Rollen-, Ressourcen-, Negativ-, Schreib-, Lösch- und Connection-Pooling-Tests;
  • Wiederholung der acht grundlegenden Datenbankschutzprüfungen gegen den Stand nach der vierten Migration;
  • Laufzeitprüfungen für alle Fachtabellen und sicherheitsrelevanten Constraints;
  • Integrationsprüfung der ausgerollten Vertragskontaktfelder im vollständigen Vertragsablauf;
  • vollständige Backend-Umstellung auf das Prisma-v4-Zielschema;
  • produktive Provisionierung, Härtung, Überwachung und Rechteprüfung.

Die acht Basisprüfungen sind daher ein belastbarer Zwischenbeleg, aber kein Ersatz für die vollständigen Testkriterien UC00-09-03 und UC00-09-23.