UC00 – Tenant-Onboarding & Schulverwaltung

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

Datum, Uhrzeit	Version	Änderung	Autor
10.08.2026 20:00	3.3	Sicheren UC00-Merge-Stand nach main übernommen und Branch-Nachführung ergänzt	Codex
10.08.2026 19:46	3.2	Plan-Typ bei der Tenant-Vorbereitung verpflichtend festgelegt, sicheren Backend-Zwischenstand abgegrenzt, vierten Migrationsstand angewendet und erfolgreichen Build nachgeführt	Codex
09.08.2026 19:10	3.1	Backend-Status auf In Bearbeitung präzisiert: Build bis auf bekannte TOTP-Stelle wiederhergestellt, vertragsgebundene Einladungssperre code-seitig umgesetzt	Claude
09.08.2026 15:43	3.0	API-Endpunkte mit dem kanonischen OpenAPI- und Testvertrag vereinheitlicht und historische Planungsangaben bereinigt	Codex
09.08.2026 14:41	2.9	Prisma-v4-Zielschema formal validiert und technische Statusangaben auf das neue Zielmodell aktualisiert	Codex
09.08.2026 13:54	2.8	Altwidersprüche zu globaler E-Mail, Versandfehler und Schemaumsetzung anhand der Nachverfolgbarkeitsmatrix korrigiert	Codex
09.08.2026 13:04	2.7	Geplanten Schweizer Einzelunternehmensrahmen und vorläufige zehnjährige DACH-Vertragsnachweisfrist präzisiert	Codex
09.08.2026 12:55	2.6	TOM-Katalog und verbindliches Wirksamkeitsnachweismodell für UC00-07-10 vervollständigt	Codex
09.08.2026 12:49	2.5	Support-, Notfall-, Provider- und Auslandszugriffsmodell nach ADR-023 festgelegt	Codex
09.08.2026 12:34	2.4	Eigenbetriebenen ClamAV-Scanservice und ausfallsichere PDF-Freigabe nach ADR-022 festgelegt	Codex
09.08.2026 12:17	2.3	Grafana Cloud Pro Frankfurt sowie anbieterunabhängige Daten-, Sicherheits- und Kostengrenzen nach ADR-021 festgelegt	Codex
09.08.2026 11:52	2.2	Risikobasierte RPO- und RTO-Ziele, getrennten Backupstandort und verlustfreien Vertragsabschluss nach ADR-020 festgelegt	Codex
09.08.2026 11:33	2.1	Hetzner Object Storage Nürnberg und AWS KMS Frankfurt als bevorzugte V1-Speicher- und Schlüsselarchitektur festgelegt	Codex
08.08.2026 14:48	2.0	Revisionsfähiges Auditmodell und tägliche kryptografische Sammelnachweise nach ADR-018 festgelegt	Codex
08.08.2026 13:40	1.9	Tenant-Offboarding mit sofortiger Sperrung, 30 Tagen Exportzugang und operativer Löschung spätestens nach 90 Tagen festgelegt	Codex
08.08.2026 13:28	1.8	Hostpoint als V1-E-Mail-Provider sowie zulässige einmalige Links und ausgeschlossene vertrauliche E-Mail-Inhalte festgelegt	Codex
08.08.2026 11:57	1.7	Verbindliche Speicher- und Löschfristen für Verträge, operative Daten, Token, Protokolle, E-Mail-Nachweise und Backups festgelegt	Codex
08.08.2026 11:44	1.6	V1-Schutzanforderungen für Zugriff, Verschlüsselung, Uploads, Wiederherstellung, Monitoring, Schwachstellen und Vorfälle festgelegt	Codex
07.08.2026 19:45	1.5	Empfänger, Providerregister, Entwicklungsdaten, Hetzner-SMTP-Kandidat und Auslandsübermittlungsregeln festgelegt	Codex
07.08.2026 19:34	1.4	Authentifizierungs-, Audit-, Zugriffs-, System-, Lösch- und Versandprotokolle mit Minimierungs- und Ausfallregeln festgelegt	Codex
07.08.2026 19:22	1.3	V1-Onboarding auf vier Schritte vereinheitlicht sowie rechtliche Tenant-Daten, Schulprofil, Freigaben und Abschlussstatus getrennt	Codex
07.08.2026 19:15	1.2	Benutzeraktivierung nach 2FA, Argon2id, verschlüsselte TOTP-Geheimnisse sowie gehashte Einladungs- und Wiederherstellungscodes festgelegt	Codex
07.08.2026 18:57	1.1	Einheitliches Vertragsnachweismodell, Statuslogik, Sieben-Tage-Vertragstoken und V1-Prüfprozess festgelegt	Codex
07.08.2026 18:42	1.0	Vertragskontakt, unterzeichnende Person und Tenant-Admin fachlich getrennt sowie Telefon-, MwSt-, Logo- und Veröffentlichungsregeln festgelegt	Codex
07.08.2026 18:38	0.9	Vollständige rechtliche Bezeichnung und Vertragsanschrift als Voraussetzung vor AVV-Abschluss festgelegt; Schweizer Schreibweise bereinigt	Codex
06.08.2026 19:08	0.8	ADR-015 eingearbeitet: Auftragsverarbeitungsvertrag vor Tenant-Admin-Einladung, elektronischer Abschluss und Upload externer Vereinbarungen	Codex
01.08.2026 14:55	0.7	Kopfbereich vereinheitlicht	David Mittig
Mai 2026	0.7	Screen-Artefakte von docs/developer/wireframes nach docs/developer/uc00/screens verschoben; Abschnitt 9.3 und 9.4 auf neue Pfade aktualisiert	David Mittig
Mai 2026	0.6	Schritt 4 auf 🟡 In Bearbeitung gesetzt; Feldnamen is_active → status (Tenant: pending/active/deactivated, User: invited/active) gemäss Prisma-Schema-Diff; G13 aktualisiert; Stand + Version korrigiert	David Mittig
April 2026	0.5	Datenmodell validiert: recovery_codes + notification_templates Struktur bestätigt, Abschnitt 4 + 7 aktualisiert, Schritt 3 ✅	David Mittig
April 2026	0.4	Wireframes OB-01–OB-06 + TA-01–TA-02 abgeschlossen; 9.1 Screen-Tabelle vollständig, 9.2 OB/TA-Entscheide ergänzt, 9.3 alle 22 Dateipfade eingetragen	David Mittig
April 2026	0.3	Wireframes SA-01–SA-03 abgeschlossen (JSX + SVG); Abschnitt 9 vollständig überarbeitet: Screen-Tabelle, Entscheide OE7–OE9, Dateipfade; OE7–OE9 in Abschnitt 6 ergänzt	David Mittig
April 2026	0.2	Alle Entscheide OE1–OE6 eingearbeitet, Schema-Delta, Recovery-Codes, Templates	David Mittig
April 2026	0.1	Initiale Version – Steckbrief	David Mittig

Spezifikationsdatei – Leitdokument für Entwicklung, Testing und Abnahme
Review: offen

---

Status-Übersicht

Schritt	Bezeichnung	Status	Kommentar
1	Steckbrief	✅ Abgeschlossen	v0.2 – alle Entscheide eingearbeitet
2	Screen-Flow & Wireframes	✅ Abgeschlossen	Alle 11 Screens fertig (SA-01–SA-03, OB-01–OB-06, TA-01–TA-02)
3	Datenmodell	✅ Abgeschlossen	Prisma-v4-Zielschema fachlich und technisch abgestimmt sowie formal validiert; Migration und Datenbank-Rollout sind getrennte Umsetzungsschritte
4	Backend (NestJS)	🟡 In Bearbeitung	Build und 22 Unit-Tests erfolgreich; Tenant-Vorbereitung mit Pflicht-Plan, getrennte Vertragskontaktdaten, kontrollierte Einladungssperren und AWS-KMS-TOTP-Pfad als sichere Teilpakete umgesetzt. Vertragsabschluss einschliesslich Vollständigkeitssperre, Benutzer-Voranlage, Einladung und Integrationsnachweise bleiben offen.
5	Prisma / Supabase	⬜ Offen	—
6	Frontend (React)	⬜ Offen	—
7	Testing	⬜ Offen	—

Legende: ✅ Abgeschlossen | 🟡 In Bearbeitung | 🔴 Blockiert | ⬜ Offen

---

1. Steckbrief

1.1 Übersicht

Feld	Inhalt
UC-ID	UC00
Name	Tenant-Onboarding & Schulverwaltung
Version	V1
Onboarding-Modell	Option C1 – Hybrid (Superadmin + Tenant-Admin, 72h Token)
Zielgruppe	Plattform-Administration
Primärakteur	superadmin
Sekundärakteur	tenant_admin (Schulinhaber)
Priorität	Hoch – Voraussetzung für alle anderen UseCases

