M2 abschließen und M3 vorbereiten

- M2-Abschlussstatus und Abschlusskriterien dokumentieren
- M3-SaaS-Basisplan mit Tenant/User/Participant-Modell ergänzen
- Hauptplan mit M2-Abschluss und M3-Startpunkten aktualisieren

docs/m2-technical-foundation.md

@@ -5,6 +5,9 @@ Stand: 2026-07-12
 M2 fuehrt die technischen Grundbausteine fuer den SaaS-Umbau ein, ohne das
 Legacy-Verhalten oder das bestehende Design zu veraendern.
 
+Status: abgeschlossen fuer den M2-Scope. Bewusst ausgelagerte Themen sind unten
+als Grenzen und M3-/M6-Uebergabe dokumentiert.
+
 ## Ziel
 
 - Versionierte Datenbankmigrationen statt loser Schema-Ausfuehrung.
@@ -142,13 +145,35 @@ Die Skripte erwarten die bekannten Dev-Umgebungsvariablen `DB_HOST`, `DB_NAME`,
 ## Bewusste Grenzen
 
 - Keine Tenant-/User-/Rollen-Tabellen in M2. Diese gehoeren zu M3.
-- Keine globale CSRF-Erzwingung in M2. Die Absicherung weiterer POST-Seiten
-  erfolgt schrittweise.
-- Kein Layout-Umbau in M2. Die visuelle Struktur bleibt stabil.
+- Keine globale CSRF-Erzwingung fuer Spezialprozesse. `mailversenden.php` und
+  `jahresauswertung.php` werden in M6 als Jobs mit Dry-Run, Audit und
+  Versandlog neu betrachtet.
+- Kein Layout-Umbau in M2. Die visuelle Struktur bleibt stabil; Public-/App-
+  Layouts werden mit der M3-/M7-Struktur vorbereitet.
 - PDF-/Mail-/Jahresprozesse bleiben als M6-Themen offen.
 
-## Naechste Schritte
+## Abschlusskriterien
 
-1. Eine duenne View-/Layout-Struktur vorbereiten, ohne Header/Footer-Markup
-   sofort zu verschieben.
-2. Danach M3 starten: Tenants, User, Registrierung, Login und Rollen.
+- Migrationsrunner ist vorhanden und idempotent.
+- Bootstrap, Session und CSRF-Helper sind zentral verfuegbar.
+- Die relevanten Legacy-Schreibseiten sind CSRF-geschuetzt.
+- CSV-Uploads liegen nicht mehr im Webroot.
+- Bestehende Legacy-Seiten bleiben per HTTP-Smoke erreichbar.
+- Golden-Master-Fachwerte bleiben unveraendert.
+
+## Uebergabe an M3
+
+M3 startet mit additiven SaaS-Tabellen und einer Default-Tenant-Abbildung. Die
+Legacy-Seiten sollen dabei weiterhin ueber die bestehenden Tabellen laufen, bis
+der fachliche Kern in M4/M5 schrittweise auf das Zielmodell umgestellt wird.
+
+Naechster Startpunkt:
+
+1. `tenants`, `tenant_settings`, `users`, `tenant_memberships` und
+   `participants` als neue Migration anlegen.
+2. Einen Default-Tenant fuer die bestehende Kaffeeliste definieren.
+3. Bestehende `kl_Mitarbeiter` in `participants` spiegeln, inklusive
+   `legacy_mitarbeiter_id`.
+4. Admins aus `kl_Mitarbeiter.admin` als `tenant_memberships.role = 'admin'`
+   beziehungsweise fuer den ersten Hauptnutzer als `owner` abbilden.
+5. Erst danach Login/Registrierung und Public-/App-Routen anschliessen.

docs/m3-saas-basis-vorbereitung.md

