patrickandClaude Sonnet 5
5e6ee2c456
- Generic org/team/member data model (renamed from club-specific naming) - Auth, organizations, invitations with mail + Matrix provisioning - Teams with automatic Matrix room creation, sync-job retry, reconciliation - Departments, seasons, roles (RBAC with privilege-escalation guard), audit log - Dashboard, members list, org switcher on the frontend - Synapse setup docs (Docker + bare-metal) and generalized PRD/architecture docs Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TBf3yfnnHzMQ5qhLV2285A
8.6 KiB
PRD: TalkTime
Status: Entwurf. Starter-Kit (
ai-coding-starter-kit-v2) noch nicht im Repo vorhanden — Annahmen zu Stack/Struktur unten explizit markiert. Vor Implementierung: Repo klonen und Kapitel "Offene Annahmen" verifizieren.
0. Generalisierung: nicht nur Sportvereine
Datenmodell und Code sind bewusst generisch gehalten (organizations statt clubs, Rollen wie ORG_ADMIN/TEAM_LEAD/GUARDIAN statt sportspezifischer Begriffe). Die Kernabstraktion Organisation → Abteilung → Team → Mitglied → Kommunikationsgruppe → Matrix-Room passt auf mehrere Zielgruppen:
| Konzept (Code) | Sportverein (Leitbeispiel) | Firma | NGO / Verband |
|---|---|---|---|
| Organization | Verein (SV Musterstadt) | Firma (Muster GmbH) | NGO/Dachverband |
| Department | Abteilung (Fußball, Handball) | Abteilung (Vertrieb, IT) | Bereich (Katastrophenhilfe, Bildung) |
| Team | Mannschaft (1. Herren) | Team/Projektgruppe | Projektgruppe/Einsatzteam |
| ORG_ADMIN | Vereinsadministrator | Geschäftsführung/HR-Admin | Vorstand/Geschäftsstelle |
| TEAM_MANAGER | Mannschaftsleiter | Teamlead | Projektleitung |
| TEAM_LEAD | Trainer | Fachlicher Lead | Einsatzleiter |
| SUPERVISOR | Betreuer | Mentor/Buddy | Betreuer:in |
| GUARDIAN | Eltern (bei Minderjährigen) | — (meist nicht relevant) | Erziehungsberechtigte (bei Jugendarbeit) |
| Chatgruppe/Matrix-Room | Mannschafts-/Abteilungschat | Team-Channel | Projekt-/Einsatzchat |
Die Sportverein-Beispiele (Abschnitte 2-4 unten) bleiben als durchgängiges Leitbeispiel stehen, weil sie die konkreteste/komplexeste Hierarchie abdecken (mehrere Mannschaften, Minderjährige, Saisons). Für Firma/NGO gilt dieselbe Struktur mit den Begriffen aus der Tabelle.
1. Produkt
Produktname: TalkTime
Vision: Datenschutzfreundliche, selbst hostbare Kommunikations- und Verwaltungsplattform für Sportvereine, die WhatsApp als Vereins-Kommunikationskanal ersetzt.
Zielgruppe: Sportvereine (Amateur-/Breitensport), Abteilungen, Mannschaften, Trainer, Eltern, Mitglieder — primär im deutschsprachigen Raum, DSGVO-relevant.
Problem:
- WhatsApp-Gruppen für Vereine sind datenschutzrechtlich problematisch (Kontaktabgleich, US-Anbieter, keine Vereinsstruktur-Abbildung).
- Klassische Vereinssoftware (z. B. Mitgliederverwaltung) bietet keine Echtzeit-Kommunikation.
- Kein Tool bildet Vereinsstruktur (Abteilung → Mannschaft → Mitglied) 1:1 auf Kommunikationsgruppen ab.
Lösung: Eigene Verwaltungsschicht über Matrix/Synapse. Verein denkt in Vereins-Objekten (Mitglied, Mannschaft, Rolle), Matrix bleibt unsichtbare Infrastruktur im Hintergrund.
USP:
- Automatische Gruppenzuordnung basierend auf Vereinsstruktur (kein manuelles Gruppenmanagement).
- Selbst hostbar, DSGVO-konform, keine Datenweitergabe an Dritte.
- Rollenmodell exakt auf Vereinsrealität zugeschnitten (Trainer, Betreuer, Abteilungsleiter, ...).
Abgrenzung zu WhatsApp: kein Kontaktabgleich mit Telefonbuch, keine Rufnummer als Identität nötig, Admin-gesteuerte Gruppenmitgliedschaft statt manuellem Hinzufügen, Datenhoheit beim Verein.
Abgrenzung zu klassischen Vereinssoftwares (z. B. Vereinsverwaltungen mit Mitgliederdatenbank): Fokus liegt auf Kommunikation in Echtzeit, nicht auf Beitragsverwaltung/Buchhaltung (bewusst nicht im MVP, siehe Abschnitt 5).
Zielmärkte: MVP für einzelne Sportvereine, Skalierung Richtung Verbände/Dachorganisationen (Multi-Tenant) als spätere Erweiterung.
2. Benutzerrollen
| Rolle | Beschreibung | Benötigt für MVP |
|---|---|---|
| SYSTEM_ADMIN | Betreiber der Plattform, verwaltet Vereine/Tenants, keine Vereinsdaten-Einsicht per Default | Ja |
| CLUB_ADMIN (Vereinsadministrator) | Voller Zugriff auf einen Verein, verwaltet Abteilungen/Mannschaften/Rollen/Mitglieder | Ja |
| CLUB_MANAGER (Vereinsmanager) | Wie CLUB_ADMIN, ohne Rechte-/Rollenvergabe an andere Admins (Privilege-Escalation-Schutz) | V1 |
| DEPARTMENT_ADMIN (Abteilungsleiter) | Verwaltet eine Abteilung inkl. deren Mannschaften | Ja |
| TEAM_MANAGER (Mannschaftsleiter) | Verwaltet eine Mannschaft (Mitglieder, Trainer zuweisen) | Ja |
| COACH (Trainer) | Kommunikation mit eigener Mannschaft, kein Verwaltungszugriff | Ja |
| ASSISTANT_COACH (Co-Trainer) | Wie Trainer, eingeschränkter | V1 |
| SUPERVISOR (Betreuer) | Begleitfunktion, Zugriff wie Co-Trainer auf zugewiesene Mannschaft | V1 |
| MEMBER (Mitglied/Spieler) | Teilnahme an zugewiesenen Gruppen, kein Verwaltungszugriff | Ja |
| PARENT (Eltern/Erziehungsberechtigte) | Stellvertretend für minderjährige Mitglieder, eingeschränkte Sicht | V1 (MVP: rudimentär) |
Rollen sind pro Verein und ggf. pro Abteilung/Mannschaft skopiert (nicht global außer SYSTEM_ADMIN/CLUB_ADMIN).
3. Vereinsstruktur
Hierarchie: Verein → Abteilung → Mannschaft → Mitgliedschaft (Saison-gebunden).
- Verein: Tenant-Wurzel, hat Name, Domain/Slug, Einstellungen, Matrix-Homeserver-Zuordnung.
- Abteilung: gehört zu genau einem Verein (z. B. Fußball, Handball).
- Mannschaft: gehört zu genau einer Abteilung, gehört zu einer Saison.
- Saison: zeitlich begrenzt (z. B. 2025/2026), Mannschaften/Mitgliedschaften sind saisongebunden für Wiedereintritt/Historie.
- Mitgliedschaft: verknüpft Mitglied mit Verein (immer), optional mit Mannschaft(en) und Rolle(n). Ein Mitglied kann mehrere Mannschaften und mehrere Rollen gleichzeitig haben (z. B. Spieler in Mannschaft A, Co-Trainer in Mannschaft B).
- Vorstand: als spezielle "Abteilung ohne Mannschaften" oder eigener Objekttyp — Empfehlung: als Abteilung ohne Mannschaftsebene modellieren, um Datenmodell nicht zu verzweigen (siehe architecture.md ADR).
4. Mitgliederverwaltung
Attribute: Vorname, Nachname, E-Mail, Telefon (optional), Geburtsdatum, Status (aktiv/inaktiv/gesperrt/ausgetreten), Matrix User ID.
Regeln:
- Minderjährige: Geburtsdatum bestimmt
is_minor. Für Minderjährige ist mind. ein Elternteil-Konto (PARENT) verknüpfbar; Einladungs-/Consent-Flow für Erziehungsberechtigte im V1. - Mehrere Mannschaften/Rollen: über separate Zuordnungstabellen (n:m), nicht über Felder am Mitglied.
- Vereinswechsel: Mitglied-Datensatz bleibt beim ursprünglichen Verein (Tenant-Grenze); Wechsel = Austritt + Neuanlage im Zielverein. Kein Cross-Tenant-Merge im MVP.
- Austritt: Status
left, Matrix-Raum-Mitgliedschaften werden entfernt, Matrix-Account wird deaktiviert (nicht gelöscht), Daten nach Aufbewahrungsfrist anonymisiert/gelöscht (siehe security.md/DSGVO). - Sperrung: Status
suspended, Login gesperrt, Matrix-Account deaktiviert, Daten bleiben (Reaktivierung möglich). - Löschung: harte Löschung nur auf expliziten Antrag (DSGVO-Auskunft/Löschbegehren) unter Beachtung gesetzlicher Aufbewahrungsfristen; Standardfall ist Anonymisierung.
- Wiedereintritt: neue Mitgliedschaft/Saison-Zuordnung, alte Matrix-ID wird nach Möglichkeit wiederverwendet (siehe Abschnitt Matrix User Provisioning), Historie bleibt nachvollziehbar.
5. MVP-Scope
MVP: Login, Verein anlegen, Vereinsadministrator, Mitglieder, Abteilungen, Mannschaften, Rollen (Kernrollen), Einladungen, Synapse-Verbindung, Matrix User Provisioning, Matrix-Räume, automatische Gruppenmitgliedschaft, grundlegender Chat (eingebetteter/verlinkter Matrix-Client), Audit Log, Tenant Isolation, Docker Deployment, Tests.
Nicht im MVP: Vereinsbuchhaltung, Beitragsverwaltung, Rechnungen, Ticketing, Vereins-ERP, Turnierverwaltung, Trainingsplanung, KI-Assistent, Videokonferenzen, PARENT-Rolle voll ausgebaut, ASSISTANT_COACH/SUPERVISOR als eigene Rolle (MVP: unter COACH/MEMBER subsumiert oder als V1 nachgezogen — siehe features/INDEX.md).
6. Priorisierung
- MVP: siehe oben.
- V1: PARENT-Rolle vollständig, ASSISTANT_COACH/SUPERVISOR getrennt, CLUB_MANAGER, Passwort-Reset/E-Mail-Verification vollständig, Sync-Resync-UI, erweiterte Audit-Log-Ansicht.
- V2: OIDC-Login, Push-Notifications, Medien-Retention-Policies, erweiterte Benachrichtigungssteuerung, PWA.
- Future: React-Native-App, Videokonferenzen-Integration, Vereins-Module (Beitragsverwaltung etc.) als Plugins.
7. Offene Annahmen (bis Starter-Kit-Analyse nachgeholt)
- Starter-Kit-Stack wie im Master-Prompt beschrieben: React+TS+Vite+Tailwind+shadcn/ui (Frontend), Fastify+TypeScript (Backend), Drizzle ORM, PostgreSQL. Nicht verifiziert — Repo lag beim Erstellen dieses Dokuments nicht lokal vor.
- Vorhandene Auth-Lösung des Starter-Kits unbekannt — Abschnitt 17 im Master-Prompt ("Untersuche zuerst die Authentifizierung") noch offen.
- Vorhandene Feature-/Skill-/Agent-Struktur des Starter-Kits unbekannt.
Nächster Schritt: Repository klonen, gegen dieses PRD abgleichen, Annahmen bestätigen oder korrigieren, dann architecture.md/Datenmodell verfeinern.