1.2 Ziel

Der Superadmin bereitet eine neue Tauchschule (Tenant) mit minimalen Vertragsdaten vor. Nach Abschluss des Auftragsverarbeitungsvertrags wird der Tenant-Admin eingeladen. Der Schulinhaber vervollständigt beim Erstlogin sein Schulprofil, setzt sein Passwort und richtet Zwei-Faktor-Authentifizierung (2FA) ein. Danach ist der Tenant aktiv und einsatzbereit.

1.3 Vorbedingungen

#	Bedingung
V1	Superadmin ist eingeloggt und hat 2FA aktiv
V2	E-Mail-Adresse des Schulinhabers liegt vor
V3	Plan-Typ wurde mit dem Schulinhaber vereinbart (Starter / Professional / Enterprise)
V4	Hostpoint-SMTP ist gemäss ADR-016 für die jeweilige Umgebung freigegeben und konfiguriert
V5	Eine vertretungsberechtigte Person für den Abschluss des Auftragsverarbeitungsvertrags ist bekannt

1.4 Nachbedingungen (Erfolgsfall)

#	Bedingung
N1	Tenant-Datensatz ist in der DB angelegt (Status: aktiv)
N2	Tenant-Admin-User ist angelegt (Status: aktiv, 2FA aktiv)
N3	Schulprofil ist vollständig ausgefüllt (alle Pflichtfelder)
N4	Invitation-Token ist als verwendet markiert (used_at gesetzt)
N5	Recovery-Codes wurden generiert und dem Tenant-Admin angezeigt
N6	Erster Login des Tenant-Admins ist in auth_log protokolliert
N7	Gültiger Nachweis des Auftragsverarbeitungsvertrags ist unveränderlich gespeichert und dem Tenant zugeordnet

---

2. Ablaufbeschreibung

2.1 Happy Path (Normalfall)

SUPERADMIN-TEIL:
─────────────────────────────────────────────────────────
1. Superadmin öffnet Superadmin-Panel → "Neuer Tenant"
2. Füllt das vorbereitende Basis-Formular aus:
   – Schulname (Pflicht)
   – Land: DE / CH / AT (Pflicht)
   – Plan-Typ: Starter / Professional / Enterprise (Pflicht)
   – Vertragskontakt und geschäftliche E-Mail (Pflicht)
   – Optional: Adresse, PLZ, Stadt
3. Klickt "Tenant vorbereiten"
4. System:
   – Generiert 8-stelligen Zufalls-Slug (z.B. "k7x2m9pq")
   – Legt den Tenant mit fachlichem Status `contract_pending` an
   – Legt noch keinen Tenant-Admin und kein Produkteinladungstoken an
4a. Vor Einleitung oder kontrollierter Erfassung des Vertragsabschlusses prüft das System:
   – vollständige rechtliche Bezeichnung des Tenants
   – Strasse und Hausnummer
   – Postleitzahl und Ort
   – Land
   – Vertragskontakt und geschäftliche E-Mail
   – bei unvollständigen Vertragsparteidaten bleibt der Status `contract_pending`; der AVV-Abschluss wird gesperrt
5. Auftragsverarbeitungsvertrag wird abgeschlossen:
   – elektronisch über einen einmaligen, nur gehasht gespeicherten und sieben Kalendertage gültigen Vertragstoken durch eine als vertretungsberechtigt bestätigte Person oder
   – ausserhalb der Anwendung; der Superadmin lädt das signierte Dokument hoch und erfasst den Abschluss kontrolliert
6. System speichert Vertragsversion, Vertragsparteien-Snapshot, Nachweis-PDF, Abschlussart und Abschlusszeitpunkt unveränderlich.
7. System setzt den fachlichen Tenant-Status auf `onboarding` und gibt die Tenant-Admin-Einladung frei.
8. Superadmin erfasst beziehungsweise bestätigt die E-Mail des Tenant-Admins und versendet die Produkteinladung.
   – Vertragskontakt, unterzeichnende Person und Tenant-Admin dürfen dieselbe Person sein, bleiben fachlich und historisch aber getrennte Rollen
9. System:
   – Legt den Benutzer mit Rolle `tenant_admin` und Status `invited` an
   – Erstellt `invitation_token` mit `token_type = 'admin'` und Ablaufzeit +72 Stunden
   – Sendet die Einladungs-E-Mail via Template `invite_admin` / `de`
10. Superadmin sieht die Bestätigung: "Einladung gesendet an [E-Mail]"

TENANT-ADMIN-TEIL (Schulinhaber):
─────────────────────────────────────────────────────────
11. Schulinhaber öffnet Einladungslink aus E-Mail
12. System prüft: Token gültig + nicht abgelaufen + nicht verwendet
13. Schulinhaber setzt Passwort:
    – Plattform-Minimum (unveränderlich): 12 Zeichen,
      Gross + Klein + Zahl + Sonderzeichen
    – Inline-Validierung während Eingabe
14. Schulinhaber richtet 2FA ein (TOTP, z.B. Google Authenticator):
    – QR-Code wird angezeigt
    – Bestätigung mit erstem Code erforderlich
15. System generiert 8 Recovery-Codes:
    – Werden einmalig im Klartext angezeigt
    – Schulinhaber muss bestätigen ("Codes gesichert")
    – Codes werden ausschliesslich als Hash in recovery_codes gespeichert
16. System aktiviert User-Account (status = 'active')
17. System markiert die Einladung als verwendet und leitet zum Vier-Schritt-Onboarding weiter.
18. Schritt `school_profile`: Schulinhaber erfasst angezeigten Schulnamen, operative Strasse, Postleitzahl, Ort, Land und Standardwährung CHF oder EUR. Rechtliche Vertragsdaten bleiben unverändert.
19. Schritt `contact_details`: Schulinhaber erfasst Kontaktperson, Kontakt-E-Mail, mindestens Festnetz oder Mobiltelefon und optional eine Website. Für E-Mail, Festnetz, Mobiltelefon und Website wird jeweils eine ausdrückliche Veröffentlichungsentscheidung gespeichert; Standard ist `false`.
20. Schritt `first_employee`: Schulinhaber lädt optional einen ersten Benutzer mit der festen Rolle `mitarbeiter` ein oder überspringt den Schritt ausdrücklich.
21. Schritt `confirmation`: Schulinhaber prüft die Zusammenfassung und bestätigt Vollständigkeit und Richtigkeit des Profils. Eine unspezifische Annahme von Nutzungsbedingungen findet hier nicht statt.
22. System prüft Pflichtfelder, Schrittfolge und weiterhin gültigen AVV-Nachweis, setzt Onboarding und Tenant idempotent auf `completed` beziehungsweise `active`, schreibt Audit-Ereignisse und leitet zum Dashboard weiter.

2.2 Alternative Pfade

ID	Situation	Ablauf
A1	Superadmin bricht Formular ab	Kein Datensatz wird angelegt, kein Token erstellt
A2	Schulinhaber öffnet Link, schliesst Browser vor Abschluss	Token bleibt gültig, Schulinhaber kann Link erneut öffnen (solange < 72h)
A3	Schulinhaber schliesst Browser nach Passwort/2FA, vor Schulprofil	Account ist aktiv, Schulprofil unvollständig → beim nächsten Login direkt zum Schulprofil
A4	Superadmin möchte Einladung erneut senden	Klick "Einladung erneut senden" → alter Token invalidiert, neuer Token (+72h) erstellt und gesendet
A5	Tenant-Admin verliert 2FA-Gerät, hat Recovery-Codes	Recovery-Code eingeben → einmalig gültig, danach neue 2FA einrichten
A6	Tenant-Admin verliert 2FA-Gerät, hat keine Recovery-Codes	Superadmin setzt 2FA zurück → E-Mail-Benachrichtigung via Template '2fa_reset' / 'de'
A7	Auftragsverarbeitungsvertrag wurde ausserhalb der Anwendung unterzeichnet	Superadmin lädt das signierte Original hoch, erfasst Version, Abschlussdatum, Unterzeichner und Vertretungsberechtigung und bestätigt die Prüfung
A8	Wesentliche neue Vertragsversion erforderlich	Bestehender Nachweis bleibt unverändert; neue Version wird separat zur Annahme vorgelegt und versioniert gespeichert
A9	Neue Vertragsversion ist noch nicht akzeptiert	Bisherige akzeptierte Version bleibt aktuell und gültig; sie wird erst nach Annahme der neuen Version als superseded markiert

2.3 Fehlerfälle