@@ -0,0 +1,118 @@
+# M3 SaaS-Basis Vorbereitung
+
+Stand: 2026-07-12
+
+M3 fuehrt Mandanten, Benutzer, Mitgliedschaften und Grundeinstellungen additiv
+ein. Die bestehende Legacy-App bleibt dabei lauffaehig und wird noch nicht auf
+das neue Modell umgestellt.
+
+## Ziel
+
+- Einen Default-Tenant fuer 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
+  sofort zu ersetzen.
+
+## Nicht-Ziele fuer den ersten M3-Schritt
+
+- Kein kompletter Login-Umbau in einem Schritt.
+- Keine Migration von Einzahlungen und Kaffeeverbrauch nach `ledger_entries`;
+  das gehoert zu M4.
+- Kein Design- oder Layout-Umbau.
+- Kein Billing, keine Tarife, keine E-Mail-Verifikation im ersten Schritt.
+- Kein produktiver Tenant-Wechsel in bestehenden Legacy-Seiten.
+
+## Vorgeschlagene Migration
+
+Naechste Migration:
+
+```text
+database/migrations/0002_saas_identity_tenants.sql
+```
+
+Tabellen:
+
+- `tenants`
+- `tenant_settings`
+- `users`
+- `tenant_memberships`
+- `participants`
+
+Wichtige Regeln:
+
+- `users` sind Login-Konten.
+- `participants` sind Kaffeelisten-Teilnehmer.
+- Ein `participant` kann optional auf einen `user` zeigen.
+- Rollen liegen in `tenant_memberships`, nicht in `participants`.
+- `participants.legacy_mitarbeiter_id` speichert die alte ID aus
+  `kl_Mitarbeiter`.
+- Geldwerte in neuen Settings als Cent-Integer speichern.
+
+## Default-Tenant
+
+Fuer den Bestand wird ein erster Tenant angelegt:
+
+```text
+slug: default
+name: Kaffeeliste Bestand
+status: active
+timezone: Europe/Berlin
+locale: de-DE
+currency_code: EUR
+```
+
+Die Werte koennen spaeter in einer Tenant-Einstellungsseite angepasst werden.
+
+## Backfill-Vorschlag
+
+Ein separates Skript sollte die bestehenden Mitarbeiter spiegeln:
+
+```text
+scripts/backfill-default-tenant.php
+```
+
+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
+   aktualisieren.
+4. Fuer 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.
+
+Der Backfill muss idempotent sein und darf keine bestehenden Legacy-Daten
+loeschen.
+
+## Erste Akzeptanzkriterien
+
+- Migrationen laufen mehrfach ohne Fehler.
+- Default-Tenant existiert genau einmal.
+- `tenant_settings` enthalten Preis pro Strich und bestehende PayPal-Optionen.
+- Jeder bestehende `kl_Mitarbeiter` hat genau einen `participant`.
+- `participants.legacy_mitarbeiter_id` ist gesetzt.
+- Admins werden als tenant-scoped Rolle abgebildet.
+- Golden-Master und HTTP-Smoke bleiben gruen.
+
+## Risiken
+
+| Risiko | Gegenmassnahme |
+| --- | --- |
+| 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 |
+| Falsche Owner-Zuordnung | Owner per Env-Konfiguration oder manuell dokumentierter Entscheidung setzen |
+
+## Empfohlene Reihenfolge
+
+1. Migration `0002_saas_identity_tenants.sql` erstellen.
+2. `scripts/backfill-default-tenant.php` erstellen.
+3. Backfill gegen die Dev-Datenbank ausfuehren.
+4. Kontrollskript fuer Tenant/Participant/Role-Counts schreiben.
+5. Golden-Master und HTTP-Smoke ausfuehren.
+6. Danach Login-/Registrierungsrouten planen.
+

docs/saas-umstrukturierungsplan.md

@@ -282,7 +282,7 @@ Uebersicht:
 | --- | --- | --- |
 | M0 | Baseline | Bestand, Sicherheit und Designreferenz sind dokumentiert |
 | M1 | Golden Master | Legacy-Ergebnisse sind als Vergleichsbasis eingefroren; HTTP-Smoke prueft sichere Seiten |
-| M2 | Technisches Fundament | Migrationen, Bootstrap, Session und CSRF-Helper stehen |
+| M2 | Technisches Fundament | Abgeschlossen: Migrationen, Bootstrap, Session, CSRF-Helper und Legacy-Schreibseitenschutz stehen |
 | M3 | SaaS-Basis | Tenants, User, Registrierung, Login und Rollen funktionieren |
 | M4 | Datenmigration | Legacy-Daten sind tenant-sicher im Zielmodell abgebildet |
 | M5 | App-Kern | Dashboard, Striche, Einzahlungen, Mitglieder und Liste laufen |
@@ -395,6 +395,7 @@ Ergebnis:
 - Grundgeruest fuer neue SaaS-App.
 - Kein fachlicher Rewrite, aber klare Struktur fuer die Migration.
 - Dokumentation: `docs/m2-technical-foundation.md`.
+- Status: abgeschlossen fuer den M2-Scope.
 
 Abhaengigkeiten:
 
@@ -409,7 +410,11 @@ Mehrkundenfaehigkeit und Kunden-Onboarding technisch aktivieren.
 Schritte:
 
 - Tabellen fuer `tenants`, `users`, `tenant_memberships` und
-  `tenant_settings` anlegen.
+  `tenant_settings` anlegen. Vorbereitung dokumentiert in
+  `docs/m3-saas-basis-vorbereitung.md`.
+- Zusaetzlich `participants` als getrennte Kaffee-Teilnehmer-Tabelle anlegen.
+- Default-Tenant fuer den aktuellen Bestand anlegen.
+- Bestehende `kl_Mitarbeiter` idempotent in `participants` spiegeln.
 - Registrierung: Tenant + Owner-User + Default-Settings erzeugen.
 - Login, Logout, Passwort-Reset und E-Mail-Verifikation bauen.
 - Tenant-Aufloesung definieren.