DiveLogix360 – Projektstatus
Stand: 12.08.2026 16:55
Branch: main
Status: Aktiv
| Datum, Uhrzeit |
Version |
Änderung |
Autor |
| 12.08.2026 16:55 |
5.13 |
Aufgabenhoheit gegenüber Roadmap und KI-Übergabeunterlage klargestellt |
Codex |
| 10.08.2026 20:00 |
5.12 |
Sicheren UC00-Merge-Stand nach main übernommen und Branch-Nachführung ergänzt |
Codex |
| 10.08.2026 19:46 |
5.11 |
Sichere Tenant-Vorbereitung mit Pflicht-Plan und AWS-KMS-TOTP-Pfad umgesetzt, unsicheren Vertragszwischenstand entfernt, vierte Migration angewendet sowie erfolgreichen Backend-Build nachgeführt |
Codex |
| 09.08.2026 19:35 |
5.10 |
Fehlenden Wrangler-Entry-Point für das Cloudflare-Workers-Projekt "divelogix360" ergänzt, damit die MkDocs-Dokumentation dort veröffentlicht werden kann; Deployment-Erfolg noch nicht im Dashboard geprüft |
Claude |
| 09.08.2026 19:10 |
5.9 |
Vertragsgebundene Einladungssperre code-seitig umgesetzt (Backend-Build bis auf bekannte TOTP-Stelle wiederhergestellt); Datenbank- und Integrationsnachweis stehen aus |
Claude |
| 09.08.2026 17:32 |
5.8 |
Globale E-Mail-Normalisierung, Konfliktbehandlung, Einladungstoken-Hashspeicherung und dritte Schutzmigration mit Tests umgesetzt |
Codex |
| 09.08.2026 16:40 |
5.7 |
Getrennte Prisma-Runtime-Clients, Konfigurationssperren und transaktionsgebundenen RLS-Kontextwrapper mit fünf Unit-Tests umgesetzt |
Codex |
| 09.08.2026 16:25 |
5.6 |
UC00-Entwicklungsdatenbank kontrolliert neu aufgebaut, sicheren Basis-Seed ausgeführt und sieben grundlegende RLS-Laufzeitprüfungen nachgewiesen |
Codex |
| 09.08.2026 15:43 |
5.5 |
Kanonischen UC00-OpenAPI- und Testvertrag mit 33 Operationen und 61 Testfall-IDs abgeschlossen sowie Prüfabhängigkeit und Lockfile synchronisiert |
Codex |
| 09.08.2026 15:22 |
5.4 |
Initiale UC00-Migrationsfolge, Datenbank-Constraints, RLS und statische Migrationsprüfung umgesetzt |
Codex |
| 09.08.2026 14:41 |
5.3 |
Prisma-v4-Zielschema für UC00 abgeleitet, formal validiert und nachgelagerten Backend-Umstellungsbedarf erfasst |
Codex |
| 09.08.2026 14:24 |
5.2 |
ADR-012 akzeptiert, providerneutrale RLS-Strategie festgelegt und Umsetzungsnachweise erfasst |
Codex |
| 09.08.2026 14:10 |
5.1 |
ADR-010 akzeptiert, historische SQL-Ablage eingeordnet und führendes Prisma-Migrationsverfahren festgelegt |
Codex |
| 09.08.2026 14:01 |
5.0 |
ADR-009 akzeptiert und Prisma-Schema mit abgegrenzten Nachweisrollen als technische Wahrheit festgelegt |
Codex |
| 09.08.2026 13:54 |
4.9 |
Modellrelevante UC00-Nachverfolgbarkeit abgeschlossen und ADR-009 als nächsten Architekturentscheid festgelegt |
Codex |
| 09.08.2026 13:43 |
4.8 |
UC00-Verantwortlichkeiten zugeordnet, reproduzierbare Prisma-Ausgangsbasis geprüft und widersprüchliche Fertigmeldungen korrigiert |
Codex |
| 09.08.2026 13:04 |
4.7 |
UC00-07-11 mit vorläufiger RF-03-Frist und juristischem Prüfbriefing für DACH vorbereitet |
Codex |
| 09.08.2026 12:55 |
4.6 |
TOM-Katalog und verbindliches Wirksamkeitsnachweismodell für UC00-07-10 vervollständigt |
Codex |
| 09.08.2026 12:49 |
4.5 |
Zeitbegrenztes Support-, Notfall- und Auslandszugriffsmodell nach ADR-023 festgelegt |
Codex |
| 09.08.2026 12:34 |
4.4 |
Eigenbetriebenen ClamAV-Scanservice und ausfallsichere Vertrags-PDF-Prüfung nach ADR-022 festgelegt |
Codex |
| 09.08.2026 12:17 |
4.3 |
Grafana Cloud Pro Frankfurt sowie verbindliche Daten-, Sicherheits- und Kostenkontrollen nach ADR-021 festgelegt |
Codex |
| 09.08.2026 11:52 |
4.2 |
Risikobasierte V1-Backup- und Wiederherstellungsarchitektur nach ADR-020 festgelegt |
Codex |
| 09.08.2026 11:33 |
4.1 |
Hetzner Object Storage Nürnberg und AWS KMS Frankfurt als bevorzugte V1-Architektur festgelegt |
Codex |
| 08.08.2026 14:48 |
4.0 |
Revisionsfähiges Auditmodell mit täglichen kryptografischen Sammelnachweisen nach ADR-018 festgelegt |
Codex |
| 08.08.2026 14:43 |
3.9 |
DSFA-Schwellenprüfung für UC00 abgeschlossen; vollständige Folgenabschätzung derzeit nicht erforderlich |
Codex |
| 08.08.2026 14:35 |
3.8 |
Modulare AVV-Arbeitsvorlage und kontrollierten Freigabeprozess erstellt; juristische Produktivfreigabe bleibt offen |
Codex |
| 08.08.2026 13:40 |
3.7 |
Tenant-Offboarding mit Sperrung, 30 Tagen Exportzugang und operativer Löschung spätestens nach 90 Tagen freigegeben |
Codex |
| 08.08.2026 13:28 |
3.6 |
Hostpoint als V1-E-Mail-Provider entschieden sowie Produktivsperre, sichere Linkübermittlung, SMTP- und Bounce-Aufgaben erfasst |
Codex |
| 08.08.2026 11:57 |
3.5 |
UC00-Speicherfristen fachlich freigegeben sowie technische Löschung, Providerabgleich und juristische Länderprüfung erfasst |
Codex |
| 08.08.2026 11:44 |
3.4 |
UC00-Schutzanforderungen, zentrale TOM-Übersicht, Wiederherstellungsziele sowie offene Sicherheits- und Prüfaufgaben aufgenommen |
Codex |
| 07.08.2026 19:45 |
3.3 |
UC00-Empfänger und Übermittlungen entschieden sowie Provider- und Unterauftragnehmerregister eingeführt |
Codex |
| 07.08.2026 19:34 |
3.2 |
UC00-Protokollarten, Kontexttrennung, Minimierung und Ausfallschutz entschieden sowie offene Umsetzung erfasst |
Codex |
| 07.08.2026 19:22 |
3.1 |
UC00-Onboarding und Schulprofil fachlich vereinheitlicht sowie unzutreffende Fertigmeldungen zu Schema und Service korrigiert |
Codex |
| 07.08.2026 19:15 |
3.0 |
UC00-Benutzer-, Einladungs- und Authentifizierungsregeln entschieden und offene Sicherheitsumsetzungen erfasst |
Codex |
| 07.08.2026 18:57 |
2.9 |
Vertragsstatus, Parteiensnapshot, Sieben-Tage-Token und externer V1-Prüfprozess entschieden und Umsetzung erfasst |
Codex |
| 07.08.2026 18:42 |
2.8 |
Kontaktrollen, Telefonpflicht und kontrollierte Veröffentlichung für UC00 entschieden und offene Umsetzung erfasst |
Codex |
| 07.08.2026 18:38 |
2.7 |
Vollständige Vertragsanschrift als AVV-Sperrbedingung erfasst und Schweizer Schreibweise in aktuellen Aufgaben bereinigt |
Codex |
| 07.08.2026 18:11 |
2.6 |
UC00-Datenkatalog zur Prüfung erstellt und private PDF-Vertragsablage im Objektspeicher mit ADR-013 akzeptiert |
Codex |
| 07.08.2026 17:44 |
2.5 |
Verbindliche UC00-Abschlusscheckliste mit zehn Prüfgates, stabilen Kriterien-IDs und Nachweispflicht eingeführt |
Codex |
| 07.08.2026 17:30 |
2.4 |
Verbindlichen UC-Dossier-Standard, Repository-Inventar, Vorlage, UC00-Pilot und automatisierte Strukturprüfung umgesetzt |
Codex |
| 06.08.2026 19:08 |
2.3 |
ADR-015 akzeptiert; Vertragsabschluss vor Tenant-Admin-Einladung sowie elektronische und externe Abschlusswege für UC00 festgelegt |
Codex |
| 06.08.2026 18:42 |
2.2 |
ADR-011 als akzeptiert dokumentiert und offene Umsetzungsschritte ausgewiesen |
Codex |
| 03.08.2026 13:33 |
2.1 |
Datums- und Zeitangaben gegen Zeilenumbruch geschützt und chronologische Sortierung geprüft |
Codex |
| 03.08.2026 13:06 |
2.0 |
Status aus PROJECT-STATUS.md überführt und nach Scope, Spezifikation und Implementierung getrennt |
Codex |
| 01.08.2026 14:55 |
1.0 |
Kopfbereich vereinheitlicht |
David Mittig |
| 01.08.2026 11:12 |
1.0 |
Kopfbereich ergänzt |
David Mittig |
Zweck: Verbindliche Übersicht über den aktuellen Projekt- und Bearbeitungsstand.
Abgrenzung: Der geplante Produktumfang und strategische Meilensteine stehen in der Produkt-Roadmap, der zeitliche Verlauf in der Projekt-Historie. KIToDo.md ist eine abgeleitete Übergabeunterlage und keine zweite Aufgabenquelle.
Statusmodell
Die drei Dimensionen werden unabhängig voneinander geführt:
| Dimension |
Leitfrage |
Mögliche Angaben |
| Produkt-Scope |
In welcher Produktversion ist die Funktion vorgesehen? |
V1, V2, V3, nicht zugeordnet |
| Spezifikationsstand |
Wie weit sind Fachkonzept, Regeln und Screens ausgearbeitet? |
Offen, in Bearbeitung, abgeschlossen |
| Implementierungsstand |
Wie weit sind Backend, Frontend und Tests umgesetzt? |
Offen, in Bearbeitung, abgeschlossen, blockiert |
Eine Funktion kann beispielsweise zum V2-Scope gehören, fachlich bereits abgeschlossen, aber noch nicht implementiert sein.
Gesamtstatus
| Bereich |
Produkt-Scope |
Spezifikationsstand |
Implementierungsstand |
| UC00 – Tenant-Onboarding und Schulverwaltung |
V1 |
In Bearbeitung; Kernfachregeln, Prisma-v4-Zielschema sowie OpenAPI- und Testvertrag abgestimmt, Oberflächenkonsolidierung offen |
In Bearbeitung; Datenbank, Basis-Seed und Prisma-Kontextwrapper nachgewiesen, fachliches Backend, Runtime-Logins, Frontend und vollständige Laufzeittests offen |
| UC01 – Equipment erfassen |
V1 |
Abgeschlossen |
Offen |
| UC02 – TÜV-Inspektion einreichen |
V1 |
Abgeschlossen; einzelne Fachfragen offen |
Offen |
| UC03 – Füll-Abo und Füllkarten-Verwaltung |
V1 |
Weitgehend abgeschlossen; einzelne Punkte offen |
Offen |
| UC04 – Inhouse-Service erfassen |
V1 |
Abgeschlossen |
Offen |
| UC05 – Fristen-Dashboard |
V1 |
Abgeschlossen |
Offen |
| UC06 – Kunden einladen und Portal |
V1 |
Abgeschlossen |
Offen |
| UC07 – Benachrichtigungen |
V1 vereinfacht |
Abgeschlossen |
Offen |
| UC08 – Benutzerverwaltung |
V1 |
Abgeschlossen |
Offen |
| UC09 – Berichte und Export |
V1 vereinfacht |
Spezifikation abgeschlossen; Screens offen |
Offen |
| UC-SA – Superadmin-Panel |
V1 |
Abgeschlossen |
Offen |
| UC18 – Equipment-Verleih |
V2 |
Spezifikation abgeschlossen; Screens offen |
Offen |
Die Zuordnung zum Produkt-Scope ersetzt keine Aussage zum Spezifikations- oder Implementierungsstand.
Aktueller Arbeitsschwerpunkt
UC00 bleibt der aktive Arbeitsschwerpunkt. Fachlich verantwortlich ist David Mittig als Product Owner und Fachverantwortlicher; technisch verantwortlich ist David Mittig als Technische Leitung. Die interne Security- und Compliance-Koordination liegt vorläufig ebenfalls bei David Mittig. Ausdrücklich geforderte Rechts-, Datenschutz- und Sicherheitsprüfungen bleiben unabhängigen externen Experten vorbehalten.
Die modellrelevante UC00-Nachverfolgbarkeit, ADR-009, ADR-010, ADR-012, das Prisma-v4-Zielschema sowie der kanonische OpenAPI- und Testvertrag sind abgeschlossen. Alle vier versionierten Migrationen und der nicht personenbezogene Basis-Seed sind gegen Entwicklung nachgewiesen. Acht grundlegende Datenbank-Laufzeitprüfungen waren nach der dritten Migration erfolgreich; ihre Wiederholung nach der vierten Migration ist wegen der nicht erreichbaren Runtime-Verbindung offen. Getrennte Prisma-Runtime-Clients verweigern fehlende oder identische Zugangskonfigurationen; der Kontextwrapper setzt Tenant, Benutzer, Request und optionalen Retention-Lauf parametrisiert innerhalb derselben Transaktion. Globale E-Mail-Normalisierung, ausschliessliche Hashspeicherung von Einladungstoken, Tenant-Vorbereitung mit Pflicht-Plan, getrennte Vertragskontaktdaten, kontrollierte Einladungssperren und der AWS-KMS-TOTP-Pfad sind als Teilpakete umgesetzt. Der Backend-Build und 22 Unit-Tests sind erfolgreich. Vollständigkeitssperre beim Vertragsabschluss, Runtime-Login-Provisionierung, sichere Benutzer-Voranlage und Einladung, beide Vertragsabschlusswege sowie vollständige Ressourcen-, Pooling-, Integrations- und Sicherheitstests bleiben offen.
Legende der Detailcheckliste
Priorität
| Label |
Bedeutung |
| P0 |
Blocker – blockiert alles Weitere und ist sofort zu lösen |
| P1 |
Hoch – vor der nächsten Phase oder vor dem Go-live zu erledigen |
| P2 |
Mittel – wichtig, aber nicht unmittelbar blockierend |
| P3 |
Niedrig oder Backlog – kein akuter Zeitdruck |
Bereichsstatus
| Symbol |
Bedeutung |
| 🔴 |
Blockiert oder kritisch offen |
| 🟠 |
Offen mit ausstehenden Entscheidungen |
| 🟡 |
In Bearbeitung |
| 🟢 |
Abgeschlossen |
| ⬜ |
Noch nicht gestartet |
Aufgabenzustand
| Symbol |
Bedeutung |
[ ] |
Offen |
[~] |
In Bearbeitung |
[x] |
Erledigt |
Detaillierter Arbeitsstand
Die folgende Checkliste wurde aus der bisherigen PROJECT-STATUS.md übernommen. Sie enthält die operativen Aufgaben und Detailstände der einzelnen Projektbereiche.
Kurzübersicht: Was als nächstes
Dieser Abschnitt zeigt die wichtigsten nächsten Schritte über alle Domänen hinweg.
Detailbegründungen stehen in den Domänen-Abschnitten weiter unten.
| Prio |
Aufgabe |
Domäne |
| ~~P0~~ |
~~Supabase Dev-Datenbank verbinden (DATABASE_URL in .env)~~ |
~~Backend~~ ✅ |
| ~~P0~~ |
~~npx prisma validate lokal ausführen und Prisma-Schema technisch bestätigen~~ |
~~Datenbank~~ ✅ |
| ~~P0~~ |
~~Initiale Prisma-v4-Migration und überprüfte PostgreSQL-Ergänzungen erstellen~~ |
~~Datenbank~~ ✅ |
| ~~P0~~ |
~~Migrationsfolge gegen die PostgreSQL-Entwicklungsdatenbank ausführen und grundlegende RLS-Rollennachweise erbringen~~ |
~~Datenbank~~ ✅ |
| ~~P0~~ |
~~Backend-Build nach Zielmodellumstellung und erneuter Prisma-Client-Erzeugung wiederherstellen~~ |
~~Backend~~ ✅ |
| ~~P1~~ |
~~UC00 Backend: 2FA-Setup-Flow (3 fehlende Endpoints)~~ |
~~Backend~~ ✅ |
| P1 |
OnboardingService auf verbindliches persistentes Vier-Schritt-Modell umstellen |
Backend |
| P1 |
MailService-Abhängigkeiten reproduzierbar synchronisieren und sicheren Versand nach ADR-016 umsetzen |
Backend |
| ~~P1~~ |
~~Nicht personenbezogenen, idempotenten Basis-Seed erstellen und ausführen~~ |
~~Backend~~ ✅ |
| ~~P1~~ |
~~Prisma-Ausgangsbasis und Verantwortungsgrenzen formal als technische Wahrheit festlegen (ADR-009)~~ |
~~Datenbank~~ ✅ |
| ~~P1~~ |
~~User.email – global eindeutig oder tenant-bezogen? Entscheidung in ADR-011~~ |
~~Datenbank~~ ✅ |
| ~~P1~~ |
~~Globale E-Mail-Normalisierung, Konfliktbehandlung und sichere Einladungstoken umsetzen~~ |
~~Backend/Datenbank~~ ✅ |
| ~~P1~~ |
~~Prisma-Migrationen als führendes Deploymentverfahren festlegen (ADR-010)~~ |
~~Datenbank~~ ✅ |
| ~~P1~~ |
~~Providerneutrale RLS-Strategie festlegen (ADR-012)~~ |
~~Datenbank~~ ✅ |
| ~~P1~~ |
~~UC00-Zielschema aus Fachregeln, Nachverfolgbarkeitsmatrix und ADRs ableiten~~ |
~~Datenbank~~ ✅ |
| P1 |
Vorhandene AVV-Arbeitsvorlage extern juristisch prüfen und produktiv freigeben |
Compliance |
| P1 |
GDPR-Consent-Felder in customers ergänzen (GEM 03) |
Compliance |
1. Backend 🟡
NestJS-Grundstruktur und eine UC00-Teilimplementierung sind vorhanden.
Nach aktueller Prisma-Client-Erzeugung ist der Backend-Build erfolgreich. Zielmodell, Entwicklungsdatenbank-Rollout mit allen vier versionierten Migrationen und Basis-Seed sind nachgewiesen; fachliche Backend-Vervollständigung und vollständige Tests sind offen.
1.1 Infrastruktur & Konfiguration
| Prio |
Status |
Aufgabe |
| P0 |
[x] |
Supabase Dev-Verbindung einrichten: DATABASE_URL und DIRECT_URL in .env setzen |
| P1 |
[ ] |
.env.example vollständig prüfen und dokumentieren (JWT, Cookie, CORS, DB-Trennung Dev/Prod) |
| P1 |
[~] |
Getrennte Plattform-, Tenant- und Migrationszugänge dokumentiert und im Backend erzwungen; echte Runtime-Logins noch provisionieren und prüfen |
| P1 |
[ ] |
backend/src/common/prisma/prisma.module.ts separat prüfen |
| P1 |
[ ] |
backend/src/common/prisma/prisma.service.ts separat prüfen |
| P1 |
[ ] |
backend/src/app.module.ts separat prüfen |
| P2 |
[ ] |
backend/package.json auf Abhängigkeiten und Schwachstellen prüfen; npm meldet am 09.08.2026 37 Befunde, davon einen kritischen |
1.2 Prisma
| Prio |
Status |
Aufgabe |
| P0 |
[x] |
npx prisma validate lokal ausführen |
| P0 |
[x] |
npx prisma generate nach validate ausführen |
| P0 |
[x] |
Initiale Prisma-v4- und PostgreSQL-Schutzmigration erzeugen und mit npm run prisma:migrations:validate statisch prüfen |
| P1 |
[x] |
Historischen db pull-Nachweis durch aktuellen Inventur-, Migrations- und Laufzeitnachweis ersetzen |
| P0 |
[x] |
npm run build unmittelbar nach prisma generate am 10.08.2026 erfolgreich ausgeführt |
1.3 UC00 Business-Logik
| Prio |
Status |
Aufgabe |
| P1 |
[x] |
2FA-Setup-Flow: Endpoint GET /auth/2fa/setup implementiert |
| P1 |
[x] |
2FA-Setup-Flow: Endpoint POST /auth/2fa/verify-setup implementiert |
| P1 |
[x] |
2FA-Setup-Flow: Endpoint POST /auth/2fa/disable implementiert |
| P1 |
[~] |
OnboardingService: Teilstand vorhanden; Methodensignatur, Vier-Schritt-Modell, Pflichtprüfungen, Drafts und Abschlusslogik anpassen |
| P1 |
[~] |
Mail- und QR-Code-Abhängigkeiten in Paket- und Sperrdatei synchronisiert; Backend-Build erfolgreich, sicherer Hostpoint-Versand und Produktivnachweise offen |
| P1 |
[x] |
Freigegebenes UC00-Zielschema nach ADR-009, ADR-010 und ADR-012 kontrolliert gegen die Entwicklungsdatenbank migrieren |
| P1 |
[x] |
Getrennte Prisma-Runtime-Clients und transaktionsgebundenen Datenbankkontext implementieren und unit-testen |
| P1 |
[x] |
Globale E-Mail-Normalisierung und Konfliktbehandlung sowie ausschliessliche Hashspeicherung von Einladungstoken implementieren und unit-testen |
| P1 |
[ ] |
Manuelle Tests: Login, 2FA-Setup-Flow, Onboarding-Wizard, Tenant-Isolation |
| P1 |
[~] |
ADR-015: Tenant-Vorbereitung mit Pflicht-Plan und ohne Sofort-Einladung umgesetzt; Vertragsabschluss, sichere Benutzer-Voranlage und Admin-Einladung offen |
| P1 |
[~] |
ADR-015: Admin-Einladung ohne gültigen Vertragsnachweis mit 409 contract_not_accepted und bis zur sicheren Benutzer-Voranlage kontrolliert mit 503 tenant_admin_invitation_not_ready gesperrt; vollständige Einladung offen |
| P1 |
[ ] |
ADR-015: elektronischen Vertragsabschluss und kontrollierten Upload extern unterzeichneter Dokumente implementieren |
| P1 |
[ ] |
Einheitliches Vertragsmodell mit sechs Statuswerten, unveränderlichem Parteiensnapshot, PDF-Objektschlüssel und SHA-256-Hash implementieren |
| P1 |
[ ] |
Gehashten einmaligen Vertragstoken mit sieben Kalendertagen Laufzeit und Widerruf bei Neuanforderung implementieren |
| P1 |
[ ] |
Externen Upload und separate auditierte Superadmin-Prüfung implementieren; dieselbe Person darf in V1 beide Aktionen ausführen |
1.4 Seed & Testdaten
| Prio |
Status |
Aufgabe |
| P1 |
[x] |
Sicheren Basis-Seed für drei globale Vorlagen und vier Plan-Features erstellt; keine Personen-, Tenant- oder Geheimnisdaten |
| P1 |
[x] |
Basis-Seed nach kontrolliertem Datenbankaufbau erfolgreich ausführen |
| P2 |
[ ] |
Fachliche UC00- und UC01-Testdaten getrennt und kontrolliert für die jeweiligen Integrationstests aufbauen |
| P2 |
[x] |
Seed idempotent gestalten (upsert, mehrfach ausführbar) |
1.5 UC00-Testfluss
Alle Schritte aus docs/developer/uc00/UC00-BACKEND-STABILISIERUNG.md Kap. 5.
| Prio |
Status |
Aufgabe |
| P1 |
[ ] |
SuperAdmin Login / Logout / ungültiges Passwort |
| P1 |
[ ] |
Tenant erstellen, anzeigen, Status ändern, Plan abrufen/ändern |
| P1 |
[ ] |
Tenant-Admin-Einladung erzeugen, einlösen, bereits verwendete Einladung |
| P1 |
[ ] |
Refresh Token Rotation und Wiederverwendungserkennung |
| P1 |
[ ] |
Rollenprüfung SuperAdmin-Endpunkte + Tenant-Isolation |
1.6 RLS & Sicherheit
| Prio |
Status |
Aufgabe |
| P1 |
[~] |
Datenbankrollen ausgerollt und Prisma-Clients getrennt; nicht administrative Runtime-Logins provisionieren und gegen die Rollen prüfen |
| P1 |
[~] |
Getrennte Tenant- und Plattform-Prisma-Clients sowie Kontextwrapper umgesetzt; Runtime-Logins provisionieren und alle Dienste auf den passenden Pfad umstellen |
| P1 |
[~] |
Providerneutrale RLS-Policies mit ENABLE und FORCE ROW LEVEL SECURITY für 35 Tabellen ausgerollt; sieben Basisprüfungen erfolgreich, vollständige Testmatrix offen |
| P1 |
[ ] |
RLS-, Rollen-, Negativ- und Pooling-Isolationstests RLS-01 bis RLS-12 automatisieren |
| P2 |
[ ] |
Rate Limiting auf allen API-Endpoints prüfen |
1.7 Tests
| Prio |
Status |
Aufgabe |
| P2 |
[ ] |
Unit-Tests AuthService schreiben |
| P2 |
[~] |
Drei Unit-Tests für Tenant-Vorbereitung mit Pflicht-Plan sowie beide Einladungssperren vorhanden; weitere Tenant-Service-Pfade offen |
| P2 |
[ ] |
Unit-Tests Guards und Rollenprüfung schreiben |
| P2 |
[ ] |
Unit-Tests InvitationRedeem + Refresh Token Rotation |
| P1 |
[x] |
Fünf Unit-Tests für getrennte Prisma-Zugänge, transaktionslokalen Kontext und Konfigurationsverweigerung |
| P1 |
[ ] |
Integration- und E2E-Tests für Vertragsstatus, Abschlussnachweis, Upload und Einladungssperre gemäss ADR-015 |
| P1 |
[ ] |
Vertragstoken auf Sieben-Tage-Ablauf, Einmaligkeit und Widerruf sowie Statusersetzung erst nach neuer Annahme testen |
| P1 |
[ ] |
Vollständige rechtliche Bezeichnung und Vertragsanschrift vor AVV-Abschluss validieren; bei Lücke 409 contract_party_incomplete liefern |
| P1 |
[ ] |
Vertragskontakt, unterzeichnende Person und Tenant-Admin getrennt modellieren; dieselbe Person in mehreren Rollen zulassen |
| P2 |
[ ] |
Veröffentlichungsfreigaben für Kontakt-E-Mail, Festnetz und Mobilnummer getrennt und standardmässig deaktiviert umsetzen |
1.8 Vorhandene und historisch ausgeführte Arbeiten
| Status |
Aufgabe |
[x] |
NestJS-Grundstruktur (Module Auth, Tenants, Users, Onboarding) |
[x] |
Security-Basis: Helmet, CORS, Cookie Parser, ValidationPipe |
[x] |
Auth-Logik: Login, Logout, Refresh Token, 2FA (Login-Flow), Invitation Redeem |
[x] |
Tenant-Logik: Erstellung, Suche, Statuswechsel, Planverwaltung |
[x] |
package.json, package-lock.json und lokale Installation sind einschliesslich Mail-, QR-Code- und AWS-KMS-Abhängigkeiten synchronisiert |
[x] |
prisma validate am 09.08.2026 gegen die eingecheckte Prisma-Ausgangsbasis erfolgreich |
[x] |
prisma generate am 09.08.2026 erfolgreich (Prisma Client 5.22.0) |
[x] |
npm run build am 10.08.2026 nach prisma generate ohne TypeScript-Fehler erfolgreich |
[x] |
(this.prisma as any).recoveryCode – dynamischer Cast bereinigt |
[x] |
Supabase-Entwicklungszugang verbunden und PostgreSQL-17.6-Iststand kontrolliert inventarisiert |
[x] |
Historischen prisma db pull durch aktuellen Migrations-, Inventur- und RLS-Laufzeitnachweis ersetzt |
[x] |
Historischer Einsatz von prisma db push --accept-data-loss durch vier versionierte, kontrolliert angewendete Migrationen und aktuellen Zielmodellnachweis abgelöst |
[x] |
2FA-Setup-Flow: GET /auth/2fa/setup, POST /verify-setup, POST /disable |
[~] |
MailService und Abhängigkeiten sind vorhanden; sicherer Hostpoint-Versand, Bounce-Prozess und Produktivnachweise bleiben offen |
[~] |
OnboardingService als Teilstand vorhanden; Schrittmodell, Pflichtprüfungen, Drafts und Abschlusslogik weichen vom Fachentscheid ab |
[x] |
Persistentes Vier-Schritt-Onboarding und TenantProfile sind im formal validierten Prisma-v4-Zielschema modelliert |
[x] |
Initiale Prisma-v4- und PostgreSQL-Schutzmigration sind statisch geprüft und erfolgreich gegen Entwicklung ausgerollt |
[x] |
Sicherer Basis-Seed in prisma/seed.ts idempotent ausgeführt; nur versionierte Referenzdaten |
[x] |
PrismaService verwendet getrennte Plattform- und Tenant-Clients sowie parametrisierte, transaktionslokale Kontextwerte; fünf Unit-Tests erfolgreich |
[x] |
Zentrale E-Mail-Normalisierung, globale Konfliktprüfung und Einladungstoken-Hashspeicherung mit elf Unit-Tests und Datenbankprüfung DB-RLS-B08 erfolgreich |
[~] |
AWS-KMS-TOTP-Pfad mit drei Unit-Tests umgesetzt; produktive Schlüssel-, Rechte-, Rotations-, Integrations- und Ausfallnachweise offen |
[~] |
Tenant-Vorbereitung mit Pflicht-Plan, getrennte Vertragskontaktdaten und kontrollierte Einladungssperren mit drei Unit-Tests umgesetzt; Vollständigkeitssperre und vollständiger Vertrags-/Einladungspfad offen |
2. Datenbank / Schema 🟠
Das aktuelle backend/prisma/schema.prisma ist die technische Wahrheit des fachlich und technisch abgestimmten Prisma-v4-Zielmodells für UC00. Der kontrolliert ausgerollte Entwicklungsdatenbankstand ist im docs/developer/uc00/uc00-datenbank-iststand.md nachgewiesen.
Referenzdokumente: docs/developer/uc00/uc00-prisma-v4-zielschema.md und docs/developer/uc00/prisma-v3-validierung-offen.md
2.1 Technische Validierung des Prisma-v4-Zielschemas
| Prio |
Status |
Aufgabe |
| P0 |
[x] |
npx prisma validate lokal ausführen und Ergebnis dokumentieren |
| P0 |
[x] |
npx prisma generate nach validate ausführen |
| P0 |
[x] |
Initialmigration, PostgreSQL-Schutzmigration und statischen Migrationsvalidator erstellen |
| P0 |
[x] |
npm run build nach generate am 10.08.2026 erfolgreich bestätigt |
| P1 |
[x] |
Historischen db pull-Nachweis nach Freigabe des UC00-Zielmodells durch einen aktuellen Ist-Soll-Abgleich ersetzen |
2.2 Offene Schema-Entscheidungen
Quelle: docs/developer/database/schema-abgleich/db-schema-gegencheck-checkliste.md
Hinweis: Frühere konzeptionelle Entscheidungen wurden gegen die akzeptierten UC00-Fachregeln und das Prisma-v4-Zielschema neu zugeordnet. Migration und Laufzeitverhalten bleiben getrennt nachzuweisen.
| Prio |
Status |
Entscheidung |
| P1 |
[x] |
17 modellrelevante UC00-Regelbereiche gegen Prisma, OpenAPI, Backend und Tests nachverfolgt |
| P1 |
[x] |
Prisma-Ausgangsbasis und Grenzen ihrer technischen Wahrheit gemäss ADR-009 formal festgelegt |
| P1 |
[x] |
recovery_codes speichert im Prisma-v4-Zielschema ausschliesslich codeHash |
| P1 |
[x] |
notification_templates ist im Prisma-v4-Zielschema modelliert |
| P1 |
[x] |
InvitationToken.tokenType, Hash, Status und Lifecycle-Zeitpunkte sind im Prisma-v4-Zielschema konsistent modelliert |
| P1 |
[~] |
User.email global eindeutig gemäss ADR-011; Normalisierung, Fehlerbehandlung und Tests offen |
| P1 |
[~] |
customers.organization_id → entschieden: raus aus V1 (laut roadmap-schema-sync-2026-05-08.md), ADR fehlt |
| P1 |
[x] |
Prisma-Migrationen mit überprüften PostgreSQL-Ergänzungen gemäss ADR-010 als führendes Deploymentverfahren festgelegt |
| P1 |
[x] |
Providerneutrale RLS-Strategie für Supabase-Entwicklung und generisches Produktions-PostgreSQL gemäss ADR-012 festgelegt |
| P2 |
[~] |
UC01-Felder sind teilweise modelliert; formale Zuordnung und ADR fehlen |
| P2 |
[x] |
refresh_tokens, recovery_codes, notification_templates, plan_features in roadmap.md V1-Tabellenliste ergänzt ✅ |
2.3 Schema-Dokumente nachführen
| Prio |
Status |
Aufgabe |
| P2 |
[~] |
docs/developer/database/db-schema.md als historisch gekennzeichnet; nach Zielmodellfreigabe vollständig aktualisieren |
| P2 |
[x] |
database/README.md auf ADR-009 und ADR-010 ausgerichtet und vorhandene SQL-Dateien klassifiziert |
| P2 |
[x] |
database/schema-final.sql und weitere mutierende SQL-Dateien als historisch und nicht ausführbar gekennzeichnet |
| P2 |
[x] |
docs/developer/database/supabase-rls-strategy.md providerneutral neu gefasst und Policy-Matrix des aktuellen Schemas nachgeführt |
| P3 |
[x] |
Prisma-v4-Zielmodell, initiale Migration und PostgreSQL-Ergänzungen kontrolliert gegen Entwicklung ausgerollt |
2.4 Historische Schemaarbeiten
Die folgenden Angaben beschreiben nachweisbare Arbeiten aus Mai 2026. Sie bestätigen weder die Vollständigkeit des aktuellen UC00-Zielmodells noch einen aktuellen Datenbankstand.
| Status |
Aufgabe |
[x] |
18 Tabellen auf Supabase Dev installiert |
[x] |
Damaligen Schemaentwurf konzeptionell gegen UC00–UC09, UC-SA und UC18-Kompatibilität geprüft |
[x] |
db-schema.md v6 erstellt |
[x] |
db-schema-gegencheck-checkliste.md – 11 Prüfschritte durchgeführt |
[x] |
roadmap-schema-sync-2026-05-08.md – Roadmap-Korrekturbedarf dokumentiert |
[x] |
Damaligen Stand mit npx prisma validate technisch geprüft |
[x] |
Damaligen Ist-Soll-Diff zwischen Supabase und Schema analysiert |
[x] |
Damaligen Schemastand mit npx prisma db push auf Supabase synchronisiert |
[x] |
Schema um RecoveryCode, NotificationTemplate und PlanFeature ergänzt |
[x] |
Fachlich beschlossenes TenantProfile, TenantOnboarding, Schrittmodell und Tenant-Lifecycle in Prisma umgesetzt und formal validiert |
3. Use Cases ⬜
Alle UC-Spezifikationen (UC01–UC09, UC-SA) sind ausgearbeitet. Backend und Frontend sind noch nicht gestartet.
UC00 ist der aktive Use Case — alle anderen warten auf UC00-Abschluss.
3.1 UC00 – Tenant-Onboarding & Schulverwaltung 🟡
| Schritt |
Status |
| Steckbrief |
[x] Abgeschlossen |
| Screen-Flow & Wireframes (11 Screens) |
[x] Abgeschlossen |
| Datenmodell / Prisma-Zielschema |
[x] Fachlich und technisch abgestimmt, statisch validiert und kontrolliert gegen die Entwicklungsdatenbank ausgerollt |
| GEM-Reviews (Quality Gate) |
[x] 13/15 DONE → GO für Schritt 4 |
| OpenAPI 3.1 Spezifikation |
[x] Kanonischer UC00-Vertrag mit 33 Operationen, 61 Testfall-IDs und automatischer Strukturprüfung abgeschlossen; frühere vier Blöcke historisch |
| Backend Scaffolding |
[x] Abgeschlossen |
| Backend Business-Logik |
[~] In Bearbeitung – Auth, MailService und Onboarding-Teilstand vorhanden; Onboarding-Schritte, Pflichtprüfungen, Drafts, Abschluss und Tests anzupassen |
| Frontend (React) |
[ ] Offen |
| Testing (Jest + Cypress) |
[ ] Offen |
3.2 UC01 – Equipment erfassen ⬜
| Schritt |
Status |
| Spezifikation |
[x] Abgeschlossen |
| Screens (EQ-01 bis EQ-10) |
[x] Abgeschlossen |
| Backend |
[ ] Offen – startet nach UC00-Stabilisierung |
| Frontend |
[ ] Offen |
| Testing |
[ ] Offen |
3.3 UC02 – TÜV-Inspektion einreichen ⬜
| Schritt |
Status |
| Spezifikation v0.3 |
[x] Abgeschlossen (inkl. Praxisdokument-Abgleich PD-01) |
| Screens (TÜV-01 bis TÜV-08) |
[x] Abgeschlossen |
| Praxisanalyse (PD-01) |
[x] Abgeschlossen |
| Backend |
[ ] Offen |
| Frontend |
[ ] Offen |
| Testing |
[ ] Offen |
Offene fachliche Fragen UC02 (Quelle: docs/developer/praxisdokumente/pd01-flaschenpruefung-real-workflow.md Kap. 10):
| Prio |
Status |
Frage |
| P2 |
[ ] |
F1: Reparatur-/Füllauftrag als digitales Dokument in V1? |
| P2 |
[ ] |
F2: inspection_calendar_week als Batch-Gruppierung im UI nutzen? |
| P2 |
[ ] |
F3: wj_permanent_expansion_pct > 5% → auto-failed oder nur Warnung? |
| P2 |
[ ] |
F4: TÜV-Zeitraum-Symbol (◆) → ENUM oder Freitext? |
3.4 UC03 – Füll-Abo & Füllkarten-Verwaltung ⬜
| Schritt |
Status |
| Spezifikation |
[x] Abgeschlossen |
| Fachentscheidungen v0.4 |
[x] Abgeschlossen |
| Screens (FA-01 bis FA-15) |
[x] Abgeschlossen |
| Self-Service-Ergänzung |
[x] Abgeschlossen |
| Offene Punkte (OP-RR5, OP-SS6, OP-OQ7, u.a.) |
[~] Teilweise offen – siehe docs/developer/uc03/uc03-offene-punkte.md |
| Backend |
[ ] Offen |
| Frontend |
[ ] Offen |
| Testing |
[ ] Offen |
3.5 UC04 – Inhouse-Service erfassen ⬜
| Schritt |
Status |
| Spezifikation |
[x] Abgeschlossen |
| Screens (IS-01 bis IS-08) |
[x] Abgeschlossen |
| Backend |
[ ] Offen |
| Frontend |
[ ] Offen |
| Testing |
[ ] Offen |
3.6 UC05 – Fristen-Dashboard ⬜
| Schritt |
Status |
| Spezifikation |
[x] Abgeschlossen |
| Screens (FR-01 bis FR-08) |
[x] Abgeschlossen |
| Backend |
[ ] Offen |
| Frontend |
[ ] Offen |
| Testing |
[ ] Offen |
3.7 UC06 – Kunden einladen & Portal ⬜
| Schritt |
Status |
| Spezifikation |
[x] Abgeschlossen |
| Screens (KP-01 bis KP-08) |
[x] Abgeschlossen |
| Backend |
[ ] Offen |
| Frontend |
[ ] Offen |
| Testing |
[ ] Offen |
3.8 UC07 – Benachrichtigungen ⬜
| Schritt |
Status |
| Spezifikation |
[x] Abgeschlossen |
| Screens (BN-01 bis BN-08) |
[x] Abgeschlossen |
| Backend |
[ ] Offen |
| Frontend |
[ ] Offen |
| Testing |
[ ] Offen |
3.9 UC08 – Benutzerverwaltung ⬜
| Schritt |
Status |
| Spezifikation |
[x] Abgeschlossen |
| Screens (BU-01 bis BU-08) |
[x] Abgeschlossen |
| Backend |
[ ] Offen |
| Frontend |
[ ] Offen |
| Testing |
[ ] Offen |
3.10 UC09 – Berichte & Export ⬜
| Schritt |
Status |
| Spezifikation |
[x] Abgeschlossen |
| Screens |
[ ] Nicht vorhanden |
| Backend |
[ ] Offen |
| Frontend |
[ ] Offen |
| Testing |
[ ] Offen |
3.11 UC-SA – Superadmin-Panel ⬜
| Schritt |
Status |
| Spezifikation |
[x] Abgeschlossen |
| Screens (SA-01 bis SA-08) |
[x] Abgeschlossen |
| Backend |
[ ] Offen |
| Frontend |
[ ] Offen |
| Testing |
[ ] Offen |
3.12 UC18 – Equipment-Verleih ⬜ (V2/Backlog)
| Schritt |
Status |
| Spezifikation |
[x] Abgeschlossen |
| Screens |
[ ] Nicht vorhanden |
| V2-Kompatibilität im bisherigen Schemaentwurf berücksichtigt |
[x] Ja (keine V1-Tabellen) |
| Umsetzung |
[ ] V2/Backlog |
4. Compliance & GEM-Reviews 🟠
4.1 GEM-Reviews UC00 Quality Gate
| GEM |
Rolle |
Status |
Datei |
| GEM 01 |
Software-Architekt |
[x] DONE |
gem01-review.md |
| GEM 02 |
Coding-Assistent |
[~] Business-Logik implementiert – Review ausstehend |
– |
| GEM 03 |
Compliance-Wächter |
[x] DONE v1.1 |
gem03-review_claude.md |
| GEM 04 |
Normen-Engine |
[x] DONE v2.0 |
gem04-review_claude.md |
| GEM 05 |
Mobile-Workflow-Experte |
[x] DONE |
gem05-review.md |
| GEM 06 |
QA-Engineer |
[x] DONE |
gem06-review.md |
| GEM 07 |
Localization-Experte |
[x] DONE |
gem07-review.md |
| GEM 08 |
Modul-Integrator |
[x] DONE |
gem08-review.md |
| GEM 09 |
UX/UI Designer |
[x] DONE |
gem09-review.md |
| GEM 10 |
SaaS-Business-Manager |
[x] DONE |
gem10-review.md |
| GEM 11 |
DevOps / Infrastruktur |
[x] DONE |
gem11-review.md |
| GEM 12 |
Security-Experte |
[x] DONE |
gem12-review.md |
| GEM 13 |
Datenbank-Administrator |
[x] DONE |
gem13-review.md |
| GEM 14 |
Dokumentations-Manager |
[x] DONE |
gem14-review.md |
| GEM 00 |
Projektleitung |
[ ] Nach Abschluss Schritt 4 |
– |
4.2 GEM-Nacharbeiten (P1 – vor Go-Live)
Quelle: docs/developer/review/gem03-review_claude.md und gem04-review_claude.md
| Prio |
Status |
Aufgabe |
Quelle |
| P1 |
[~] |
Modulare AVV-Vorlage erstellt; juristische Prüfung und Produktivfreigabe vor erstem produktivem Tenant abschliessen |
GEM 03 |
| P1 |
[ ] |
GDPR-Consent-Felder in customers-Tabelle ergänzen (vor UC06) |
GEM 03 |
| ~~P1~~ |
[x] |
~~ADR-015: Datenschutzrollen und Prozess des Auftragsverarbeitungsvertrags dokumentieren~~ |
GEM 03 ✅ |
| ~~P1~~ |
[x] |
~~ADR-016: Hostpoint als V1-E-Mail-Provider auswählen und dokumentieren~~ |
GEM 03 ✅ |
| P1 |
[~] |
Datenkatalog UC00 erstellt; Abschnitte 1 bis 11 und Speicherfristen fachlich geprüft, Gesamtabnahme offen |
GEM 03 |
| P1 |
[ ] |
UC00-Authentifizierung auf Argon2id, verschlüsselte TOTP-Geheimnisse und gehashte Wiederherstellungscodes umstellen; Einladungstoken-Hashspeicherung ist abgeschlossen |
UC00 Abschnitt 7 |
| P1 |
[ ] |
UC00-Konto erst nach erfolgreicher 2FA aktivieren und temporäre 2FA-Sitzungen zentral und kurzlebig speichern |
UC00 Abschnitt 7 |
| P1 |
[ ] |
Rechtliche Tenant-Daten und operatives Schulprofil mit TenantProfile trennen |
UC00 Abschnitt 8 |
| P1 |
[~] |
Persistentes Vier-Schritt-Onboarding, Pflichtprüfungen, Drafts und Tenant-Lifecycle im Backend vereinheitlichen; Schema und OpenAPI sind abgeschlossen |
UC00 Abschnitt 8 |
| P1 |
[ ] |
Plattform-, Tenant-, Auth-, Zugriffs-, System-, Lösch- und Versandprotokolle minimiert und manipulationsgeschützt vereinheitlichen |
UC00 Abschnitt 9 |
| P1 |
[ ] |
Wiederherstellungscodes aus dem E-Mail-Versand entfernen und Logausfälle überwachen sowie sicher nachliefern |
UC00 Abschnitte 7/9 |
| P1 |
[~] |
Provider- und Unterauftragnehmerregister vollständig prüfen; aktuell kein produktiver Dienst approved |
UC00 Abschnitt 10 |
| P1 |
[~] |
Hostpoint-Produktivfreigabe abschliessen: Nutzungsbestätigung, Auftragsbearbeitungsvereinbarung, Volumen, Standorte, Unterauftragnehmer, Aufbewahrung und Löschung |
UC00-07-12 |
| P1 |
[ ] |
Hostpoint-SMTP, STARTTLS, Zertifikatsprüfung, SPF, DKIM, DMARC, Absenderrichtlinie und Bounce-Prozess umsetzen und testen |
ADR-016 |
| P1 |
[~] |
Hetzner Object Storage Nürnberg und AWS KMS Frankfurt vertraglich und datenschutzrechtlich prüfen; Support, Unterauftragnehmer, Löschung, Schlüsselbetrieb und Wiederherstellung vor Produktivbetrieb freigeben |
UC00-07-09, ADR-019 |
| P1 |
[~] |
Hetzner Object Storage Falkenstein als getrennten Backupstandort vertraglich und technisch freigeben; RPO, RTO, Löschung und Restore nachweisen |
UC00-07-09, ADR-020 |
| P1 |
[~] |
Grafana Cloud Pro Frankfurt vertraglich und datenschutzrechtlich freigeben; Data Processing Agreement (DPA, Auftragsverarbeitungsvertrag), Unterauftragnehmer, Support, Retention, Löschung, Filter und Alarmkette nachweisen |
UC00-07-09, ADR-021 |
| P1 |
[~] |
Eigenbetriebenen ClamAV-Scanservice gemäss ADR-022 härten und nachweisen; Support-, Notfall- und Auslandszugriffe gemäss ADR-023 umsetzen und dienstbezogen nachweisen |
UC00-07-09, ADR-022, ADR-023 |
| P1 |
[~] |
ADR-013 und ADR-019 umsetzen: private SSE-C-Ablage, AWS-KMS-Envelope-Encryption, 10-MB-Grenze, backendvermittelte Fünf-Minuten-Links und Malware-Prüfung |
UC00 |
| P1 |
[~] |
Alle 33 TOM umsetzen und vor Produktivbetrieb mit vollständigem Nachweisdatensatz wirksam prüfen; kritische Abweichungen vor Freigabe beheben |
UC00-07-10, UC00 Abschnitt 11 |
| P1 |
[ ] |
Zugriffsschutz, RLS, aktive Ratenbegrenzung, CSRF, zentrale Geheimnisverwaltung, TLS, Verschlüsselung und Serverhärtung umsetzen |
UC00 Abschnitt 11 |
| P1 |
[ ] |
PDF-Upload auf 10 MB begrenzen, in Quarantäne prüfen und über höchstens fünf Minuten gültige signierte Anwendungslinks backendvermittelt bereitstellen |
UC00 Abschnitt 11 |
| P1 |
[ ] |
ADR-020 umsetzen: WAL-PITR, tägliche und wöchentliche Sicherungen, RPO ≤ 1 Stunde, RTO ≤ 8 Stunden, tägliche Überwachung sowie quartalsweisen Restore betreiben |
UC00 Abschnitt 11 |
| P1 |
[ ] |
Vertragsabschluss erst nach dauerhafter konsistenter Speicherung von SQL-Datensatz, PDF-Objekt und Auditnachweis bestätigen; Teilausfälle kompensieren und alarmieren |
ADR-020 |
| P1 |
[ ] |
Grafana Alloy und Grafana Cloud Pro mit minimierten Metriken und Logs, externer Prüfung, vollständiger Alarmkette und monatlicher Kostenkontrolle umsetzen |
ADR-021 |
| P1 |
[~] |
Speicher- und Aufbewahrungsfristen fachlich festgelegt; Retention-Klassen, tägliche Löschläufe, Provider- und Backup-Löschung technisch umsetzen |
UC00-07-02 |
| P1 |
[~] |
Prüfbriefing für vorläufige zehnjährige RF-03-Vertragsfrist erstellt; endgültige Firma und Schweizer Einzelunternehmen sowie Pflichten für Deutschland, Schweiz und Österreich schriftlich juristisch bestätigen |
UC00-07-11 |
| P1 |
[ ] |
cylinder_details-Schema um EN 1802/1968-Pflichtfelder erweitern |
GEM 04 |
| P2 |
[x] |
DSFA-Schwellenprüfung für UC00 durchführen |
GEM 03 |
| P1 |
[ ] |
UC00-Schwellenprüfung vor Produktivbetrieb durch Datenschutzfachperson bestätigen und jährlich sowie bei Auslösern neu bewerten |
UC00-07-07 |
| P1 |
[ ] |
ADR-018 umsetzen: Audit-Schema bereinigen, Positivlisten erzwingen und täglichen kryptografischen Versiegelungsjob betreiben |
UC00-07-08 |
| P2 |
[x] |
Tenant-Offboarding-Flow mit ADR-017 fachlich definieren |
GEM 03 |
| P1 |
[ ] |
ADR-017 technisch umsetzen: Lifecycle, tenantweite Sperrung, Exportpaket, Benachrichtigungen, Löschlauf und Backup-Kontrolle |
UC00-07-04 |
| P2 |
[ ] |
GEM 12 + GEM 13 nach Recovery-Codes-Entscheidung erneut bewerten |
GEM Reviews |
5. Dokumentation 🟠
Mehrere historische Datenbankdokumente sind noch nicht mit dem Prisma-v4-Zielschema und dem tatsächlichen Datenbankstand konsolidiert.
5.1 Roadmap & Index
| Prio |
Status |
Aufgabe |
| P2 |
[~] |
docs/management/roadmap.md: V1-Tabellenliste erweitern – refresh_tokens, recovery_codes, notification_templates, plan_features ✅ erledigt; fill_subscriptions, fill_cards, fill_card_transactions, equipment_notes, equipment_identifiers noch offen |
| P2 |
[ ] |
docs/management/roadmap.md: customers.organization_id Aussage korrigieren (ist nicht in V1) |
| P2 |
[ ] |
docs/management/roadmap.md: UC18 als V2-Kompatibilitätsanforderung markieren |
| P2 |
[ ] |
docs/management/roadmap.md: Nächste-Schritte-Tabelle (Kap. 6) aktualisieren |
| P2 |
[ ] |
docs/index.md: UC02–UC09 und UC-SA als Einträge ergänzen |
| P2 |
[ ] |
docs/index.md: UC00-Datenmodell-Status korrigieren (nicht abgeschlossen) |
| P2 |
[ ] |
docs/index.md: UC01-Status mit Schema-Prüfhinweis ergänzen |
| P2 |
[x] |
Verbindlichen Aufbau, Terminologie und Statuswerte für UC-Dossiers definieren |
| P2 |
[x] |
Repository-weites UC-Artefaktinventar und wiederverwendbare Dossier-Vorlage erstellen |
| P2 |
[x] |
UC00 als Pilot-Dossier erstellen und im Dokumentationsindex verlinken |
| P2 |
[x] |
Automatisierte Struktur- und Linkprüfung für UC-Dossiers ergänzen |
| P1 |
[x] |
Verbindliche UC00-Abschlusscheckliste mit zehn Prüfgates und Nachweispflicht erstellen |
| P1 |
[x] |
Modellrelevante UC00-Nachverfolgbarkeitsmatrix gegen Prisma, OpenAPI, Backend und Testkriterien erstellen |
| P1 |
[x] |
Kanonischen UC00-OpenAPI-Vertrag und zentralen Testvertrag mit lückenloser automatischer Testfallzuordnung erstellen |
| P1 |
[~] |
UC00-Agenda UC00-07-03 bis UC00-07-11 fachlich bearbeitet; UC00-07-11 bleibt bis zur externen schriftlichen Rechtsfreigabe offen |
| P2 |
[ ] |
UC00-Pilot fachlich und redaktionell abnehmen |
| P2 |
[ ] |
Dossiers für UC01 bis UC08, UC-SA und UC18 aus derselben Vorlage erstellen |
| P2 |
[ ] |
Kanonischen Ordner und Spezifikationsablage für UC09 festlegen und Dossier erstellen |
| P2 |
[ ] |
Nach vollständigem Rollout die Dossier-Prüfung im strikten Modus verbindlich ausführen |
5.2 Datenbankdokumentation
| Prio |
Status |
Aufgabe |
| P2 |
[~] |
docs/developer/database/db-schema.md als historisch gekennzeichnet; nach Zielmodellfreigabe vollständig aktualisieren |
| P2 |
[x] |
database/README.md auf ADR-009 und ADR-010 ausgerichtet; Zielmodell- und Migrationsdetails werden über das UC00-Dossier geführt |
| P2 |
[x] |
database/schema-final.sql und weitere mutierende SQL-Dateien als historisch und nicht ausführbar gekennzeichnet |
| P3 |
[ ] |
Alte Verweise auf docs/developer/uc00-spezifikation.md (ohne Unterordner) prüfen |
5.3 CLAUDE.md
| Prio |
Status |
Aufgabe |
| P2 |
[ ] |
CLAUDE.md: Abschnitt 'Nächste Schritte' aktualisieren (UC03 ist ausgearbeitet, nicht mehr offen) |
| P2 |
[ ] |
CLAUDE.md: UC04–UC09 und UC-SA als ausgearbeitet markieren |
| P2 |
[ ] |
CLAUDE.md: Aktueller Arbeitsbranch-Hinweis aktualisieren |
5.4 Offene Backend-Dateiprüfungen
Quelle: docs/developer/database/schema-abgleich/db-schema-gegencheck-checkliste.md Kap. 4.2 – noch nicht geprüft
| Prio |
Status |
Datei |
| P2 |
[ ] |
backend/src/common/prisma/prisma.module.ts |
| P2 |
[ ] |
backend/src/common/prisma/prisma.service.ts |
| P2 |
[ ] |
backend/src/app.module.ts |
| P2 |
[ ] |
backend/.env.example |
| P2 |
[ ] |
backend/package.json |
| P3 |
[ ] |
CLAUDE.md (Schema-Konsistenz-Prüfung) |
6. Frontend ⬜
Frontend ist noch nicht gestartet. Startet nach UC00-Backend-Stabilisierung.
| Prio |
Status |
Aufgabe |
| P2 |
[ ] |
React-Frontend Grundstruktur aufsetzen |
| P2 |
[ ] |
Routing-Konzept implementieren (UUID-basiert, keine sequenziellen IDs) |
| P2 |
[ ] |
Design-System erstellen (GEM 09) |
| P3 |
[ ] |
UC00 Frontend implementieren |
| P1 |
[ ] |
ADR-015: Superadmin-Oberfläche für Vertragsstatus, elektronischen Abschluss und Upload externer Vertragsdokumente entwerfen und implementieren |
| P3 |
[ ] |
UC01–UC09, UC-SA Frontend (nach UC00) |
7. Offene Architekturentscheide (ADRs)
| Prio |
Status |
ADR |
Thema |
| ~~P1~~ |
[x] |
ADR-009 |
Prisma-Schema als technische Wahrheit der Anwendungsmodelle mit Grenzen zu Fachmodell, Migration und Datenbankstand akzeptiert ✅ |
| ~~P1~~ |
[x] |
ADR-010 |
Prisma-Migrationen mit überprüften PostgreSQL-Ergänzungen als führendes Deploymentverfahren akzeptiert ✅ |
| P1 |
[~] |
ADR-011 |
Globale E-Mail-Eindeutigkeit, zentrale Normalisierung, Konfliktbehandlung und Einladungstoken-Hashspeicherung umgesetzt; vollständige Integrations- und End-to-End-Tests offen |
| ~~P1~~ |
[x] |
ADR-012 |
Providerneutrale RLS mit getrennten Datenbankrollen und transaktionsgebundenem Tenant-Kontext akzeptiert ✅ |
| P1 |
[~] |
ADR-013 |
Private PDF-Vertragsablage akzeptiert; Anbieterwahl gemäss ADR-019 entschieden, technische Umsetzung offen |
| P1 |
[~] |
ADR-015 |
Auftragsverarbeitungsvertrag und Datenschutzrollen akzeptiert; juristische Prüfung und technische Umsetzung offen |
| ~~P1~~ |
[x] |
ADR-016 |
Hostpoint als V1-E-Mail-Provider akzeptiert; Produktivsperre und Umsetzung separat offen ✅ |
| P1 |
[~] |
ADR-019 |
Hetzner Object Storage und AWS KMS akzeptiert; Produktivnachweise und technische Umsetzung offen |
| P1 |
[~] |
ADR-020 |
Backup und Wiederherstellung akzeptiert; Produktivnachweise, Umsetzung und Restore-Tests offen |
| P1 |
[~] |
ADR-021 |
Grafana Cloud Pro und Monitoringkostenkontrolle akzeptiert; Produktivnachweise, Umsetzung und Alarmtests offen |
| P1 |
[~] |
ADR-022 |
Eigenbetriebene Malware-Prüfung akzeptiert; Härtung, Umsetzung, Ressourcen- und Wirksamkeitsnachweise offen |
| P1 |
[~] |
ADR-023 |
Support-, Notfall- und Auslandszugriffsmodell akzeptiert; Provider-, Umsetzung- und Zugriffsnachweise offen |
Das verbindliche Register wird unter docs/developer/adr/README.md geführt. ADR-006, ADR-007, ADR-008, ADR-011, ADR-013, ADR-015, ADR-016, ADR-017, ADR-018, ADR-019, ADR-020, ADR-021, ADR-022 und ADR-023 sind akzeptiert; Produktivnachweise, Implementierung und Tests werden getrennt nachgeführt.
Historische Arbeitsnotizen
Diese aus dem früheren Statusdokument übernommenen Notizen bleiben als historische Belege erhalten. Die verbindliche Änderungshistorie steht im Dokumentenkopf.
| Datum, Uhrzeit |
Änderung |
| 13.05.2026 20:08 |
Business-Logik UC00: 2FA-Setup-Flow (3 Endpoints), MailService (nodemailer), OnboardingService (vollständig), schema.prisma v4 (OnboardingStep + onboardingCompletedAt), Seed-Script erstellt |
| 13.05.2026 17:30 |
Supabase verbunden, prisma validate/generate/db push erfolgreich, schema.prisma v3 um RecoveryCode/NotificationTemplate/PlanFeature ergänzt, roadmap.md V1-Tabellen nachgeführt, P0-Blocker geschlossen |
| Mai 2026 |
Initiale Erstellung – konsolidiert aus roadmap.md, GEM-REVIEW-STATUS.md, UC00-BACKEND-STABILISIERUNG.md, db-schema-gegencheck-checkliste.md, prisma-v3-validierung-offen.md, uc03-offene-punkte.md, pd01-flaschenpruefung-real-workflow.md |