ID	Fehler	Verhalten
F1	E-Mail-Adresse bereits vergeben	Formular-Fehler: "Diese E-Mail ist bereits registriert"
F2	Slug-Kollision (extrem unwahrscheinlich)	System generiert automatisch neuen Zufalls-Slug
F3	Einladungslink abgelaufen (> 72h)	Fehlermeldung: "Dieser Link ist abgelaufen. Bitte kontaktiere die Tauchschule."
F4	Einladungslink bereits verwendet	Fehlermeldung: "Dieser Link wurde bereits verwendet."
F5	E-Mail-Versand der Tenant-Admin-Einladung schlägt fehl	Tenant und akzeptierter Vertrag bleiben im Status onboarding; Einladung bleibt kontrolliert wiederholbar, Fehler wird minimiert protokolliert und alarmiert
F6	Passwort erfüllt Plattform-Minimum nicht	Inline-Validierung mit konkretem Hinweis
F7	2FA-Code falsch	Max. 5 Versuche, dann 15 Minuten Sperre, auth_log-Eintrag
F8	Recovery-Code falsch oder bereits verwendet	Fehlermeldung, auth_log-Eintrag
F9	Tenant-Admin-Einladung vor Vertragsabschluss	Serverseitige Ablehnung mit 409 contract_not_accepted, Audit-Log-Eintrag
F10	Extern unterzeichneter Vertrag ohne Dokument oder Pflichtmetadaten	Validierungsfehler; Status bleibt contract_pending
F11	Vertretungsberechtigung nicht bestätigt	Vertragsabschluss wird nicht akzeptiert; keine Produkteinladung möglich
F12	Rechtliche Bezeichnung oder vollständige Vertragsanschrift fehlt	Vertragsabschluss wird serverseitig mit 409 contract_party_incomplete gesperrt; Status bleibt contract_pending
F13	Vertragstoken ist älter als sieben Kalendertage	Abschluss wird abgewiesen; Superadmin muss einen neuen Token anfordern
F14	Vertragstoken wurde verwendet oder durch Neuanforderung widerrufen	Abschluss wird abgewiesen; Token kann nicht reaktiviert werden

---

3. Geschäftsregeln

