talktime/claude.md

MASTER-PROMPT: VereinsChat – Kommunikationsplattform für Sportvereine

1. Rolle

Du bist ein Senior Software Architect, Product Engineer, Security Engineer und DevOps Engineer.

Du arbeitest in einem bestehenden Repository auf Basis des Projekts:

https://gitea.perlbach24.de/scripte/ai-coding-starter-kit-v2

Das bestehende Starter-Kit ist die technische Grundlage des Projekts.

Das Ziel ist der Aufbau einer professionellen, selbst hostbaren Kommunikations- und Verwaltungsplattform für Sportvereine.

Arbeitstitel des Produkts: VereinsChat

VereinsChat soll eine datenschutzfreundliche Alternative zu WhatsApp für Sportvereine werden.

Die eigentliche Kommunikation soll auf Matrix/Synapse basieren.

Für die Administration und Vereinslogik soll eine eigene Anwendung über der Synapse-Infrastruktur aufgebaut werden. 2. Wichtigste Regel

Arbeite NICHT sofort blind mit der Implementierung los.

Zuerst:

Repository vollständig analysieren.
Bestehende Architektur verstehen.
Bestehende Skills, Agents, Regeln und Workflows verstehen.
Vorhandene Funktionalität identifizieren.
Anforderungen für VereinsChat ausarbeiten.
Architektur definieren.
Datenmodell definieren.
API definieren.
Berechtigungsmodell definieren.
Synapse-Integration definieren.
Sicherheitsmodell definieren.
Deployment definieren.
Teststrategie definieren.
Feature-Roadmap erstellen.
Erst danach mit der Implementierung beginnen.

Bestehende Funktionen des Starter-Kits dürfen nicht unnötig überschrieben oder zerstört werden.

Nutze vorhandene Patterns des Starter-Kits. 3. Produktvision

VereinsChat soll die zentrale digitale Kommunikationsplattform eines Sportvereins werden.

Der Verein soll damit:

Mitglieder verwalten
Abteilungen verwalten
Mannschaften verwalten
Trainer verwalten
Betreuer verwalten
Rollen verwalten
Einladungen verschicken
Kommunikationsgruppen erstellen
Mitglieder automatisch Gruppen zuordnen
Matrix/Synapse-Benutzer verwalten
Matrix-Räume verwalten
Vereinskommunikation durchführen

können.

Der Benutzer soll möglichst wenig von Matrix oder Synapse wissen müssen.

Die technische Matrix-Infrastruktur soll im Hintergrund arbeiten.

Der Benutzer denkt in:

Verein
Abteilung
Mannschaft
Mitglied
Rolle
Gruppe

und nicht in:

Matrix Homeserver
Room IDs
Matrix IDs
Synapse Admin API

4. Technische Grundarchitektur

Verwende grundsätzlich folgende Architektur:

                ┌─────────────────────────┐
                │       VereinsChat       │
                │       Web Frontend      │
                │ React + TypeScript      │
                └────────────┬────────────┘
                             │
                             │ HTTPS
                             ▼
                ┌─────────────────────────┐
                │     VereinsChat API     │
                │ Fastify + TypeScript    │
                │                         │
                │ Auth                    │
                │ Vereine                 │
                │ Mitglieder              │
                │ Mannschaften            │
                │ Rollen                  │
                │ Gruppen                 │
                │ Invitations             │
                │ Synapse Integration     │
                └──────┬───────────┬──────┘
                       │           │
                       ▼           ▼
                PostgreSQL      Synapse
                                  │
                                  ▼
                               Matrix

PostgreSQL enthält die Vereins- und Verwaltungsdaten.

Synapse ist das Messaging-Backend.

Nachrichten sollen NICHT zusätzlich in der VereinsChat-Datenbank gespeichert werden.

Unsere Datenbank speichert lediglich die Zuordnung zwischen Vereinsobjekten und Matrix-Objekten. 5. Starter-Kit analysieren

Untersuche zuerst das komplette Repository.

Analysiere insbesondere:

package.json
Frontend-Struktur
Backend-Struktur
Datenbank
Drizzle
Fastify
React
Vite
Tailwind
shadcn/ui
Authentifizierung
vorhandene API-Struktur
vorhandene Komponenten
vorhandene Hooks
vorhandene Tests
Docker
CI/CD
Dokumentation
.claude
Agents
Skills
Rules
Features
vorhandene PRDs

Nutze die vorhandene Projektstruktur als Grundlage.

Wenn das Starter-Kit bereits eine Funktionalität besitzt, die wir benötigen, soll diese wiederverwendet und nicht neu erfunden werden. 6. Product Requirements Document

Erstelle bzw. erweitere:

docs/PRD.md

Das PRD muss VereinsChat vollständig beschreiben.

Es soll mindestens folgende Kapitel enthalten: Produkt

Produktname
Vision
Zielgruppe
Problem
Lösung
USP
Zielmärkte
Abgrenzung zu WhatsApp
Abgrenzung zu klassischen Vereinssoftwares

Benutzer

Beschreibe:

Vereinsadministrator
Vereinsmanager
Abteilungsleiter
Mannschaftsleiter
Trainer
Co-Trainer
Betreuer
Spieler
Mitglied
Eltern/Erziehungsberechtigte
Systemadministrator

Prüfe, welche Rollen tatsächlich benötigt werden. 7. Vereinsstruktur

Das System muss hierarchische Vereinsstrukturen unterstützen.

Beispiel:

Sportverein │ ├── Abteilung Fußball │ │ │ ├── 1. Herren │ ├── 2. Herren │ ├── A-Jugend │ ├── B-Jugend │ └── C-Jugend │ ├── Abteilung Handball │ │ │ ├── Damen │ └── Herren │ └── Vorstand

Definiere:

Verein
Abteilung
Mannschaft
Saison
Mitgliedschaft
Rollen
Zuständigkeiten

8. Mitgliederverwaltung

Entwickle ein vollständiges Konzept für Mitglieder.

Ein Mitglied soll beispielsweise folgende Eigenschaften besitzen:

Vorname Nachname E-Mail Telefon Geburtsdatum Status Rolle Abteilung Mannschaft Matrix User ID

Prüfe insbesondere:

Minderjährige
Eltern
mehrere Mannschaften
mehrere Rollen
Vereinswechsel
Austritt
Sperrung
Löschung
Wiedereintritt

Datenschutz muss berücksichtigt werden. 9. Matrix / Synapse Integration

Synapse ist das Messaging-System.

Entwickle eine saubere Integration über die Synapse Admin API.

Wichtig:

Der Browser darf niemals direkt auf die Synapse Admin API zugreifen.

Stattdessen:

Browser │ ▼ VereinsChat Backend │ ▼ Synapse Admin API

Das Synapse Admin Token darf niemals an den Client gelangen.

Definiere eine eigene:

SynapseService

bzw. geeignete Service-/Adapter-Struktur.

Diese muss beispielsweise unterstützen:

Benutzer anlegen
Benutzer suchen
Benutzer deaktivieren
Benutzer aktivieren
Benutzerinformationen abrufen
Räume erstellen
Räume verwalten
Benutzer zu Räumen hinzufügen
Benutzer aus Räumen entfernen
Rollen/Berechtigungen verwalten
Synchronisation
Health Check

Nutze die offizielle aktuelle Synapse-Dokumentation als Referenz.

Wenn sich APIs zwischen Synapse-Versionen unterscheiden, dokumentiere die verwendete Version. 10. Matrix User Provisioning

Wenn ein Vereinsmitglied einen Account erhält:

Vereinsmitglied │ ▼ VereinsChat Account │ ▼ Matrix Account

Die Matrix-ID soll nach einem definierten Schema erzeugt werden.

Beispiel:

@max.mustermann:chat.vereinschat.de

Entwickle Regeln für:

Namenskonflikte
Umbenennung
E-Mail-Änderung
Löschung
Deaktivierung
Wiederaktivierung
Datenschutz
Migration

Matrix User IDs dürfen nicht leichtfertig geändert werden. 11. Chatgruppen / Räume

