Deutsche Umlaute in UI und Dokumentation korrigieren

docs/saas-umstrukturierungsplan.md

@@ -3,28 +3,28 @@
 Stand: 2026-07-13
 
 Dieses Dokument beschreibt den geplanten Umbau der bestehenden Kaffeelisten-App zu
-einer mehrkundenfaehigen SaaS-Anwendung mit oeffentlicher Landingpage,
-Kundenregistrierung und geschuetzter App. Die bestehende Bedienlogik und das
+einer mehrkundenfähigen SaaS-Anwendung mit öffentlicher Landingpage,
+Kundenregistrierung und geschützter App. Die bestehende Bedienlogik und das
 visuelle Grunddesign sollen bewusst erhalten bleiben.
 
 ## Zielbild
 
-- Mehrere Kunden koennen eigene Kaffeelisten betreiben.
+- Mehrere Kunden können eigene Kaffeelisten betreiben.
 - Jeder Kunde hat isolierte Daten, Einstellungen, Mitglieder und Buchungen.
-- Neue Kunden koennen sich ueber eine oeffentliche Landingpage registrieren.
+- Neue Kunden können sich über eine öffentliche Landingpage registrieren.
 - Die operative App bleibt optisch nah am aktuellen Bestand: Sidebar, Tabellen,
   schlichte Formulare, HTML5-UP-Anmutung.
-- Authentifizierung, Rollen, Mandantenkontext und Sicherheitspruefungen werden
+- Authentifizierung, Rollen, Mandantenkontext und Sicherheitsprüfungen werden
   zentralisiert.
-- Finanznahe Vorgaenge werden nachvollziehbar und revisionsfreundlich
+- Finanznahe Vorgänge werden nachvollziehbar und revisionsfreundlich
   gespeichert.
 
-## Nicht-Ziele fuer den ersten Umbau
+## Nicht-Ziele für den ersten Umbau
 
 - Kein kompletter Design-Relaunch.
-- Keine verspielte Marketing-App statt der bestehenden Arbeitsoberflaeche.
-- Kein gleichzeitiger Neubau aller Randmodule, wenn diese fuer den MVP nicht
-  benoetigt werden.
+- Keine verspielte Marketing-App statt der bestehenden Arbeitsoberfläche.
+- Kein gleichzeitiger Neubau aller Randmodule, wenn diese für den MVP nicht
+  benötigt werden.
 - Kein Dual-Write zwischen Legacy und neuer App als Standardbetrieb.
 - Keine Mandanten-ID aus Formularfeldern oder URL-Parametern als alleinige
   Sicherheitsbasis.
@@ -35,12 +35,12 @@ Die aktuelle App ist eine flache PHP/sqlsrv-Legacy-App im Webroot.
 
 Wichtige Bereiche:
 
-- `index.php`: persoenliches Dashboard.
+- `index.php`: persönliches Dashboard.
 - `stricheintragen.php`: Sammelerfassung von Kaffee-Strichen.
 - `einzahlung.php`: Sammelerfassung von Einzahlungen.
-- `kaffeeliste.php`: Gesamtuebersicht.
+- `kaffeeliste.php`: Gesamtübersicht.
 - `mitarbeiterverwalten.php`: Mitglieder- und Adminpflege.
-- `letzteneintraege.php`: Korrektur beziehungsweise Loeschung letzter Buchungen.
+- `letzteneintraege.php`: Korrektur beziehungsweise Löschung letzter Buchungen.
 - `csvupload.php`: Zahlungsimport.
 - `exportKaffeeliste.php`: PDF-/Listenexport.
 - `mailversenden.php`: Massenmail.
@@ -49,7 +49,7 @@ Wichtige Bereiche:
 
 Zentrale technische Beobachtungen:
 
-- Authentifizierung haengt an Windows/IIS `AUTH_USER` und LDAP.
+- Authentifizierung hängt an Windows/IIS `AUTH_USER` und LDAP.
 - Die Mailadresse des Nutzers wird in `functionsLDAP.php` ermittelt.
 - Rollen liegen als Boolean `admin` direkt auf `kl_Mitarbeiter`.
 - Datenzugriff findet direkt in den einzelnen PHP-Seiten per `sqlsrv_query`
@@ -66,23 +66,23 @@ mit einem stabilen SaaS-Fundament:
 
 1. Bestand dokumentieren und fachliche Ergebnisse einfrieren.
 2. Mandantenmodell, Auth und Rollen sauber aufbauen.
-3. Bestehende Fachlogik schrittweise tenant-sicher uebernehmen.
+3. Bestehende Fachlogik schrittweise tenant-sicher übernehmen.
 4. Landingpage und App-Shell trennen, ohne das App-Design neu zu erfinden.
 
-So bleibt die vertraute Kaffeelisten-Oberflaeche erhalten, waehrend die
-Datenbasis und Sicherheit SaaS-faehig werden.
+So bleibt die vertraute Kaffeelisten-Oberfläche erhalten, während die
+Datenbasis und Sicherheit SaaS-fähig werden.
 
 ## Zielarchitektur
 
 ### Public-Bereich
 
