Deutsche Umlaute in UI und Dokumentation korrigieren

docs/m3-saas-basis-vorbereitung.md

@@ -2,27 +2,27 @@
 
 Stand: 2026-07-13
 
-M3 fuehrt Mandanten, Benutzer, Mitgliedschaften und Grundeinstellungen additiv
-ein. Die bestehende Legacy-App bleibt dabei lauffaehig und wird noch nicht auf
+M3 führt Mandanten, Benutzer, Mitgliedschaften und Grundeinstellungen additiv
+ein. Die bestehende Legacy-App bleibt dabei lauffähig und wird noch nicht auf
 das neue Modell umgestellt.
 
-Status: abgeschlossen fuer den M3-Scope. M4 startet mit der additiven
+Status: abgeschlossen für den M3-Scope. M4 startet mit der additiven
 Migration von Einzahlungen und Kaffeeverbrauch nach `ledger_entries`.
 
 ## Ziel
 
-- Einen Default-Tenant fuer den aktuellen Bestand erzeugen.
+- Einen Default-Tenant für den aktuellen Bestand erzeugen.
 - Login-Benutzer und Kaffee-Teilnehmer fachlich trennen.
 - Rollen tenant-spezifisch vorbereiten.
 - Bestehende `kl_Mitarbeiter` ohne Datenverlust in `participants` spiegeln.
-- Die Grundlage fuer Registrierung und Login schaffen, ohne die Legacy-Auth
+- Die Grundlage für Registrierung und Login schaffen, ohne die Legacy-Auth
   sofort zu ersetzen.
 
-## Nicht-Ziele fuer den ersten M3-Schritt
+## Nicht-Ziele für den ersten M3-Schritt
 
 - Kein kompletter Login-Umbau in einem Schritt.
 - Keine Migration von Einzahlungen und Kaffeeverbrauch nach `ledger_entries`;
-  das gehoert zu M4.
+  das gehört zu M4.
 - Kein Design- oder Layout-Umbau.
 - Kein Billing und keine Tarife im ersten Schritt.
 - Kein produktiver Tenant-Wechsel in bestehenden Legacy-Seiten.
@@ -47,7 +47,7 @@ Tabellen:
 - `participants`
 - `tenant_domains`
 
-Ergaenzende Skripte:
+Ergänzende Skripte:
 
 ```text
 scripts/backfill-default-tenant.php
@@ -73,7 +73,7 @@ Wichtige Regeln:
 
 ## Default-Tenant
 
-Fuer den Bestand wird ein erster Tenant angelegt:
+Für den Bestand wird ein erster Tenant angelegt:
 
 ```text
 slug: default
