Roadmap angelegt

docs/legacy-feature-catalog.md

@@ -13,6 +13,9 @@ Umsetzungspakete genutzt werden kann.
 - Die Inhalte stammen aus einer Codeanalyse der Legacy-Seiten und muessen bei
   Bedarf um fachliche Regeln aus FAQ, E-Mails und Betriebswissen ergaenzt
   werden.
+- Fuer Entwicklungsarbeit reicht dieser Katalog allein nicht aus; die
+  ergaenzenden Leitplanken und Mindestanforderungen in diesem Dokument sind vor
+  paralleler Umsetzung mitzupflegen.
 
 ## Empfohlene Planungsmodule
 
@@ -58,8 +61,8 @@ Ziel fuer SaaS:
 - [ ] Entfaellt
 
 Manuelle Ergaenzungen:
-- 
-- 
+-
+-
 
 ### 2. Operative Buchung und Kassenfuehrung
 
@@ -96,8 +99,8 @@ Ziel fuer SaaS:
 - [ ] Entfaellt
 
 Manuelle Ergaenzungen:
-- 
-- 
+-
+-
 
 ### 3. Uebersichten, Reporting und Export
 
@@ -128,8 +131,8 @@ Ziel fuer SaaS:
 - [ ] Entfaellt
 
 Manuelle Ergaenzungen:
-- 
-- 
+-
+-
 
 ### 4. Mitglieder, Rollen und Berechtigungen
 
@@ -161,8 +164,9 @@ Ziel fuer SaaS:
 - [ ] Entfaellt
 
 Manuelle Ergaenzungen:
-- die Authentifizierung an einem AD und ADFS sollen hinzugefügt werden.
-- 
+- Die Authentifizierung an AD und ADFS soll hinzugefuegt werden.
+- Eine Azure-AD-Variante ist ebenfalls als moegliche Tenant-Integration zu
+  pruefen.
 
 ### 5. Kommunikation, Hinweise und Benachrichtigungen
 
@@ -196,8 +200,10 @@ Ziel fuer SaaS:
 - [ ] 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.
+- Es soll die Moeglichkeit geben, dass Benutzer Anfragen an die
+  Verantwortlichen der Kaffeeliste des jeweiligen Kunden senden koennen.
+- Es soll die Moeglichkeit geben, dass Verantwortliche der Kaffeeliste Anfragen
+  an die zentrale Administration stellen koennen.
 
 ### 6. Feedback und Umfragen
 
@@ -225,8 +231,10 @@ Ziel fuer SaaS:
 - [ ] 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.
-- 
+- Es soll moeglich sein, dass Verantwortliche der Kaffeeliste Umfragen
+  einrichten koennen.
+- Verantwortliche der Kaffeeliste sollen Umfragen vollumfaenglich verwalten und
+  auswerten koennen.
 
 ### 7. Sonderprozesse und Jahresabschluss
 
@@ -251,8 +259,9 @@ Ziel fuer SaaS:
 - [ ] Entfaellt
 
 Manuelle Ergaenzungen:
-- Es sollt die möglichkeit geben eine Jahresbonus z.B. anhand der im Jahr verbrauchten Strichen zu verteilen an die Mitglieder
-- 
+- Es soll die Moeglichkeit geben, einen Jahresbonus oder eine
+  Sonderausschuettung anhand der im Jahr verbrauchten Striche zu verteilen.
+-
 
 ## Seiteninventar
 