ID	Regel
G1	Jede normalisierte E-Mail-Adresse identifiziert genau einen globalen Benutzer und ist tenantübergreifend eindeutig
G2	Invitation-Token läuft nach 72 Stunden ab (Modell C1)
G3	2FA ist für tenant_admin Pflicht und kann nicht deaktiviert werden
G4	Passwort Plattform-Minimum (hardcodiert, unveränderlich): 12 Zeichen, Gross + Klein + Zahl + Sonderzeichen
G5	Tenant-Admin kann in V2 eine strengere Passwort-Policy setzen (nie unterhalb Plattform-Minimum)
G6	Schulprofil muss vollständig sein (alle Pflichtfelder) bevor Mitarbeiter eingeladen werden können
G7	Ein Tenant kann nur vom Superadmin angelegt werden (kein Self-Service in V1)
G8	Der Slug ist ein 8-stelliger Zufallsstring (alphanumerisch, Kleinbuchstaben) — keine Rückschlüsse auf Kundendaten
G9	Standard-Währung kann nach dem ersten Speichern nur durch Superadmin geändert werden
G10	Acht Recovery-Codes werden nur einmal im Klartext angezeigt, ausschliesslich als Hash gespeichert und jeweils nur einmal verwendet; Neuerzeugung oder 2FA-Reset invalidiert alle bisherigen Codes
G11	Recovery-Codes werden nur einmalig im Klartext angezeigt — danach nicht mehr abrufbar
G12	Superadmin-Reset von 2FA löst E-Mail-Benachrichtigung an Tenant-Admin aus
G13	Tenant kann nur deaktiviert werden (status = 'deactivated'), nicht gelöscht (V1)
G14	E-Mail-Templates sind in der DB hinterlegt (notification_templates), V1 nur DE
G15	Der Auftragsverarbeitungsvertrag muss vor Anlage und Einladung des Tenant-Admins abgeschlossen sein (ADR-015)
G16	Vor Vertragsabschluss darf ein Tenant nur mit minimalen Vertragsdaten im fachlichen Status contract_pending vorbereitet werden
G17	Nach Vertragsabschluss wechselt der Tenant in den fachlichen Status onboarding; erst dann ist die Produkteinladung zulässig
G18	Der Abschluss erfolgt elektronisch durch eine als vertretungsberechtigt bestätigte Person oder durch kontrollierte Erfassung eines extern unterzeichneten Dokuments
G19	Vertragsversion, Dokument beziehungsweise Snapshot, Abschlussart, Unterzeichner und Abschlusszeitpunkt werden unveränderlich nachgewiesen
G20	Extern unterzeichnete Dokumente dürfen nur durch einen Superadmin hochgeladen und als geprüft bestätigt werden
G21	Wesentliche Vertragsänderungen erzeugen eine neue Version; bestehende Nachweise werden nicht überschrieben
G22	Ohne gültigen Vertragsnachweis werden Produkteinladung und produktive Verarbeitung serverseitig gesperrt
G23	Die endgültige Vertragsvorlage und der Nachweisprozess müssen vor dem Produktivbetrieb juristisch geprüft werden
G24	Vor jedem elektronischen oder extern erfassten AVV-Abschluss müssen vollständige rechtliche Bezeichnung, Strasse, Postleitzahl, Ort und Land des Tenants vorliegen; die vorbereitende Tenant-Anlage darf weiterhin mit Minimaldaten erfolgen
G25	Vertragskontakt, unterzeichnende Person und Tenant-Admin sind getrennte fachliche Rollen; dieselbe natürliche Person darf mehrere oder alle Rollen übernehmen
G26	Name und geschäftliche E-Mail des Vertragskontakts sind vor AVV-Abschluss Pflicht; eine Telefonnummer ist dafür nicht erforderlich
G27	Beim Abschluss des Schulprofils ist mindestens eine Festnetz- oder Mobiltelefonnummer Pflicht; Mehrwertsteuernummer bleibt optional und Logo gehört zu V2
G28	Kontakt-E-Mail und Telefonnummern werden niemals automatisch veröffentlicht; jede öffentliche Sichtbarkeit erfordert eine ausdrückliche Einstellung durch den Tenant-Admin und ist einzeln widerrufbar
G29	Vertragsstatus sind pending_acceptance, pending_review, accepted, rejected, superseded und terminated; nur accepted erlaubt die Tenant-Admin-Einladung
G30	Der elektronische Vertragstoken ist sieben Kalendertage gültig, einmalig verwendbar und nur als Hash gespeichert; eine Neuanforderung widerruft den vorherigen Token
G31	superseded bedeutet durch eine neuere akzeptierte Version ersetzt; die ältere Version bleibt unveränderlich als historischer Nachweis erhalten
G32	Upload und Prüfung eines externen Vertrags sind getrennte, auditierte Aktionen; in V1 darf dieselbe Superadmin-Person beide Aktionen durchführen, ein Vier-Augen-Prinzip ist nicht erforderlich
G33	Beide Abschlusswege erzeugen eine unveränderliche PDF-Kopie im privaten Objektspeicher; vollständige Vertragsinhalte werden nicht in SQL gespeichert
G34	Der Vertragsnachweis enthält keine IP-Adresse und keinen User-Agent; solche Daten bleiben getrennten Sicherheitsprotokollen und deren Aufbewahrungsregeln vorbehalten
G35	Beim Abschluss werden Vertragspartei, Vertragskontakt und Unterzeichner einschliesslich geschäftlicher E-Mail unveränderlich in den Vertragsdatensatz kopiert
G36	E-Mail-Adressen werden vor Einladung, Anlage, Anmeldung und Änderung durch Trimmen und Kleinschreibung normalisiert und global auf Konflikte geprüft
G37	Der erste Tenant-Admin bleibt bis zur erfolgreichen Einrichtung und Prüfung der verpflichtenden 2FA im Status invited; erst danach wird er active
G38	Die Anmeldung erfolgt ausschliesslich mit E-Mail und Passwort; username besitzt in V1 keine Anmelde- oder sonstige fachliche Funktion
G39	Passwörter werden in V1 mit Argon2id gehasht; bestehende bcrypt-Hashwerte mit Kostenfaktor 12 werden erkannt und beim nächsten erfolgreichen Login migriert
G40	Das TOTP-Geheimnis wird verschlüsselt gespeichert; der Schlüssel liegt ausserhalb der SQL-Datenbank und der Klarwert ist nur während der Einrichtung sichtbar
G41	Einladungsgeheimnisse werden nur als Hash gespeichert, sind 72 Stunden gültig und einmalig; Neuausstellung widerruft offene Vorgängertoken
G42	Refresh-Token werden nur als Hash gespeichert und rotiert; Abmeldung, Passwortänderung, Sperre, Deaktivierung und 2FA-Reset widerrufen die betroffenen Sitzungen
G43	Temporäre 2FA-Sitzungen sind zweckgebunden, einmalig, versuchsbegrenzt und höchstens zehn Minuten gültig; sie werden produktiv in einem zentralen kurzlebigen Speicher geführt
G44	lastLoginAt wird erst nach einer vollständig erfolgreichen Anmeldung einschliesslich eines erforderlichen zweiten Faktors aktualisiert
G45	Passworthashes, TOTP-Geheimnisse sowie Wiederherstellungs-, Einladungs- und Refresh-Token sind für administrative Rollen nicht lesbar und werden niemals protokolliert
G46	Rechtliche Tenant-Stammdaten und operatives Schulprofil sind getrennt; Profiländerungen überschreiben weder rechtlichen Namen noch Vertragsanschrift
G47	Das operative Schulprofil wird in einem eigenen Eins-zu-eins-Modell TenantProfile geführt
G48	V1 verwendet genau die Schritte school_profile, contact_details, first_employee und confirmation in dieser serverseitig erzwungenen Reihenfolge
G49	Logo, Verbände, Zertifizierungen und Öffnungszeiten gehören nicht zum V1-Onboarding
G50	first_employee ist optional, ausdrücklich überspringbar und erlaubt ausschliesslich die Rolle mitarbeiter
G51	Draftdaten werden direkt in fachlichen Zielfeldern gespeichert; das Fortschrittsmodell speichert Status und Zeitpunkte, aber keine zusätzliche freie JSON-Kopie
G52	Schrittstatus sind not_started, in_progress, completed und bei optionalen Schritten skipped; Gesamtstatus sind pending, in_progress und completed
G53	Der fachliche Tenant-Lifecycle lautet contract_pending, onboarding, active; active wird erst nach vollständiger serverseitiger Abschlussprüfung gesetzt
G54	Kontakt-E-Mail, Festnetz, Mobiltelefon und Website besitzen getrennte Veröffentlichungsfreigaben mit Standardwert false; nur der Tenant-Admin darf sie ändern
G55	Die Profilbestätigung speichert bestätigende Person und Zeitpunkt; ein unspezifisches terms_accepted wird nicht verarbeitet
G56	Die Standardwährung ist bei der Ersteinrichtung CHF oder EUR und danach nur durch den Superadmin änderbar; Änderungen werden auditiert
G57	Der Onboarding-Abschluss prüft den weiterhin gültigen AVV-Nachweis und ist idempotent
G58	Protokolle unterscheiden verbindlich scope = platform und scope = tenant; eine Tenant-ID ist nur im Tenant-Kontext zwingend
G59	Authentifizierungs-, Audit-, Zugriffs-, System-, Lösch- und E-Mail-Versandereignisse verwenden feste Ereignis-, Ergebnis-, Schweregrad- und Grundcodes sowie eine geheimnisfreie Korrelations-ID
G60	Passwörter, Passworthashes, TOTP-Werte und -Geheimnisse, Wiederherstellungs-, Access-, Refresh-, Einladungs- und Vertragstoken werden niemals protokolliert
G61	Unbekannte Anmeldebezüge werden höchstens zweckgebunden pseudonymisiert; vollständige E-Mail-Adressen werden dabei nicht protokolliert
G62	Audit-Alt- und Neuwerte folgen einer Feld-Whitelist; bei Sicherheitsfeldern wird nur changed: true ohne Wert gespeichert
G63	Besonders sensible Lese-, Download-, Export-, Support- und Protokollzugriffe werden in einem eigenen Access-Protokoll nachgewiesen
G64	Systemprotokolle enthalten keine freien Request-/Response-Bodies, Nachrichteninhalte, Providerfehlermeldungen, Vertragsdokumente oder Datenbank-Geheimnisse
G65	Löschprotokolle enthalten keinen Snapshot gelöschter Personendaten, sondern nur minimierte Lösch- und Nachweismetadaten
G66	Fachliche Protokolle sind append-only; Protokollzugriffe und -exporte werden selbst protokolliert und Ausfall oder Manipulation alarmiert
G67	Kritische administrative Änderungen werden transaktional mit ihrem Audit-Eintrag gespeichert und bei fehlendem Audit-Nachweis abgebrochen
G68	Kurzfristiger Ausfall der Authentifizierungsprotokollierung blockiert gewöhnliche Login-Vorgänge nicht, erfordert aber unabhängigen Alarm, sichere Pufferung und Nachlieferung
G69	UC00-E-Mail-Versandnachweise enthalten nur geschützte Empfängerreferenz, Template-Metadaten, Provider-ID, Status, Zeitpunkte und standardisierte Fehlercodes
G70	Wiederherstellungscodes werden ausschliesslich einmalig in der Anwendung angezeigt und niemals per E-Mail versendet
G71	Produktive Primärverarbeitung und Backups erfolgen grundsätzlich in der Schweiz, EU oder im Europäischen Wirtschaftsraum; Deutschland oder Schweiz werden für V1 bevorzugt
G72	Hetzner ist bevorzugter Kandidat für den Anwendungsbetrieb; Hostpoint ist gemäss ADR-016 der gewählte V1-E-Mail-Provider und erst nach vollständigem Produktivnachweis für reale Empfänger zulässig
G73	Resend, Hetzner-SMTP und ein selbst betriebener Mailserver gehören nicht zum V1-Zielbild; jeder Ersatz für Hostpoint benötigt eine neue Providerprüfung und dokumentierte Freigabe
G74	Supabase wird ohne separate Produktivfreigabe ausschliesslich für Entwicklung mit synthetischen Daten verwendet
G75	Entwicklungs-, Test- und Demo-Umgebungen enthalten keine Produktionskopien, echten Vertragsdokumente, produktiven Geheimnisse oder realen Sicherheitstoken
G76	Jeder produktive externe Dienst benötigt Status approved im versionierten Provider- und Unterauftragnehmerregister
G77	Backup-, Support-, Monitoring-, Malware-, Fernzugriffs- und Unterauftragnehmerstandorte werden wie sonstige Empfänger und mögliche Auslandsübermittlungen geprüft
G78	Vertrags-PDFs werden weder öffentlich noch über ein globales CDN verteilt; externe Malware-Prüfung vollständiger Dokumente benötigt eine eigene Freigabe
G79	Drittlandübermittlungen benötigen Angemessenheit oder vorab dokumentierte Garantien, Transferprüfung und erforderliche Zusatzmassnahmen
G80	Anbieter- und Unterauftragnehmeränderungen werden versioniert, erneut geprüft und nach dem AVV-Prozess vor ihrem Einsatz angekündigt
G81	Interne und externe Supportzugriffe benötigen persönliche Konten, 2FA, Minimalrechte, dokumentierten Grund und Audit; ohne Drittlandfreigabe bleiben sie auf Schweiz/EU/EWR begrenzt
G82	Zugriff wird standardmässig verweigert und serverseitig nach Rolle, Tenant und Ressource freigegeben; RLS bildet eine zusätzliche Schutzschicht
G83	Administrative Zugriffe verwenden persönliche Konten, 2FA und dokumentierte Gründe; Rechte werden bei Wegfall sofort entzogen und quartalsweise geprüft
G84	Produktive Geheimnisse und Schlüssel werden zentral, umgebungsgetrennt, minimal berechtigt und rotationsfähig ausserhalb der Datenbank verwaltet
G85	Transportwege verwenden TLS 1.2 oder höher; Datenbank, Objektspeicher und Backups sind im Ruhezustand verschlüsselt
G86	Datenbank und interne Dienste sind nicht öffentlich erreichbar und werden über private Netze, Firewalls, minimale Ports und gehärtete Prozesse geschützt
G87	API-Endpunkte verwenden konkrete Datenübertragungsobjekte, Feld- und Längenprüfungen sowie bereinigte Fehler; unkontrolliertes any ist nicht zulässig
G88	Allgemeine und verschärfte Auth-Ratenbegrenzung, sichere Cookies, exaktes CORS sowie Herkunfts- und CSRF-Schutz sind produktiv aktiv
G89	Vertragsuploads erlauben ausschliesslich geprüfte PDF-Dateien bis 10 MB; verschlüsselte oder aktive Inhalte werden abgewiesen und Dateien bis zum Malware-Scan quarantänisiert
G90	Vertragsobjekte sind privat; signierte Anwendungslinks gelten höchstens fünf Minuten und werden weder gespeichert noch protokolliert; der eigentliche Download wird durch das Backend vermittelt
G91	Verschlüsselte automatische Backups und Point-in-Time Recovery erreichen RPO höchstens eine Stunde und RTO höchstens acht Stunden
G92	Backups werden täglich überwacht, monatlich geprüft, quartalsweise wiederhergestellt und jährlich in einer vollständigen Notfallwiederherstellung getestet
G93	Sicherheits- und Betriebsmonitoring deckt die in Abschnitt 11 des Datenkatalogs benannten Ereignisse ab; jeder Alarm besitzt einen verantwortlichen Empfänger
G94	Automatisierte Sicherheitsprüfungen, SBOM und OWASP ASVS Level 2 sind Pflicht; unabhängige Penetrationstests erfolgen vor Go-live, nach wesentlichen Änderungen und jährlich
G95	Ein dokumentierter Incident-Response-Prozess mit Register, Meldeprüfung, Ursachenanalyse und jährlicher Übung ist vor Produktivbetrieb vorhanden
G96	Organisatorische Massnahmen umfassen Vertraulichkeit, jährliche Schulung, Rechte-Lifecycle, Endgeräteschutz, Providerprüfung und jährliche TOM-Überprüfung; kritische Änderungen werden nach Möglichkeit gegengeprüft und Ausnahmen dokumentiert
G97	Unvollständige Vertragsvorbereitungen werden nach 90 Tagen Inaktivität gelöscht; abgelehnte Vertragsvorgänge einschliesslich nicht akzeptierter PDFs werden 90 Tage nach Ablehnung oder Abbruch gelöscht
G98	Akzeptierte, ersetzte und beendete AVV-Nachweise einschliesslich Parteiensnapshot und vertragsrelevanter Auditdaten werden zehn Jahre ab Ende des Kalenderjahres des Vertragsendes getrennt und gesperrt aufbewahrt; juristische Länderprüfung bleibt Go-live-Pflicht
G99	Operative Tenant-, Profil- und Kontodaten werden bei Ende sofort gesperrt und spätestens nach 90 Tagen gelöscht oder irreversibel anonymisiert, soweit keine spezifische Aufbewahrung oder ein dokumentierter legal_hold greift
G100	Token- und Recovery-Code-Hashes werden spätestens 30 Tage nach Ablauf, Verwendung, Widerruf oder Ersetzung gelöscht; temporäre 2FA-Sitzungen bestehen höchstens zehn Minuten
G101	Authentifizierungsprotokolle gelten sechs Monate, vollständige IP-Adressen 30 Tage, allgemeine Auditdaten drei Jahre, Access-Protokolle ein Jahr und Systemprotokolle 30 Tage
G102	Minimierte Löschprotokolle gelten drei Jahre, E-Mail-Versandnachweise 90 Tage und Nachrichteninhalte beim Provider höchstens sieben Tage
G103	Point-in-Time-Recovery-Daten werden sieben Tage und verschlüsselte rollierende Backups 35 Tage aufbewahrt; gelöschte Primärdaten dürfen bei Restore nicht unkontrolliert reaktiviert werden
G104	Ein täglicher idempotenter Retention-Job löscht SQL-Daten, Objekte und Providerdaten gemeinsam; Fehler werden alarmiert und Löschläufe monatlich geprüft
G105	Passwörter, Wiederherstellungscodes, Access- und Refresh-Token sowie Vertragsdokumente werden nicht per E-Mail übertragen; sie werden ausschliesslich über die HTTPS-geschützte Anwendung gesetzt, angezeigt oder abgerufen
G106	Einmalige Einladungs-, Passwortzurücksetzungs- und Vertragslinks sind per E-Mail zulässig, wenn die Token befristet, einmalig, widerrufbar, serverseitig nur gehasht und aus Protokollen ausgeschlossen sind
G107	Entwicklungsversand vor Hostpoints Produktivfreigabe ist auf kontrollierte interne oder synthetische Adressen begrenzt; automatisierte Tests verwenden einen lokalen Mail-Catcher
G108	Produktiver Hostpoint-Versand verwendet Port 587 mit STARTTLS, strikte Absenderrichtlinie, SPF, DKIM, DMARC sowie getrennte Versand- und Bounce-Adressen
G109	Zum Vertragsende werden reguläre Nutzung, Sitzungen, Token, Schreibzugriffe, Jobs und Integrationen des Tenants sofort gesperrt
G110	Ausschliesslich ein verifizierter Tenant-Admin erhält für 30 Kalendertage einen eingeschränkten Exportzugang; danach endet jeder Tenant-Zugang
G111	Der Offboarding-Export enthält maschinenlesbare CSV- und JSON-Daten, zugehörige Dateien und ein Integritätsmanifest; Erstellung und zeitlich befristeter Download werden auditiert
G112	Operative Tenant-Daten werden spätestens 90 Kalendertage nach Vertragsende gelöscht oder irreversibel anonymisiert; diese Produktfrist ist keine allgemeine gesetzliche Frist
G113	Reaktivierung ist nur vor irreversibler Löschung, nach administrativer Prüfung und mit gültiger Vertragsgrundlage am bestehenden Tenant zulässig
G114	Globale E-Mail-Adressen bleiben während des Offboardings reserviert; eine spätere Freigabe benötigt einen kontrollierten administrativen Prozess
G115	Vertrags- und Datenschutzaktionen verwenden standardisierte Ereignis-, Ergebnis- und Grundcodes sowie Kontext, Akteur, Objekt, UTC-Zeitpunkt und Korrelations-ID
G116	Vertragsereignisse referenzieren Vertragsinstanz, Vertragsversion und Dokument-Hash; Löschprotokolle enthalten keinen Daten-Snapshot
G117	Kritische Änderung und Auditnachweis werden transaktional gespeichert; Audit- und Access-Exporte werden selbst protokolliert
G118	Je UTC-Tag und Verantwortlichkeitskontext wird ein SHA-256-Sammelnachweis erzeugt und unveränderlich getrennt im privaten Objektspeicher abgelegt
G119	Hetzner Object Storage in Nürnberg ist der bevorzugte V1-Objektspeicher; AWS KMS in Frankfurt verwaltet den kundenseitigen Hauptschlüssel und erzeugt objektspezifische Datenschlüssel
G120	Schutzbedürftige Objekte werden mit SSE-C verschlüsselt; Klartextschlüssel werden nicht persistiert, protokolliert oder an Clients ausgegeben
G121	Downloads erfolgen nach serverseitiger Autorisierung ausschliesslich backendvermittelt; direkte S3-URLs und personenbezogene Angaben in Objektpfaden oder AWS-KMS-Verschlüsselungskontexten sind ausgeschlossen
G122	Hetzner Object Storage und AWS KMS bleiben bis zu vollständigen Vertrags-, Regionen-, Unterauftragnehmer-, Sicherheits-, Lösch- und Wiederherstellungsnachweisen für Produktivdaten gesperrt
G123	RPO höchstens eine Stunde und RTO höchstens acht Stunden sind risikobasierte interne V1-Obergrenzen und keine gesetzlich festgelegten Zahlen
G124	Bestätigte Vertragsabschlüsse dulden keinen bewusst akzeptierten Verlust; Erfolg wird erst nach dauerhafter konsistenter Speicherung von SQL-Datensatz, PDF-Objekt und Auditnachweis gemeldet
G125	PostgreSQL-PITR-Daten, tägliche Sicherungen und wöchentliche Vollsicherungen werden verschlüsselt in einem getrennten Hetzner-Object-Storage-Bucket in Falkenstein gespeichert
G126	Der Backupbetrieb wird täglich überwacht, monatlich technisch geprüft, quartalsweise wiederhergestellt und jährlich vollständig als Notfallwiederherstellung erprobt
G127	Grafana Cloud Pro in Deutschland beziehungsweise Frankfurt ist bevorzugtes V1-Monitoring; Grafana Alloy übermittelt nur freigegebene minimierte Metriken und technische Logs
G128	Personenbezogene und fachliche IDs sind als Metriklabels ausgeschlossen; Metriken werden insbesondere nicht pro Tenant, Benutzer, Kunde, Equipmentteil, Vertrag oder Dokument erzeugt
G129	Normale Messintervalle betragen grundsätzlich eine Minute, externe Prüfintervalle fünf Minuten; kürzere Intervalle benötigen eine dokumentierte Begründung
G130	Warnungen erfolgen spätestens bei 70 Prozent und kritische Kostenwarnungen bei 85 Prozent eines Tarifkontingents; prognostizierte Mehrkosten und Zusatzmodule benötigen Freigabe
G131	Sentry, Application, Database und Frontend Observability, Session Replay, Tracing und Profiling sind in V1 nicht freigegeben
G132	Kostenoptimierung darf die verbindliche Sicherheits- und Alarmabdeckung nicht reduzieren
G133	Die Malware-Prüfung erfolgt durch einen eigenbetriebenen ClamAV-Dienst innerhalb der Hetzner-Infrastruktur; externe Analysedienste erhalten keine Vertragsdateien
G134	Nur ein erfolgreicher Scan mit höchstens zwei Stunden alten Signaturen gibt ein Dokument frei; Scanner-, Signatur-, Zeit- oder Prüffehler sperren die Freigabe
G135	Signierte Vertrags-PDFs werden weder bereinigt noch neu geschrieben; unzulässige aktive oder eingebettete Inhalte führen zur Abweisung
G136	Interne Infrastrukturrechte werden zweckgebunden für höchstens vier Stunden vergeben und berechtigen nicht zur routinemässigen Einsicht in Tenant-Daten
G137	Normaler tenantbezogener Supportzugriff ist standardmässig deaktiviert, benötigt eine ticketbezogene Tenant-Admin-Freigabe und gilt höchstens acht Stunden
G138	Ein alarmierter Notfallzugriff ohne vorherige Tenant-Freigabe ist nur zur konkreten Schadensabwehr oder Wiederherstellung und für höchstens eine Stunde zulässig
G139	Menschliche Produktivzugriffe sind in V1 auf Schweiz, EU und EWR begrenzt; andere Länder benötigen vorab Transferprüfung, Garantien, Zusatzmassnahmen und dokumentierte Freigabe
G140	Supportzugriffe verwenden persönliche eingeschränkte Konten, erlauben keinen freien Tenantwechsel oder Identitätsübernahme und werden mit Zweck, Umfang, Dauer und Ergebnis auditiert
G141	Physischer Rechenzentrumsschutz, Überlastungs- und DDoS-Schutz, Datenschutz durch Technikgestaltung, Betroffenenprozesse und sichere Ressourcenvernichtung sind verbindliche V1-Schutzbereiche
G142	Jede produktionsrelevante TOM besitzt einen nachvollziehbaren Nachweis mit Geltungsbereich, Verantwortlichkeit, Referenz, Prüfperson, Methode, Ergebnis, Abweichung und nächstem Prüftermin
G143	UC00-07-10 ist erst erledigt, wenn alle anwendbaren Massnahmen umgesetzt, vorgeschriebene Wirksamkeitsprüfungen bestanden und kritische Abweichungen behoben sind
G144	DiveLogix360 soll für V1 voraussichtlich als Schweizer Einzelunternehmen betrieben werden; endgültige Firma, Adresse, Register- und Steuerangaben werden erst nach tatsächlicher Gründung als Vertragsidentität verwendet
G145	RF-03 bleibt vorläufig zehn Jahre ab Ende des Kalenderjahres des Vertragsendes; dies ist eine konservative DACH-Vertragsnachweisfrist und keine Behauptung einer identischen gesetzlichen Mindestfrist
G146	UC00-07-11 ist erst nach schriftlicher juristischer Freigabe mit eindeutiger Versionsreferenz für Schweiz, Deutschland und Österreich erledigt
G147	Ein globaler Benutzer gehört in V1 höchstens einem Tenant an
G148	Ein Superadmin besitzt keine Tenant-Zuordnung; seine normalisierte E-Mail bleibt dennoch global reserviert
G149	Mehrfachzugehörigkeiten gehören nicht zu V1 und werden später über tenantbezogene Mitgliedschaften ergänzt, ohne die globale E-Mail-Eindeutigkeit aufzuheben

