DiveLogix360 – UC00-Nachverfolgbarkeitsmatrix¶
Stand: 10.08.2026 20:00 Branch: main Status: Aktiv
| Datum, Uhrzeit | Version | Änderung | Autor |
|---|---|---|---|
| 10.08.2026 20:00 | 1.12 | Sicheren UC00-Merge-Stand nach main übernommen und Branch-Nachführung ergänzt |
Codex |
| 10.08.2026 19:46 | 1.11 | Sichere Tenant-Vorbereitung, vierte Migration, kontrollierte Einladungssperren, AWS-KMS-TOTP-Pfad und erfolgreichen Build abgegrenzt sowie unsichere Vertragsnachweise zurückgenommen | Codex |
| 09.08.2026 19:10 | 1.10 | Vertragsgebundene Einladungssperre (M-02, M-05, M-06) als code-seitig umgesetzt, aber ohne Datenbank- und Laufzeitnachweis nachgeführt | Claude |
| 09.08.2026 17:32 | 1.9 | Zentrale E-Mail-Normalisierung, globale Konfliktbehandlung und ausschliessliche Einladungstoken-Hashspeicherung für M-01, M-06 und M-08 nachgeführt | Codex |
| 09.08.2026 16:40 | 1.8 | Getrennte Prisma-Runtime-Clients und transaktionsgebundenen Kontextwrapper für M-16 nachgeführt | Codex |
| 09.08.2026 16:25 | 1.7 | Entwicklungsdatenbank-Rollout, Basis-Seed und grundlegende RLS-Laufzeitprüfung für M-16 und M-17 nachgeführt | Codex |
| 09.08.2026 15:43 | 1.6 | Kanonischen UC00-OpenAPI- und Testvertrag gegen alle modellrelevanten Regelbereiche nachgeführt | Codex |
| 09.08.2026 15:22 | 1.5 | Migrations-, Constraint-, Tenant-Fremdschlüssel- und RLS-Abdeckung für M-01 bis M-17 nachgeführt | Codex |
| 09.08.2026 14:41 | 1.4 | Prisma-v4-Zielschema gegen alle 17 Regelbereiche geprüft und Modellabdeckung nachgeführt | Codex |
| 09.08.2026 14:24 | 1.3 | ADR-012 als akzeptierten Nachweis für die providerneutrale RLS-Strategie nachgeführt | Codex |
| 09.08.2026 14:10 | 1.2 | ADR-010 als akzeptierten Nachweis für das führende Deploymentverfahren nachgeführt | Codex |
| 09.08.2026 14:01 | 1.1 | ADR-009 als akzeptierten Nachweis für die technische Schemawahrheit nachgeführt | Codex |
| 09.08.2026 13:54 | 1.0 | Modellrelevante UC00-Fachregeln gegen Prisma, OpenAPI, Backend und Testkriterien abgeglichen | Codex |
Zweck: Begrenzte Nachverfolgbarkeit der für das UC00-Zielmodell relevanten Regeln und ihrer tatsächlichen technischen Abdeckung.
Abgrenzung: Die Matrix ersetzt weder die fachliche Spezifikation noch den Datenkatalog, das Prisma-Schema, OpenAPI oder die Abschlusscheckliste.
1. Führende Quellen und Auswertungsregel¶
| Informationsart | Führende Quelle |
|---|---|
| Fachliche Regeln und Akzeptanz | UC00-Spezifikation |
| Daten, Zwecke, Schutz und Fristen | UC00-Datenkatalog und zentrale Compliance-Dokumente |
| Akzeptierte Architekturentscheidungen | ADR-Register und verlinkte Einzeldateien |
| Eingechecktes Datenbankschema | Prisma-Schema |
| Programmierschnittstellen | Kanonischer UC00-OpenAPI-Vertrag und UC00-API-Testvertrag |
| Tatsächliche Backend-Teilimplementierung | backend/src |
| Abnahmereife | UC00-Abschlusscheckliste |
Bei einem Widerspruch wird die fachliche Vorgabe nicht aus einem älteren technischen Artefakt abgeleitet. Akzeptierte Fachregeln werden in die technischen Zielartefakte überführt; historische Fertigmeldungen gelten nicht als Umsetzungsnachweis.
2. Statuswerte der Matrix¶
| Status | Bedeutung |
|---|---|
| Entspricht | Das Artefakt bildet die zugeordnete Regel für den geprüften Umfang ab. |
| Teilweise | Ein verwertbarer Teil ist vorhanden; wesentliche Anforderungen fehlen. |
| Fehlt | Für die Regel ist keine belastbare Abbildung vorhanden. |
| Widerspricht | Das Artefakt bildet einen fachlich überholten oder unzulässigen Zustand ab. |
| Nicht anwendbar | Die Regel gehört nicht in dieses Artefakt. |
3. Modellrelevante Nachverfolgbarkeit¶
| ID | Regelbereich und führende Fachquellen | Prisma | OpenAPI | Backend | Abnahme und Ergebnis |
|---|---|---|---|---|---|
| M-01 | Globale Benutzeridentität, Normalisierung und E-Mail-Konflikt: G1/G36, ADR-011 | Entspricht: User.email ist global eindeutig; Datenbank-Checks erzwingen die gespeicherte Normalform und ein partieller Index verhindert parallele offene Einladungen derselben Adresse. |
Entspricht: Normalisierung und 409 email_already_in_use gelten an Login-, Admin- und Mitarbeitereinladungsgrenzen. |
Entspricht: zentrale Normalisierung, globale Prüfung einschliesslich deaktivierter und soft-gelöschter Benutzer sowie kontrollierte Datenbankkonflikte sind in Einladung, Login, Einlösung und Benutzeränderung umgesetzt. | UC00-05-01 und UC00-08-01 erledigt; UC00-09-09 mit elf Unit- und einem Datenbank-Laufzeittest in Bearbeitung, vollständige Integrations- und End-to-End-Tests offen. |
| M-02 | Vorbereitender Tenant, vollständige Vertragspartei und getrennter Vertragskontakt: G15–G27, ADR-015 | Entspricht: rechtliche Tenant-Daten, Vertragskontakt und operatives Profil sind getrennt modelliert; Tenant.contractContactName/contractContactEmail mit Migration 20260809180000_uc00_contract_party_contact_fields gegen Entwicklung ausgerollt. |
Entspricht: vorbereitende Tenant-Anlage mit verpflichtendem Plan-Typ, getrennte Vertragspartei und contract_party_incomplete sind abgebildet. |
Teilweise: Tenant-Anlage speichert den verpflichtenden Plan-Typ, getrennte Vertragskontaktdaten und erzeugt keine unmittelbare Admin-Einladung. Integrationsnachweis, Abschlussendpunkt, Vollständigkeitssperre und Frontend fehlen. | UC00-04-02 und UC00-05-05 erledigt; UC00-08-02, UC00-08-08 bis UC00-08-10 bleiben mit Teilfortschritt offen, siehe KIToDo. |
| M-03 | Vertragsinstanz, sechs Statuswerte, Parteiensnapshot, Versionierung und Ersetzung: G29/G31/G35, ADR-015 | Entspricht: TenantContract und Vertragsenums bilden Lifecycle, Snapshot und Ersetzung ab. |
Entspricht: Vertragsliste, Anforderung, elektronische Annahme, Upload und getrennte Prüfung bilden Status, Versionierung und Ersetzung ab. | Fehlt: Der unsichere elektronische Zwischenstand wurde entfernt; vollständige elektronische und externe Abschlusswege sind nicht implementiert. | UC00-05-02 erledigt; UC00-08-03, UC00-08-11 und UC00-09-07 bleiben offen. |
| M-04 | Unveränderliche PDF-Kopie, Objektschlüssel, SHA-256, Upload- und Prüfmetadaten: G32–G35, G89/G90, ADR-013, ADR-019, ADR-022 | Entspricht: ContractDocument enthält Objekt-, Hash-, Datei-, Scan- und Prüfmetadaten. |
Entspricht: PDF-Grenze, Quarantänestatus, SHA-256 und getrennte Prüfentscheidung sind spezifiziert; Objektschlüssel bleiben intern. | Fehlt. | UC00-05-08 erledigt; UC00-08-13, UC00-08-46, UC00-09-08, UC00-09-25, UC00-09-38 bleiben offen. |
| M-05 | Elektronischer Vertragstoken: sieben Kalendertage, Hash, Einmaligkeit und Widerruf: G30 | Entspricht: eigenes ContractAcceptanceToken-Modell mit Hash und Lifecycle-Zeitpunkten; Datenbank-Check begrenzt die Laufzeit auf sieben Tage. |
Entspricht: Sieben-Tage-Laufzeit, Einmaligkeit und Widerruf bei Neuanforderung sind verbindlich beschrieben. | Fehlt: Der nicht ausreichend abgesicherte Zwischenstand wurde entfernt. | UC00-05-07 erledigt; UC00-08-12 und UC00-09-08 bleiben offen. |
| M-06 | Tenant-Admin-Einladung erst nach akzeptiertem Vertrag; 72-Stunden-Token: G15/G17/G22/G41 | Entspricht: Hash, Tokenart, Status, Ablauf, Verwendung und Widerruf sind modelliert; die Vertragssperre bleibt eine Backend-Regel. | Entspricht: getrennte Admin-Einladung, 72-Stunden-Regel und 409 contract_not_accepted sind spezifiziert. |
Teilweise: Die Admin-Einladung wird nicht bei Tenant-Anlage erzeugt und ist ohne akzeptierten Vertrag mit 409 contract_not_accepted gesperrt. Nach akzeptiertem Vertrag bleibt sie bis zur sicheren Benutzer-Voranlage kontrolliert mit 503 tenant_admin_invitation_not_ready blockiert; Benutzeranlage, user_id, Token und Versand fehlen. |
UC00-05-03 und die allgemeine Hashspeicherung UC00-08-18 sind erledigt; UC00-08-02, UC00-09-07 und vollständige Token-Sicherheitstests bleiben offen. |
| M-07 | Benutzerstatus invited bis erfolgreich geprüfte Zwei-Faktor-Authentifizierung; lastLoginAt erst nach vollständigem Login: G37/G44 |
Teilweise: Status- und Zeitfelder vorhanden. | Entspricht: Aktivierung erfolgt erst nach Passwort-, TOTP- und Wiederherstellungscode-Setup; Loginzeitpunkt folgt erst auf vollständige Anmeldung. | Widerspricht: Einladungseinlösung setzt den Benutzer bereits vor der Zwei-Faktor-Einrichtung auf active. |
OpenAPI-Vertrag erledigt; UC00-08-14, UC00-09-10 bleiben offen. |
| M-08 | Argon2id, verschlüsseltes TOTP-Geheimnis, gehashte Recovery- und Einladungscodes, rotierte Sitzungen: G39–G45 | Entspricht für die Modellstruktur: verschlüsseltes TOTP-Feld, Schlüsselversion sowie ausschliessliche Hashfelder für Codes und Token sind vorhanden; Algorithmus und Rotation bleiben Backend-Aufgaben. | Entspricht auf Vertragsebene: sichere Einrichtung, einmalige Recovery-Codes und Sitzungsrotation sind spezifiziert; geheime Speicherwerte werden nicht ausgegeben. | Teilweise: Einladungstoken und Recovery-Codes verwenden Hashfelder; TOTP-Geheimnisse werden über AWS KMS mit gebundenem Kontext verschlüsselt. Bcrypt, Versandfunktion für Recovery-Codes, Sitzungsrotation sowie produktive Schlüssel-, Rechte-, Rotations-, Integrations- und Ausfallnachweise bleiben offen. | UC00-08-18 erledigt; UC00-08-16 und UC00-09-11 in Bearbeitung; die übrigen zugeordneten Kriterien bleiben offen. |
| M-09 | Rechtliche Tenant-Daten getrennt vom operativen Eins-zu-eins-Schulprofil: G46/G47/G54/G56 | Entspricht: TenantProfile ist getrennt und über tenantId eindeutig zugeordnet. |
Entspricht: Vertragspartei und operatives Schulprofil haben getrennte Operationen und Schemas; einzelne Veröffentlichungsfreigaben sind abgebildet. | Widerspricht: Onboarding überschreibt rechtlichen Namen und Vertragsanschrift. | OpenAPI-Vertrag erledigt; UC00-08-22, UC00-08-26, UC00-09-12, UC00-09-14 bleiben offen. |
| M-10 | Persistentes Vier-Schritt-Onboarding mit school_profile, contact_details, first_employee, confirmation: G48–G57 |
Entspricht: Gesamtstatus und vier persistente Schrittarten mit Zeitpunkten sind vorhanden. | Entspricht: genau vier Schrittwerte, typisierte Payloads, Drafts und Abschlussoperation sind spezifiziert. | Widerspricht: drei andere Schritte, keine Persistenz, freie any-Payload und vorzeitige Tenant-Aktivierung. |
UC00-08-23 bis UC00-08-27, UC00-09-13, UC00-09-14 bleiben offen. |
| M-11 | Tenant-Lifecycle einschliesslich contract_pending, onboarding, active, offboarding_export, retention_only und Reaktivierungsgrenze: G53/G99/G109–G114, ADR-017 |
Entspricht: Statusenum, TenantOffboarding, TenantExport und Fristfelder bilden das Ziel ab. |
Entspricht: kontrollierte Statusänderung, Onboarding-Aktivierung, Offboarding, 30-Tage-Export, 90-Tage-Löschgrenze und Exportzugriff sind spezifiziert. | Widerspricht: alte Statusmaschine und direkte Aktivierung. | UC00-05-04 erledigt; UC00-08-27, UC00-08-56 bis UC00-08-59, UC00-09-34, UC00-09-35 bleiben offen. |
| M-12 | Getrennte, minimierte und revisionsfähige Auth-, Audit-, Access-, System-, Lösch- und Versandprotokolle: G58–G69/G115–G118, ADR-018 | Entspricht für Modell und statische Datenbankregeln: getrennte Protokolle, Scope-Checks, minimierte Felder, append-only-Rechte und AuditSeal sind vorhanden. |
Teilweise: request_id, minimierte Fehler und sicherheitsrelevante Zustände sind im externen Vertrag abgebildet; interne Ereignisschemas sind nicht Bestandteil der öffentlichen API. |
Widerspricht: Auth-Log-Ausfall wird still verworfen; freie Fehlertexte und geheime Empfängerwerte können protokolliert werden. | UC00-08-29 bis UC00-08-36, UC00-08-60, UC00-08-61, UC00-09-15 bis UC00-09-18, UC00-09-36, UC00-09-37; Backend und Laufzeittests bleiben offen. |
| M-13 | Retention-Klassen, retainUntil, begründeter legal_hold und koordinierte Löschung: G97–G104 |
Entspricht für das Zielmodell: RF-01 bis RF-22, Fristfelder, LegalHold und RetentionRun sind vorhanden. |
Teilweise: Offboarding- und Exportfristen sind nach aussen spezifiziert; interne Retention-Jobs und Legal-Hold-Verwaltung sind keine UC00-V1-Schnittstelle. | Fehlt: kein zentraler täglicher Retention-Job. | UC00-08-52, UC00-08-53, UC00-09-30, UC00-09-31; Löschorchestrierung bleibt offen. |
| M-14 | Zeitbegrenzte interne, tenantfreigegebene und Notfall-Supportzugriffe: G136–G140, ADR-023 | Entspricht: SupportAccessGrant enthält Typ, Status, Zweck, Umfang, Freigabe, Ablauf, Widerruf und Notfallprüfung. |
Fehlt. | Fehlt. | UC00-08-40, UC00-09-21; Backend und Prüfungen bleiben offen. |
| M-15 | Dauerhafte Vertragsbestätigung, Backup-, Malware- und Monitoringnachweise: G123–G135, ADR-020 bis ADR-022 | Nicht anwendbar für den Grossteil der Infrastrukturkonfiguration; Vertrags- und Auditstatus benötigen jedoch persistente Referenzen. | Teilweise: Upload-, Quarantäne-, Scan- und Vertragsstatus sind spezifiziert; interne Backup- und Monitoringnachweise bleiben ausserhalb der öffentlichen API. | Fehlt. | UC00-08-47, UC00-08-48, UC00-08-62 bis UC00-08-64, UC00-09-26, UC00-09-27, UC00-09-40 bis UC00-09-42; nach Kernmodell als Betriebsintegration umsetzen. |
| M-16 | Standardverweigerung, Rollen-, Tenant- und Ressourcenprüfung sowie RLS als zusätzliche Schutzschicht: G82/G83, ADR-012 | Teilweise umgesetzt: tenantkonsistente Relationen, drei Datenbankrollen, minimale Grants, Kontextfunktionen, ENABLE und FORCE RLS sind ausgerollt; Standardverweigerung, grundlegende Tenant-Isolation und Plattformtrennung wurden zur Laufzeit geprüft. |
Entspricht auf Vertragsebene: Rollen, Standardverweigerung sowie generische 403- und 404-Antworten ohne fremde Existenzinformation sind festgelegt; RLS bleibt interne Schutzschicht. |
Teilweise umgesetzt: getrennte Prisma-Clients, Konfigurationssperren und Transaktionswrapper sind mit fünf Unit-Tests vorhanden; Runtime-Login-Provisionierung, Dienstumstellung und vollständige Autorisierung fehlen. | UC00-04-05 und UC00-06-05 erledigt; Basisnachweis vorhanden, UC00-08-41, UC00-09-03, UC00-09-23 sowie vollständige Runtime-, Ressourcen- und Pooling-Tests bleiben offen. |
| M-17 | Führendes Schema- und Deployment-Verfahren | Umgesetzt für Entwicklung: Vier Migrationen sind versioniert, statisch geprüft und gegen die Entwicklungsdatenbank ausgerollt. | Nicht anwendbar. | Teilweise: generierter Client, nicht personenbezogener Basis-Seed und Backend-Build entsprechen dem aktuellen Zwischenstand; vollständige Fachimplementierung fehlt. | UC00-04-01, UC00-04-03, UC00-04-04, UC00-04-06, UC00-06-03 und UC00-06-04 erledigt; Backend-Vervollständigung und produktiver Rollout bleiben offen. |
4. Eindeutig aufgelöste Altwidersprüche¶
Für die folgenden Punkte ist kein neuer Fachentscheid erforderlich, weil eine jüngere akzeptierte Regel eindeutig vorliegt:
| Widerspruch | Verbindliche Auflösung |
|---|---|
| G1 beschränkte die E-Mail-Eindeutigkeit sprachlich auf Tenant-Admins. | ADR-011 und G36 gelten global für alle Benutzerkonten. |
| Fehlerfall F5 wollte bei fehlgeschlagenem Einladungsversand den Tenant nicht anlegen. | Der Tenant und der akzeptierte Vertrag bestehen bereits vor der Einladung. Bei Versandfehler bleibt der Tenant im Status onboarding; die Einladung bleibt kontrolliert wiederholbar. |
OE1 und das alte Schema-Delta meldeten token_type und gehashte Recovery-Codes als ausgeführt beziehungsweise produktionsbereit. |
Das Prisma-v4-Zielschema und die Entwicklungsdatenbank enthalten nun InvitationToken.tokenType, InvitationToken.tokenHash und RecoveryCode.codeHash; Backend und Tests bleiben offen. |
| OpenAPI und Backend verwenden drei beziehungsweise sechs ältere Onboarding-Schritte. | G48 bis G57 legen genau vier Schritte und deren Semantik verbindlich fest. |
| Frühere Unterlagen meldeten das Prisma-Schema gleichzeitig als V2, V3 und V4. | Der alte Stand ist als Prisma-Ausgangsbasis eingeordnet; „Prisma v4“ bezeichnet seit 09.08.2026 14:41 ausschliesslich das fachlich und technisch abgestimmte UC00-Zielschema. |
5. Technische Entscheidungsgrundlage¶
Die Matrix bestätigt die bereits festgelegte Reihenfolge:
- ADR-009 grenzt fachliche Wahrheit, technische Schemawahrheit, generierte Artefakte und Datenbankzustand verbindlich voneinander ab.
- ADR-010 legt Prisma-Migrationen mit überprüften PostgreSQL-Ergänzungen als reproduzierbaren Deploymentweg fest.
- ADR-012 legt die zusätzliche providerneutrale RLS-Schicht für Entwicklungs- und Produktions-PostgreSQL fest.
- Das Prisma-v4-Zielschema wurde aus diesen Grundlagen abgeleitet, formal validiert und gegen alle 17 Regelbereiche geprüft.
- Initiale Migration und PostgreSQL-Ergänzungen sind erstellt und statisch geprüft.
- Kanonischer OpenAPI- und Testvertrag sind aus Zielmodell und Fachregeln abgeleitet und strukturell geprüft.
- Entwicklungsdatenbank mit vier Migrationen, Basis-Seed, globale E-Mail- und Einladungstokenlogik sowie der erfolgreiche Backend-Build sind reproduzierbar nachgewiesen. Die acht grundlegenden Datenbank-Laufzeitprüfungen waren nach der dritten Migration erfolgreich; ihre Wiederholung nach der vierten Migration ist wegen der nicht erreichbaren Runtime-Verbindung offen. Als Nächstes folgt die Integration des sicheren Tenant-Vorbereitungspakets; danach Benutzer-Voranlage, Admin-Einladung und vollständige Vertragsabschlusswege.
6. Ergebnis der Fachprüfung¶
Die Prüfung hat keine neue fachliche Mehrdeutigkeit ergeben. Die offenen Punkte sind technische Modellierungs-, Migrations-, Schnittstellen-, Implementierungs- oder Nachweisaufgaben. Externe Rechts- und Sicherheitsfreigaben bleiben davon unberührt und dürfen nicht durch die technische Umsetzung ersetzt werden.
Die Matrix ist erfüllt, wenn jede Zeile entweder den Status Entspricht in allen anwendbaren Zielartefakten erreicht oder mit einer ausdrücklich akzeptierten und dokumentierten Ausnahme begründet ist.