VereinsChat soll automatisch Kommunikationsräume verwalten.

Beispiel:

SV Musterstadt

#verein #vorstand #fussball #fussball-1-herren #fussball-2-herren #fussball-a-jugend #handball #handball-damen

Entwickle Regeln dafür, wann ein Raum automatisch erstellt wird.

Beispiel:

Mannschaft erstellt ↓ Matrix Raum erstellen ↓ Trainer hinzufügen ↓ Mitglieder hinzufügen

Wenn ein Mitglied aus einer Mannschaft entfernt wird:

Mitglied entfernt ↓ VereinsChat aktualisieren ↓ Matrix Membership aktualisieren

12. Synchronisierung

Entwickle eine robuste Synchronisationslogik.

Es muss verhindert werden, dass beispielsweise:

VereinsChat sagt: Max ist Mitglied

Synapse sagt: Max existiert nicht

oder:

VereinsChat: Max ist nicht mehr in Mannschaft A

Synapse: Max ist weiterhin Mitglied im Raum

Entwickle deshalb:

Sync Jobs
Reconciliation
Retry
Idempotenz
Fehlerzustände
Audit Logs
manuellen Resync
Health Checks

13. Rollen und Berechtigungen

Implementiere ein sauberes RBAC-System.

Beispiel:

SYSTEM_ADMIN CLUB_ADMIN CLUB_MANAGER DEPARTMENT_ADMIN TEAM_MANAGER COACH ASSISTANT_COACH SUPERVISOR MEMBER PARENT

Definiere exakt:

wer Benutzer anlegen darf
wer Benutzer löschen darf
wer Mannschaften erstellen darf
wer Gruppen erstellen darf
wer Mitglieder hinzufügen darf
wer Mitglieder entfernen darf
wer Rollen vergeben darf
wer Vereinsdaten bearbeiten darf

Verhindere Privilege Escalation.

Ein Trainer darf beispielsweise nicht automatisch Vereinsadministrator werden können. 14. Multi-Tenant Architektur

VereinsChat soll mehrere Vereine unterstützen.

Beispiel:

VereinsChat │ ├── Verein A ├── Verein B ├── Verein C └── Verein D

Alle Daten müssen tenant-sicher getrennt sein.

Definiere:

Tenant ID
Datenbankmodell
Authorization
API Guards
Query Scoping
Audit Logs
Tenant Isolation

Ein Benutzer darf niemals Daten eines anderen Vereins sehen können. 15. Dashboard

Entwickle ein modernes Admin Dashboard.

Es soll mindestens enthalten:

Dashboard

Mitglieder Abteilungen Mannschaften Chatgruppen Einladungen Aktivitäten Systemstatus

Beispiel:

┌─────────────────────────────────────────────┐ │ SV Musterstadt │ ├─────────────────────────────────────────────┤ │ │ │ Mitglieder 438 │ │ Mannschaften 24 │ │ Chatgruppen 31 │ │ Einladungen 7 │ │ │ │ Letzte Aktivitäten │ │ │ └─────────────────────────────────────────────┘

16. Einladungen

Entwickle ein vollständiges Invitation-System.

Ablauf:

Administrator │ ▼ E-Mail-Adresse │ ▼ Einladung │ ▼ Link │ ▼ Account erstellen │ ▼ Matrix Account │ ▼ Vereinsgruppen

Definiere:

Token
Ablaufzeit
Wiederverwendung
Widerruf
E-Mail
Status
Audit Log
Fehlerfälle

17. Authentifizierung

Untersuche zunächst die Authentifizierung des Starter-Kits.

Erweitere sie nur, wenn erforderlich.

Entwickle:

Login
Logout
Session
Passwort Reset
E-Mail Verification
MFA als spätere Option
Rollenprüfung

Die Matrix-Authentifizierung und die VereinsChat-Authentifizierung müssen sauber voneinander getrennt werden.

Prüfe, ob OIDC sinnvoll ist. 18. Datenschutz / DSGVO

Datenschutz ist ein Kernbestandteil des Projektes.

Definiere:

personenbezogene Daten
Zweckbindung
Datenminimierung
Löschung
Deaktivierung
Export
Auditierung
Aufbewahrungsfristen
Backups
Log-Daten
IP-Adressen
E-Mail-Adressen
Telefonnummern

Insbesondere Minderjährige müssen berücksichtigt werden.

Es darf keine Funktion gebaut werden, die personenbezogene Daten unnötig kopiert. 19. Sicherheit

Führe ein Security Design durch.

Berücksichtige:

OWASP
SQL Injection
XSS
CSRF
SSRF
IDOR
Broken Access Control
Rate Limiting
Session Security
Secrets
API Tokens
Password Security
Audit Logs
Brute Force
Enumeration
Upload Security

Das Synapse Admin Token darf niemals:

im Frontend
im Browser
in Logs
in API Responses
in Git

auftauchen. 20. Medien und Dateien

Matrix soll für Kommunikation und Medien genutzt werden.

Prüfe:

Bilder
Videos
PDFs
Dokumente
Dateigrößen
MIME Types
Upload Limits
Virenscanner
Storage
Retention

Entscheide, was durch Synapse und was durch VereinsChat verwaltet werden sollte. 21. Benachrichtigungen

Konzipiere:

In-App Notifications
Push
E-Mail
wichtige Vereinsnachrichten
Einladungen
Systemmeldungen

Nicht jede Matrix-Nachricht muss zwingend durch das VereinsChat-Backend verarbeitet werden.

Nutze Matrix-Funktionalität, wo sinnvoll. 22. Audit Log

Entwickle ein Audit-System.

Beispiel:

Administrator ↓ Mitglied gelöscht

Administrator ↓ Trainerrolle vergeben

Administrator ↓ Mannschaft erstellt

System ↓ Matrix Raum erstellt

Audit Logs müssen nachvollziehbar und vor Manipulation geschützt sein. 23. Fehlerbehandlung

Definiere Fehlerzustände zwischen:

VereinsChat ↕ Synapse

Beispiel:

Raum konnte nicht erstellt werden

Das darf nicht dazu führen, dass die Mannschaftserstellung komplett unkontrolliert fehlschlägt.

Verwende:

Transactions
Jobs
Retries
Outbox Pattern, falls sinnvoll
Idempotency
Statusfelder

24. Datenmodell

Erstelle ein vollständiges relationales Datenmodell.

Mindestens prüfen:

clubs users club_members roles permissions departments teams seasons team_members invitations chat_rooms chat_room_memberships synapse_users sync_jobs audit_logs notifications

Normalisiere sinnvoll.

Nutze Drizzle ORM gemäß dem Starter-Kit. 25. API

Entwickle eine konsistente REST API.

Beispielsweise:

/api/auth /api/clubs /api/members /api/departments /api/teams /api/seasons /api/invitations /api/chat /api/rooms /api/synapse /api/audit

Definiere:

Request
Response
Validation
Authorization
Errors
Pagination
Filtering
Sorting

Verwende TypeScript-Typen und Schema Validation. 26. Frontend

Verwende die im Starter-Kit vorhandene Technologie.

Grundsätzlich:

React
TypeScript
Vite
Tailwind
shadcn/ui

Das UI soll professionell, modern und einfach bedienbar sein.

Designziel:

modern ruhig sportlich übersichtlich mobile-friendly barrierearm

Kein überladenes Enterprise-UI. 27. Chat Client

Prüfe sorgfältig, wie der eigentliche Matrix-Chat integriert werden soll.

Mögliche Strategien:

vorhandenen Matrix Client integrieren
Matrix Client einbetten
eigene Chat-Oberfläche mit Matrix SDK
Kombination

Vergleiche die Varianten hinsichtlich:

Entwicklungsaufwand
Sicherheit
UX
E2EE
Wartbarkeit
Mobile
Push
Medien
Threads
Reaktionen

Treffe anschließend eine begründete Architekturentscheidung. 28. Mobile

Die Plattform soll perspektivisch:

Desktop
Tablet
Smartphone

unterstützen.

Prüfe:

PWA
responsive Web
React Native
Expo
bestehende Matrix Mobile Clients

Für MVP möglichst keine unnötige zweite Codebasis erzeugen. 29. Deployment

Entwickle ein Deployment-Konzept.

Mindestens:

Reverse Proxy │ ├── VereinsChat Web │ ├── VereinsChat API │ └── Synapse │ └── PostgreSQL

Prüfe:

Docker Compose
Produktionsbetrieb
TLS
Domains
Secrets
Backups
Updates
Monitoring
Logging

30. Beispiel Deployment

Entwickle beispielsweise:

chat.verein.de admin.verein.de api.verein.de

oder eine geeignetere Struktur.

Für lokale Entwicklung:

docker compose

mit:

postgres synapse vereinschat-api vereinschat-web

31. Observability

Definiere:

Health Check
Readiness
Liveness
Application Logs
Error Tracking
Metrics
Synapse Health
Database Health
Sync Status

Beispielsweise:

GET /health GET /ready GET /metrics

32. Tests

Entwickle eine vollständige Teststrategie.

Mindestens: Unit Tests

Für:

Services
Permissions
Rollen
Sync Logic
Validierung

Integration Tests

Für:

PostgreSQL
Fastify API
Synapse Integration

E2E Tests

Für:

Verein erstellen ↓ Mitglied erstellen ↓ Mannschaft erstellen ↓ Matrix User erstellen ↓ Matrix Raum erstellen ↓ Mitglied hinzufügen

Security Tests

Für:

Tenant Isolation
RBAC
IDOR
Authentication
Authorization

33. Feature-System des Starter-Kits verwenden

Nutze die bestehende Feature-Struktur des Starter-Kits.

Erstelle einen Feature-Index:

features/INDEX.md

und anschließend einzelne Features.

Beispiel:

features/ ├── PROJ-001-project-foundation.md ├── PROJ-002-authentication.md ├── PROJ-003-club-management.md ├── PROJ-004-member-management.md ├── PROJ-005-role-management.md ├── PROJ-006-departments.md ├── PROJ-007-teams.md ├── PROJ-008-seasons.md ├── PROJ-009-invitations.md ├── PROJ-010-synapse-integration.md ├── PROJ-011-matrix-users.md ├── PROJ-012-matrix-rooms.md ├── PROJ-013-membership-sync.md ├── PROJ-014-chat.md ├── PROJ-015-audit-log.md ├── PROJ-016-notifications.md └── ...

Jedes Feature muss enthalten:

Problem Ziel Scope Nicht im Scope User Stories Acceptance Criteria Datenmodell API Frontend Backend Security Tests Dependencies Definition of Done

34. Priorisierung

Ordne Features in: MVP

Nur absolut notwendige Funktionen. V1

Wichtige produktionsreife Funktionen. V2

Erweiterungen. Future

Optionale Funktionen.

MVP soll möglichst klein bleiben. 35. MVP

Das MVP soll mindestens können:

✓ Login ✓ Verein anlegen ✓ Vereinsadministrator ✓ Mitglieder ✓ Abteilungen ✓ Mannschaften ✓ Rollen ✓ Einladungen ✓ Synapse Verbindung ✓ Matrix User Provisioning ✓ Matrix Räume ✓ automatische Gruppenmitgliedschaft ✓ grundlegender Chat ✓ Audit Log ✓ Tenant Isolation ✓ Docker Deployment ✓ Tests

36. Nicht im MVP

Nicht ungefragt riesige Zusatzfeatures bauen.

Beispielsweise zunächst nicht:

komplexe Vereinsbuchhaltung
Beitragsverwaltung
Rechnungen
Ticketing
vollständige Vereins-ERP-Funktionen
Turnierverwaltung
Trainingsplanung
KI-Assistent
Videokonferenzen

Diese können später als Module kommen. 37. Architekturentscheidungen

Erstelle:

docs/architecture.md

Dokumentiere darin alle wichtigen Entscheidungen.

Beispielsweise:

ADR-001 Matrix als Messaging Backend

ADR-002 Synapse Admin API nur Backend-seitig

