Planung der neuen Anwendung

.gitignore

@@ -0,0 +1 @@
+.vscode/sftp.json

docs/legacy-feature-catalog.md

@@ -0,0 +1,303 @@
+# Legacy Funktionskatalog Fuer Projektplanung
+
+Diese Datei bereitet den Funktionsumfang unter `legacy-app/` so auf, dass er
+als Grundlage fuer Projektplanung, Scope-Entscheidungen und spaetere
+Umsetzungspakete genutzt werden kann.
+
+## Verwendung
+
+- Nutze die Checklisten als fachliches Inventar.
+- Ergaenze neue Punkte direkt unter `Manuelle Ergaenzungen`.
+- Markiere unter `Ziel fuer SaaS` spaeter, was uebernommen, veraendert oder
+  verworfen werden soll.
+- Die Inhalte stammen aus einer Codeanalyse der Legacy-Seiten und muessen bei
+  Bedarf um fachliche Regeln aus FAQ, E-Mails und Betriebswissen ergaenzt
+  werden.
+
+## Empfohlene Planungsmodule
+
+| Modul | Legacy-Quellen | Kernziel |
+| --- | --- | --- |
+| Benutzerkonto und Dashboard | `legacy-app/index.php`, `legacy-app/namenanpassen.php` | Persoenliche Uebersicht, Self-Service, Profilpflege |
+| Ledger und Zahlungen | `legacy-app/index.php`, `legacy-app/stricheintragen.php`, `legacy-app/einzahlung.php`, `legacy-app/letzteneintraege.php` | Striche, Einzahlungen, Saldo, Korrekturen |
+| Mitglieder und Rechte | `legacy-app/mitarbeiterverwalten.php`, `legacy-app/functions.php`, `legacy-app/functionsLDAP.php` | Benutzerverwaltung, Rollen, Zugang |
+| Reporting und Export | `legacy-app/kaffeeliste.php`, `legacy-app/teilnehmerauswertung.php`, `legacy-app/exportKaffeeliste.php` | Gesamtlisten, Detailauswertungen, PDF |
+| Kommunikation | `legacy-app/hinweise.php`, `legacy-app/mailversenden.php`, `legacy-app/mailausgebe.php`, `legacy-app/faq.php`, `legacy-app/jahresauswertung.php` | Hinweise, Serienmails, Sonderkommunikation |
+| Importe und Sonderprozesse | `legacy-app/csvupload.php`, `legacy-app/jahresauswertung.php` | CSV-Abgleich, Jahresabschlusslogik |
+| Feedback und Surveys | `legacy-app/umfrage.php`, `legacy-app/umfrageergebnisse.php` | Umfragen, Ergebnisdarstellung |
+
+## Funktionsbereiche
+
+### 1. Benutzer-Self-Service
+
+Legacy-Quellen:
+- `legacy-app/index.php`
+- `legacy-app/namenanpassen.php`
+- `legacy-app/faq.php`
+
+Funktionen:
+- [X] Persoenliches Dashboard mit aktuellem Stand
+- [X] Jahresuebersicht fuer Ausgaben, Striche und Einzahlungen
+- [X] Anzeige letzter Einzahlungen
+- [X] Anzeige letzter Striche
+- [X] Self-Service-Stricheintrag fuer 1 oder 2 Striche, wenn freigeschaltet
+- [X] Direkte PayPal-Links fuer feste Betraege und offenen Saldo
+- [X] Eigene Namensanpassung
+- [X] FAQ und Regelwerk fuer Nutzer
+
+Risiken und Hinweise:
+- Self-Service-Stricherfassung ist fachlich eng mit `kl_config.strichperweb`
+  verbunden.
+- Die Zahlungslogik ist kein echter Payment-Workflow, sondern Linksteuerung.
+- Teile der fachlichen Regeln liegen nur in Fliesstexten.
+
+Ziel fuer SaaS:
+- [X] Uebernehmen
+- [ ] Vereinfachen
+- [X] Neu denken
+- [ ] Entfaellt
+
+Manuelle Ergaenzungen:
+- 
+- 
+
+### 2. Operative Buchung und Kassenfuehrung
+
+Legacy-Quellen:
+- `legacy-app/stricheintragen.php`
+- `legacy-app/einzahlung.php`
+- `legacy-app/letzteneintraege.php`
+- `legacy-app/csvupload.php`
+
+Funktionen:
+- [X] Sammelerfassung von Strichen fuer viele Mitarbeitende
+- [X] Sammelerfassung von Einzahlungen fuer viele Mitarbeitende
+- [X] Filterlogik fuer Vorderseite, Rueckseite oder alle Mitarbeitenden
+- [X] Anpassbarer Kosten-pro-Strich-Wert beim Eintragen
+- [X] Loeschung letzter Einzahlungsbuchungen
+- [X] Loeschung letzter Strichbuchungen
+- [X] CSV-Upload fuer externe Einzahlungseingaenge
+- [X] Dublettenpruefung beim CSV-Import
+- [X] Namensabgleich ueber Name oder `paypalname`
+- [X] Import-Auswertung pro Datensatz
+
+Risiken und Hinweise:
+- `legacy-app/stricheintragen.php` hat keine sichtbare Admin-Pruefung im Code.
+- `legacy-app/einzahlung.php` hat ebenfalls keine sichtbare Admin-Pruefung im
+  Code.
+- In `legacy-app/einzahlung.php` wirkt die Filterlogik inkonsistent, weil
+  `action` und `aktion` gemischt werden.
+- Korrekturen erfolgen per Loeschung statt per Audit- oder Stornologik.
+
+Ziel fuer SaaS:
+- [X] Uebernehmen
+- [ ] Vereinfachen
+- [X] Neu denken
+- [ ] Entfaellt
+
+Manuelle Ergaenzungen:
+- 
+- 
+
+### 3. Uebersichten, Reporting und Export
+
+Legacy-Quellen:
+- `legacy-app/kaffeeliste.php`
+- `legacy-app/teilnehmerauswertung.php`
+- `legacy-app/exportKaffeeliste.php`
+
+Funktionen:
+- [X] Gesamtuebersicht aller aktiven Mitarbeitenden
+- [X] Anzeige von Saldo, Gesamtausgabe, Gesamtstrichen, Gesamteinzahlungen
+- [X] Drilldown auf Teilnehmendendetails
+- [X] Detailansicht mit Jahreswerten und Transaktionshistorie
+- [X] PDF-Export der Kaffeeliste
+- [X] Vorderseiten-/Rueckseitenlogik fuer Druckprozess
+- [ ] Wasserzeichen und farbliche Markierungen im Export
+- [X] PayPal-Aktionslinks in der Teilnehmerdetailansicht
+
+Risiken und Hinweise:
+- Die Reportinglogik ist mehrfach dupliziert.
+- `legacy-app/exportKaffeeliste.php` hat keine sichtbare Zugriffspruefung.
+- Fachliche Schwellenwerte sind fest im Code hinterlegt.
+
+Ziel fuer SaaS:
+- [X] Uebernehmen
+- [X] Vereinfachen
+- [X] Neu denken
+- [ ] Entfaellt
+
+Manuelle Ergaenzungen:
+- 
+- 
+
+### 4. Mitglieder, Rollen und Berechtigungen
+
+Legacy-Quellen:
+- `legacy-app/mitarbeiterverwalten.php`
+- `legacy-app/functions.php`
+- `legacy-app/functionsLDAP.php`
+- `legacy-app/config.php`
+
+Funktionen:
+- [X] Mitglied anlegen
+- [X] Mitglied bearbeiten
+- [X] Mitglied aktivieren oder deaktivieren
+- [X] Admin-Flag setzen oder entfernen
+- [X] Zugriff fuer aktive Nutzer pruefen
+- [X] Zugriff fuer Admins pruefen
+- [ ] Benutzer ueber Windows-Login und LDAP-Merkmale identifizieren
+- [ ] Verknuepfung zwischen technischer Identitaet und `kl_Mitarbeiter`
+
+Risiken und Hinweise:
+- Keine sichtbare Dublettenpruefung fuer Benutzerstammdaten.
+- Rollenmodell ist sehr knapp: aktiv oder admin.
+- Authentifizierung und Autorisierung sind technisch eng vermischt.
+
+Ziel fuer SaaS:
+- [X] Uebernehmen
+- [ ] Vereinfachen
+- [X] Neu denken
+- [ ] Entfaellt
+
+Manuelle Ergaenzungen:
+- die Authentifizierung an einem AD und ADFS sollen hinzugefügt werden.
+- 
+
+### 5. Kommunikation, Hinweise und Benachrichtigungen
+
+Legacy-Quellen:
+- `legacy-app/hinweise.php`
+- `legacy-app/header.php`
+- `legacy-app/mailversenden.php`
+- `legacy-app/mailausgebe.php`
+- `legacy-app/faq.php`
+- `legacy-app/jahresauswertung.php`
+
+Funktionen:
+- [X] Globale Hinweisbanner mit Gueltigkeitsdatum
+- [X] Adminpflege fuer Hinweise
+- [X] Serienmail mit individuellem Kontostand
+- [X] Unterschiedliche Mailtexte fuer Guthaben und Schulden
+- [X] Ausgabe einer Mailadressliste
+- [X] FAQ als Hilfe- und Regelwerk
+- [X] Sondermailing im Jahresabschlussprozess
+
+Risiken und Hinweise:
+- `legacy-app/mailversenden.php` startet beim Aufruf sofort den Versand.
+- `legacy-app/mailversenden.php` hat keine sichtbare Admin-Pruefung.
+- `legacy-app/mailausgebe.php` ist fachlich und datenschutzseitig zu pruefen.
+- Hinweise koennen angelegt und geloescht, aber nicht bearbeitet werden.
+
+Ziel fuer SaaS:
+- [X] Uebernehmen
+- [ ] Vereinfachen
+- [X] Neu denken
+- [ ] Entfaellt
+
+Manuelle Ergaenzungen:
+- Es solle die möglichkeit geben auch Anfragen von dem Benutzern an den Verantwortlichen der Kaffeeliste des jeweiligen Kunden zusenden.
+- Es soll die möglichkeit geben das der Verwortliche der Kaffeeliste auch Anfragen an die zentrale Administration stellen kann.
+
+### 6. Feedback und Umfragen
+
+Legacy-Quellen:
+- `legacy-app/umfrage.php`
+- `legacy-app/umfrageergebnisse.php`
+
+Funktionen:
+- [X] Einmalige Umfrageteilnahme pro normalisierter E-Mail
+- [X] Ratings, Mehrfachauswahl und Freitextantworten
+- [X] Validierung unvollstaendiger Eingaben
+- [X] Speicherung strukturierter Antworten
+- [X] Ergebnisdarstellung mit Durchschnittswerten und Haeufigkeiten
+- [X] Anzeige letzter Freitextantworten
+
+Risiken und Hinweise:
+- Die Umfrage ist aktuell per Flag deaktiviert.
+- Fragebogen und Antwortoptionen sind fest im Code definiert.
+- Ergebniszugriff ist nicht klar auf Admins begrenzt.
+
+Ziel fuer SaaS:
+- [X] Uebernehmen
+- [X] Vereinfachen
+- [X] Neu denken
+- [ ] Entfaellt
+
+Manuelle Ergaenzungen:
+- Es soll möglich sein, das die Verantwortlichen der Kaffeeliste Umfrage einrichten können. Die Verantwortlichen der Kaffeeliste sollten die Umfrange vollumfänglich verwalten und auswerten können.
+- 
+
+### 7. Sonderprozesse und Jahresabschluss
+
+Legacy-Quellen:
+- `legacy-app/jahresauswertung.php`
+
+Funktionen:
+- [X] Ermittlung von Jahresstrichen aller aktiven Mitglieder
+- [X] Proportionale Verteilung einer festen Strichmenge
+- [X] Umbuchung der daraus entstehenden Werte als Einzahlung
+- [X] Versand einer Begleitmail
+
+Risiken und Hinweise:
+- Hoher Seiteneffekt beim blossen Aufruf.
+- Parameter wie Strichmenge und Preis sind hartcodiert.
+- Die Datei enthaelt Sonderlogik ausserhalb des normalen App-Rahmens.
+
+Ziel fuer SaaS:
+- [X] Uebernehmen
+- [X] Vereinfachen
+- [X] Neu denken
+- [ ] Entfaellt
+
+Manuelle Ergaenzungen:
+- Es sollt die möglichkeit geben eine Jahresbonus z.B. anhand der im Jahr verbrauchten Strichen zu verteilen an die Mitglieder
+- 
+
+## Seiteninventar
+
+| Datei | Zweck | Wichtige Funktionen | Risiko fuer Neuentwicklung |
+| --- | --- | --- | --- |
+| `legacy-app/index.php` | Nutzer-Dashboard | Saldo, Jahreswerte, letzte Buchungen, Self-Service-Striche, PayPal-Links | Fachlogik direkt in Seite, kaum zentralisiert |
+| `legacy-app/namenanpassen.php` | Anzeigename pflegen | Eigene Namensaenderung, Admin-Auswahl anderer Nutzer | Profilmodell sehr schmal |
+| `legacy-app/faq.php` | Hilfe und Regeln | FAQ, Prozesswissen, Kontaktinformationen | Geschaeftsregeln liegen nur in Textform vor |
+| `legacy-app/stricheintragen.php` | Massenbuchung Striche | Front-/Rueckseitenfilter, Kosten pro Strich, Bulk-Erfassung | Sichtbar fehlender Adminschutz |
+| `legacy-app/einzahlung.php` | Massenbuchung Einzahlungen | Bulk-Erfassung, letzte Eintraege, CSV-Upload-Verlinkung | Mischfehler `action` vs. `aktion`, sichtbar fehlender Adminschutz |
+| `legacy-app/letzteneintraege.php` | Korrektur letzter Buchungen | Letzte 100 Einzahlungen, letzte 100 Verbraeuche, Loeschen | Keine Auditspur |
+| `legacy-app/csvupload.php` | CSV-Import | Datei-Upload, Dublettenpruefung, Ergebnisreport | Implizites Dateiformat, Freitext-Matching |
+| `legacy-app/kaffeeliste.php` | Gesamtuebersicht | Summenliste, Drilldown, Export, Mailstart | Reporting schwer wiederverwendbar |
+| `legacy-app/teilnehmerauswertung.php` | Personendetailansicht | Jahreswerte, Historie, PayPal-Links | Doppelte Logik, teils unparametrisierte SQL |
+| `legacy-app/exportKaffeeliste.php` | PDF-Ausdruck | PDF, Wasserzeichen, Farbmarkierungen, Papierlogik | Layout und Fachlogik stark vermischt |
+| `legacy-app/mitarbeiterverwalten.php` | Stammdatenverwaltung | Anlegen, Bearbeiten, Aktivieren, Deaktivieren, Admin-Flag | Kaum Validierung, einfaches Rollenmodell |
+| `legacy-app/hinweise.php` | Hinweisverwaltung | Hinweis anlegen, listen, loeschen | Kein Bearbeiten, Loeschen per GET |
+| `legacy-app/mailversenden.php` | Serienmail | Stand berechnen und direkt versenden | Aufruf triggert sofort Versand |
+| `legacy-app/mailausgebe.php` | Adressliste | Semikolon-Liste aktiver E-Mails | Datenschutz und Berechtigung pruefen |
+| `legacy-app/umfrage.php` | Umfrageerfassung | Einmalige Teilnahme, Validierung, Antwortspeicherung | Fragebogen fest im Code |
+| `legacy-app/umfrageergebnisse.php` | Umfrageauswertung | Aggregationen, Haeufigkeiten, Freitextlisten | Ergebniszugriff fachlich unklar |
+| `legacy-app/jahresauswertung.php` | Jahresabschluss-Sonderprozess | Verteilung, Einzahlung, Mail | Sehr hoher fachlicher und technischer Sonderfall |
+
+## Offene Entscheidungen Fuer Die Planung
+
+- [X] Soll die Vorderseiten-/Rueckseitenlogik aus dem Papierprozess erhalten
+  bleiben?
+- [X] Soll Self-Service-Stricherfassung erhalten bleiben?
+- [ ] Soll die Zahlung weiter ueber reine PayPal-Links laufen?
+- [X] Brauchen Loeschungen kuenftig Storno- und Audit-Logik?
+- [ ] Wer darf Umfrageergebnisse sehen?
+- [ ] Ist `mailausgebe.php` fachlich gewollt oder nur Hilfsfunktion?
+- [ ] Ist `jahresauswertung.php` ein wiederkehrender Prozess?
+- [ ] Welche Fachregeln aus FAQ und Mailtexten muessen als echte Anforderungen
+  uebernommen werden?
+- [ ] Welche Zusatzfelder braucht das kuenftige Benutzerprofil, z. B.
+  `paypalname`?
+- [ ] Welche Aktionen brauchen kuenftig Vorschau, Freigabe oder Testmodus?
+
+## Notizen
+
+- Die Zahlung soll der Verantwortliche der Kaffeeliste einstellen können. Bar, Überweisung und Paypal sollen auswählbar sein. Bei Paypal können die E-Mails von Paypal an ein bestimmtes Postfach gesendet werden. Dieses wird von der Seite regelmäßig aus gelesen werden. Dabei soll ein catch-all Postfach gearbeitet werden. Die Empfängeradresse legt die jeweilige Kaffeeliste fest. Der Empfänger ist der Name. 
+- Die Umfrageergebnisse sollten nach Freigabe des Verantwortlichen auch die Benutzer sehen können.
+- mailausgabe.php ist vermutlich nur eine Hilfsfunktion.
+- jahresauswertung.php soll im Rahmen der gesamtdarstellung und die Jahes sonderausschüttung benötigt wurden sein.
+- die FAQ und Mailtexte müssen durch die Verantwortlichen der Kaffeeliste angepasst werden können, es soll aber eine StandardVorlage geben
+- Welche Feld noch benötigt, muss ermittelt werden.
+- 