---

4. Betroffene Datenbank-Tabellen

Tabelle	Operation	Felder
tenants	INSERT	slug (Zufalls-8-Zeichen), name, country, plan_type, status = 'pending'
tenants	UPDATE	Lifecycle contract_pending → onboarding → active; rechtliche Stammdaten bleiben vom Schulprofil getrennt
tenant_profiles	INSERT/UPDATE	Anzeigename, operative Adresse, Kontaktperson, Kontakt-E-Mail, Telefonnummern, Website, Standardwährung und getrennte Veröffentlichungsfreigaben
tenant_onboardings	INSERT/UPDATE	Gesamtstatus, Start- und Abschlusszeit, abschliessender Benutzer
onboarding_steps	INSERT/UPDATE	Schritt, Status, Start- und Abschlusszeit, ausführender Benutzer; keine freie Kopie der Profildaten
users	INSERT	tenant_id, email, role = tenant_admin, status = 'invited'
users	UPDATE	Argon2id-password_hash, verschlüsseltes tfa_secret, tfa_enabled = TRUE, status = 'active' erst nach erfolgreicher 2FA
invitation_tokens	INSERT	tenant_id, user_id, token_type = 'admin', invited_by, invited_email, expires_at = +72h
invitation_tokens	UPDATE	used_at = NOW() (bei Abschluss)
recovery_codes	INSERT	8 Datensätze pro User (code_hash, user_id, tenant_id)
recovery_codes	UPDATE	used_at = NOW() (bei Einlösung)
notification_templates	READ	Templates invite_admin (Admin-Einladung) + 2fa_reset (2FA-Benachrichtigung), beide de, systemweit
auth_log	INSERT	Erster Login, 2FA-Events, Recovery-Code-Nutzung
audit_log	INSERT	Alle Datenänderungen
system_log	INSERT	E-Mail-Fehler (F5)
access_log	INSERT	Sensible Vertrags-, Sicherheits-, Export-, Support- und Protokollzugriffe
deletion_log	INSERT	Minimierte Lösch- und Anonymisierungsmetadaten ohne Daten-Snapshot
notification_log	INSERT/UPDATE	Geschützte Empfängerreferenz, Template-Version, Provider-ID, Versandstatus, Zeitpunkte und Fehlercode ohne Nachrichteninhalt
tenant_contracts, contract_documents	INSERT/UPDATE	tenant_id, Status, Vertragsversion, Vertragsparteien-Snapshot, Vertragskontakt, Unterzeichner mit E-Mail und Funktion, Vertretungsbestätigung, Abschlussart/-zeitpunkt, Objektschlüssel, SHA-256-Hash und Prüfmetadaten
contract_acceptance_tokens	INSERT/UPDATE	Token-Hash, Ablauf nach sieben Kalendertagen, Verwendungs- und Widerrufszeitpunkt
Vertragsdokument, kontrollierte Ablage	CREATE	Unveränderliche PDF-Vertragskopie für beide Abschlusswege mit Zugriffsschutz und Tenant-Zuordnung im privaten Objektspeicher