-Der Public-Bereich ist ohne Login erreichbar und laedt keine Mandantendaten.
+Der Public-Bereich ist ohne Login erreichbar und lädt keine Mandantendaten.
 
 Empfohlene Routen:
 
 - `/`: Landingpage.
-- `/preise` oder spaeter `/pricing`: optional, falls Tarife eingefuehrt werden.
-- `/faq`: oeffentliche FAQ oder FAQ-Auszug.
+- `/preise` oder später `/pricing`: optional, falls Tarife eingeführt werden.
+- `/faq`: öffentliche FAQ oder FAQ-Auszug.
 - `/registrieren` beziehungsweise aktuell `register.php`: Kundenregistrierung.
 - `/login` beziehungsweise aktuell `login.php`: Login.
 - `/passwort-vergessen` beziehungsweise aktuell `passwort-vergessen.php`:
@@ -91,16 +91,16 @@ Empfohlene Routen:
 Landingpage-Inhalte:
 
 - Hero mit Name `Kaffeeliste` und kurzer Nutzenbeschreibung.
-- Drei Kernablaeufe: Kaffee nehmen, Strich setzen, bei Bedarf bezahlen.
+- Drei Kernabläufe: Kaffee nehmen, Strich setzen, bei Bedarf bezahlen.
 - Kurzer Blick auf Funktionen: Mitglieder, Guthaben, Einzahlungen, Export,
   Hinweise.
 - App-Screenshot oder Demo-Ansicht im bestehenden Stil.
 - FAQ-Auszug.
 - Call-to-Action zu Registrierung und Login.
 
-### Geschuetzte App
+### Geschützte App
 
-Die geschuetzte App bleibt die operative Arbeitsoberflaeche.
+Die geschützte App bleibt die operative Arbeitsoberfläche.
 
 Empfohlene Routen:
 
@@ -109,8 +109,8 @@ Empfohlene Routen:
 - `/app/striche`: Eigene Striche erfassen, falls erlaubt.
 - `/app/einzahlungen`: Zahlungen und PayPal-Optionen.
 - `/app/mitglieder`: Mitgliederverwaltung.
-- `/app/liste`: Gesamtuebersicht.
-- `/app/buchungen`: Letzte Eintraege und Korrekturen.
+- `/app/liste`: Gesamtübersicht.
+- `/app/buchungen`: Letzte Einträge und Korrekturen.
 - `/app/importe`: CSV-Importe.
 - `/app/export/pdf`: PDF-/Listenexport.
 - `/app/hinweise`: Hinweise.
@@ -118,29 +118,29 @@ Empfohlene Routen:
 
 Die App sollte eine Sidebar behalten, aber besser gruppiert werden:
 
-- Persoenlich: Meine Kaffeeliste, Namensanpassung, FAQ.
+- Persönlich: Meine Kaffeeliste, Namensanpassung, FAQ.
 - Erfassung: Striche, Einzahlungen.
 - Auswertung: Kaffeeliste, Buchungen, Export.
 - Administration: Mitglieder, Hinweise, Einstellungen, Importe.
 - Konto: Kundenkonto und Logout. Public-Links wie Login und Registrierung
-  gehoeren nicht in die App-Sidebar.
+  gehören nicht in die App-Sidebar.
 
 ### Webspace- und Host-Strategie
 
-Empfohlen fuer den Start:
+Empfohlen für den Start:
 
-- `kaffeeliste.de` oder `www.kaffeeliste.de` fuer Landingpage, Registrierung
+- `kaffeeliste.de` oder `www.kaffeeliste.de` für Landingpage, Registrierung
   und Login.
-- `app.kaffeeliste.de` fuer die geschuetzte App.
-- Keine Wildcard-Subdomains fuer Kunden.
-- Mandantenauswahl nach Login ueber Session und `tenant_memberships`.
-- Kundeneigene feste Domains oder Subdomains erst spaeter gezielt einrichten,
-  wenn DNS und Zertifikat pro Domain sauber geprueft sind.
+- `app.kaffeeliste.de` für die geschützte App.
+- Keine Wildcard-Subdomains für Kunden.
+- Mandantenauswahl nach Login über Session und `tenant_memberships`.
+- Kundeneigene feste Domains oder Subdomains erst später gezielt einrichten,
+  wenn DNS und Zertifikat pro Domain sauber geprüft sind.
 
-Damit bleibt der Betrieb webspace-tauglich: Fuer den Start reichen zwei feste
-Hosts mit normalen Let's-Encrypt-Zertifikaten. Die fachliche Tenant-Aufloesung
+Damit bleibt der Betrieb webspace-tauglich: Für den Start reichen zwei feste
+Hosts mit normalen Let's-Encrypt-Zertifikaten. Die fachliche Tenant-Auflösung
 ist in M3 vorbereitet; produktive Host-Rewrites, Cookie-Domain und Zertifikats-
-Details gehoeren zur M8-Betriebshaertung.
+Details gehören zur M8-Betriebshärtung.
 
 ## Datenmodell
 
@@ -218,9 +218,9 @@ Wichtige Modellierungsregeln:
 - `users` sind Login-Konten.
 - `participants` sind Kaffee-Teilnehmer.
 - Ein Teilnehmer kann, muss aber nicht, ein Login-Konto haben.
-- Rollen gehoeren in `tenant_memberships`, nicht direkt auf Teilnehmer.
-- Buchungen sollten nicht hart geloescht werden.
-- Korrekturen laufen ueber Storno- oder Reversal-Eintraege.
+- Rollen gehören in `tenant_memberships`, nicht direkt auf Teilnehmer.
+- Buchungen sollten nicht hart gelöscht werden.
+- Korrekturen laufen über Storno- oder Reversal-Einträge.
 - Legacy-IDs werden bei Migration gespeichert, damit Ergebnisse vergleichbar
   bleiben.
 - Geldwerte sollten als Cent-Integer gespeichert werden, nicht als Float.
@@ -229,7 +229,7 @@ Wichtige Modellierungsregeln:
 
 Empfohlene Rollen:
 
-- `owner`: Kunde verwalten, Billing, Admins, Loeschung, Grundeinstellungen.
+- `owner`: Kunde verwalten, Billing, Admins, Löschung, Grundeinstellungen.
 - `admin`: Mitglieder, Hinweise, fachliche Einstellungen, Auswertungen.
 - `treasurer`: Zahlungen, CSV-Import, Korrekturen, Exporte, Mails.
 - `member`: eigenes Dashboard, eigene Striche, eigener Anzeigename.
@@ -246,22 +246,22 @@ SaaS-Basis:
 - E-Mail-Verifikation.
 - Passwort-Reset.
 - Sichere Session-Cookies.
-- CSRF-Schutz fuer alle schreibenden Aktionen.
-- Rate-Limits fuer Login, Registrierung und Passwort-Reset.
+- CSRF-Schutz für alle schreibenden Aktionen.
+- Rate-Limits für Login, Registrierung und Passwort-Reset.
 - Zentrale Funktionen oder Middleware: `requireLogin`, `requireTenant`,
   `requireRole`, `csrfToken`.
 
-Tenant-Aufloesung:
+Tenant-Auflösung:
 
-- Primaer serverseitig aus Subdomain, Custom Domain oder tenantgebundener
+- Primär serverseitig aus Subdomain, Custom Domain oder tenantgebundener
   Auswahl nach Login.
 - Nicht allein aus Hidden Inputs oder frei manipulierbaren IDs.
 - Jede fachliche Query braucht einen Tenant-Scope.
 
-Spaeter moeglich:
+Später möglich:
 
 - LDAP/AD oder SSO pro Kunde als optionaler Identity Provider.
-- MFA fuer Owner/Admins.
+- MFA für Owner/Admins.
 - Row-Level-Security in der Datenbank.
 
 ## Design-Leitplanken
@@ -270,12 +270,12 @@ Das bestehende Design soll erhalten bleiben.
 
 Beibehalten:
 
-- Gruener Akzent `#38761d`.
-- Weiss/Grau als ruhige Grundflaeche.
-- Roboto Slab fuer Ueberschriften.
-- Open Sans fuer Fliesstext.
-- Sidebar fuer die geschuetzte App.
-- Tabellen als primaere Darstellung fuer operative Daten.
+- Grüner Akzent `#38761d`.
+- Weiß/Grau als ruhige Grundfläche.
+- Roboto Slab für Überschriften.
+- Open Sans für Fließtext.
+- Sidebar für die geschützte App.
+- Tabellen als primäre Darstellung für operative Daten.
 - Schlichte Formularfelder und Buttons.
 
 Verbessern ohne Relaunch:
@@ -283,38 +283,38 @@ Verbessern ohne Relaunch:
 - Hinweise als wiederverwendbare Komponente statt Inline-Style.
 - Einheitliche Erfolgs-, Fehler- und Warnmeldungen.
 - Dashboardwerte als kompakte Statusbereiche.
-- Aktionsleisten ueber Tabellen.
+- Aktionsleisten über Tabellen.
 - Sidebar-Gruppierung und aktive Navigation.
-- FAQ strukturieren, aber Inhalte nicht stark veraendern.
+- FAQ strukturieren, aber Inhalte nicht stark verändern.
 
 Nicht tun:
 
 - Kein komplett neues Farbsystem.
 - Keine dekorative Marketingoptik in der App.
-- Keine App-Tabellen in Kartenlandschaften aufloesen.
-- Keine Navigationsstruktur, die die heutigen Kernablaeufe versteckt.
+- Keine App-Tabellen in Kartenlandschaften auflösen.
+- Keine Navigationsstruktur, die die heutigen Kernabläufe versteckt.
 
 ## Meilensteinplan
 
-Uebersicht:
+Übersicht:
 
 | Meilenstein | Schwerpunkt | Hauptergebnis |
 | --- | --- | --- |
 | M0 | Baseline | Bestand, Sicherheit und Designreferenz sind dokumentiert |