docs/legacy-implementation-roadmap.md

@@ -0,0 +1,360 @@
+# Legacy Zu SaaS Umsetzungsfahrplan
+
+Diese Datei verdichtet die Review des Funktionskatalogs zu einem
+umsetzungsorientierten Fahrplan. Ziel ist es, nur solche Themen parallel
+anzugehen, die bereits fachlich und technisch sauber geschnitten sind.
+
+## Review Ergebnis
+
+Der Katalog in `docs/legacy-feature-catalog.md` ist als Planungsgrundlage gut,
+aber noch nicht komplett implementierungsreif. Mehrere Themen sind im
+`saas-app`-Geruest bereits vorbereitet, allerdings oft nur als Datenmodell oder
+Demo-Service. Vor einer breiten Parallelumsetzung muessen deshalb zuerst einige
+Architektur- und Fachentscheidungen festgezogen werden.
+
+## Harte Blocker Vor Breiter Umsetzung
+
+### 1. Identity-Strategie
+
+Offen:
+- OIDC-first mit ADFS als OIDC-Provider
+- oder direkter AD-/LDAP-Abgleich
+
+Warum blocker:
+- Das aktuelle SaaS-Geruest ist OIDC-orientiert.
+- Der Katalog nennt AD und ADFS, beschreibt aber die Zielarchitektur nicht
+  praezise genug.
+
+Benötigte Entscheidung:
+- [X] Zielpfad fuer Anmeldung und Benutzerabgleich festlegen
+
+Der Verantwortliche für die jeweilige Kaffeeliste sollt auswählen könne, ob per ADFS oder LDAP Anbindung oder Azure AD Abfrage eingerichtet werden kann.
+
+### 2. Rollenmatrix
+
+Offen:
+- Welche Rollen gibt es ausser `platform_admin`, `tenant_admin`, `member`?
+- Braucht es z. B. `finance_admin`, `support_contact`, `survey_manager`?
+
+Warum blocker:
+- Zahlungsfreigaben, Kommunikationswege und Survey-Rechte haengen direkt von
+  Rollen ab.
+
+Benötigte Entscheidung:
+- [X] Rollenmodell und Rechte pro Rolle festlegen
+
+Ja es sollte Rollen und Rechte pro Rolle geben. Tenant Admin soll immer alle Recht haben
+
+
+### 3. Zahlungsmodell
+
+Offen:
+- Pro Tenant aktivierbare Zahlungsarten
+- Bankdaten
+- PayPal-Empfaenger
+- Catch-all-Mailbox und Zahlungsabgleich
+
+Warum blocker:
+- Das aktuelle `payment_entries`-Modell ist fuer einfache Buchungen gut, aber
+  noch nicht fuer automatischen Abgleich oder Mailbox-Importe.
+
+Benötigte Entscheidung:
+- [Ja umsetzen] Zahlungsarten pro Tenant definieren
+- [Ja umsetzen] Reconciliation-Modell definieren
+- [Ja umsetzen] Mailbox-Import als eigenes Folgepaket abgrenzen
+
+
+
+### 4. Kommunikationsmodell
+
+Offen:
+- Soll eine Anfrage nur per Mail weitergeleitet werden?
+- Oder als Vorgang im System bestehen bleiben?
+- Wer ist die zentrale Administration fachlich genau?
+
+Warum blocker:
+- Aktuell existiert nur `support_email`, aber kein Vorgangs- oder Routingmodell.
+
+Benötigte Entscheidung:
+- [Ja] Support-Request-Workflow definieren
+
+Die Anfragen information soll an den Verantwortlichen der Anfragen bzw. den Tenant Admin gehen. 
+Die Zentrale Administration ist die Verwaltung aller Tenant
+
+### 5. Survey-Modell
+
+Offen:
+- Wer darf Surveys anlegen?
+- Wie werden Antwortoptionen modelliert?
+- Wann sind Ergebnisse fuer Benutzer sichtbar?
+- Live-Ansicht oder freigegebener Snapshot?
+
+Warum blocker:
+- Das Grundschema existiert, aber Freigabe, Multiple Choice und Auswertung sind
+  noch nicht ausreichend modelliert.
+
+Benötigte Entscheidung:
+- [ ] Survey-MVP fachlich festziehen
+
+Ermöglich eine Standardgerüst für Umfragen. Die Umfragen sollten von der jeweiligen Rolle oder dem Tenant Administrator vollständig verwaltet werden können.
+
+### 6. Audit Und Storno
+
+Offen:
+- Darf weiterhin direkt geloescht werden?
+- Oder braucht es kuenftig Storno, Historie und Freigaben?
+
+Warum blocker:
+- Legacy arbeitet vielfach mit direkter Loeschung; das ist fuer SaaS und
+  Nachvollziehbarkeit meist zu schwach.
+
+Benötigte Entscheidung:
+- [X] Korrekturmodell fuer Buchungen definieren
+Nein es sollte nicht gelöscht werden können es soll Storne und Historie geben.
+
+## Bereits Tragfaehige Grundlagen Im SaaS-Geruest
+
+Vorhanden:
+- Mandantenmodell
+- tenantbezogene Einstellungen
+- OIDC-Provider- und Identity-Tabellen
+- Rollen- und Tenant-User-Grundmodell
+- Ledger-, Payment-, Content-, Survey-, Import- und Export-Tabellen
+- Feature-Gating fuer mehrere Module
+
+Einordnung:
+- Das Geruest ist gut genug, um fokussierte MVPs umzusetzen.
+- Es ist nicht gut genug, um alle Themen parallel ohne weitere
+  Fachspezifikation produktiv zu bauen.
+
+## Empfohlene Reihenfolge Fuer Spezialistenpakete
+
+### Paket 1. Identity Baseline
+
+Ziel:
+- Zielarchitektur fuer Login und Identitaetsverknuepfung festziehen
+
+Scope:
+- OIDC-/ADFS-Entscheid dokumentieren
+- Provider-Konfiguration pro Tenant
+- Benutzeridentitaeten sauber mappen
+
+Ergebnis:
+- Eine stabile Basis fuer alle spaeteren Rollen- und Zugriffsthemen
+
+Status:
+- [ ] Noch nicht spezifiziert
+- [ ] Danach implementierbar
+
+### Paket 2. Rollen Und Verantwortlichkeiten
+
+Ziel:
+- Fachrollen fuer Tenant-Betrieb sauber schneiden
+
+Scope:
+- Plattform-Admin
+- Tenant-Admin
+- Mitglied
+- optional Finance, Support, Survey-Manager
+
+Ergebnis:
+- Klare Berechtigungsbasis fuer Payments, Support und Surveys
+
+Status:
+- [ ] Noch nicht spezifiziert
+- [ ] Danach implementierbar
+
+### Paket 3. Content MVP
+
+Ziel:
+- Hinweise und FAQ durch Tenant-Admins pflegbar machen
+
+Scope:
+- CRUD fuer Hinweise
+- CRUD fuer FAQ
+- aktiv/inaktiv
+- Sortierung
+- Sichtbarkeit bis Datum
+- optionale Standardvorlage als Startbestand
+
+Ergebnis:
+- Erstes direkt nutzbares Fachmodul mit bereits passendem Datenmodell
+
+Status:
+- [X] Fachlich fast schnittreif
+- [ ] Kann frueh implementiert werden
+
+### Paket 4. Support Requests MVP
+
+Ziel:
+- Anfragen Benutzer -> Kaffeelistenverantwortliche
+- Anfragen Verantwortliche -> zentrale Administration
+
+Scope:
+- `support_requests`
+- Richtung
+- Kategorie
+- Nachricht
+- Absender
+- Ziel
+- Status
+- Zeitstempel
+
+Ergebnis:
+- Ein nachvollziehbarer Kommunikationsprozess statt nackter Mailweiterleitung
+
+Status:
+- [ ] Vorher Workflow-Entscheid noetig
+- [ ] Danach implementierbar
+
+### Paket 5. Payment Configuration MVP
+
+Ziel:
+- Tenant-spezifische Zahlungsarten und Zahlungsdaten
+
+Scope:
+- Bar
+- Ueberweisung
+- PayPal
+- aktivierte Methoden
+- Hinweise fuer Benutzer
+- tenantbezogene Zahlungsparameter
+
+Ergebnis:
+- Saubere Grundlage fuer spaetere Automatisierung
+
+Status:
+- [ ] Vorher Fachmodell vervollstaendigen
+- [ ] Danach implementierbar
+
+### Paket 6. Ledger Audit Und Korrekturen
+
+Ziel:
+- Buchungen sicher korrigieren statt direkt loeschen
+
+Scope:
+- Storno statt Hard Delete
+- Auditfelder
+- Referenzen auf Ursprungseintraege
+- Begruendung oder Freigabeoption
+
+Ergebnis:
+- Nachvollziehbares Buchungsmodell
+
+Status:
+- [ ] Vorher Korrekturregeln definieren
+- [ ] Danach implementierbar
+
+### Paket 7. Survey Admin MVP
+
+Ziel:
+- Tenant-seitige Survey-Erstellung und Verwaltung
+
+Scope:
+- Survey anlegen
+- Fragen anlegen
+- Aktivierungszeitraum
+- Ergebnisfreigabe
+- Auswertung fuer Tenant-Admins
+
+Ergebnis:
+- Nutzbares Survey-Modul fuer den operativen Betrieb
+
+Status:
+- [ ] Vorher Antwortoptionen und Freigabemodell ergaenzen
+- [ ] Danach implementierbar
+
+### Paket 8. Survey Publishing Fuer Benutzer
+
+Ziel:
+- Benutzer duerfen freigegebene Ergebnisse sehen
+
+Scope:
+- Freigabeflag
+- Benutzeransicht
+- Aggregationen
+- optionale Snapshot-Logik
+
+Ergebnis:
+- Kontrollierte Transparenz statt unklarer Sichtbarkeit
+
+Status:
+- [ ] Abhaengig von Paket 7
+
+### Paket 9. Payment Reconciliation
+
+Ziel:
+- Zahlungen aus externen Quellen belastbar abgleichen
+
+Scope:
+- Status
+- externe Referenz
+- Quelle
+- Matching
+- manuelle Klaerung
+- Audit
+
+Ergebnis:
+- Technische Basis fuer Import- und Mailbox-Automatisierung
+
+Status:
+- [ ] Abhaengig von Paket 5
+
+### Paket 10. Catch-All Mailbox Integration
+
+Ziel:
+- Zahlungsbenachrichtigungen automatisiert einlesen und zuordnen
+
+Scope:
+- Eingangskanal
+- Parser
+- Sicherheitsregeln
+- Matching-Regeln
+- Klaerungsfaelle
+
+Ergebnis:
+- Eigenstaendige Integrationsstrecke, nicht Teil eines kleinen MVPs
+
+Status:
+- [ ] Abhaengig von Paket 9
+
+## Was Jetzt Schon Sicher Parallelisierbar Ist
+
+Diese Themen koennen nach kurzer Feinspezifikation gut durch getrennte
+Spezialisten umgesetzt werden:
+
+- Content-MVP
+- Rollenmatrix und Rechtekonzept
+- Tenant Payment Configuration
+- Support-Requests Datenmodell
+- Survey-Admin-Konzept
+
+Diese Themen sollten noch nicht in Produktcode parallel umgesetzt werden:
+
+- Catch-all-Mailbox fuer PayPal
+- finale Identity-Integration ohne Architekturentscheid
+- Survey-Publishing fuer Benutzer ohne Freigabemodell
+- Audit-/Storno-Implementierung ohne fachliche Korrekturregeln
+
+## Konkrete Naechste Entscheidungsliste
+
+- [ ] OIDC mit ADFS als Zielpfad bestaetigen oder AD-/LDAP-Abgleich bevorzugen
+- [ ] Rollenmatrix festlegen
+- [ ] Support Requests als Mailweiterleitung oder Vorgangssystem definieren
+- [ ] FAQ/Mailtexte als Standardvorlage mit Tenant-Override bestaetigen
+- [ ] Survey-Freigabemodell fuer Benutzer festlegen
+- [ ] Storno/Audit statt direkter Loeschung bestaetigen
+- [ ] Catch-all-Mailbox ausdruecklich als spaeteres Integrationspaket bestaetigen
+
+## Empfehlung
+
+Wenn du sofort in Umsetzung gehen willst, ist die sauberste Reihenfolge:
+
+1. Content-MVP
+2. Rollenmatrix
+3. Payment Configuration MVP
+4. Support Requests MVP
+5. Survey Admin MVP
+
+Erst danach sollten wir Payment-Reconciliation, Mailbox-Import und komplexere
+Identity-Integrationen parallelisieren.