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.