M2 Umsetzung

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 | Public-/App-Struktur, Bootstrap, Session und CSRF stehen |
+| M2 | Technisches Fundament | Migrationen, Bootstrap, Session und CSRF-Helper 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 |
@@ -373,19 +373,27 @@ Schritte:
 - Projektstruktur festlegen: Public-Routes, App-Routes, Views/Templates,
   Services/Repositories.
 - Zentrales Bootstrap fuer Config, DB-Verbindung, Session und Fehlerbehandlung.
-- Layouts trennen: Public-Layout und App-Layout.
+  Begonnen mit `app/bootstrap.php`.
+- Versionierte Migrationen einfuehren. Begonnen mit
+  `database/migrations/0001_legacy_mysql_baseline.sql` und
+  `scripts/migrate.php`.
+- Layouts trennen: Public-Layout und App-Layout. Noch offen; Header/Footer
+  bleiben vorerst Legacy-Wrapper.
 - Bestehende Assets weiterverwenden.
-- CSRF- und Session-Basis einziehen.
+- CSRF- und Session-Basis einziehen. Session und CSRF-Helper sind vorhanden;
+  globale Erzwingung erfolgt schrittweise pro POST-Seite.
 - Konfigurationswerte aus Code in Umgebung oder Settings verschieben.
 
 Ergebnis:
 
 - Grundgeruest fuer neue SaaS-App.
 - Kein fachlicher Rewrite, aber klare Struktur fuer die Migration.
+- Dokumentation: `docs/m2-technical-foundation.md`.
 
 Abhaengigkeiten:
 
 - Entscheidung, ob PHP nativ weitergefuehrt oder ein Framework genutzt wird.
+- M2 bleibt bewusst ohne Tenant-/User-/Rollen-Tabellen; diese starten in M3.
 
 ### M3: Mandanten, Registrierung und Login