-| M1 | Golden Master | Legacy-Ergebnisse sind als Vergleichsbasis eingefroren; HTTP-Smoke prueft sichere Seiten |
+| M1 | Golden Master | Legacy-Ergebnisse sind als Vergleichsbasis eingefroren; HTTP-Smoke prüft sichere Seiten |
 | M2 | Technisches Fundament | Abgeschlossen: Migrationen, Bootstrap, Session, CSRF-Helper und Legacy-Schreibseitenschutz stehen |
 | M3 | SaaS-Basis | Abgeschlossen: Tenants, User, Registrierung, Login, Rollen, Mail-Links und zentrale Mandantenauswahl funktionieren |
-| M4 | Datenmigration | Gestartet: Ledger-Tabelle, Legacy-Backfill, Paritaetscheck, Ledger-Service und Preview sind umgesetzt |
-| M5 | App-Kern | Gestartet: Gesamtuebersicht liest read-only aus dem Ledger |
+| M4 | Datenmigration | Gestartet: Ledger-Tabelle, Legacy-Backfill, Paritätscheck, Ledger-Service und Preview sind umgesetzt |
+| M5 | App-Kern | Gestartet: Gesamtübersicht liest read-only aus dem Ledger |
 | M6 | Betriebsflows | Import, Export, Mail und Jahresprozesse sind auditierbar |
-| M7 | Landingpage | Public-Seite und Auth-Seiten sind im gemeinsamen Stil nutzbar; spaetere Ausbaustufen folgen |
-| M8 | Haertung | Betrieb, Datenschutz, Monitoring und Isolation sind geprueft |
+| M7 | Landingpage | Public-Seite und Auth-Seiten sind im gemeinsamen Stil nutzbar; spätere Ausbaustufen folgen |
+| M8 | Härtung | Betrieb, Datenschutz, Monitoring und Isolation sind geprüft |
 | M9 | Cutover | Produktivumstellung ist vorbereitet und Legacy ist read-only |
 
 ### M0: Planungs- und Sicherheitsbaseline
 
 Ziel:
-Den aktuellen Zustand verlaesslich dokumentieren, bevor umgebaut wird.
+Den aktuellen Zustand verlässlich dokumentieren, bevor umgebaut wird.
 
 Arbeitsartefakte:
 
@@ -331,7 +331,7 @@ Schritte:
 - Tabellen, Spalten, Indizes und Constraints dokumentieren.
 - Bekannte Jobs/Skripte erfassen, zum Beispiel Mailversand und Jahresauswertung.
 - Secrets inventarisieren und rotieren, insbesondere hart codierte Zugangsdaten.
-- Bestehende Seiten und UI-Zustaende per Screenshots festhalten.
+- Bestehende Seiten und UI-Zustände per Screenshots festhalten.
 - Fachliche Kernregeln dokumentieren: Saldo, Jahreswerte, Preis pro Strich,
   100-Tage-Listen, CSV-Deduplizierung, PDF-Ausgabe.
 
@@ -342,7 +342,7 @@ Ergebnis:
 - Designreferenz.
 - Liste kritischer Sicherheitsrisiken.
 
-Abhaengigkeiten:
+Abhängigkeiten:
 
 - Zugriff auf echte oder anonymisierte Datenbank.
 - Kenntnis der Produktivumgebung.
@@ -350,7 +350,7 @@ Abhaengigkeiten:
 ### M1: Golden-Master-Validierung
 
 Ziel:
-Sicherstellen, dass spaetere neue Berechnungen dieselben Ergebnisse wie der
+Sicherstellen, dass spätere neue Berechnungen dieselben Ergebnisse wie der
 Bestand liefern.
 
 Schritte:
@@ -359,42 +359,42 @@ Schritte:
   Master in der MySQL-Dev-Datenbank.
 - Pro Mitglied berechnen: Gesamteinzahlungen, Gesamtausgaben, Gesamtstriche,
   aktueller Stand, Jahreswerte. Erledigt mit `scripts/check-golden-master.php`.
-- CSV-Importfaelle sammeln: Treffer, Dubletten, unbekannte Namen. Erledigt im
+- CSV-Importfälle sammeln: Treffer, Dubletten, unbekannte Namen. Erledigt im
   Golden-Master-Check.
-- Testfaelle fuer Guthaben, Schulden, Nullsaldo und inaktive Teilnehmer
+- Testfälle für Guthaben, Schulden, Nullsaldo und inaktive Teilnehmer
   anlegen. Erledigt.
-- Sichere GET-Seiten per HTTP-Smoke pruefen. Erledigt mit
+- Sichere GET-Seiten per HTTP-Smoke prüfen. Erledigt mit
   `scripts/http-smoke.php`.
 - PDF-/Export-Summen als Referenz sichern. Offen, weil die TCPDF-Kopie im Repo
-  unvollstaendig ist.
+  unvollständig ist.
 
 Ergebnis:
 
 - Golden-Master-Daten.
 - Vergleichsqueries oder Vergleichsskript.