---

5. API-Endpunkte

Die verbindliche und maschinenlesbare Quelle ist der UC00-OpenAPI-Vertrag. Die zugehörigen Abnahmeziele und 61 stabilen Testfall-IDs stehen im UC00-API-Testvertrag.

Methode	Endpoint	Akteur	Beschreibung
POST	/auth/login	alle	Normalisierte Anmeldung starten
POST	/auth/login/2fa	alle	Zwei-Faktor-Challenge abschliessen
POST	/auth/login/recovery	alle	Einmaligen Wiederherstellungscode verwenden
POST	/auth/token/refresh	authentifiziert	Sitzung rotieren
POST	/auth/logout	authentifiziert	Sitzung widerrufen
GET, POST	/auth/invite/{token} und /auth/invite/{token}/accept	öffentlich	Einladung prüfen und sicheren Erstzugang abschliessen
GET, POST	/superadmin/tenants	superadmin	Tenant-Liste abrufen oder Tenant vorbereiten
GET	/superadmin/tenants/{tenantSlug}	superadmin	Tenant mit Fachstatus abrufen
PATCH	/superadmin/tenants/{tenantSlug}/contract-party	superadmin	Vertragspartei und Vertragskontakt pflegen
PATCH	/superadmin/tenants/{tenantSlug}/status	superadmin	Zulässigen Statusübergang ausführen
GET	/superadmin/tenants/{tenantSlug}/contracts	superadmin	Versionierte Verträge auflisten
POST	/superadmin/tenants/{tenantSlug}/contracts/request	superadmin	Elektronischen Vertragsabschluss anfordern
GET, POST	/contracts/{token} und /contracts/{token}/accept	öffentlich	Vertrag prüfen und elektronisch akzeptieren
POST	/superadmin/tenants/{tenantSlug}/contracts/upload	superadmin	Extern unterzeichnetes PDF in Quarantäne hochladen
POST	/superadmin/tenants/{tenantSlug}/contracts/{contractId}/review	superadmin	Externen Nachweis getrennt akzeptieren oder ablehnen
POST	/superadmin/tenants/{tenantSlug}/admin-invitation	superadmin	Tenant-Admin nach gültigem Vertrag einladen
POST	/superadmin/tenants/{tenantSlug}/admin-invitation/resend	superadmin	Offene Admin-Einladung kontrolliert ersetzen
POST	/superadmin/users/{userId}/reset-2fa	superadmin	Zwei-Faktor-Authentifizierung revisionsfähig zurücksetzen
GET, PATCH	/tenants/profile	tenant_admin	Operatives Schulprofil abrufen oder pflegen
GET	/onboarding/status	tenant_admin	Persistenten Onboardingstatus abrufen
PUT	/onboarding/steps/{stepKey}	tenant_admin	Einen der vier typisierten Schritte speichern
POST	/onboarding/complete	tenant_admin	Onboarding nach Pflichtprüfung abschliessen
POST	/users/invitations	tenant_admin	Mitarbeiter tenantisoliert einladen
GET, POST	/superadmin/tenants/{tenantSlug}/offboarding	superadmin	Offboardingstatus abrufen oder Offboarding starten
POST	/superadmin/tenants/{tenantSlug}/offboarding/cancel	superadmin	Offboarding vor der Löschgrenze abbrechen
POST	/tenants/exports	tenant_admin	Tenant-Export anfordern
GET	/tenants/exports/{exportId}	tenant_admin	Exportstatus tenantisoliert abrufen
GET	/tenants/exports/{exportId}/download	tenant_admin	Export zeitbegrenzt und backendvermittelt herunterladen