@@ -84,7 +84,7 @@ locale: de-DE
 currency_code: EUR
 ```
 
-Die Werte koennen spaeter in einer Tenant-Einstellungsseite angepasst werden.
+Die Werte können später in einer Tenant-Einstellungsseite angepasst werden.
 
 ## Backfill
 
@@ -98,9 +98,9 @@ Vorgang:
 
 1. Default-Tenant anlegen oder laden.
 2. `tenant_settings` aus `kl_config` erzeugen.
-3. Fuer jede Zeile aus `kl_Mitarbeiter` einen `participant` anlegen oder
+3. Für jede Zeile aus `kl_Mitarbeiter` einen `participant` anlegen oder
    aktualisieren.
-4. Fuer aktive Admins optional einen `user` und eine `tenant_membership`
+4. Für aktive Admins optional einen `user` und eine `tenant_membership`
    erzeugen.
 5. `admin = 1` als Rolle `admin` abbilden; ein konfigurierter erster Benutzer
    kann Rolle `owner` erhalten.
@@ -108,10 +108,10 @@ Vorgang:
    aus dem Default-Tenant entfernen.
 
 Der Backfill muss idempotent sein und darf keine bestehenden Legacy-Daten
-loeschen. Geloescht werden nur SaaS-Spiegelungen, deren Legacy-Mitarbeiter in
+löschen. Gelöscht werden nur SaaS-Spiegelungen, deren Legacy-Mitarbeiter in
 `kl_Mitarbeiter` nicht mehr existiert.
 
-Ausgefuehrter Dev-Stand:
+Ausgeführter Dev-Stand:
 
 - Default-Tenant `default` wurde angelegt.
 - 9 Legacy-Mitarbeiter wurden als `participants` gespiegelt.
@@ -145,15 +145,15 @@ Umgesetzter Umfang:
 
 - Registrierung legt Tenant, Owner-User, Default-Settings, Membership und
   Owner-Participant in einer Transaktion an.
-- Login prueft `users.password_hash`, aktive Membership und aktiven Tenant.
+- Login prüft `users.password_hash`, aktive Membership und aktiven Tenant.
 - Hat ein User genau einen aktiven Mandanten, wird dieser direkt in die Session
   gelegt.
-- Hat ein User mehrere aktive Mandanten, fuehrt der Login zur
+- Hat ein User mehrere aktive Mandanten, führt der Login zur
   Mandantenauswahl.
 - Logout beendet die neue PHP-Login-Session.
-- `konto.php` zeigt den aktuellen SaaS-Kontext fuer den angemeldeten User.
-- `functions.php` akzeptiert eine SaaS-Login-Session als erste Identitaetsquelle,
-  laesst `DEV_AUTH_EMAIL` und `AUTH_USER` aber als Legacy-Fallback bestehen.
+- `konto.php` zeigt den aktuellen SaaS-Kontext für den angemeldeten User.
+- `functions.php` akzeptiert eine SaaS-Login-Session als erste Identitätsquelle,
+  lässt `DEV_AUTH_EMAIL` und `AUTH_USER` aber als Legacy-Fallback bestehen.
 - `footer.php` bleibt App-Sidebar und zeigt keine Public-Login- oder
   Registrierungslinks mehr.
 - Login, Registrierung, Passwort-Reset und E-Mail-Verifikation nutzen das
@@ -161,7 +161,7 @@ Umgesetzter Umfang:
 - Passwort-Reset erzeugt Single-Use-Tokens und speichert nur Token-Hashes.
 - E-Mail-Verifikation erzeugt Single-Use-Tokens und setzt
   `users.email_verified_at`.
-- Reset- und Verifikationslinks werden ueber `app/saas-mail.php` versendet.
+- Reset- und Verifikationslinks werden über `app/saas-mail.php` versendet.
   Der Dev-Standard schreibt Mails nach `var/mail`; produktiv kann auf PHP
   `mail()` umgestellt werden.
 - Dev-Links werden weiterhin nur im Dev-Modus angezeigt, damit lokale Checks
@@ -169,7 +169,7 @@ Umgesetzter Umfang:
 
 Noch offen im M3-Auth-Scope:
 
-- Weitergehende Rollenmatrix fuer spaetere SaaS-Seiten.
+- Weitergehende Rollenmatrix für spätere SaaS-Seiten.
 - Produktive SMTP-/Provider-Anbindung inklusive Bounce-/Fehlerprotokoll.
 
 ## Public-Landingpage
@@ -184,35 +184,35 @@ assets/css/public.css
 
 Umgesetzter Umfang:
 
-- Oeffentliche Landingpage ohne Legacy-DB-Zugriff.
-- Hero mit generiertem Bild-Asset, bestehender Typografie und gruenem Akzent.
+- Öffentliche Landingpage ohne Legacy-DB-Zugriff.
+- Hero mit generiertem Bild-Asset, bestehender Typografie und grünem Akzent.
 - CTA zu Login und Registrierung.
-- Login, Registrierung und oeffentliche Auth-Hilfsseiten sind optisch in den
+- Login, Registrierung und öffentliche Auth-Hilfsseiten sind optisch in den
   Public-Bereich integriert.
-- Kurzabschnitt zu Stricherfassung, Mandantenfaehigkeit und Webspace-Betrieb.
-- Die geschuetzte App-Sidebar bleibt von der Public-Seite getrennt.
+- Kurzabschnitt zu Stricherfassung, Mandantenfähigkeit und Webspace-Betrieb.
+- Die geschützte App-Sidebar bleibt von der Public-Seite getrennt.
 
-## Tenant-Aufloesung
+## Tenant-Auflösung
 
-Entscheidung fuer den Webspace-Betrieb:
+Entscheidung für den Webspace-Betrieb:
 
 - Keine Wildcard-Subdomains im ersten Schritt.
-- Primaere App-Adresse ist eine zentrale App-Domain wie `app.kaffeeliste.de`.
-- Die Public-Seite kann ueber `kaffeeliste.de` beziehungsweise
+- Primäre App-Adresse ist eine zentrale App-Domain wie `app.kaffeeliste.de`.
+- Die Public-Seite kann über `kaffeeliste.de` beziehungsweise
   `www.kaffeeliste.de` laufen.
-- Der aktive Mandant wird nach Login ueber `tenant_memberships` und die PHP-
+- Der aktive Mandant wird nach Login über `tenant_memberships` und die PHP-
   Session gesetzt.
 - Bei genau einem Mandanten wird automatisch weitergeleitet.
 - Bei mehreren Mandanten nutzt der User `mandant-auswahl.php`.
-- `tenant_domains` ist vorbereitet fuer spaeter gezielt eingerichtete feste
-  Domains oder Subdomains, aber nicht Voraussetzung fuer den Start.
+- `tenant_domains` ist vorbereitet für später gezielt eingerichtete feste
+  Domains oder Subdomains, aber nicht Voraussetzung für den Start.
 
 Noch offen:
 
 - `APP_PRIMARY_HOST` in der Zielumgebung setzen.
-- Optional `APP_PUBLIC_HOST` beziehungsweise Host-Rewrite fuer die Landingpage
+- Optional `APP_PUBLIC_HOST` beziehungsweise Host-Rewrite für die Landingpage
   in der Zielumgebung definieren.
-- Produktive Domain-/Zertifikatspruefung fuer einzelne feste Domains
+- Produktive Domain-/Zertifikatsprüfung für einzelne feste Domains
   definieren.
 
 ## Rollen und Grundeinstellungen
@@ -226,43 +226,43 @@ mandant-einstellungen.php
 Umgesetzter Umfang:
 
 - `saas_user_has_role()`, `saas_require_role()` und
-  `saas_can_manage_tenant_settings()` zentralisieren die erste Rollenpruefung.
-- Owner und Admin duerfen Tenant-Grundeinstellungen bearbeiten.
-- Die Seite bearbeitet Kundenname, Zeitzone, Locale, Waehrung, Preis pro
+  `saas_can_manage_tenant_settings()` zentralisieren die erste Rollenprüfung.
+- Owner und Admin dürfen Tenant-Grundeinstellungen bearbeiten.
+- Die Seite bearbeitet Kundenname, Zeitzone, Locale, Währung, Preis pro
   Strich, Web-Striche, PayPal-Link, Listenfenster und Schulden-Warnschwelle.
 - Geldwerte werden in der UI als Euro-Werte erfasst und weiterhin als Cent-
   Integer gespeichert.
-- `konto.php` und die Sidebar verlinken die Einstellungen nur fuer passende
+- `konto.php` und die Sidebar verlinken die Einstellungen nur für passende
   Rollen.
 
 ## Erste Akzeptanzkriterien
 
-- Migrationen laufen mehrfach ohne Fehler: erfuellt.
-- Default-Tenant existiert genau einmal: erfuellt.
+- Migrationen laufen mehrfach ohne Fehler: erfüllt.
+- Default-Tenant existiert genau einmal: erfüllt.
 - `tenant_settings` enthalten Preis pro Strich und bestehende PayPal-Optionen:
-  erfuellt.
-- Jeder bestehende `kl_Mitarbeiter` hat genau einen `participant`: erfuellt.
-- `participants.legacy_mitarbeiter_id` ist gesetzt: erfuellt.
-- Admins werden als tenant-scoped Rolle abgebildet: erfuellt.
-- Registrierung und Login funktionieren fuer einen neuen Test-Tenant:
-  erfuellt.
-- Owner-/Admin-Grundeinstellungen koennen aktualisiert werden: erfuellt.
+  erfüllt.
+- Jeder bestehende `kl_Mitarbeiter` hat genau einen `participant`: erfüllt.
+- `participants.legacy_mitarbeiter_id` ist gesetzt: erfüllt.
+- Admins werden als tenant-scoped Rolle abgebildet: erfüllt.
+- Registrierung und Login funktionieren für einen neuen Test-Tenant:
+  erfüllt.
+- Owner-/Admin-Grundeinstellungen können aktualisiert werden: erfüllt.
 - Passwort-Reset und E-Mail-Verifikation funktionieren mit Single-Use-Tokens:
-  erfuellt.
+  erfüllt.
 - Reset- und Verifikationslinks werden im Dev-/Testmodus als Mail-Log erzeugt:
-  erfuellt.
-- Mandantenauswahl funktioniert fuer User mit mehreren Mandanten: erfuellt.
-- Oeffentliche Landingpage ist per HTTP-Smoke erreichbar: erfuellt.
-- Golden-Master und HTTP-Smoke bleiben gruen: erfuellt.
+  erfüllt.
+- Mandantenauswahl funktioniert für User mit mehreren Mandanten: erfüllt.
+- Öffentliche Landingpage ist per HTTP-Smoke erreichbar: erfüllt.
+- Golden-Master und HTTP-Smoke bleiben grün: erfüllt.
 
 ## Risiken
 
-| Risiko | Gegenmassnahme |
+| Risiko | Gegenmaßnahme |
 | --- | --- |
 | Login-User und Kaffee-Teilnehmer werden vermischt | `users` und `participants` strikt getrennt halten |
 | Mehrfacher Backfill erzeugt Duplikate | Eindeutige Constraints und Upsert-Logik |
 | Legacy-App bricht durch neue Tabellen | M3 nur additiv, keine Legacy-Queries umstellen |
-| Rollen werden global statt tenant-scoped | Rollen ausschliesslich in `tenant_memberships` speichern |
+| Rollen werden global statt tenant-scoped | Rollen ausschließlich in `tenant_memberships` speichern |
 | Falsche Owner-Zuordnung | Owner per Env-Konfiguration oder manuell dokumentierter Entscheidung setzen |
 
 ## Empfohlene Reihenfolge
@@ -270,24 +270,24 @@ Umgesetzter Umfang:
 1. Migration `0002_saas_identity_tenants.sql` erstellen: erledigt.
 2. Migration `0003_saas_auth_account_fields.sql` erstellen: erledigt.
 3. `scripts/backfill-default-tenant.php` erstellen: erledigt.
-4. Backfill gegen die Dev-Datenbank ausfuehren: erledigt.
-5. Kontrollskript fuer Tenant/Participant/Role-Counts schreiben: erledigt.
+4. Backfill gegen die Dev-Datenbank ausführen: erledigt.
+5. Kontrollskript für Tenant/Participant/Role-Counts schreiben: erledigt.
 6. Login-/Registrierungsrouten bauen: erledigt.
 7. Auth-Flow-Kontrollskript schreiben: erledigt.
-8. Zentrale Rollenpruefung und Mandant-Einstellungen bauen: erledigt.
+8. Zentrale Rollenprüfung und Mandant-Einstellungen bauen: erledigt.
 9. Settings-Flow-Kontrollskript schreiben: erledigt.
 10. Migration `0004_saas_auth_tokens.sql` erstellen: erledigt.
 11. Passwort-Reset und E-Mail-Verifikation bauen: erledigt.
 12. Password-/E-Mail-Flow-Kontrollskript schreiben: erledigt.
 13. Migration `0005_saas_tenant_resolution.sql` erstellen: erledigt.
-14. Mandantenauswahl und zentrale Session-Aufloesung bauen: erledigt.
+14. Mandantenauswahl und zentrale Session-Auflösung bauen: erledigt.
 15. Tenant-Resolution-Kontrollskript schreiben: erledigt.
-16. Golden-Master und HTTP-Smoke ausfuehren: erledigt.
+16. Golden-Master und HTTP-Smoke ausführen: erledigt.
 17. Mail-Transport-Abstraktion und Mail-Flow-Kontrollskript bauen: erledigt.
 18. Public-Landingpage mit erstem Hero-Asset vorbereiten: erledigt.
 19. M3-Abschlusscheck dokumentieren und M4-Datenmigration starten: erledigt.
 
-## Uebergabe an M4
+## Übergabe an M4
 
 M4 ist in `docs/m4-data-migration.md` dokumentiert. Der erste M4-Schritt ist
 bewusst additiv: