DiveLogix360 – UC00-API-Testvertrag¶

Stand: 09.08.2026 15:43 Branch: main Status: Verbindlich

Datum, Uhrzeit	Version	Änderung	Autor
09.08.2026 15:43	1.0	Verbindlichen Testvertrag für alle Operationen des kanonischen UC00-OpenAPI-Vertrags erstellt	Codex

Zweck: Dieser Vertrag ordnet jeder Operation der kanonischen UC00-OpenAPI-Spezifikation stabile Abnahmetest-IDs und das erwartete Verhalten zu.

Abgrenzung: Die Zuordnung ist verbindliche Testgrundlage. Sie ist noch kein Nachweis einer ausgeführten Implementierung oder eines bestandenen Laufzeittests.

1. Verbindliche Konventionen¶

Eingehende E-Mail-Adressen werden vor Prüfung und Speicherung durch Entfernen äusserer Leerzeichen und Kleinschreibung normalisiert.
Authentifizierungsfehler geben keine Auskunft darüber, ob ein Konto, Tenant, Vertrag oder Token existiert, soweit kein fachlich erforderlicher Statusfehler vorgesehen ist.
Fehler verwenden den strukturierten Fehlervertrag mit stabilem code, HTTP-Status und request_id.
Rollen-, Tenant- und Ressourcenprüfung folgen dem Prinzip der Standardverweigerung. Row-Level Security (RLS, zeilenbasierte Zugriffskontrolle) ist eine zusätzliche Datenbankschutzschicht.
Token, Passwörter, Wiederherstellungscodes, TOTP-Geheimnisse und vollständige Vertragsdokumente dürfen nicht protokolliert oder per E-Mail übertragen werden.
Tenant-Admin-Einladungen sind erst nach erfolgreich akzeptiertem Auftragsverarbeitungsvertrag (AVV) zulässig.

2. Testfallzuordnung¶

Operation	Test-IDs	Verbindliches Abnahmeziel
`POST /auth/login`	`API-UC00-01`, `API-UC00-02`, `API-UC00-03`	Normalisierte Anmeldung; Zwei-Faktor-Challenge bei aktivierter Zwei-Faktor-Authentifizierung; generische Ablehnung ungültiger Zugangsdaten
`POST /auth/login/2fa`	`API-UC00-04`, `API-UC00-05`	Vollständige Anmeldung nur mit gültiger Challenge und gültigem zeitbasiertem Einmalpasswort; ungültige oder abgelaufene Challenge wird abgewiesen
`POST /auth/login/recovery`	`API-UC00-06`, `API-UC00-07`	Einmalige Nutzung eines gehashten Wiederherstellungscodes; Wiederverwendung oder ungültiger Code wird abgewiesen
`POST /auth/token/refresh`	`API-UC00-08`, `API-UC00-09`	Rotierte Sitzung bei gültigem Refresh-Token; Wiederverwendung oder Widerruf wird erkannt und abgewiesen
`POST /auth/logout`	`API-UC00-10`	Sitzung und Refresh-Token werden kontrolliert widerrufen
`GET /auth/invite/{token}`	`API-UC00-11`, `API-UC00-12`	Gültige Einladung liefert nur notwendige Metadaten; ungültige, verwendete, widerrufene oder abgelaufene Einladung wird abgewiesen
`POST /auth/invite/{token}/accept`	`API-UC00-13`, `API-UC00-14`, `API-UC00-15`	Passwort und Zwei-Faktor-Authentifizierung werden sicher eingerichtet; Benutzer wird erst nach vollständiger Prüfung aktiv; Wiederherstellungscodes werden einmalig ausgegeben
`GET /superadmin/tenants`	`API-UC00-16`	Nur Superadmins erhalten eine paginierte, minimierte Tenant-Übersicht
`POST /superadmin/tenants`	`API-UC00-17`, `API-UC00-18`	Vorbereitender Tenant wird ohne Benutzer und Einladung angelegt; Slug- oder Fachdatenkonflikte werden strukturiert abgewiesen
`GET /superadmin/tenants/{tenantSlug}`	`API-UC00-19`	Nur Superadmins erhalten den Tenant mit Vertrags-, Einladungs- und Onboardingstatus
`PATCH /superadmin/tenants/{tenantSlug}/contract-party`	`API-UC00-20`, `API-UC00-21`	Rechtliche Vertragspartei und Vertragskontakt werden getrennt aktualisiert; unvollständige oder ungültige Daten werden abgewiesen
`PATCH /superadmin/tenants/{tenantSlug}/status`	`API-UC00-22`	Nur zulässige Lifecycle-Übergänge werden revisionsfähig ausgeführt
`GET /superadmin/tenants/{tenantSlug}/contracts`	`API-UC00-23`	Versionierte Vertragsnachweise werden ohne unkontrollierten Dokumentzugriff aufgelistet
`POST /superadmin/tenants/{tenantSlug}/contracts/request`	`API-UC00-24`, `API-UC00-25`, `API-UC00-26`	Vollständige Vertragspartei erzeugt einen einmaligen, gehashten Sieben-Tage-Token; Alt-Token wird widerrufen; unvollständige Partei ergibt `409 contract_party_incomplete`
`GET /contracts/{token}`	`API-UC00-27`, `API-UC00-28`	Gültiger Vertragstoken liefert den erforderlichen Vertragskontext; ungültiger oder abgelaufener Token wird abgewiesen
`POST /contracts/{token}/accept`	`API-UC00-29`, `API-UC00-30`, `API-UC00-31`	Akzeptanz mit Unterzeichner-E-Mail, Funktion und Vertretungsbestätigung wird einmalig und dauerhaft gespeichert; Altversion wird erst danach ersetzt
`POST /superadmin/tenants/{tenantSlug}/contracts/upload`	`API-UC00-32`, `API-UC00-33`, `API-UC00-34`	Nur PDF bis 10 MiB wird in Quarantäne angenommen; Hash und Metadaten werden erfasst; falscher Typ oder Grenzüberschreitung wird abgewiesen
`POST /superadmin/tenants/{tenantSlug}/contracts/{contractId}/review`	`API-UC00-35`, `API-UC00-36`	Nur erfolgreich geprüfte Datei kann akzeptiert werden; Annahme und Ablehnung werden getrennt revisionsfähig erfasst
`POST /superadmin/tenants/{tenantSlug}/admin-invitation`	`API-UC00-37`, `API-UC00-38`, `API-UC00-39`	Einladung erfolgt nur nach akzeptiertem Vertrag; fehlender Vertrag ergibt `409 contract_not_accepted`; globale E-Mail-Kollision ergibt `409 email_already_in_use`
`POST /superadmin/tenants/{tenantSlug}/admin-invitation/resend`	`API-UC00-40`	Neue 72-Stunden-Einladung widerruft die vorherige offene Einladung kontrolliert
`POST /superadmin/users/{userId}/reset-2fa`	`API-UC00-41`	Superadmin kann Zwei-Faktor-Authentifizierung revisionsfähig zurücksetzen, ohne Geheimnisse offenzulegen
`GET /tenants/profile`	`API-UC00-42`	Tenant-Admin liest ausschliesslich das eigene operative Schulprofil
`PATCH /tenants/profile`	`API-UC00-43`, `API-UC00-44`	Operatives Profil verändert keine Vertragspartei; E-Mail-, Festnetz- und Mobilfreigabe bleiben getrennt und standardmässig deaktiviert
`GET /onboarding/status`	`API-UC00-45`	Persistenter Gesamt- und Schrittstatus wird ausschliesslich für den eigenen Tenant geliefert
`PUT /onboarding/steps/{stepKey}`	`API-UC00-46`, `API-UC00-47`, `API-UC00-48`	Nur `school_profile`, `contact_details`, `first_employee` und `confirmation` sind zulässig; Draft und Abschluss werden typisiert und tenantisoliert gespeichert
`POST /onboarding/complete`	`API-UC00-49`, `API-UC00-50`, `API-UC00-51`	Abschluss gelingt nur nach allen Pflichtschritten und aktiviert den Tenant einmalig; unvollständiger oder wiederholter Abschluss wird abgewiesen
`POST /users/invitations`	`API-UC00-52`, `API-UC00-53`	Tenant-Admin lädt Mitarbeiter nur im eigenen Tenant ein; globale E-Mail-Kollision wird einheitlich abgewiesen
`GET /superadmin/tenants/{tenantSlug}/offboarding`	`API-UC00-54`	Superadmin erhält Fristen, Export- und Löschstatus des Offboardings
`POST /superadmin/tenants/{tenantSlug}/offboarding`	`API-UC00-55`, `API-UC00-56`	Offboarding setzt 30 Tage Exportzugang und operative Löschung spätestens nach 90 Tagen; unzulässiger Wiederholungsstart wird abgewiesen
`POST /superadmin/tenants/{tenantSlug}/offboarding/cancel`	`API-UC00-57`	Abbruch ist nur vor der irreversiblen Löschgrenze und mit revisionsfähigem Grund zulässig
`POST /tenants/exports`	`API-UC00-58`	Berechtigter Tenant-Admin fordert innerhalb des Exportfensters einen tenantisolierten Export an
`GET /tenants/exports/{exportId}`	`API-UC00-59`	Exportstatus ist nur für den eigenen Tenant und ohne fremde Existenzinformation abrufbar
`GET /tenants/exports/{exportId}/download`	`API-UC00-60`, `API-UC00-61`	Download erfolgt zeitbegrenzt und backendvermittelt; fremder, abgelaufener oder nicht bereiter Export wird abgewiesen

3. Erforderliche Prüfebenen¶

Ebene	Mindestnachweis
Vertragsprüfung	OpenAPI 3.1 ist parsebar; interne Verweise, Operation-IDs, Fehlercodes, Schrittwerte und Test-IDs sind vollständig
Unit-Tests	Normalisierung, Statusübergänge, Tokenregeln, Berechtigungsentscheidungen und fachliche Sperrbedingungen
Integrations-Tests	NestJS, Prisma und PostgreSQL einschliesslich Transaktionen, Constraints, Rollen und Row-Level Security
Ende-zu-Ende-Tests	Elektronischer und externer Vertragsweg, Einladung, Erstzugang, Vier-Schritt-Onboarding, Offboarding und Export
Sicherheits-Tests	Tenant- und Objektzugriff, Tokenwiederverwendung, Protokollminimierung, Upload-Quarantäne und Standardverweigerung

4. Nachweisstatus¶

Der Vertrag und seine Zuordnung sind dokumentiert und automatisch strukturell prüfbar. Die fachlichen Schnittstellenkriterien UC00-05-01 bis UC00-05-08 können damit als spezifiziert gelten. Die zugehörigen Implementierungs- und Laufzeitnachweise unter UC00-08-* und UC00-09-* bleiben ausdrücklich offen, bis die Tests implementiert und gegen die Zielumgebung erfolgreich ausgeführt wurden.