-- HTTP-Smoke-Test fuer sichere UI-Seiten.
-- Akzeptanzkriterien fuer Migration und neue App.
-- Dokumentierte offene Punkte: PDF-Export/TCPDF, PHPMailer-Abhaengigkeit,
+- HTTP-Smoke-Test für sichere UI-Seiten.
+- Akzeptanzkriterien für Migration und neue App.
+- Dokumentierte offene Punkte: PDF-Export/TCPDF, PHPMailer-Abhängigkeit,
   GET-Nebenwirkungen bei Mailversand und Jahresauswertung.
 
-Abhaengigkeiten:
+Abhängigkeiten:
 
 - M0 abgeschlossen.
 - PDF-/Mail-/Jahresprozesse werden in M6 gezielt neu gestaltet, statt sie in M1
-  per GET-Smoke auszufuehren.
+  per GET-Smoke auszuführen.
 
 ### M2: Technisches Fundament
 
 Ziel:
-Eine saubere Basis fuer App, Public-Seiten, Auth und Mandanten schaffen.
+Eine saubere Basis für App, Public-Seiten, Auth und Mandanten schaffen.
 
 Schritte:
 
 - Projektstruktur festlegen: Public-Routes, App-Routes, Views/Templates,
   Services/Repositories.
-- Zentrales Bootstrap fuer Config, DB-Verbindung, Session und Fehlerbehandlung.
+- Zentrales Bootstrap für Config, DB-Verbindung, Session und Fehlerbehandlung.
   Begonnen mit `app/bootstrap.php`.
-- Versionierte Migrationen einfuehren. Begonnen mit
+- Versionierte Migrationen einführen. Begonnen mit
   `database/migrations/0001_legacy_mysql_baseline.sql` und
   `scripts/migrate.php`.
 - Layouts trennen: Public-Layout und App-Layout. Noch offen; Header/Footer
@@ -405,36 +405,36 @@ Schritte:
   abgesichert: `hinweise.php`, `mitarbeiterverwalten.php`,
   `namenanpassen.php`, `index.php`, `stricheintragen.php`, `einzahlung.php`,
   `letzteneintraege.php`, `csvupload.php`.
-- CSV-Upload ausserhalb des Webroots speichern. In M2 als Legacy-Haertung
-  umgesetzt: temporaer unter `var/uploads`, Dateityp-/Groessenpruefung und
-  Loeschung nach Verarbeitung.
+- CSV-Upload außerhalb des Webroots speichern. In M2 als Legacy-Härtung
+  umgesetzt: temporär unter `var/uploads`, Dateityp-/Größenprüfung und
+  Löschung nach Verarbeitung.
 - Konfigurationswerte aus Code in Umgebung oder Settings verschieben.
 
 Ergebnis:
 
-- Grundgeruest fuer neue SaaS-App.
-- Kein fachlicher Rewrite, aber klare Struktur fuer die Migration.
+- Grundgerüst für neue SaaS-App.
+- Kein fachlicher Rewrite, aber klare Struktur für die Migration.
 - Dokumentation: `docs/m2-technical-foundation.md`.
-- Status: abgeschlossen fuer den M2-Scope.
+- Status: abgeschlossen für den M2-Scope.
 
-Abhaengigkeiten:
+Abhängigkeiten:
 
-- Entscheidung, ob PHP nativ weitergefuehrt oder ein Framework genutzt wird.
+- Entscheidung, ob PHP nativ weitergeführt oder ein Framework genutzt wird.
 - M2 bleibt bewusst ohne Tenant-/User-/Rollen-Tabellen; diese starten in M3.
 
 ### M3: Mandanten, Registrierung und Login
 
 Ziel:
-Mehrkundenfaehigkeit und Kunden-Onboarding technisch aktivieren.
+Mehrkundenfähigkeit und Kunden-Onboarding technisch aktivieren.
 
 Schritte:
 
-- Tabellen fuer `tenants`, `users`, `tenant_memberships` und
+- Tabellen für `tenants`, `users`, `tenant_memberships` und
   `tenant_settings` anlegen. Vorbereitung dokumentiert in
   `docs/m3-saas-basis-vorbereitung.md`: erster Schritt erledigt.
-- Zusaetzlich `participants` als getrennte Kaffee-Teilnehmer-Tabelle anlegen:
+- Zusätzlich `participants` als getrennte Kaffee-Teilnehmer-Tabelle anlegen:
   erledigt.
-- Default-Tenant fuer den aktuellen Bestand anlegen: erledigt.
+- Default-Tenant für den aktuellen Bestand anlegen: erledigt.
 - Bestehende `kl_Mitarbeiter` idempotent in `participants` spiegeln:
   erledigt.
 - Registrierung: Tenant + Owner-User + Default-Settings erzeugen: erster
@@ -442,10 +442,10 @@ Schritte:
 - Login und Logout bauen: erster Flow erledigt.
 - Passwort-Reset und E-Mail-Verifikation bauen: Dev-Flow mit Single-Use-Tokens
   und Mail-Transport-Abstraktion erledigt.