---

6. Offene Fragen / Entscheide

ID	Frage	Priorität	Status	Entscheid
OE1	invitation_tokens: nullable + token_type	Hoch	✅	user_id ist nullable; token_type, Hash, Status und Lifecycle-Zeitpunkte sind im Prisma-v4-Zielschema und der statisch geprüften Initialmigration modelliert; Datenbankausführung und Backend bleiben offen
OE2	Slug-Generierung	Mittel	✅	8-stelliger Zufalls-Slug, keine Kundendaten in URL
OE3	E-Mail-Templates & Mehrsprachigkeit	Mittel	🟡	Fachlich entschieden: notification_templates, V1 nur DE; Modell und Initialmigration vorhanden, Seed-Inhalt und Laufzeitverhalten noch nicht verifiziert
OE4	2FA-Gerät verloren	Hoch	✅	Beide: Recovery-Codes + Superadmin-Reset
OE5	Schulprofil-Vollständigkeit	Niedrig	✅	Pflichtfeld-Markierung (*) + System-Hinweis, kein Prozentsatz
OE6	Tenant deaktivieren/löschen	Mittel	✅	V1 nur Deaktivieren, Löschen mit Pseudonymisierung in V2
OE7	Plan ändern auf SA-03	Mittel	✅	Separater Modal-Dialog mit Plan-Kacheln + optionaler Notiz
OE8	Superadmin-2FA-Reset auf SA-03	Mittel	✅	Im Benutzer-Abschnitt auf SA-03, Button direkt beim Admin
OE9	Onboarding-Status auf SA-03	Niedrig	✅	Status-Banner wenn Token offen oder Schulprofil unvollständig
OE10	Abschlusszeitpunkt des Auftragsverarbeitungsvertrags	Hoch	✅	ADR-015: nach vorbereitender Tenant-Anlage, vor Anlage und Einladung des Tenant-Admins
OE11	Extern unterzeichneter Vertrag	Hoch	✅	Superadmin kann signiertes Original hochladen und Abschluss kontrolliert erfassen

---

7. Schema-Delta (UC00)

Historisch berichtete Datenbankarbeiten

• Für invitation_tokens, notification_templates und recovery_codes wurden im Mai 2026 Datenbankarbeiten und Prüfungen berichtet.
• Diese Angaben bestätigen nicht den aktuellen Datenbankstand und ersetzen keine Migration des freigegebenen UC00-Zielschemas.
• Das Prisma-v4-Zielschema besitzt ein nullable InvitationToken.userId sowie tokenType, tokenHash, Status und Lifecycle-Zeitpunkte.
• NotificationTemplate ist im aktuellen Prisma-Schema vorhanden; produktive Inhalte und aktueller Datenbankstand wurden in diesem Prüflauf nicht verifiziert.
• RecoveryCode besitzt im Prisma-v4-Zielschema ein optionales tenantId und speichert ausschliesslich codeHash; der Authentifizierungsdienst verwendet das Hashfeld, vollständige Sicherheits- und Laufzeitnachweise bleiben offen.

Aktuell reproduzierbare technische Prüfung

• prisma validate ist gegen das eingecheckte Prisma-v4-Zielschema erfolgreich.
• prisma generate erzeugt Prisma Client 5.22.0 erfolgreich.
• npm run build ist am 10.08.2026 unmittelbar nach prisma generate erfolgreich.
• Vier Migrationen, Datenbankabgleich und Basis-Seed sind nachgewiesen; die additive Vertragskontaktmigration ist in der Entwicklungsdatenbank angewendet.
• Details und Befehlsreihenfolge stehen im Validierungsstatus; die Modellabdeckung steht im Prisma-v4-Zielmodellnachweis.

Abbildung von ADR-015 im Prisma-v4-Zielschema

• contract_pending und onboarding sind im Tenant-Lifecycle enthalten.
• Versionierter Vertragsnachweis, Parteiensnapshot und Vorgängerrelation sind je Tenant modelliert.
• Dokument-Hash, Objektschlüssel, Datei-, Scan- und Prüfmetadaten sind ohne PDF-Inhalt in SQL modelliert.
• electronic_acceptance und signed_document sind als Abschlussarten enthalten.
• Unterzeichner-, Vertretungs-, Upload- und Prüfmetadaten sind enthalten.
• Vertragstoken werden ausschliesslich als Hash mit Ablauf, Verwendung und Widerruf modelliert.
• Der sichere elektronische und externe Abschluss, Objektspeicher, Auditierung und die vollständige Datenbankintegration bleiben offen.

---

8. Abhängigkeiten

Abhängigkeit	Typ	Status
Supabase-Entwicklungsdatenbank und aktueller Ist-Soll-Abgleich	Technisch	🟡 Historisch konfiguriert; aktuelle Prüfung offen
Hostpoint-SMTP gemäss ADR-016 konfiguriert und für die Umgebung freigegeben	Technisch/Compliance	⬜ Offen
JWT-Authentifizierung implementiert	Technisch	🟡 Teilimplementierung vorhanden; Build und Sicherheitstests offen
2FA-Bibliothek (otplib)	Technisch	🟡 Im Quellcode verwendet; Build und Schutz des TOTP-Geheimnisses offen
Argon2id-Bibliothek und Migration vorhandener bcrypt-Passworthashes	Technisch	⬜ Offen
Slug-Generator (nanoid / custom)	Technisch	⬜ Offen
Superadmin-User existiert in DB	Daten	⬜ Offen

---

9. Screen-Flow & Wireframes

Status: ✅ Abgeschlossen — alle 11 Screens fertiggestellt (JSX + SVG)

9.1 Screen-Übersicht

Screen	Bezeichnung	Akteur	Wireframe	Dateien
SA-01	Tenant-Liste	superadmin	✅ Abgeschlossen	sa-01-tenant-liste.jsx / sa-01-tenant-liste.svg
SA-02	Neuer Tenant (Formular)	superadmin	✅ Abgeschlossen	sa-02-neuer-tenant.jsx / sa-02-neuer-tenant.svg
SA-03	Tenant-Detail (Profil + Status + Aktionen)	superadmin	✅ Abgeschlossen	sa-03-tenant-detail.jsx / sa-03-tenant-detail.svg
OB-01	Einladungslink öffnen (Token-Validierung)	tenant_admin	✅ Abgeschlossen	ob-01-einladungslink.jsx / ob-01-einladungslink.svg
OB-02	Passwort setzen	tenant_admin	✅ Abgeschlossen	ob-02-passwort-setzen.jsx / ob-02-passwort-setzen.svg
OB-03	2FA einrichten (QR-Code)	tenant_admin	✅ Abgeschlossen	ob-03-2fa-einrichten.jsx / ob-03-2fa-einrichten.svg
OB-04	Recovery-Codes anzeigen + bestätigen	tenant_admin	✅ Abgeschlossen	ob-04-recovery-codes.jsx / ob-04-recovery-codes.svg
OB-05	Schulprofil ausfüllen	tenant_admin	✅ Abgeschlossen	ob-05-schulprofil.jsx / ob-05-schulprofil.svg
OB-06	Dashboard (Erstanmeldung abgeschlossen)	tenant_admin	✅ Abgeschlossen	ob-06-dashboard.jsx / ob-06-dashboard.svg
TA-01	Schulprofil bearbeiten	tenant_admin	✅ Abgeschlossen	ta-01-schulprofil-bearbeiten.jsx / ta-01-schulprofil-bearbeiten.svg
TA-02	Login mit Recovery-Code	tenant_admin	✅ Abgeschlossen	ta-02-login-recovery-code.jsx / ta-02-login-recovery-code.svg

9.2 Wireframe-Entscheide