ADR-003 PostgreSQL für Vereinsdaten

ADR-004 Multi-Tenant Architektur

ADR-005 Matrix IDs werden persistent gespeichert

ADR-006 Synchronisierung über Jobs

ADR-007 Chat Client Strategie

Jede Entscheidung muss begründet werden. 38. Technische Risiken

Erstelle:

docs/risks.md

Analysiere insbesondere:

Synapse API Änderungen
Matrix E2EE
Benutzer-Provisionierung
Room Management
Synchronisierung
Tenant Isolation
DSGVO
Minderjährige
Medien-Storage
Push Notifications
Mobile Apps
Migration

Bewerte:

Risiko Wahrscheinlichkeit Auswirkung Mitigation

39. Security Dokumentation

Erstelle:

docs/security.md

Dokumentiere:

Trust Boundaries
Secrets
Authentication
Authorization
RBAC
Tenant Isolation
Synapse Admin API
API Security
Logging
Datenschutz
Backups
Incident Response

40. Deployment Dokumentation

Erstelle:

docs/deployment.md

Beschreibe:

lokale Entwicklung
Docker
Environment Variables
PostgreSQL
Synapse
Reverse Proxy
TLS
Backup
Restore
Updates
Monitoring

41. Environment Variables

Definiere ein sauberes Schema.

Beispielsweise:

DATABASE_URL=

SYNAPSE_BASE_URL= SYNAPSE_ADMIN_TOKEN=

APP_BASE_URL= API_BASE_URL=

SESSION_SECRET=

SMTP_HOST= SMTP_PORT= SMTP_USER= SMTP_PASSWORD=

Keine Secrets committen.

Erstelle:

.env.example

42. Migrationen

Alle Datenbankänderungen müssen über Drizzle Migrationen erfolgen.

Keine manuellen Änderungen an Produktionsdatenbanken. 43. Codequalität

Halte dich strikt an:

TypeScript strict
bestehende Linter
Formatter
bestehende Coding Standards
kleine Module
Dependency Injection, wo sinnvoll
klare Services
keine unnötigen Singletons
keine God Classes
keine Copy/Paste-Architektur

44. Keine unnötige Komplexität

YAGNI beachten.

Nicht jede mögliche Enterprise-Funktion implementieren.

Die Architektur soll erweiterbar sein, aber der MVP soll überschaubar bleiben. 45. Dokumentationspflicht

Jede größere technische Entscheidung muss dokumentiert werden.

Jedes Feature muss nachvollziehbar sein.

Wenn du eine Entscheidung triffst, dokumentiere:

Warum? Welche Alternativen? Warum verworfen? Welche Konsequenzen?

46. Arbeitsweise

Arbeite iterativ.

Nach der Analyse: Schritt 1

Repository analysieren. Schritt 2

PRD erstellen. Schritt 3

Architektur erstellen. Schritt 4

Datenmodell erstellen. Schritt 5

Feature Backlog erstellen. Schritt 6

MVP priorisieren. Schritt 7

Foundation implementieren. Schritt 8

Synapse Integration implementieren. Schritt 9

Vereinsverwaltung implementieren. Schritt 10

Chat Integration implementieren. Schritt 11

Tests implementieren. Schritt 12

Deployment implementieren. 47. Autonomie

Du darfst selbstständig:

Dateien erstellen
Dateien ändern
Code refactoren
Tests erstellen
Dokumentation erstellen
Migrationen erstellen
Docker-Konfiguration erstellen

Du darfst jedoch keine bestehende Funktionalität ohne Grund entfernen.

Bei widersprüchlichen Anforderungen:

bestehende Projektregeln beachten
Sicherheit priorisieren
Datenintegrität priorisieren
Architektur dokumentieren
sinnvolle Entscheidung treffen

Nicht bei jeder Kleinigkeit nachfragen. 48. Externe Dokumentation

Für technische Aussagen über Synapse/Matrix darfst du nicht ausschließlich auf dein vorhandenes Wissen zurückgreifen.

Nutze die aktuelle offizielle Dokumentation.

Insbesondere:

Synapse Admin API
Matrix Client-Server API
Matrix Room API
Matrix Authentication
Matrix E2EE
Synapse Configuration
Synapse Security

Versionen müssen berücksichtigt werden. 49. Definition of Done

Ein Feature ist erst fertig, wenn:

✓ Anforderungen erfüllt ✓ Backend implementiert ✓ Frontend implementiert ✓ Validation vorhanden ✓ Authorization vorhanden ✓ Security geprüft ✓ Tests vorhanden ✓ Migration vorhanden, falls erforderlich ✓ Dokumentation vorhanden ✓ Fehlerbehandlung vorhanden ✓ Logging vorhanden, falls erforderlich ✓ keine TypeScript-Fehler ✓ Linter erfolgreich ✓ Tests erfolgreich

50. Erste Aufgabe

Beginne NICHT mit dem Coding.

Führe zunächst eine vollständige Analyse des vorhandenen Repositories durch.

Erstelle danach:

docs/PRD.md docs/architecture.md docs/security.md docs/deployment.md docs/risks.md features/INDEX.md

Erstelle außerdem das initiale Feature-Backlog.

Gib nach der Analyse einen Bericht aus mit:

Bestehende Architektur
Wiederverwendbare Komponenten
Fehlende Komponenten
Empfohlene Zielarchitektur
Datenmodell
Synapse-Integrationsstrategie
Sicherheitsmodell
Multi-Tenant-Modell
MVP
V1
V2
Risiken
Feature-Backlog
Implementierungsreihenfolge

Erst wenn diese Grundlage erstellt wurde, beginne mit der Implementierung. 51. Wichtig: Produktqualität

VereinsChat soll kein Demo-Projekt werden.

Behandle das Projekt als reale produktive SaaS-/Self-Hosted-Anwendung.

Code muss:

wartbar
testbar
sicher
nachvollziehbar
erweiterbar
dokumentiert

sein.

Die Plattform soll später von vielen Vereinen eingesetzt werden können. 52. Zielbild

Am Ende soll ein Vereinsadministrator eine Plattform sehen, die ungefähr folgendes ermöglicht:

VereinsChat

SV Musterstadt

Dashboard │ ├── Mitglieder │ ├── Abteilungen │ ├── Fußball │ ├── Handball │ └── Volleyball │ ├── Mannschaften │ ├── 1. Herren │ ├── 2. Herren │ └── A-Jugend │ ├── Chatgruppen │ ├── Verein │ ├── Vorstand │ ├── Fußball │ └── 1. Herren │ ├── Einladungen │ ├── Rollen & Rechte │ ├── Aktivitäten │ └── Einstellungen

Der normale Benutzer bekommt dagegen eine einfache Kommunikationsoberfläche:

VereinsChat

Chats

📢 Verein ⚽ Fußball ⚽ 1. Herren 👥 Trainer 💬 Max Müller

          Nachrichten
          Bilder
          Dateien
          Reaktionen

Die Komplexität von Synapse/Matrix bleibt im Hintergrund. 53. Endziel

Baue keine reine Admin-Oberfläche für Synapse.

Baue eine: Vereinsplattform mit integrierter Matrix-Kommunikation.

Synapse ist die technische Messaging-Infrastruktur.

VereinsChat ist das eigentliche Produkt.

Die wichtigste Abstraktion lautet:

Verein ↓ Abteilung ↓ Mannschaft ↓ Mitglied ↓ Kommunikationsgruppe ↓ Matrix Room

Diese Abstraktion muss sich durch die gesamte Architektur ziehen.

Beginne jetzt mit der Repository-Analyse und erstelle anschließend die oben definierten Dokumente und das Feature-Backlog.

Damit hast du einen Prompt, der den Agenten nicht nur zum Programmieren, sondern zum kompletten Ausarbeiten des Produkts zwingt. Besonders wichtig finde ich dabei die Trennung „VereinsChat verwaltet den Verein / Synapse verwaltet die Kommunikation“. Dadurch bleibt die Architektur sauber und wir können später sogar verschiedene Matrix/Synapse-Deployments dahinter betreiben.