-- Tenant-Aufloesung definieren: zentrale App-Domain mit Session-Kontext und
+- Tenant-Auflösung definieren: zentrale App-Domain mit Session-Kontext und
   Mandantenauswahl erledigt; feste Domains vorbereitet, keine Wildcards.
-- Rollenpruefung zentralisieren: erster Owner/Admin-Check erledigt.
-- Erste Admin-/Owner-Seite fuer Grundeinstellungen: erledigt.
+- Rollenprüfung zentralisieren: erster Owner/Admin-Check erledigt.
+- Erste Admin-/Owner-Seite für Grundeinstellungen: erledigt.
 - Erste Public-Landingpage mit CTA zu Login und Registrierung: erledigt.
 - Login, Registrierung, Passwort-Reset und E-Mail-Verifikation im Public-Stil:
   erledigt.
@@ -454,51 +454,51 @@ Schritte:
 Ergebnis:
 
 - Ein neuer Kunde kann sich registrieren und in seine eigene App gelangen.
-- Rollen und Tenant-Kontext sind serverseitig verfuegbar.
-- Reset- und Verifikationslinks koennen im Dev-Modus geloggt und produktiv ueber
+- Rollen und Tenant-Kontext sind serverseitig verfügbar.
+- Reset- und Verifikationslinks können im Dev-Modus geloggt und produktiv über
   einen konfigurierten Mail-Transport versendet werden.
-- Status: abgeschlossen fuer den M3-Scope.
+- Status: abgeschlossen für den M3-Scope.
 
-Abhaengigkeiten:
+Abhängigkeiten:
 
 - M2 abgeschlossen.
 
 ### M4: Migration des fachlichen Kerns
 
 Ziel:
-Bestehende Kaffeelisten-Daten tenant-sicher uebernehmen.
+Bestehende Kaffeelisten-Daten tenant-sicher übernehmen.
 
 Schritte:
 
-- Initialen Tenant fuer den bisherigen Bestand anlegen: erledigt in M3.
+- Initialen Tenant für den bisherigen Bestand anlegen: erledigt in M3.
 - `kl_Mitarbeiter` nach `participants` migrieren: erledigt in M3.
-- `admin`-Informationen in `tenant_memberships` oder Admin-Rollen ueberfuehren:
+- `admin`-Informationen in `tenant_memberships` oder Admin-Rollen überführen:
   erledigt in M3.
 - `kl_config` nach `tenant_settings` migrieren: erledigt in M3.
 - `ledger_entries` als tenant-sichere Buchungstabelle anlegen: erledigt.
 - `kl_Einzahlungen` und `kl_Kaffeeverbrauch` additiv nach `ledger_entries`
   spiegeln: erster Backfill erledigt.
-- Legacy-IDs speichern: erledigt ueber `legacy_table` und `legacy_id`.
+- Legacy-IDs speichern: erledigt über `legacy_table` und `legacy_id`.
 - Salden gegen Golden-Master vergleichen: Kontrollskript erledigt.
-- Ledger-Service fuer Tenant-Summen, Teilnehmer-Summen und letzte Buchungen:
+- Ledger-Service für Tenant-Summen, Teilnehmer-Summen und letzte Buchungen:
   erledigt.
-- Read-only Ledger-Preview fuer Browservergleich: erledigt.
+- Read-only Ledger-Preview für Browservergleich: erledigt.
 
 Ergebnis:
 
 - Bestehender Datenbestand kann im neuen Modell abgebildet werden.
-- Saldenparitaet ist ueber `scripts/check-m4-ledger-migration.php`
+- Saldenparität ist über `scripts/check-m4-ledger-migration.php`
   nachweisbar.
-- Erste App-Abfragen koennen ueber `app/ledger.php` tenant-sicher aus dem neuen
+- Erste App-Abfragen können über `app/ledger.php` tenant-sicher aus dem neuen
   Modell lesen.
 - `ledger-preview.php` zeigt die neue Ledger-Auswertung ohne Schreibzugriffe.
 - Dokumentation: `docs/m4-data-migration.md`.
 
-Abhaengigkeiten:
+Abhängigkeiten:
 
 - M1 und M3 abgeschlossen.
 
-### M5: Geschuetzte App-Funktionen
+### M5: Geschützte App-Funktionen
 
 Ziel:
 Die operativen Kernseiten im neuen Modell bereitstellen.
@@ -509,9 +509,9 @@ Schritte:
 - Eigene Stricherfassung umsetzen.
 - Zahlungs-/PayPal-Bereich umsetzen.
 - Mitgliederverwaltung tenant- und rollenbasiert umsetzen.
-- Gesamtuebersicht umsetzen: erster read-only Stand in `kaffeeliste.php`
+- Gesamtübersicht umsetzen: erster read-only Stand in `kaffeeliste.php`
   erledigt.