ID	Entscheid	Screen	Beschreibung
OE7	Plan ändern	SA-03	Separater Modal-Dialog mit Plan-Kacheln (Test / Starter / Professional / Enterprise), optionales Notizfeld, Button erst aktiv bei Planwechsel
OE8	Superadmin-2FA-Reset	SA-03	Button direkt im Benutzer-Abschnitt; Modal-Dialog mit Warn-Banner (Template-Hinweis 2fa_reset/de) und Bestätigungs-Checkbox
OE9	Onboarding-Status-Banner	SA-03	Gelber Banner erscheint nur wenn Token noch offen oder Schulprofil unvollständig; enthält direkten Button "Einladung erneut senden"
—	Deaktivieren-Dialog	SA-01 / SA-03	Identischer Modal-Dialog auf beiden Screens: Pflicht-Dropdown Grund, optionaler Freitext, E-Mail-Vorschau, Button erst aktiv nach Grundauswahl
—	Aktions-Buttons SA-01	SA-01	Pro Zeile: Detail → SA-03 | Deaktiv./Aktivier. → Dialog | Plan ä. → SA-03
—	Fortschrittsleiste	OB-01–OB-05	5-Schritt-Leiste (Link, Passwort, 2FA, Codes, Profil) durchläuft alle Onboarding-Screens
—	Token-Zustände	OB-01	Drei Zustände simulierbar: gültig (Happy Path), F3 abgelaufen, F4 bereits verwendet
—	Vollständigkeits-Indikator	OB-05	Zwei %-Werte nebeneinander: Pflichtfelder + alle Felder
—	Währung readonly	OB-05 / TA-01	Währungs-Feld nach erstem Speichern readonly mit G9-Hinweis
—	Recovery-Code Zwangs-2FA	TA-02	Nach erfolgreichem Login mit Recovery-Code → Zwangs-Weiterleitung zu OB-03 (neue 2FA einrichten)

9.3 Dateipfade

Alle Screen-Artefakte liegen unter docs/developer/uc00/screens/:

docs/developer/uc00/screens/
  sa-01-tenant-liste.jsx      ← interaktiver Wireframe (React)     ✅
  sa-01-tenant-liste.svg      ← statischer Wireframe (GitHub/Doku) ✅
  sa-02-neuer-tenant.jsx      ← interaktiver Wireframe (React)     ✅
  sa-02-neuer-tenant.svg      ← statischer Wireframe (GitHub/Doku) ✅
  sa-03-tenant-detail.jsx     ← interaktiver Wireframe (React)     ✅
  sa-03-tenant-detail.svg     ← statischer Wireframe (GitHub/Doku) ✅
  ob-01-einladungslink.jsx    ← interaktiver Wireframe (React)     ✅
  ob-01-einladungslink.svg    ← statischer Wireframe (GitHub/Doku) ✅
  ob-02-passwort-setzen.jsx   ← interaktiver Wireframe (React)     ✅
  ob-02-passwort-setzen.svg   ← statischer Wireframe (GitHub/Doku) ✅
  ob-03-2fa-einrichten.jsx    ← interaktiver Wireframe (React)     ✅
  ob-03-2fa-einrichten.svg    ← statischer Wireframe (GitHub/Doku) ✅
  ob-04-recovery-codes.jsx    ← interaktiver Wireframe (React)     ✅
  ob-04-recovery-codes.svg    ← statischer Wireframe (GitHub/Doku) ✅
  ob-05-schulprofil.jsx       ← interaktiver Wireframe (React)     ✅
  ob-05-schulprofil.svg       ← statischer Wireframe (GitHub/Doku) ✅
  ob-06-dashboard.jsx         ← interaktiver Wireframe (React)     ✅
  ob-06-dashboard.svg         ← statischer Wireframe (GitHub/Doku) ✅
  ta-01-schulprofil-bearbeiten.jsx ← interaktiver Wireframe (React)     ✅
  ta-01-schulprofil-bearbeiten.svg ← statischer Wireframe (GitHub/Doku) ✅
  ta-02-login-recovery-code.jsx    ← interaktiver Wireframe (React)     ✅
  ta-02-login-recovery-code.svg    ← statischer Wireframe (GitHub/Doku) ✅

9.4 Wireframe-Vorschau

9.4.1 SA-01 Tenant-Liste // superadmin

9.4.2 SA-02 Neuer Tenant (Formular) // superadmin

9.4.3 Tenant-Detail (Profil + Status + Aktionen) // superadmin

9.4.4 OB-01 Einladungslink öffnen (Token-Validierung) // tenant-admin

9.4.5 OB-02 Passwort setzen // tenant-admin

9.4.6 OB-03 2FA einrichten (QR-Code) // tenant-admin

9.4.7 OB-04 Recovery-Codes anzeigen + bestätigen // tenant-admin

9.4.8 OB-05 Schulprofil ausfüllen // tenant-admin

9.4.9 OB-06 Dashboard (Erstanmeldung abgeschlossen) // tenant-admin

9.4.10 TA-01 Schulprofil bearbeiten // superadmin

9.4.11 TA-02 Login mit Recovery-Code // superadmin

10. Testing

Status: ⬜ Offen — folgt in Schritt 7

10.1 Test-Kategorien (Planung)

Kategorie	Tool	Umfang
Unit-Tests	Jest	TenantService, InvitationService, AuthService, SlugGenerator, RecoveryCodeService
Integration-Tests	Jest + Supertest	Alle API-Endpunkte aus Abschnitt 5
E2E-Tests	Cypress	Happy Path UC00, Fehlerfälle F3, F4, F7
Sicherheits-Tests	Manuell	Tenant-Isolation, Rollenprüfung, Token-Missbrauch, Recovery-Code-Replay

10.2 Pflicht-Testfälle (Planung)

ID	Testfall	Typ
T01	Superadmin bereitet Tenant vor, schliesst den Vertragsprozess ab und sendet danach die Tenant-Admin-Einladung	E2E
T02	Schulinhaber akzeptiert Einladung → Account aktiv, 2FA aktiv	E2E
T03	Recovery-Codes werden generiert und angezeigt	E2E
T04	Schulinhaber füllt Schulprofil aus → Tenant vollständig	E2E
T05	Token nach 72h abgelaufen → Fehlerfall F3	Integration
T06	Token bereits verwendet → Fehlerfall F4	Integration
T07	Recovery-Code einlösen → einmalig gültig, danach ungültig	Integration
T08	Superadmin-Reset 2FA → E-Mail-Benachrichtigung	Integration
T09	Tenant A kann Daten von Tenant B nicht sehen	Sicherheit
T10	mitarbeiter kann keinen Tenant anlegen	Sicherheit
T11	Passwort unter Plattform-Minimum → Ablehnung	Unit
T12	Slug ist 8 Zeichen, alphanumerisch, eindeutig	Unit
T13	Mitarbeiter-Einladung blockiert wenn Schulprofil unvollständig	Integration
T14	Tenant wird ohne Vertragsnachweis nur als contract_pending vorbereitet	Integration
T15	Tenant-Admin-Einladung vor Vertragsabschluss wird mit 409 contract_not_accepted abgewiesen	Integration
T16	Elektronischer Vertragsabschluss speichert Version, Snapshot, Unterzeichner, Vertretungsbestätigung und UTC-Zeitpunkt	Integration
T17	Extern unterzeichnetes Dokument kann nur durch Superadmin vollständig erfasst und bestätigt werden	Sicherheit / Integration
T18	Fehlendes Dokument oder Pflichtmetadaten lassen den Status contract_pending unverändert	Integration
T19	Nach gültigem Vertragsabschluss wechselt der fachliche Status auf onboarding und die Produkteinladung wird freigegeben	E2E
T20	Neue Vertragsversion überschreibt keinen bestehenden Nachweis	Integration
T21	Dieselbe normalisierte E-Mail wird im gleichen und in einem anderen Tenant mit 409 email_already_in_use abgewiesen	Integration
T22	Gross- und Kleinschreibung sowie umgebende Leerzeichen erzeugen keine getrennten Benutzeridentitäten	Unit / Integration
T23	Deaktivierte Benutzer und Superadmins reservieren ihre normalisierte E-Mail weiterhin global	Integration

---

11. Was in CLAUDE.md übernommen wird

In CLAUDE.md übernommen:

• UC-ID, Name und Status (Zeile in der Checkliste)
• Neue Tabellen im DB-Überblick (notification_templates, recovery_codes)
• Neue offene Punkte in der Nächste-Schritte-Liste

Nur in der UC-Spezifikation (nicht in CLAUDE.md):

• Detaillierter Ablauf (Happy Path, Alternative Pfade, Fehlerfälle)
• Geschäftsregeln
• Offene Fragen / Entscheide und deren Begründungen
• Screen-Identifikation und Wireframes
• Test-Cases
• Schema-Delta-Details
• Abhängigkeiten
• Änderungshistorie