@@ -281,11 +290,13 @@ Manuelle Ergaenzungen:
 - [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?
+- [X] Soll die Zahlung ueber ein konfigurierbares Zahlungsmodul mit mehreren
+  Zahlarten laufen?
+- [X] Brauchen Korrekturen kuenftig Storno- und Loeschregeln?
+- [X] Umfrageergebnisse werden nach Freigabe durch Tenant-Verantwortliche oder
+  Survey-Verantwortliche sichtbar.
+- [X] `mailausgebe.php` spielt fuer die neue Webseite keine Rolle.
+- [X] Jahresauswertungen sollen als bedarfsorientierter Prozess moeglich sein.
 - [ ] Welche Fachregeln aus FAQ und Mailtexten muessen als echte Anforderungen
   uebernommen werden?
 - [ ] Welche Zusatzfelder braucht das kuenftige Benutzerprofil, z. B.
@@ -294,10 +305,181 @@ Manuelle Ergaenzungen:
 
 ## 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.
-- 
+- Die Zahlung soll der Verantwortliche der Kaffeeliste einstellen koennen. Bar,
+  Ueberweisung und PayPal sollen auswaehlbar sein.
+- Bei PayPal koennen Benachrichtigungen an ein tenantbezogenes Postfach gesendet
+  werden. Ein Catch-all-Postfach fuer automatisierte Auswertung ist als spaeteres
+  Integrationspaket vorgesehen.
+- Die Umfrageergebnisse sollen nach Freigabe des Verantwortlichen auch die
+  Benutzer sehen koennen.
+- `mailausgebe.php` wird fuer die neue Webseite nicht uebernommen.
+- Jahresauswertungen sollen bei Bedarf durch Verantwortliche ausgeloest werden
+  koennen, inklusive moeglicher fixer oder flexibler Boni.
+- FAQ und Mailtexte muessen durch die Verantwortlichen der Kaffeeliste angepasst
+  werden koennen; zusaetzlich soll es eine Standardvorlage geben.
+- Welche weiteren Profilfelder benoetigt werden, muss tenantweit noch ermittelt
+  werden.
+
+## Ergaenzte Leitplanken Fuer Das SaaS-Zielbild
+
+Diese Leitplanken verdichten die bisher bekannten Antworten aus Katalog,
+Roadmap und Review. Sie ersetzen noch keine Detailkonzepte, schaffen aber eine
+stabilere Basis fuer die Fachspezifikation.
+
+### Bereits Vorlaeufig Geklaert
+
+- Self-Service-Stricheintrag soll erhalten bleiben, aber tenantbezogen
+  aktivierbar sein.
+- Einzahlungen sollen stornierbar sein; Stricheintraege sollen durch
+  Verantwortliche loeschbar sein.
+- Tenant-Admins sollen ihre Inhalte fuer Hinweise, FAQ, Umfragen und
+  Zahlungsarten selbst pflegen koennen.
+- Zahlungsarten sollen pro Tenant konfigurierbar sein: mindestens Bar,
+  Ueberweisung und PayPal.
+- Umfrageergebnisse sollen fuer Benutzer erst nach expliziter Freigabe sichtbar
+  werden.
+- FAQ- und Kommunikationstexte sollen als Standardvorlagen verfuegbar sein und
+  tenantseitig ueberschrieben werden koennen.
+- Supportanfragen sollen je nach Richtung an Tenant-Verantwortliche oder
+  Plattform-Administration geroutet werden.
+- Anmeldung soll immer lokal im System moeglich sein und zusaetzlich per
+  ADFS/OIDC erfolgen koennen.
+- `mailausgebe.php` wird nicht als Produktfunktion fuer die neue Webseite
+  uebernommen.
+
+### Noch Fachlich Zu Praezisieren
+
+- Wie Erstlogin, Fallback und Dubletten bei lokaler Anmeldung plus ADFS/OIDC
+  behandelt werden.
+- Welche Spezialrollen neben `tenant_admin` und `member` benoetigt werden und
+  welche Rechte diese konkret haben.
+- Ob Zahlungsabgleiche per PayPal-Mailbox Teil des MVPs sind oder ein spaeteres
+  Integrationspaket bilden.
+- Wie Jahresauswertungen und moegliche Bonus-/Sonderausschuettungen fachlich
+  parametrisiert werden.
+- Welche zusaetzlichen Profilfelder kuenftig tenantweit oder pro Benutzer
+  gepflegt werden muessen.
+
+### Empfohlene Detailentscheidungen
+
+- Identity: lokale Anmeldung immer aktiv, ADFS/OIDC als einzige zusaetzliche
+  externe Anmeldung, E-Mail-Mapping als Standard, Admin-Klaerfall bei
+  Dubletten.
+- Payment: Reconciliation und Mailbox-Abgleich nicht im MVP, aber mit
+  vorbereiteten Statusfeldern fuer spaetere Erweiterung.
+- Surveys: Mitglieder sehen freigegebene Snapshots statt Live-Daten.
+- Jahresauswertung: bedarfsorientierter Admin-Prozess mit Vorschau, Freigabe
+  und parametrisierbarer Bonuslogik.
+- Profilfelder: tenantweit konfigurierbare Zusatzfelder; `paypalname` ist
+  Startkandidat fuer Matching.
+- Schutzmechanismen: Vorschau und Testmodus fuer riskante Sammelaktionen im MVP,
+  Vier-Augen-Freigabe fuer Jahresauswertung, Massenmail, Import und
+  Sammel-Storno; die Vier-Augen-Freigabe muss tenantweit deaktivierbar sein.
+
+
+## Mindestanforderungen Fuer Entwicklungsreife
+
+Die folgenden Punkte fehlen in der Legacy-Ableitung noch oder sind nur implizit
+enthalten. Sie sollten vor paralleler Umsetzung je Modul ergaenzt werden.
+
+### Funktionale Mindesttiefe
+
+- Pro Modul eine kurze Fachspezifikation mit Ausloeser, Vorbedingungen,
+  Nachbedingungen und Fehlerfaellen.
+- Pro Modul Akzeptanzkriterien fuer den MVP.
+- Pro Workflow ein Statusmodell, mindestens fuer Support Requests, Surveys,
+  Zahlungsabgleich und Buchungskorrekturen.
+- Pro Integrationspunkt eine Beschreibung des Eingangsformats, der
+  Fehlerbehandlung und der manuellen Klaerfaelle.
+
+### Rollen Und Rechte
+
+- Rechte-Matrix pro Rolle und Aktion, z. B. lesen, anlegen, freigeben,
+  korrigieren, exportieren, versenden.
+- Klarstellung, welche Rechte `tenant_admin` immer besitzt und welche
+  Spezialrollen delegierbar sind.
+- Tenant-Grenzen fuer Zugriffe, Exporte und Supportvorgaenge.
+- Trennung zwischen Authentifizierung, Autorisierung und Benutzerabgleich.
+
+### Daten Und Historie
+
+- Felddefinitionen fuer Zahlungsdaten, Benutzerprofile, Support Requests,
+  Surveys und Exportparameter.
+- Regeln fuer Storno, Referenzen auf Ursprungseintraege und unveraenderliche
+  Audit-Historie.
+- Aufbewahrung, Archivierung und Sichtbarkeit historischer Daten.
+- Dubletten- und Matching-Regeln fuer CSV-Importe und Mailbox-Abgleiche.
+
+### Betrieb, Sicherheit Und Compliance
+
+- Datenschutz- und Berechtigungskonzept fuer Mailadressen, Exporte und
+  Kontostandskommunikation.
+- Logging, Monitoring und Benachrichtigung bei fehlerhaften Importen,
+  Massenaktionen und Integrationsfehlern.
+- Backup-/Restore-Anforderungen fuer tenantkritische Daten.
+- Schutzmechanismen fuer risikoreiche Aktionen wie Serienmail, Jahresabschluss
+  und Sammelbuchungen, z. B. Vorschau, Testmodus, Vier-Augen-Freigabe.
+
+### Testbarkeit Und Abnahme
+
+- Mindestabdeckung fuer Unit-, Integrations- und End-to-End-Tests.
+- Testdaten und Referenzfaelle fuer typische Tenant-Szenarien.
+- Abnahmefaelle fuer Rollen, Storno, Zahlungsabgleich, Supportrouting und
+  Survey-Freigabe.
+- Definition of Done je Paket inklusive Doku, Monitoring und Betriebsfreigabe.
+
+## Empfohlene Modulspezifikation Vor Umsetzung
+
+Bevor ein Team ein Paket umsetzt, sollte fuer das jeweilige Modul mindestens
+dieser kurze Steckbrief vorliegen:
+
+| Punkt | Erwartete Aussage |
+| --- | --- |
+| Ziel | Welches Fachproblem loest das Modul im MVP? |
+| Rollen | Wer darf lesen, pflegen, freigeben, exportieren oder korrigieren? |
+| Kernworkflow | Welche Schritte durchlaeuft ein Vorgang von Start bis Abschluss? |
+| Daten | Welche Stammdaten, Bewegungsdaten und Referenzen werden benoetigt? |
+| Fehlerfaelle | Welche Validierungs-, Import- und Berechtigungsfehler gibt es? |
+| Historie | Welche Aktionen muessen nachvollziehbar protokolliert werden? |
+| Akzeptanz | Woran erkennen Fachseite und Entwicklung, dass der MVP fertig ist? |
+
+## Entscheidungsbedarf Fuer Die Naechste Runde
+
+Diese Entscheidungen sind aus heutiger Sicht die wichtigsten, bevor mehrere
+Teams parallel in Produktcode arbeiten:
+
+1. Identity-Zielbild: ein bevorzugter Standardpfad oder tenantweise frei
+   verfuegbare lokale Anmeldung plus zusaetzliches ADFS/OIDC mit E-Mail-Mapping.
+2. Rollenmodell: finale Rollenliste plus Rechte-Matrix mit Admin-Override.
+3. Supportmodell: Vorgangssystem mit Status, Routing und Sichtbarkeit.
+4. Zahlungs-MVP: nur Konfiguration und manuelle Buchung oder bereits mit
+   Reconciliation-Vorbereitung.
+5. Survey-Freigabe: wer freigibt, welche Ergebnisse sichtbar werden und ob live
+   oder per Snapshot veroeffentlicht wird.
+6. Jahresauswertung: bedarfsorientierter Fachprozess mit welchen Parametern und
+   Freigaben.
+
+
+### Konkrete Festlegungen Aus Der Review
+
+- Anmeldung funktioniert immer per lokaler Systemanmeldung und zusaetzlich per
+  ADFS/OIDC.
+- Rollen `finance_admin`, `support_contact` und `survey_manager` sollen als
+  Spezialrollen vorgesehen werden.
+- Supportanfragen sollen in der Anwendung als Vorgang mit Status sichtbar sein;
+  Empfaenger sind Tenant-Verantwortliche oder Support-Verantwortliche.
+- Zahlungsabgleiche per PayPal-Mailbox sind nicht Teil des MVPs.
+- Reconciliation wird als Folgepaket geplant, aber im Datenmodell vorbereitet.
+- `mailausgebe.php` wird nicht uebernommen, ausser eine andere Produktfunktion
+  braucht diese Ausgabe technisch intern.
+- Zusaetzliche Profilfelder sollen tenantweit definiert werden; ein Kandidat ist
+  `paypalname` fuer Matching-Zwecke.
+- Survey-Freigaben erfolgen durch Tenant-Verantwortliche oder
+  Survey-Verantwortliche. Diese steuern Freischaltung, Ende und
+  Veroeffentlichung.
+- Fuer Benutzer werden freigegebene Snapshot-Staende veroeffentlicht.
+- Es gibt keinen fixen Jahresabschluss; stattdessen soll eine bedarfsorientierte
+  Jahresauswertung mit fixer oder flexibler Bonusverteilung moeglich sein.
+- Vorschau und Testmodus sollen fuer risikoreiche Sammelaktionen Teil des MVPs
+  sein; Vier-Augen-Freigabe fuer besonders kritische Aktionen folgt ebenfalls
+  dem Zielbild und muss tenantweit deaktivierbar sein.

docs/legacy-implementation-roadmap.md

@@ -10,107 +10,233 @@ 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.
+Architektur-, Fach- und Betriebsentscheidungen festgezogen werden.
+
+## Zusammenfassung Fuer Die Projektsteuerung
+
+Aktuell ist die Roadmap als Themenkarte brauchbar, aber noch nicht belastbar
+fuer eine breite Parallelisierung mehrerer Entwicklungsteams.
+
+Belastbar vorbereitet:
+- Content-MVP fuer Hinweise und FAQ
+- Grundlegende Payment-Konfiguration auf Tenant-Ebene
+- Survey-Admin-MVP als fachliches Folgepaket
+
+Noch nicht belastbar vorbereitet:
+- Identity-Strategie und Benutzerabgleich
+- Rollen- und Rechte-Matrix
+- Audit-/Storno-Modell fuer Buchungen
+- Support-Request-Workflow
+- Nichtfunktionale Anforderungen, Test- und Abnahmekriterien
+
+## Stand Der Bisherigen Entscheidungen
+
+### Vorlaeufig Geklaerte Leitplanken
+
+- Self-Service-Striche sollen erhalten bleiben und tenantweit schaltbar sein.
+- Einzahlungen sollen im Zielsystem stornierbar sein; Stricheintraege sollen
+  durch Verantwortliche loeschbar bleiben.
+- Tenant-Admins sollen Inhalte, Zahlungsarten und Surveys verwalten koennen.
+- Zahlungsarten sollen pro Tenant mindestens Bar, Ueberweisung und PayPal
+  unterstuetzen.
+- Survey-Ergebnisse sollen erst nach Freigabe fuer Mitglieder sichtbar werden.
+- FAQ- und Kommunikationstexte sollen als Standardvorlage plus Tenant-Override
+  modelliert werden.
+- Supportanfragen sollen zwischen Benutzer, Tenant-Verantwortlichen und
+  Plattform-Administration routebar sein.
+
+### Noch Offene Produktentscheidungen
+
+- Konkrete Rechte-Matrix pro Rolle und Objekt finalisieren.
+- Konkrete Parameter und Freigabelogik fuer Jahresauswertungen und Boni.
 
 ## Harte Blocker Vor Breiter Umsetzung
 
 ### 1. Identity-Strategie
 
+Status:
+- [X] Zielbild festgelegt
+- [ ] Detailkonzept vor Implementierung spezifizieren
+
 Offen:
-- OIDC-first mit ADFS als OIDC-Provider
-- oder direkter AD-/LDAP-Abgleich
+- lokale DB-Anmeldung im System
+- zusaetzliche ADFS-/OIDC-Anmeldung
+- E-Mail-basiertes Mapping zwischen externer Identitaet und internem Benutzer
 
 Warum blocker:
 - Das aktuelle SaaS-Geruest ist OIDC-orientiert.
-- Der Katalog nennt AD und ADFS, beschreibt aber die Zielarchitektur nicht
-  praezise genug.
+- Login, Tenant-Zuordnung, Benutzerabgleich und Rollenvergabe haengen direkt an
+  dieser Entscheidung.
+- Das Zielbild ist festgelegt, aber das Detailkonzept fuer Fallback, Mapping und
+  Erstlogin fehlt noch.
 
-Benötigte Entscheidung:
-- [X] Zielpfad fuer Anmeldung und Benutzerabgleich festlegen
+Mindestinhalt der Entscheidung:
+- lokale Anmeldung immer verfuegbar
+- ADFS/OIDC als einzige zusaetzliche externe Anmeldung
+- Mapping zwischen externer Identitaet und internem Benutzer per E-Mail
+- Regeln fuer Erstlogin, Reaktivierung und Dubletten
 
-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.
+Empfehlung:
+- Lokale Anmeldung bleibt verpflichtend verfuegbar.
+- ADFS/OIDC wird als einzige zusaetzliche externe Anmeldung vorgesehen.
+- Beim Erstlogin per ADFS/OIDC erfolgt das Mapping primaer ueber E-Mail.
+- Bei Dubletten oder unklaren Zuordnungen wird ein Admin-Klaerfall erzeugt.
 
 ### 2. Rollenmatrix
 
+Status:
+- [~] Rollen grundsaetzlich festgelegt
+- [ ] Rechte-Matrix vor Implementierung spezifizieren
+
 Offen:
-- Welche Rollen gibt es ausser `platform_admin`, `tenant_admin`, `member`?
-- Braucht es z. B. `finance_admin`, `support_contact`, `survey_manager`?
+- Welche Rechte gelten pro Rolle und Objekt?
 
 Warum blocker:
-- Zahlungsfreigaben, Kommunikationswege und Survey-Rechte haengen direkt von
-  Rollen ab.
+- Zahlungsfreigaben, Kommunikation, Surveys, Exporte und Korrekturen haengen
+  direkt von Berechtigungen ab.
+- "Tenant Admin hat alles" reicht nicht als umsetzbare Rechtebeschreibung.
 
-Benötigte Entscheidung:
-- [X] Rollenmodell und Rechte pro Rolle festlegen
+Mindestinhalt der Entscheidung:
+- Rollenliste mit `platform_admin`, `tenant_admin`, `finance_admin`,
+  `support_contact`, `survey_manager`, `member`
+- Rechte-Matrix pro Aktion und Objekt
+- Tenant-Grenzen und Admin-Override
+- Delegation von Spezialrollen
 
-Ja es sollte Rollen und Rechte pro Rolle geben. Tenant Admin soll immer alle Recht haben
+Empfohlene Rechte-Matrix:
 
+| Rolle | Benutzer / Identitaet | Rollenverwaltung | Buchungen / Einzahlungen | Support | Surveys | Content / FAQ | Reporting / Export |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| `platform_admin` | global verwalten, Tenant-Identity einrichten | global | global | global | global | global | global |
+| `tenant_admin` | tenantweit alles | tenantweit alles | anlegen, bearbeiten, Einzahlungen stornieren, Striche loeschen | Vorgaenge sehen und bearbeiten | anlegen, freigeben, auswerten | pflegen | tenantweit exportieren und auswerten |
+| `finance_admin` | Benutzerdaten nur fuer Buchungskontext lesen | nein | Einzahlungen buchen und stornieren, Striche loeschen, Salden korrigieren | lesen | lesen | lesen | Finanz- und Buchungsreports exportieren |
+| `support_contact` | Benutzerdaten nur im Supportkontext lesen | nein | nein | Supportvorgaenge sehen, bearbeiten, schliessen | nein | lesen | supportbezogene Auswertungen lesen |
+| `survey_manager` | Benutzerdaten nur minimal lesen, falls fuer Surveys noetig | nein | nein | nein | Umfragen anlegen, freigeben, auswerten, veroeffentlichen | lesen | Survey-Reports exportieren |
+| `member` | eigenes Profil lesen und pflegen, Login lokal oder via `ADFS/OIDC` | nein | eigene Eintraege sehen, Self-Service nur wenn freigeschaltet | eigene Anfragen stellen und Status sehen | teilnehmen, freigegebene Ergebnisse sehen | lesen | eigene bzw. freigegebene Auswertungen lesen |
+
+Hinweise:
+- `tenant_admin` hat im eigenen Tenant Vollzugriff.
+- Spezialrollen erhalten nur die fuer ihr Modul noetigen Rechte.
+- `platform_admin` darf tenantuebergreifend administrieren.
+- Einzahlungen koennen nur durch Verantwortliche storniert werden.
+- Stricheintraege koennen nur durch Verantwortliche geloescht werden.
 
 ### 3. Zahlungsmodell
 
-Offen:
-- Pro Tenant aktivierbare Zahlungsarten
-- Bankdaten
-- PayPal-Empfaenger
-- Catch-all-Mailbox und Zahlungsabgleich
+Status:
+- [~] Teilweise geklaert
+- [ ] Vor Implementierung zu vervollstaendigen
+
+Bereits geklaert:
+- Zahlungsarten pro Tenant sind gewollt.
+- Bar, Ueberweisung und PayPal sollen Teil des MVPs sein.
+- Catch-all-Mailbox soll als eigenes Folgepaket abgegrenzt werden.
+- Payment-Reconciliation ist nicht Teil des MVPs und folgt als eigenes Paket
+  nach stabiler manueller Buchung.
+
+Noch offen:
+- Welche Zahlungsdaten pro Tenant gepflegt werden muessen.
+- Welche Hinweise und Pflichtfelder pro Zahlungsart sichtbar sind.
+- Welche manuellen Klaerfaelle vorgesehen sind.
 
 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
+- Das aktuelle `payment_entries`-Modell reicht fuer einfache Buchungen, aber
+  nicht fuer belastbaren Abgleich, Fehlerfaelle und spaetere Automatisierung.
 
+Empfehlung:
+- Im MVP nur Konfiguration und manuelle Buchung umsetzen.
+- Fuer spaetere Reconciliation bereits Statusfelder wie `neu`, `gematcht`,
+  `pruefen`, `storniert` vorbereiten.
+- Mailbox-Import und automatisches Matching bleiben Folgepakete.
 
 
 ### 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?
+Status:
+- [X] Zielbild fachlich festgelegt
+- [ ] Workflow und Statusmodell vor Implementierung spezifizieren
+
+Bereits geklaert:
+- Anfragen sollen an Tenant-Verantwortliche bzw. Tenant-Admins gehen.
+- Die Plattform-Administration ist die zentrale Verwaltung aller Tenants.
+- Support soll direkt als vollstaendiges Vorgangssystem starten.
+
+Noch offen:
+- Status, Eskalation, Routing und Bearbeitungsregeln.
+- Sichtbarkeit fuer Benutzer, Tenant-Admins und Plattform-Admins.
 
 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
+- Aktuell existiert nur `support_email`, aber kein belastbares Workflow- oder
+  Routingmodell.
 
 ### 5. Survey-Modell
 
-Offen:
-- Wer darf Surveys anlegen?
-- Wie werden Antwortoptionen modelliert?
-- Wann sind Ergebnisse fuer Benutzer sichtbar?
-- Live-Ansicht oder freigegebener Snapshot?
+Status:
+- [~] Teilweise geklaert
+- [ ] Vor Implementierung zu vervollstaendigen
+
+Bereits geklaert:
+- Tenant-seitige Erstellung und Verwaltung ist gewollt.
+- Mitglieder sollen Ergebnisse erst nach Freigabe sehen.
+- Fuer Mitglieder werden veroeffentlichte Snapshots empfohlen, keine
+  Live-Ergebnisse.
+
+Noch offen:
+- Wer Surveys genau anlegen, aktivieren und freigeben darf.
+- Wie Fragetypen und Antwortoptionen modelliert werden.
+- Welche Auswertungen im MVP benoetigt werden.
 
 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.
+Empfehlung:
+- Fachseite arbeitet auf Live-Daten.
+- Fuer Benutzer wird bei Freigabe ein stabiler Snapshot veroeffentlicht.
+- Snapshot-Versionen muessen nachvollziehbar gespeichert werden.
 
 ### 6. Audit Und Storno
 
-Offen:
-- Darf weiterhin direkt geloescht werden?
-- Oder braucht es kuenftig Storno, Historie und Freigaben?
+Status:
+- [~] Fachliche Leitplanke geklaert
+- [ ] Regelwerk vor Implementierung spezifizieren
+
+Bereits geklaert:
+- Einzahlungen sollen stornierbar sein.
+- Stricheintraege sollen loeschbar sein.
+- Korrekturen duerfen nur durch Verantwortliche erfolgen.
+
+Noch offen:
+- Ob Freigaben oder Begruendungen erforderlich sind.
+- Wie Referenzen auf Ursprungseintraege, Auditfelder und Historie aussehen.
+- Wie Importe und Jahresabschluss mit Korrekturen umgehen.
 
 Warum blocker:
-- Legacy arbeitet vielfach mit direkter Loeschung; das ist fuer SaaS und
-  Nachvollziehbarkeit meist zu schwach.
+- Legacy arbeitet vielfach mit direkter Loeschung; fuer SaaS und Nachvollzieh-
+  barkeit ist das 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.
+## Nichtfunktionale Mindestanforderungen
+
+Diese Anforderungen muessen vor oder spaetestens waehrend Paket-Spezifikation
+explizit beschrieben werden. Sie fehlen aktuell noch in den Legacy-Dokumenten.
+
+- Datenschutz und Berechtigungskonzept fuer Kontostaende, Mailadressen,
+  Exporte und Supportinhalte
+- Logging und Audit fuer Massenaktionen, Exporte, Freigaben und Integrationen
+- Monitoring und Fehlerbenachrichtigung fuer Importe, Mailversand und
+  Hintergrundprozesse
+- Backup/Restore fuer tenantkritische Stammdaten und Bewegungsdaten
+- Schutzmechanismen fuer risikoreiche Aktionen: Vorschau, Testmodus,
+  Vier-Augen-Freigabe, Idempotenz
+- Test- und Abnahmekriterien fuer alle MVP-Pakete
+
+Empfehlung:
+- Vorschau und Testmodus sind Mindestanforderung fuer riskante Sammelaktionen
+  bereits im MVP.
+- Vier-Augen-Freigabe ist fuer Jahresauswertung, Massenmail, Importlaeufe und
+  gebuendelte Stornoaktionen vorzusehen.
+- Die Vier-Augen-Freigabe muss tenantweit konfigurierbar und deaktivierbar
+  sein.
 
 ## Bereits Tragfaehige Grundlagen Im SaaS-Geruest
 
@@ -127,6 +253,91 @@ Einordnung:
 - Es ist nicht gut genug, um alle Themen parallel ohne weitere
   Fachspezifikation produktiv zu bauen.
 
+## Empfohlene Projektphasen
+
+### Phase 0. Architektur- und Fachentscheidungen
+
+Ziel:
+- Blocker aufloesen, damit nachfolgende Pakete sauber geschnitten sind.
+
+Enthaelt:
+- Identity-Zielbild
+- Rollen- und Rechte-Matrix
+- Audit-/Storno-Regeln
+- Support-Workflow
+- Survey-Freigabemodell
+- Mindestanforderungen fuer Betrieb, Sicherheit und Tests
+
+Ergebnis:
+- Verbindliche Leitplanken fuer Umsetzung und Abnahme
+
+### Phase 1. Basis Und Content MVP
+
+Ziel:
+- Schnell ein erstes nutzbares Modul liefern und gleichzeitig die
+  Tenant-Grundlagen stabilisieren.
+
+Enthaelt:
+- Content-MVP fuer Hinweise und FAQ
+- Standardvorlagen mit Tenant-Override
+- erste Rollenpruefungen auf Basis der festgelegten Matrix
+- `mailausgebe.php` nicht als Produktfunktion uebernehmen
+
+Ergebnis:
+- Erstes produktiv brauchbares Fachmodul mit klarer Zustands- und Rechtebasis
+
+### Phase 2. Operatives Ledger
+
+Ziel:
+- Buchungen, Einzahlungen und Korrekturen revisionsfaehig machen.
+
+Enthaelt:
+- operative Strich- und Einzahlungserfassung
+- Audit-/Storno-Modell
+- Basis fuer spaetere Importe und Zahlungsabgleiche
+
+Ergebnis:
+- Nachvollziehbare Buchungslogik statt Legacy-Loeschverhalten
+
+### Phase 3. Kommunikation Und Self-Service
+
+Ziel:
+- Nutzernahe Prozesse und Supportwege in den regulaeren App-Rahmen ueberfuehren.
+
+Enthaelt:
+- Support Requests MVP
+- Self-Service-Elemente rund um Dashboard und Anfragen
+- sichere Serienmail- und Kommunikationsprozesse
+
+Ergebnis:
+- Nachvollziehbarer Kommunikationsprozess statt unkontrollierter Einzeltools
+
+### Phase 4. Surveys
+
+Ziel:
+- Tenant-faehige Survey-Erstellung, Auswertung und kontrollierte Freigabe.
+
+Enthaelt:
+- Survey Admin MVP
+- Survey Publishing fuer Benutzer
+- Rollen- und Sichtbarkeitsregeln
+
+Ergebnis:
+- Nutzbares Survey-Modul fuer operativen Betrieb und spaetere Erweiterungen
+
+### Phase 5. Automatisierung Und Integrationen
+
+Ziel:
+- Auf den stabilen MVP-Modulen aufsetzen und Integrationen sicher erweitern.
+
+Enthaelt:
+- Payment Reconciliation
+- Catch-all Mailbox Integration
+- weitergehende Identity-Integrationen je Tenant
+
+Ergebnis:
+- Kontrollierte Automatisierung statt zu frueher Integrationskomplexitaet
+
 ## Empfohlene Reihenfolge Fuer Spezialistenpakete
 
 ### Paket 1. Identity Baseline
@@ -135,12 +346,13 @@ Ziel:
 - Zielarchitektur fuer Login und Identitaetsverknuepfung festziehen
 
 Scope:
-- OIDC-/ADFS-Entscheid dokumentieren
+- Zielpfad dokumentieren
 - Provider-Konfiguration pro Tenant
 - Benutzeridentitaeten sauber mappen
+- Regeln fuer Erstlogin und Dubletten
 
 Ergebnis:
-- Eine stabile Basis fuer alle spaeteren Rollen- und Zugriffsthemen
+- Stabile Basis fuer Rollen- und Zugriffsthemen
 
 Status:
 - [ ] Noch nicht spezifiziert
@@ -155,10 +367,11 @@ Scope:
 - Plattform-Admin
 - Tenant-Admin
 - Mitglied
-- optional Finance, Support, Survey-Manager
+- optionale Spezialrollen wie Finance, Support, Survey-Manager
+- Rechte-Matrix pro Aktion und Objekt
 
 Ergebnis:
-- Klare Berechtigungsbasis fuer Payments, Support und Surveys
+- Klare Berechtigungsbasis fuer Payments, Support, Surveys und Exporte
 
 Status:
 - [ ] Noch nicht spezifiziert
@@ -175,10 +388,10 @@ Scope:
 - aktiv/inaktiv
 - Sortierung
 - Sichtbarkeit bis Datum
-- optionale Standardvorlage als Startbestand
+- Standardvorlage plus Tenant-Override
 
 Ergebnis:
-- Erstes direkt nutzbares Fachmodul mit bereits passendem Datenmodell
+- Erstes direkt nutzbares Fachmodul mit passendem Datenmodell
 
 Status:
 - [X] Fachlich fast schnittreif
@@ -188,7 +401,7 @@ Status:
 
 Ziel:
 - Anfragen Benutzer -> Kaffeelistenverantwortliche
-- Anfragen Verantwortliche -> zentrale Administration
+- Anfragen Verantwortliche -> Plattform-Administration
 
 Scope:
 - `support_requests`
@@ -199,13 +412,14 @@ Scope:
 - Ziel
 - Status
 - Zeitstempel
+- Routing- und Eskalationsregeln
 
 Ergebnis:
-- Ein nachvollziehbarer Kommunikationsprozess statt nackter Mailweiterleitung
+- Nachvollziehbarer Kommunikationsprozess statt nackter Mailweiterleitung
 
 Status:
-- [ ] Vorher Workflow-Entscheid noetig
-- [ ] Danach implementierbar
+- [X] Zielbild entschieden
+- [ ] Workflow und Statusmodell spezifizieren
 
 ### Paket 5. Payment Configuration MVP
 
@@ -219,13 +433,14 @@ Scope:
 - aktivierte Methoden
 - Hinweise fuer Benutzer
 - tenantbezogene Zahlungsparameter
+- Vorbereitung fuer spaetere Reconciliation
 
 Ergebnis:
 - Saubere Grundlage fuer spaetere Automatisierung
 
 Status:
+- [~] Teilweise geklaert
 - [ ] Vorher Fachmodell vervollstaendigen
-- [ ] Danach implementierbar
 
 ### Paket 6. Ledger Audit Und Korrekturen
 
@@ -233,10 +448,12 @@ Ziel:
 - Buchungen sicher korrigieren statt direkt loeschen
 
 Scope:
-- Storno statt Hard Delete
+- Storno fuer Einzahlungen
+- Loeschung fuer Stricheintraege
 - Auditfelder
 - Referenzen auf Ursprungseintraege
 - Begruendung oder Freigabeoption
+- Regeln fuer Import- und Jahresabschlusskorrekturen
 
 Ergebnis:
 - Nachvollziehbares Buchungsmodell
@@ -256,13 +473,14 @@ Scope:
 - Aktivierungszeitraum
 - Ergebnisfreigabe
 - Auswertung fuer Tenant-Admins
+- Rollen fuer Erstellung und Freigabe
 
 Ergebnis:
 - Nutzbares Survey-Modul fuer den operativen Betrieb
 
 Status:
+- [~] Teilweise geklaert
 - [ ] Vorher Antwortoptionen und Freigabemodell ergaenzen
-- [ ] Danach implementierbar
 
 ### Paket 8. Survey Publishing Fuer Benutzer
 
@@ -324,37 +542,50 @@ 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
+- Rollenmatrix und Rechtekonzept als Spezifikationspaket
+- Tenant Payment Configuration als Fachmodell
+- Support-Requests Datenmodell als Vorarbeit
+- Survey-Admin-Konzept als Spezifikationspaket
 
 Diese Themen sollten noch nicht in Produktcode parallel umgesetzt werden:
 
 - Catch-all-Mailbox fuer PayPal
-- finale Identity-Integration ohne Architekturentscheid
+- finale Identity-Integration ohne Detailkonzept fuer Mapping und Fallback
 - Survey-Publishing fuer Benutzer ohne Freigabemodell
 - Audit-/Storno-Implementierung ohne fachliche Korrekturregeln
+- Serienmail- oder Jahresabschlussfunktionen ohne Schutzmechanismen und Testmodus
 
 ## Konkrete Naechste Entscheidungsliste
 
-- [ ] OIDC mit ADFS als Zielpfad bestaetigen oder AD-/LDAP-Abgleich bevorzugen
-- [ ] Rollenmatrix festlegen
-- [ ] Support Requests als Mailweiterleitung oder Vorgangssystem definieren
+### Entscheidungen Mit Hoher Prioritaet
+
+- [ ] Rechte-Matrix finalisieren
+- [ ] Support-Status, Routing und Eskalationsregeln festlegen
+- [ ] Storno-/Loeschregeln fuer Buchungen finalisieren
+- [ ] Identity-Detailregeln fuer Erstlogin, Fallback und Dubletten festlegen
+
+### Entscheidungen Mit Mittlerer Prioritaet
+
 - [ ] FAQ/Mailtexte als Standardvorlage mit Tenant-Override bestaetigen
-- [ ] Survey-Freigabemodell fuer Benutzer festlegen
-- [ ] Storno/Audit statt direkter Loeschung bestaetigen
+- [X] Survey-Freigabemodell fuer Benutzer als Snapshot-Veroeffentlichung
+  vorsehen
+- [X] Payment Configuration MVP ohne Reconciliation, aber mit technischer
+  Vorbereitung festlegen
+
+### Entscheidungen Mit Nachgelagerter Prioritaet
+
 - [ ] Catch-all-Mailbox ausdruecklich als spaeteres Integrationspaket bestaetigen
+- [ ] Jahresauswertung und Bonuslogik als konfigurierbaren Prozess spezifizieren
+- [ ] Zusatzfelder im Benutzerprofil tenantweit festlegen
 
 ## 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.
+1. Phase 0 als kurzer Spezifikations- und Entscheidungs-Sprint
+2. Content-MVP als erstes lieferbares Fachpaket
+3. Rollenmatrix und Payment Configuration als Basis fuer weitere Module
+4. Support Requests MVP und Ledger Audit/Korrekturen
+5. Survey Admin MVP und danach Survey Publishing
+6. Erst danach Payment-Reconciliation, Mailbox-Import und komplexere
+   Identity-Integrationen