-- Letzte Eintraege und Korrekturen als Storno statt Delete umsetzen.
+- Letzte Einträge und Korrekturen als Storno statt Delete umsetzen.
 - Hinweise als tenant-spezifische Notices umsetzen.
 
 Ergebnis:
@@ -520,7 +520,7 @@ Ergebnis:
 - App sieht weiterhin nach bestehender Kaffeeliste aus.
 - Erster M5-Stand ist in `docs/m5-app-kern.md` dokumentiert.
 
-Abhaengigkeiten:
+Abhängigkeiten:
 
 - M4 abgeschlossen.
 
@@ -531,8 +531,8 @@ Admin- und Treasurer-Flows produktionsreif machen.
 
 Schritte:
 
-- CSV-Import mit Vorschau, Dublettenpruefung und Audit bauen.
-- Uploads ausserhalb des Webroots speichern.
+- CSV-Import mit Vorschau, Dublettenprüfung und Audit bauen.
+- Uploads außerhalb des Webroots speichern.
 - PDF-/Listenexport aus neuem Datenmodell bauen.
 - Mailversand als nachvollziehbaren Versandjob mit Dry-Run und Versandlog
   gestalten.
@@ -540,22 +540,22 @@ Schritte:
 
 Ergebnis:
 
-- Kassenverwaltung ist fuer reale Betriebsablaeufe vollstaendig.
+- Kassenverwaltung ist für reale Betriebsabläufe vollständig.
 - Import/Export/Mail sind auditierbar.
 
-Abhaengigkeiten:
+Abhängigkeiten:
 
-- M5 fuer die Kernansichten.
+- M5 für die Kernansichten.
 
-### M7: Oeffentliche Landingpage
+### M7: Öffentliche Landingpage
 
 Ziel:
-Werbliche Einstiegseite und Registrierung verfuegbar machen, ohne die App-Optik
+Werbliche Einstiegseite und Registrierung verfügbar machen, ohne die App-Optik
 zu verwischen.
 
 Schritte:
 
-- Public-Layout mit bestehender Typografie und gruenem Akzent bauen. Erster
+- Public-Layout mit bestehender Typografie und grünem Akzent bauen. Erster
   Stand als `landing.php` und `assets/css/public.css` erledigt.
 - Landingpage-Inhalte erstellen. Erster Stand erledigt.
 - Demo-Screenshot oder Demo-Ansicht einbinden.
@@ -568,26 +568,26 @@ Schritte:
 
 Ergebnis:
 
-- Interessenten verstehen das Produkt und koennen sich registrieren.
-- Bestehende App bleibt optisch eigenstaendig und arbeitsorientiert.
+- Interessenten verstehen das Produkt und können sich registrieren.
+- Bestehende App bleibt optisch eigenständig und arbeitsorientiert.
 
-Abhaengigkeiten:
+Abhängigkeiten:
 
-- M3 fuer Registrierung.
-- M5 fuer echte App-Screens oder Demo.
+- M3 für Registrierung.
+- M5 für echte App-Screens oder Demo.
 
-### M8: Haertung, Datenschutz und Betrieb
+### M8: Härtung, Datenschutz und Betrieb
 
 Ziel:
-Die SaaS-App fuer mehrere Kunden sicher betreiben.
+Die SaaS-App für mehrere Kunden sicher betreiben.
 
 Schritte:
 
 - Backups und Restore-Prozess definieren.
 - Monitoring und Fehlerlogging einrichten.
-- Audit-Log fuer Admin-Aktionen pruefen.
+- Audit-Log für Admin-Aktionen prüfen.
 - Datenexport pro Tenant.
-- Loesch-/Anonymisierungsprozess fuer Teilnehmer und Kunden.
+- Lösch-/Anonymisierungsprozess für Teilnehmer und Kunden.
 - Rate-Limits und Security Headers.
 - Mandanten-Isolation testen.
 - Rollenmatrix testen.
@@ -596,7 +596,7 @@ Ergebnis:
 
 - SaaS ist betrieblich und datenschutzseitig belastbarer.
 
-Abhaengigkeiten:
+Abhängigkeiten:
 
 - M3 bis M6.
 
@@ -607,10 +607,10 @@ Produktive Umstellung ohne Datenverlust.
 
 Schritte:
 
-- Legacy fuer Schreibzugriffe sperren.
+- Legacy für Schreibzugriffe sperren.
 - Finalen Delta-Export ziehen.
-- Migration ausfuehren.
-- Rowcounts, Salden, PDF-Stichproben und Importhistorie pruefen.
+- Migration ausführen.
+- Rowcounts, Salden, PDF-Stichproben und Importhistorie prüfen.
 - DNS oder Reverse Proxy umschalten.
 - Legacy 30 bis 90 Tage read-only als Archiv behalten.
 - Rollback-Fenster und Vorgehen dokumentieren.
@@ -618,15 +618,15 @@ Schritte:
 Ergebnis:
 
 - Neuer SaaS-Betrieb ist live.
-- Alter Bestand bleibt fuer Rueckfragen lesbar.
+- Alter Bestand bleibt für Rückfragen lesbar.
 
