DiveLogix360 — Produkt-Roadmap & Versions-Backlog¶
Version: 1.1 | Stand: April 2026
Autor: David | DiveLogix360
Status: Vertraulich | Internes Arbeitsdokument
Märkte: DE | CH | AT
Inhaltsverzeichnis¶
- Projektübersicht
- Version 1 — MVP
- Version 2 — Erweiterungen
- Version 3 — Vision
- Offene Entscheide & Designprinzipien
- Nächste Schritte
- Rechtsgrundlagen & Datenschutz-Compliance
- Quellenverzeichnis
1. Projektübersicht¶
DiveLogix360 ist eine mandantenfähige SaaS-Plattform für Tauchschulen im DACH-Raum. Sie digitalisiert die Verwaltung von TÜV-Inspektionen (Druckluftflaschen nach EN 1802/EN 1968), Inhouse-Services (Regler, Jacket) und bietet Endkunden ein Tracking-Portal für ihre eigene Ausrüstung.
1.1 Geschäftsmodell¶
Direkte SaaS-Kunden (Tenants) sind Tauchschulen. Endkunden (Taucher) erhalten über Modell B ein read-only Kundenportal als Mehrwertleistung der Tauchschule.
1.2 Akteurs-Modell (Modell B)¶
Das Akteurs-Modell definiert vier Rollen auf drei Ebenen. Die Tabellenbeschriftung folgt dem Schema Kapitel-Nr. + laufende Tabellennummer.
| Ebene | Rolle | Technisch | Beschreibung |
|---|---|---|---|
| Plattform | Betreiber | superadmin |
Plattform-Administration — verwaltet alle Tenants, System-Logs |
| Tenant | Schulinhaber | tenant_admin |
Verwaltet Mitarbeiter, Kunden, Berichte, DSGVO |
| Tenant | Mitarbeiter | mitarbeiter |
Erfasst Equipment, Workflows, Prüfergebnisse |
| Portal | Taucher | kunde |
Sieht eigene Flaschen/Regler, TÜV-Termine (read-only) |
1.3 Architektur-Prinzipien¶
DiveLogix360 ist nach folgenden Kernprinzipien gebaut, die alle technischen Entscheide leiten:
| Prinzip | Beschreibung |
|---|---|
| Offline-First | Alle Kernfunktionen funktionieren ohne Internetverbindung (Lagerräume, Keller). Eine abstrakte SyncEngine synchronisiert Änderungen beim nächsten Online-Gang: Phase 1 via Timestamp-Strategie, Phase 2 via CRDT (Electric SQL, einhängbar ohne Schema-Änderung). |
| Mobile First / PWA | Die App ist als Progressive Web App (PWA) konzipiert — kein App-Store-Install nötig. Touch-optimiert, min. 44×44px Tap-Targets. Nutzung direkt am Equipment und in Lagerräumen. |
| Multi-Tenancy via RLS | Row-Level Security (PostgreSQL) stellt sicher dass jeder Tenant ausschliesslich seine eigenen Daten sieht. Tenant-übergreifender Zugriff ist technisch nur dem Superadmin möglich. |
| Modularität | Core (Tenant, Kunden, Equipment) + aktivierbare UseCase-Module. Jedes Modul ist einzeln lizenzierbar. Ein neues Modul verändert den Core nie. |
| URL-Sicherheit | Keine sequenziellen IDs in URLs. Alle Ressourcen werden über nicht erratbare UUIDs angesprochen (z.B. /equipment/a3f9b2c1 statt /equipment?id=17). |
| DSGVO by Design | Pseudonymisierung, Aufbewahrungsfristen und Audit-Log sind von Anfang an im Datenbankschema eingebaut — nicht nachträglich ergänzt. |
2. Version 1 — MVP¶
Version 1 liefert die Kernfunktionalität für den Tauchschul-Alltag. Das Schema ist bereits für V2/V3 vorbereitet — das UI bleibt fokussiert und lieferbar.
2.1 Use Cases Version 1¶
Die folgende Tabelle zeigt alle Use Cases der ersten Version. Die Spalte Zielgruppe beschreibt wer den UC nutzt (Tauchschule, Taucher-Portal, Tauchschule + Taucher oder Plattform-Administration). Die Spalte Reifegrad V1 zeigt ob die Funktionalität vollständig implementiert wird oder in V1 vereinfacht bleibt und erst in V2 vollständig konfigurierbar ist.
| UC | Name | Akteur(e) | Zielgruppe | Reifegrad V1 | Status |
|---|---|---|---|---|---|
| UC00 | Tenant-Onboarding & Schulverwaltung | Superadmin, Tenant-Admin | Plattform-Administration | Vollständig | 🟡 In Bearbeitung |
| UC01 | Equipment erfassen | Mitarbeiter | Tauchschule | Vollständig | ⬜ Offen |
| UC02 | TÜV-Inspektion einreichen (ext.) | Mitarbeiter | Tauchschule | Vollständig | ⬜ Offen |
| UC03 | Inhouse-Service erfassen | Mitarbeiter | Tauchschule | Vollständig | ⬜ Offen |
| UC04 | Fristen-Dashboard | Tenant-Admin, Mitarbeiter | Tauchschule | Vollständig | ⬜ Offen |
| UC05 | Kunden einladen & Portal | Tenant-Admin, Taucher | Taucher-Portal | Vollständig | ⬜ Offen |
| UC06 | Benachrichtigungen (Fristen) | System, Taucher | Tauchschule + Taucher | Vereinfacht | ⬜ Offen |
| UC07 | Benutzerverwaltung | Tenant-Admin | Tauchschule | Vollständig | ⬜ Offen |
| UC08 | Berichte & Export | Tenant-Admin | Tauchschule | Vereinfacht | ⬜ Offen |
| UC-SA | Superadmin-Panel | Superadmin | Plattform-Administration | Vollständig | ⬜ Offen |
2.2 Schema-Tabellen Version 1¶
Alle Datenbanktabellen die in Version 1 implementiert werden. Tabellen mit Status AMBER sind im Schema vollständig modelliert, im UI jedoch erst in Version 2 vollständig konfigurierbar.
| Feature / Tabelle | Version | Beschreibung | Mandanten-Stammdaten, Plan-Typ, Land, Adresse |
| users | V1 | Benutzer (tenant_admin, mitarbeiter, kunde), 2FA |
| customers | V1 | Kunden der Tauchschule, DSGVO-Felder |
| equipment | V1 | Alle Gerätetypen (Flasche, Regler, BCD, ...) |
| cylinder_details | V1 | TÜV-Details: EN 1802/EN 1968, DGUV, SVTI |
| regulator_details | V1 | Regler-Service-Details, Intervall |
| usecase_workflows | V1 | TÜV-Workflow, Inspektion, Inhouse-Service |
| workflow_history | V1 | Statusverlauf je Workflow (append-only) |
| invitation_tokens | V1 | Einladungsflow Taucher → Kundenportal |
| notification_rules | V1 | Mehrstufige Benachrichtigungsregeln (UI erst V2) |
| notification_log | V1 | Verhindert doppelte Benachrichtigungen |
| sync_queue | V1 | Offline-Sync, Konfliktmanagement (Vector Clock) |
| audit_log | V1 | Vollständiges Änderungsprotokoll (DSGVO) |
| access_log | V1 | Zugriffsprotokoll auf Entitäten |
| auth_log | V1 | Login / 2FA-Ereignisse |
| customer_activity_log | V1 | Kundenportal-Aktivitäten |
| deletion_log | V1 | DSGVO-Löschprotokoll |
| system_log | V1 | Systemereignisse, Fehler, Warnungen |
2.3 Bewusste V1-Einschränkungen (UI)¶
notification_rules: Schema ist mehrstufig — UI zeigt nur 1 Standardregel pro Tenant (30 Tage, E-Mail)- Taucher kann Kontaktdaten lesen, aber nicht selbst ändern (Änderungsantrag kommt in V2)
- Kein Multi-Schule-Support für Endkunden (1 Taucher = 1 Schule in V1)
- Berichte: einfacher PDF-Export, kein konfigurierbarer Reportgenerator
- Benachrichtigungen: nur E-Mail-Kanal, kein Push
- Logo/Branding: noch nicht in V1 — kommt in V2 (ev. als separates Preismodell)
- Eigene Equipment-Typen: in V1 fixer Katalog — Erweiterung in V2
- Sprache: in V1 nur DE — Mehrsprachigkeit in V2
- Tenant-Onboarding: in V1 manuell durch Superadmin — Self-Service in V2
3. Version 2 — Erweiterungen¶
Version 2 öffnet die im V1-Schema bereits vorbereiteten Flexibilitätspunkte für das UI und fügt neue Verkaufsargumente hinzu. Die V1-Einschränkungen werden schrittweise aufgehoben.
3.1 Use Cases Version 2¶
| UC | Name | Akteur(e) | Zielgruppe | Reifegrad |
|---|---|---|---|---|
| UC00+ | Self-Service-Registrierung (Tenant) | Tauchschule (neu) | Plattform-Administration | V2 |
| UC06+ | Konfigurierbares Benachrichtigungssystem | Tenant-Admin | Tauchschule | V2 |
| UC09 | Kontaktdaten-Änderungsantrag (Taucher) | Taucher, Tenant-Admin | Taucher-Portal | V2 |
| UC10 | Erweiterter Bericht & Exportkonfigurator | Tenant-Admin | Tauchschule | V2 |
| UC11 | Push-Benachrichtigungen | System, Taucher | Tauchschule + Taucher | V2 |
| UC12 | Dokument-Upload (Prüfzertifikate) | Mitarbeiter | Tauchschule | V2 |
| UC13 | Taucher bei mehreren Schulen | Taucher | Taucher-Portal | V2 |
| UC14 | Logo & Branding je Tenant | Tenant-Admin | Tauchschule | V2 |
| UC15 | Eigene Equipment-Typen verwalten | Tenant-Admin | Tauchschule | V2 |
| UC16 | Mehrsprachigkeit (FR, EN) | System | Tauchschule + Taucher | V2 |
3.2 Neue Schema-Objekte V2¶
| Feature / Tabelle | Version | Beschreibung |
|---|---|---|
customer_tenant_map |
V2 | Erlaubt 1 Taucher bei mehreren Schulen (heute: tenant_id auf users) |
documents |
V2 | Prüfzertifikate, Fotos je Equipment oder Workflow |
change_requests |
V2 | 4-Augen-Prinzip: Taucher beantragt Änderung, Tenant-Admin bestätigt |
push_tokens |
V2 | Push-Notification-Tokens je Gerät (iOS, Android) |
registration_requests |
V2 | Self-Service-Onboarding: neue Tauchschulen beantragen Zugang |
organizations |
V2 | Firmen/Vereine als optionale Gruppierung von Kunden (siehe uc-kunden-vorentscheide.md) |
3.3 Schema-Entscheide die V2 bereits vorbereiten¶
users.tenant_idbleibt in V1 —customer_tenant_mapkommt in V2 dazu (keine Migration nötig)notification_rulesist bereits mehrstufig modelliert — V2 öffnet nur das UIequipment.custom_data(JSONB) erlaubt neue Equipment-Typen ohne Schema-Migrationtenants.logo_pathist im Schema vorhanden, wird in V1 nicht befülltcustomers.organization_idist in V1 bereits als nullable FK vorbereitet — V2 aktiviert die Logik (siehedocs/developer/uc-vorentscheide/uc-kunden-vorentscheide.md)
4. Version 3 — Vision¶
Version 3 realisiert das Modell C (aktiver Taucher) und öffnet die Plattform für tiefere Integrationen mit Prüfstellen und Zahlungsanbietern.
| UC | Name | Akteur(e) | Zielgruppe | Reifegrad |
|---|---|---|---|---|
| UC-C1 | Taucher reicht Inspektion selbst ein | Taucher | Taucher-Portal | V3 |
| UC-C2 | Taucher lädt Dokumente hoch | Taucher | Taucher-Portal | V3 |
| UC-C3 | Direktzahlung / Rechnungsstellung | Taucher, Tenant-Admin | Tauchschule + Taucher | V3 |
| UC-C4 | API für Prüfstellen-Integration (SVTI) | Extern | Plattform-Administration | V3 |
| UC-C5 | White-Label / eigene Domain je Schule | Tenant-Admin | Tauchschule | V3 |
5. Offene Entscheide & Designprinzipien¶
5.1 Geklärt¶
- Tauchschule als externer Kunde: wird als normaler Kundendatensatz erfasst — kein Sonderfall im Schema
- Taucher-Registrierung V1: Einladung per E-Mail-Token durch die Schule (nicht Self-Registration)
- Kontaktdaten V1: read-only für Taucher — Schule pflegt Daten; Änderungsantrag kommt in V2
- Benachrichtigungszeitraum: flexibel und mehrstufig konfigurierbar pro Equipment-Typ
- Externe TÜV-Inspektion: Tauchschule reicht ein, externe Prüfstelle führt Prüfung durch
- Inhouse-Service: Regler und Jacket werden von der Schule selbst gewartet und erfasst
- Prüfintervalle: Tenant-Admin kann eigene Intervalle je Equipment-Typ festlegen (V1)
- Standard-Währung: Tenant-Admin setzt CHF oder EUR pro Tenant (V1)
- Tenant-Onboarding V1: manuell durch Superadmin — Self-Service in V2
- Billing: komplett ausserhalb der App (Stripe oder manuelle Rechnung) — MwSt-Nr. im Schulprofil
- Mitarbeiter-Einladungsmodell: via Einladungslink (analog UC00 Modell C1) — Details in UC-Mitarbeiter
- Kunden V1: Kunde = Person (Szenario A) — Organisations-Zuordnung optional in V2 (Szenario C)
5.2 Noch offen¶
- Preismodell: Starter / Professional / Enterprise — genaue Feature-Grenzen definieren
- Offline-Modus: welche Aktionen sind ohne Internet möglich? (
sync_queueist vorbereitet) - Sprachen: DE + CH-DE zum Start — wann kommt FR/EN?
5.3 Designprinzipien¶
- Schema-forward, UI-minimal: das DB-Design denkt 3 Versionen voraus, das UI liefert V1 fokussiert
- Keine Breaking Changes: neue Features erweitern das Schema (neue Tabellen/Spalten), nie umbauend
- DSGVO by Design: Pseudonymisierung, Löschfristen und Audit sind von Anfang an eingebaut
- Normenkonformität: EN 1802, EN 1968, DGUV, SVTI sind im Schema direkt referenzierbar
- Versionen als Verkaufsargument: Kunden kaufen V1, wissen dass V2 kommt — reduziert Churn
- Keine Gendersprache: klassische deutsche Rechtschreibung in der gesamten Applikation
6. Nächste Schritte¶
| # | Aufgabe | Priorität | Status |
|---|---|---|---|
| 1 | UC00 Schritt 1–2: Steckbrief + Wireframes | Hoch | ✅ Abgeschlossen |
| 2 | UC00 Schritt 3: Datenmodell (Schema-Delta) | Hoch | 🟡 In Bearbeitung |
| 3 | UC00 Schritt 4–7: Backend, Prisma, Frontend, Testing | Hoch | ⬜ Offen |
| 4 | Schema um notification_rules, notification_log, invitation_tokens erweitern |
Hoch | ✅ Erledigt |
| 5 | tenants-Tabelle um Schulprofil-Felder erweitern |
Hoch | ✅ Erledigt |
| 6 | Prisma-Schema v3 aktualisiert (equipment-Core) | Mittel | ✅ Erledigt |
| 7 | NestJS-Backend-Grundstruktur aufsetzen | Mittel | ⬜ Offen |
| 8 | RLS aktivieren (nach NestJS-Setup und JWT-Hook) | Mittel | ⬜ Offen |
| 9 | React-Frontend Grundstruktur und Routing | Mittel | ⬜ Offen |
| 10 | UC01 ausarbeiten: Equipment erfassen | Hoch | ⬜ Offen |
| 11 | Preismodell-Grenzen festlegen (Starter/Pro/Enterprise) | Niedrig | ⬜ Backlog |
7. Rechtsgrundlagen & Datenschutz-Compliance¶
DiveLogix360 verarbeitet Personendaten von Tauchern und Mitarbeitenden der Tauchschulen. Damit unterliegt die Plattform einem komplexen Rechtsrahmen aus Schweizer und EU-Datenschutzrecht sowie branchenspezifischen Normen. Dieses Kapitel dokumentiert die relevanten Rechtsgrundlagen und leitet daraus konkrete Anforderungen für das Produkt ab.
7.1 Schweizer Datenschutzrecht (nDSG / DSV / VDSZ)¶
Das neue Schweizer Bundesgesetz über den Datenschutz (nDSG), die Datenschutzverordnung (DSV) sowie die Verordnung über Datenschutzzertifizierungen (VDSZ) sind am 1. September 2023 in Kraft getreten. Mit der Totalrevision wird das Datenschutzrecht den veränderten technologischen und gesellschaftlichen Verhältnissen angepasst. Es wurden keine gesetzlichen Übergangsfristen vorgesehen — alle Pflichten gelten sofort.
Das nDSG annähert die Schweizer Datenschutzgesetzgebung an die EU-Datenschutzgrundverordnung (EU-DSGVO 2016/679), ist aber kein 1:1-Abbild. Der pragmatischere Schweizer Ansatz bleibt erhalten: Datenbearbeitung ist grundsätzlich erlaubt, sofern die Grundprinzipien eingehalten werden (Art. 6 nDSG) — anders als in der EU, wo ein expliziter Erlaubnisgrund benötigt wird.
7.2 Kernpflichten für DiveLogix360¶
Als SaaS-Betreiber ist DiveLogix360 sowohl Verantwortlicher (für eigene Daten) als auch Auftragsbearbeiter (für Daten der Tauchschulen). Daraus ergeben sich folgende Pflichten:
| Pflicht | Rechtsgrundlage | Umsetzung in DiveLogix360 |
|---|---|---|
| Bearbeitungsverzeichnis führen | Art. 12 nDSG i.V.m. Art. 4–6 DSV | audit_log + deletion_log dokumentieren alle Datenbearbeitungen |
| Privacy by Design & Default | Art. 7 nDSG | DSGVO-Felder, Pseudonymisierung und Löschfristen sind von Anfang an im Schema eingebaut |
| Informationspflicht (Datenschutzerklärung) | Art. 19 nDSG, Art. 13 DSV | Datenschutzerklärung auf divelogix360.ch; je Tenant bei Kundenerfassung |
| Datensicherheit (TOM) | Art. 8 nDSG, Art. 1–3 DSV | RLS, 2FA, Audit-Log, verschlüsselte Übertragung (TLS), Supabase EU-Hosting |
| Meldepflicht bei Datenschutzverletzung | Art. 24 nDSG | system_log + Eskalationsprozess an EDÖB bei hohem Risiko |
| Betroffenenrechte (Auskunft, Löschung) | Art. 25–27 nDSG | deletion_log, customer.pseudonymized, gdpr_consent-Felder |
| Auftragsbearbeitungsvertrag (AVV) | Art. 9 nDSG | AVV mit jeder Tauchschule als Tenant (Schriftform) |
| Bekanntgabe ins Ausland | Art. 16–17 nDSG | Supabase EU-Region (Frankfurt/Dublin) — keine Drittstaatenübermittlung |
7.3 Verhältnis nDSG – EU-DSGVO – BDSG¶
Da DiveLogix360 den DACH-Markt (DE, CH, AT) bedient, gilt ein dreifacher Rechtsrahmen je nach Standort des Tenants:
| Markt | Anwendbares Recht | Besonderheiten für DiveLogix360 |
|---|---|---|
| CH (Schweiz) | nDSG / DSV / VDSZ | Erlaubnis mit Verbotsvorbehalt; pragmatischer; AVV Pflicht; EDÖB als Aufsicht |
| DE (Deutschland) | EU-DSGVO + BDSG | Verbot mit Erlaubnisvorbehalt; strenger; Einwilligung oder Vertrag nötig; BfDI/LfDI |
| AT (Österreich) | EU-DSGVO + DSG AT | Wie DE; Datenschutzbehörde (Österreich) als Aufsicht |
Hinweis: Da die Schweiz von der EU als Drittstaat mit angemessenem Datenschutzniveau anerkannt ist (Angemessenheitsbeschluss), ist die grenzüberschreitende Datenübermittlung CH ↔ EU ohne zusätzliche Garantien zulässig. Diese Anerkennung basiert u.a. auf der Ratifizierung des modernisierten Datenschutzübereinkommens SEV 108+ des Europarats (2023).
7.4 Branchenspezifische Normen¶
Zusätzlich zum Datenschutzrecht unterliegt DiveLogix360 technischen Normen für die TÜV-Inspektion von Druckgeräten:
| Norm | Relevanz für DiveLogix360 |
|---|---|
| EN 1802:2002 | Wiederkehrende Inspektion nahtloser Druckluftflaschen aus Aluminium — Prüffristen und Dokumentationspflichten |
| EN 1968:2002 | Wiederkehrende Inspektion nahtloser Druckluftflaschen aus Stahl — Prüffristen und Dokumentationspflichten |
| DGUV (DE) | Deutsche Unfallverhütungsvorschriften für Druckgeräte im Tauchbereich — gilt für DE-Tenants |
| SVTI (CH) | Schweizerischer Verein für technische Inspektionen — zugelassene Prüfstelle in der Schweiz |
7.5 Datenschutz-Roadmap¶
Folgende datenschutzrechtliche Massnahmen sind als Teil der Produktentwicklung umzusetzen:
| # | Massnahme | Version | Rechtsgrundlage |
|---|---|---|---|
| 1 | Datenschutzerklärung für divelogix360.ch erstellen | V1 | Art. 19 nDSG / Art. 13 DSGVO |
| 2 | Auftragsbearbeitungsvertrag (AVV) je Tenant | V1 | Art. 9 nDSG / Art. 28 DSGVO |
| 3 | Bearbeitungsverzeichnis aufsetzen (intern für DiveLogix360) | V1 | Art. 12 nDSG / Art. 30 DSGVO |
| 4 | RLS + 2FA + TLS — technische Schutzmassnahmen (TOM) | V1 | Art. 8 nDSG / Art. 25 DSGVO |
| 5 | GDPR-Consent-Flow für Kundenerfassung durch Tauchschule | V1 | Art. 19 nDSG |
| 6 | Datenschutz-Folgenabschätzung (DSFA) für Hochrisiko-Bearbeitungen | V2 | Art. 22 nDSG / Art. 35 DSGVO |
| 7 | ISO 27001-Zertifizierung anstreben (ab Enterprise-Tier) | V3 | VDSZ / Art. 7 nDSG |
8. Quellenverzeichnis¶
Die nachfolgenden Quellen bilden die Grundlage für die in diesem Dokument enthaltenen Aussagen zu Rechtsgrundlagen, technischen Normen und strategischen Entscheiden.
8.1 Schweizer Datenschutzrecht¶
| Nr. | Titel | Quelle |
|---|---|---|
| [1] | nDSG — Bundesgesetz über den Datenschutz (revidiert) | fedlex.admin.ch/eli/cc/2022/491/de — in Kraft seit 1. September 2023 |
| [2] | DSV — Datenschutzverordnung | fedlex.admin.ch/eli/cc/2022/568/de — Ausführungsbestimmungen zum nDSG |
| [3] | VDSZ — Verordnung über Datenschutzzertifizierungen | fedlex.admin.ch — Zertifizierungsrahmen für Datenbearbeitungen |
| [4] | Neues Datenschutzgesetz DSG (Strategie Digitale Schweiz) | digital.swiss/de/aktionsplan/massnahme/neues-datenschutzgesetz-ndsg |
| [5] | KMU-Portal Bund: Neues Datenschutzgesetz (revDSG) | kmu.admin.ch — Bundesamt für Justiz, Bern |
| [6] | Übersicht zum neuen Datenschutzgesetz | economiesuisse.ch/de/artikel/datenschutz-eine-uebersicht-zum-neuen-gesetz |
8.2 EU-Datenschutzrecht¶
| Nr. | Titel | Quelle |
|---|---|---|
| [7] | EU-DSGVO 2016/679 — Datenschutz-Grundverordnung | eur-lex.europa.eu — in Kraft seit 25. Mai 2018 |
| [8] | BDSG — Bundesdatenschutzgesetz (Deutschland) | gesetze-im-internet.de/bdsg_2018 — gilt für DE-Tenants |
| [9] | DSG AT — Datenschutzgesetz Österreich | ris.bka.gv.at — gilt für AT-Tenants |
8.3 Technische Normen (TÜV / Druckgeräte)¶
| Nr. | Titel | Quelle |
|---|---|---|
| [10] | EN 1802:2002 — Nahtlose Aluminiumflaschen, wiederkehrende Inspektion | CEN / Beuth Verlag — Norm für Druckluftflaschen Aluminium |
| [11] | EN 1968:2002 — Nahtlose Stahlflaschen, wiederkehrende Inspektion | CEN / Beuth Verlag — Norm für Druckluftflaschen Stahl |
| [12] | DGUV — Deutsche Gesetzliche Unfallversicherung | dguv.de — Vorschriften für Druckgeräte im Tauchbereich |
| [13] | SVTI — Schweizerischer Verein für technische Inspektionen | svti.ch — Zugelassene Prüfstelle CH für Druckbehälter |
8.4 Technische Grundlagen¶
| Nr. | Titel | Quelle |
|---|---|---|
| [14] | Supabase — PostgreSQL-Datenbankplattform | supabase.com |
| [15] | PostgreSQL Row Level Security (RLS) | postgresql.org/docs/current/ddl-rowsecurity.html |
| [16] | NestJS — Node.js Backend Framework | nestjs.com |
| [17] | Prisma — ORM für PostgreSQL / TypeScript | prisma.io |
| [18] | React — Frontend-Framework | react.dev |
Änderungshistorie¶
| Datum | Version | Änderung | Autor |
|---|---|---|---|
| April 2026 | 1.0 | Initiale Version (aus DiveLogix360_Roadmap.docx konvertiert) | David |
| April 2026 | 1.1 | Konvertierung zu Markdown; UC00 Status aktualisiert; Nächste Schritte aktualisiert; Kunden-Vorentscheide + Mitarbeiter-Einladungsmodell in 5.1 ergänzt; organizations in 3.2 ergänzt; V2-Vorbereitung customers.organization_id in 3.3 ergänzt; Designprinzip keine Gendersprache ergänzt |
David |
| April 2026 | 1.2 | Fehlende Einleitungstexte in 1.2, 1.3, 2.1, 2.2, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 8.0 ergänzt; Hinweis-Satz 7.3 vervollständigt (SEV 108+); Quellenangaben 8.1–8.3 mit vollständigen Hinweistexten ergänzt | David |