-Abhaengigkeiten:
+Abhängigkeiten:
 
 - M8 abgeschlossen.
 
 ## Empfohlene MVP-Reihenfolge
 
-Fuer den ersten produktnahen MVP sollten nicht alle Randmodule gleichzeitig
+Für den ersten produktnahen MVP sollten nicht alle Randmodule gleichzeitig
 umgebaut werden.
 
 MVP-Paket:
@@ -634,12 +634,12 @@ MVP-Paket:
 1. Tenant, User, Login, Registrierung.
 2. Mail-Links, zentrale Mandantenauswahl und erste Landingpage.
 3. Teilnehmer, Settings, Ledger.
-4. Dashboard, Striche, Einzahlungen, Gesamtuebersicht.
+4. Dashboard, Striche, Einzahlungen, Gesamtübersicht.
 5. Mitgliederverwaltung.
 6. Hinweise.
 7. CSV-Import, Export.
 
-Spaeter:
+Später:
 
 - Umfrage-Modul.
 - SSO/LDAP pro Kunde.
@@ -650,7 +650,7 @@ Spaeter:
 
 ## Validierung
 
-Fachliche Pruefungen:
+Fachliche Prüfungen:
 
 - Saldo je Teilnehmer alt gegen neu.
 - Jahreswerte alt gegen neu.
@@ -659,37 +659,37 @@ Fachliche Pruefungen:
 - Export-Summen alt gegen neu.
 - CSV-Import: identische Treffer- und Dublettenlogik.
 
-Sicherheitspruefungen:
+Sicherheitsprüfungen:
 
 - Fremde Tenant-IDs liefern keine Daten.
 - Fremde Teilnehmer-IDs liefern keine Daten.
 - Admin-Funktionen sind ohne Rolle blockiert.
 - Alle POST-Aktionen brauchen CSRF.
-- Uploads sind nicht direkt ausfuehrbar.
+- Uploads sind nicht direkt ausführbar.
 - Ausgabe von Namen, Mails und Hinweisen ist escaped.
 
-UX-Pruefungen:
+UX-Prüfungen:
 
 - Kernseiten bleiben optisch wiedererkennbar.
-- Sidebar bleibt fuer App-Nutzer vertraut.
+- Sidebar bleibt für App-Nutzer vertraut.
 - Landingpage zeigt keine App-Adminnavigation.
 - Mobile Darstellung bleibt bedienbar.
 - Tabellen bleiben lesbar.
 
-## Risiken und Gegenmassnahmen
+## Risiken und Gegenmaßnahmen
 
-| Risiko | Gegenmassnahme |
+| Risiko | Gegenmaßnahme |
 | --- | --- |
 | Tenant-Leak durch vergessene Query-Filter | Zentrale Repository-/Query-Schicht, Tests mit zwei Tenants |
 | Falsche Salden nach Migration | Golden-Master-Vergleich vor Cutover |
-| Harte Deletes verlieren Audit-Historie | Storno-/Reversal-Modell fuer Buchungen |
+| Harte Deletes verlieren Audit-Historie | Storno-/Reversal-Modell für Buchungen |
 | Login und Teilnehmer werden vermischt | `users` und `participants` strikt trennen |
 | Bestehendes Design driftet weg | Designreferenz und App-Komponenten definieren |
-| CSV-Upload unsicher | Upload ausserhalb Webroot, Dateityppruefung, Importvorschau |
+| CSV-Upload unsicher | Upload außerhalb Webroot, Dateitypprüfung, Importvorschau |
 | Mailversand nicht nachvollziehbar | Versandlog, Dry-Run, Job-Status |
-| Unvollstaendige Vendor-Kopien fuer PDF/Mail | Dependencies sauber vendoren oder ersetzen, Smoke-Tests danach erweitern |
-| AD/LDAP blockiert SaaS-Onboarding | E-Mail/Passwort als Basis, SSO spaeter optional |
-| Kein DB-Schema im Repo | Schema exportieren und Migrationen einfuehren |
+| Unvollständige Vendor-Kopien für PDF/Mail | Dependencies sauber vendoren oder ersetzen, Smoke-Tests danach erweitern |
+| AD/LDAP blockiert SaaS-Onboarding | E-Mail/Passwort als Basis, SSO später optional |
+| Kein DB-Schema im Repo | Schema exportieren und Migrationen einführen |
 
 ## Offene Entscheidungen
 
@@ -703,9 +703,9 @@ UX-Pruefungen:
 - Braucht der MVP schon Tarife/Billing oder erstmal nur Registrierung?
 - Sollen bestehende Kunden per Einladung oder per Self-Service onboarden?
 
-## Naechster konkreter Arbeitsschritt
+## Nächster konkreter Arbeitsschritt
 
-Als naechstes sollte M0 gestartet werden:
+Als nächstes sollte M0 gestartet werden:
 
 1. Produktiv-/Testdatenbankschema exportieren.
 2. Screenshot-Referenz der wichtigsten Seiten erstellen.