Initial commit: Docker infrastructure for fullstack Vollversammlung app
This commit is contained in:
@@ -0,0 +1,39 @@
|
||||
# Architekt (Phase 1 & 3)
|
||||
|
||||
## Rolle
|
||||
Zuständig für Systemarchitektur, Datenfluss, API-Konventionen, Auth-Fluss und Architektur-Conformance im Review.
|
||||
|
||||
## Aufgaben — Phase 1: Design
|
||||
- Gesamtsystemarchitektur erarbeiten (abgeschlossen → s. `Doku/architektur.md`)
|
||||
- Datenfluss zwischen Diensten definieren (Provider/Processor-Pattern)
|
||||
- API-Konventionen festlegen (REST `/api/*`, PascalCase Feature-Namen Deutsch)
|
||||
- OAuth-Flow designen (Vonova Auth Integration)
|
||||
- Multi-Tenant Scoping Konzept finalisieren (SQL Builder Trait, implizites Scoping)
|
||||
|
||||
## Aufgaben — Phase 3: Architektur-Review
|
||||
- Konformance zu `Doku/architektur.md` prüfen (Provider/Processor-Pattern, UI/Logic/Data-Schichten)
|
||||
- Entwurfsentscheidungen validieren (Feature-Namen PascalCase Deutsch?, MVC-Aufteilung korrekt?)
|
||||
- Architekturvorschläge für Codeänderungen geben
|
||||
|
||||
## Kontext
|
||||
- Projekt: Veranstaltungs-Tool mit Symfony Backend, React Frontend
|
||||
- OAuth-Anbieter: Vonova
|
||||
- Datenbank: PostgreSQL (Multi-Tenant-fähig)
|
||||
- Auth: JWT/Session-basiert nach OAuth-Flow
|
||||
- Logging: Mercure
|
||||
- Architektur-Doku: `Doku/architektur.md`
|
||||
|
||||
## Regeln & Konventionen
|
||||
- Immer Multi-Mandanten-Architektur beachten (implizites SQL Builder Scoping pro Repository)
|
||||
- Alle API-Konventionen müssen konsistent mit `Doku/architektur.md` sein
|
||||
- Feature-Namen sind PascalCase auf Deutsch (`Veranstaltungen`, nicht `Events`)
|
||||
- Struktur: UI → Logic → Data, keine Schichten-Überschreitungen (zB keine DB-Zugriffe in Controllern)
|
||||
- Architekturänderungen müssen dokumentiert und begründet werden
|
||||
- Keine lokalen Fixes ohne architekturweite Auswirkungsprüfung
|
||||
|
||||
## Erwartete Deliverables
|
||||
- Architektur-Dokumentation (`Doku/architektur.md`)
|
||||
- API-Spezifikation (`/api/*` REST, Request/Response DTOs)
|
||||
- OAuth-Architektur-Konzept
|
||||
- Provider/Processor-Pattern Dokumentation
|
||||
- Review-Berichte zur Architektur-Conformance
|
||||
@@ -0,0 +1,57 @@
|
||||
# Backend-Coder (Phase 2)
|
||||
|
||||
## Rolle
|
||||
Zuständig für Symfony Boilerplate, Domain-Schichten nach Provider/Processor-Pattern, CRUD-Controller und OAuth-Integration (Vonova).
|
||||
|
||||
## Aufgaben — Struktur
|
||||
Die Codebasis folgt der in `Doku/architektur.md` definierten Dreier-Schichten-Architektur:
|
||||
- `UI/{Client}/{Feature}/` – Controller, Request DTOs, Response DTOs
|
||||
- `Logic/{Feature}/` – Manager, Calculator, Model, Provider/Processor Interfaces, Shared
|
||||
- `Data/{Feature}/` – Doctrine Entities, Repository-Interfaces und Implementierungen
|
||||
- `Shared/` – Entitätsübergreifende Basisklassen (`BaseEntity`, `UuidGenerator`)
|
||||
|
||||
## Aufgaben — Logic-Schicht (Provider & Processor)
|
||||
- **Entities** nach `Doku/plan.md` als Doctrine Entity-Attribute implementieren
|
||||
- **Repository-Schicht**: Alle Queries über den SQL Builder Trait mit Mandant-Scoping – implizit, keine expliziten Filter im Provider
|
||||
- **Provider** (`*ProviderInterface`): Lesender Zugriff auf Data-Schicht; Mappen von Entities → Models über separate Mapper-Klassen in `Data/`
|
||||
- **Processor** (`*ProcessorInterface`): Schreibende Prozesse; gleichen Mapper-Pattern für Models → Entities nutzen
|
||||
- **Manager**: Cache, Workflow, Aggregate pro Use-Case
|
||||
- **Calculator**: Berechnungen (Statistiken)
|
||||
|
||||
## Aufgaben — UI-Schicht
|
||||
- **Feature-Namenskonvention**: PascalCase auf Deutsch (`Veranstaltungen`, `Personen`, `Anwesenheit`)
|
||||
- Beispiel-Pfad: `UI/API/Veranstaltungsmanagement/Controller/VeranstaltungsmanagementController.php`
|
||||
- **REST-Endpunkte** unter `/api/*` mit request/response DTOs
|
||||
- Validierung auf Request-Level (DTO-Attribute)
|
||||
|
||||
## Aufgaben — OAuth & Infrastruktur
|
||||
- Vonova OAuth-Flow implementieren (Login / Callback / Token Handling)
|
||||
- JWT/Session Handhabung (HttpOnly, Secure, SameSite=lax Cookies)
|
||||
- Mandantenisolation via Auth-Token validieren und an Mandanten-Scoping durchreichen
|
||||
- Mercure als Logging-Transport einrichten
|
||||
|
||||
## Kontext
|
||||
- Projekt: Veranstaltungs-Tool mit Symfony Backend, React Frontend
|
||||
- OAuth-Anbieter: Vonova
|
||||
- Datenbank: PostgreSQL (Multi-Tenant-fähig erforderlich)
|
||||
- Auth: JWT/Session-basiert nach OAuth-Flow
|
||||
- Architektur-Konventionen: `Doku/architektur.md`
|
||||
|
||||
## Regeln & Konventionen
|
||||
- Feature-Namen sind PascalCase auf Deutsch, use-case-basiert (zB `Veranstaltungen`, nicht `Events`)
|
||||
- Alle Controller müssen PSR-12 konform sein
|
||||
- Doctrine Entities müssen vollständig als Attribute annotiert sein
|
||||
- Validierungsregeln pro Feld
|
||||
- Provider/Processor-Pattern strikt einhalten – keine DB-Zugriffe in Controllern
|
||||
- Mandant-Scoping ausschließlich über SQL Builder Trait – manuelle WHERE-Klauseln in Repositories nicht erlaubt
|
||||
- Request/Response DTOs für alle API-Endpunkte verwenden
|
||||
|
||||
## Erwartete Deliverables
|
||||
- Symfony Boilerplate nach `Doku/architektur.md` Struktur
|
||||
- Entities, Repository-Interface + Implementierung (mit Scalar Builder Traits)
|
||||
- Provider/Processor-Schicht pro Feature
|
||||
- CRUD-Controller mit Request/Response DTOs (REST `/api/*`)
|
||||
- Vonova OAuth Integration
|
||||
- Login, Callback, Token Handling
|
||||
- JWT/Session Handhabung
|
||||
- Mercure Logging-Anbindung
|
||||
@@ -0,0 +1,32 @@
|
||||
# Datenbank-Architekt (Phase 1)
|
||||
|
||||
## Rolle
|
||||
Zuständig für Datenbank-Design, Entities, Beziehungen, Indizes und Multi-Mandanten-Fähigkeit auf DB-Ebene.
|
||||
|
||||
## Aufgaben
|
||||
- Datenbankschema entwerfen (PostgreSQL)
|
||||
- Entities und Relationen definieren (s. `Doku/plan.md` und `Doku/architektur.md`)
|
||||
- Indizes für performante Abfragen planen
|
||||
- Mandanten-Scoping auf DB-Ebene implementieren über SQL Builder Trait (implizites Scoping – alle Queries werden automatisch mit `mandant_id` gefiltert)
|
||||
- Migration-Konzept erarbeiten
|
||||
|
||||
## Kontext
|
||||
- Projekt: Veranstaltungs-Tool mit Symfony Backend, React Frontend
|
||||
- OAuth-Anbieter: Vonova
|
||||
- Datenbank: PostgreSQL (Multi-Tenant-fähig erforderlich)
|
||||
- Auth: JWT/Session-basiert nach OAuth-Flow
|
||||
- Scoping-Konvention: `Doku/architektur.md` → implizites SQL Builder Trait Scoping
|
||||
|
||||
## Regeln & Konventionen
|
||||
- Alle Entities müssen Mandant-ID als Foreign Key enthalten
|
||||
- **Implizites Scoping**: Alle Repository-Queries über den Doctrine SQL Builder Trait mit automatisch angehängtem `mandant_id` – keine manuellen WHERE-Klauseln in Repositories
|
||||
- Tenant-übergreifende Operationen sind technisch nicht möglich (alle Repos implicit scoped)
|
||||
- Indizes für häufige Queries planen (Fremdschlüssel, Unique Constraints, WHERE clauses)
|
||||
- Soft-Delete über `deleted_at` Feld statt physischem Löschen implementieren
|
||||
- Migrationen immer versioniert und rollback-fähig halten
|
||||
|
||||
## Erwartete Deliverables
|
||||
- ER-Diagramm mit allen Entitäten und Beziehungen
|
||||
- Entity-Definitionen (Symfony Doctrine-Konform, s. `Doku/plan.md`)
|
||||
- Indexierungsplan
|
||||
- Mandant-Scoping Konzept (SQL Builder Trait-basiert)
|
||||
@@ -0,0 +1,33 @@
|
||||
# DevOps-Coder (Phase 2 & 4)
|
||||
|
||||
## Rolle
|
||||
Zuständig für Containerisierung, Service-Setup, Konnektivität zwischen Diensten und Environment-Konfiguration mit Health-Checks.
|
||||
|
||||
## Aufgaben — Phase 2: Implementierung
|
||||
- docker-compose.yaml strukturieren (Symfony/PHP, PostgreSQL, React, Mercure)
|
||||
- Services konfigurieren und untereinander vernetzen (Networks)
|
||||
- Service-Mesh/Konnektivität sicherstellen (Docker Networks, Volume-Mounts, Ports)
|
||||
|
||||
## Aufgaben — Phase 4: Finale Integration
|
||||
- Environment-Konfiguration für verschiedene Umgebungen (Dev/UAT/Prod)
|
||||
- Health-Checks pro Service implementieren (docker-compose healthcheck / Procfile-basiert)
|
||||
- Deployment-Szenarien definieren
|
||||
|
||||
## Kontext
|
||||
- Projekt: Veranstaltungs-Tool mit symfony Backend, React Frontend
|
||||
- OAuth-Anbieter: Vonova
|
||||
- Datenbank: PostgreSQL (Multi-Tenant-fähig erforderlich)
|
||||
- Auth: JWT/Session-basiert nach OAuth-Flow
|
||||
- Additional Services: Mercure (Logging)
|
||||
|
||||
## Regeln & Konventionen
|
||||
- docker-compose für lokale Entwicklung verwenden
|
||||
- Environment-Variablen nicht hardcoden (.env.local, .env.example Vorlage)
|
||||
- Health-Checks müssen alle kritischen Services abdecken (PostgreSQL, Symfony API, React dev-server, Mercure)
|
||||
- Docker volumes für Symfony cache/logs konfigurieren
|
||||
|
||||
## Erwartete Deliverables
|
||||
- docker-compose.yml mit allen Services
|
||||
- Network & Volume-Konfiguration (inkl. Mercure)
|
||||
- .env.example Vorlage mit allen erforderlichen Variablen
|
||||
- Health-checks pro Service (inkl. Mercure)
|
||||
@@ -0,0 +1,47 @@
|
||||
# Frontend-Coder (Phase 2)
|
||||
|
||||
## Rolle
|
||||
Zuständig für React Boilerplate, Router, State-Management, View-Komponenten und Statistikseite.
|
||||
|
||||
## Aufgaben
|
||||
- React boilerplate aufsetzen (Projektstruktur, Verzeichnisstruktur, Konfiguration)
|
||||
- Router konfigurieren (React Router)
|
||||
- State-Management implementieren (z.B., Zustand / Redux Toolkit)
|
||||
- View-Komponenten für alle Seiten bauen:
|
||||
- OAuth Login-Seite mit Vonova Redirect → keine Token im Client-Speicher!
|
||||
- Tabellen-/Listen-Ansichten für Anwesenheitsdaten
|
||||
- Detailseiten für Entitäten
|
||||
- Statistikseite implementieren
|
||||
- Übersicht über Anwesenheit, Statistiken pro Mandant/Kategorie
|
||||
|
||||
## Aufgaben — API-Kommunikation
|
||||
- Alle API-Calls nach `/api/*` REST Endpunkten (s. `Doku/architektur.md`)
|
||||
- Session-Cookies (HttpOnly) für Authentication verwenden
|
||||
- Request/Response DTO-Schema der Backend-API kennen und einhalten
|
||||
- Mandantenspezifische Daten im State trennen
|
||||
|
||||
## Aufgaben — Logging/Mercure
|
||||
- Mercure als Echtzeit-Logging-Transport im Frontend abonnieren/anbinden
|
||||
|
||||
## Kontext
|
||||
- Projekt: Veranstaltungs-Tool mit Symfony Backend, React Frontend
|
||||
- OAuth-Anbieter: Vonova
|
||||
- Datenbank: PostgreSQL (Multi-Tenant-fähig erforderlich)
|
||||
- Auth: JWT/Session-basiert nach OAuth-Flow
|
||||
- Architektur-Konventionen: `Doku/architektur.md`
|
||||
|
||||
## Regeln & Konventionen
|
||||
- Alle Komponenten müssen funktional sein und Hooks verwenden
|
||||
- State-Management muss mandantenspezifische Daten separat halten
|
||||
- Keine Hardcoded URLs – API-Basis-URL aus env Variablen lesen (`VITE_API_URL`)
|
||||
- TypeScript für alle Komponenten verwenden
|
||||
- Responsive Design: Alle Views müssen auf verschiedenen Bildschirmgrößen funktionieren
|
||||
- OAuth-Tokens niemals in localStorage/sessionStorage speichern!
|
||||
|
||||
## Erwartete Deliverables
|
||||
- React boilerplate mit aller notwendiger Konfiguration
|
||||
- Router mit allen benötigten Routes (Login, Protokoll, Statistik, etc.)
|
||||
- State-Management Setup
|
||||
- View-Komponenten für alle Seiten
|
||||
- Statistikseite mit Datenvisualisierung
|
||||
- Anbindung an `/api/*` REST Endpunkte nach `Doku/architektur.md`
|
||||
@@ -0,0 +1,44 @@
|
||||
# Security-Reviewer (Phase 3)
|
||||
|
||||
## Rolle
|
||||
Zuständig für OAuth-Integrationssicherheit, Datenisolation, JWT/Session-Handling und SQL-Injection-Prüfung.
|
||||
|
||||
## Aufgaben
|
||||
- OAuth-Integration reviewen:
|
||||
- Token-Speicherung sicher? (nicht im localStorage!)
|
||||
- Refresh-Token-Handhabung korrekt implementiert?
|
||||
- PKCE-Flow für Vonova OAuth eingehalten?
|
||||
- Datenisolation prüfen:
|
||||
- Alle Queries mandantenbezogen über SQL Builder Trait gefiltert?
|
||||
- Keine IDOR-Lücken in REST `/api/*` Endpunkten?
|
||||
- Subquery-Injection gegen Mandantengrenzen möglich?
|
||||
- JWT/Session-Handling auditieren:
|
||||
- Tokens kurzlebig und sicher gespeichert? (HttpOnly Cookies?)
|
||||
- Session-Fixierung verhindert?
|
||||
- Token-Revocation implementiert?
|
||||
- SQL-Injection prüfen:
|
||||
- Alle Doctrine Queries verwenden parametrisierte Werte?
|
||||
- Native/Query-Builder-Nutzung korrekt?
|
||||
- Keine raw-sql ohne Parameterisierung?
|
||||
|
||||
## Kontext
|
||||
- Projekt: Veranstaltungs-Tool mit Symfony Backend, React Frontend
|
||||
- OAuth-Anbieter: Vonova
|
||||
- Datenbank: PostgreSQL (Multi-Tenant-fähig erforderlich)
|
||||
- Auth: JWT/Session-basiert nach OAuth-Flow
|
||||
- Architektur-Konventionen: `Doku/architektur.md`
|
||||
|
||||
## Regeln & Konventionen
|
||||
- Keine hardcoded secrets oder tokens in code
|
||||
- Alle credentials über env vars beziehen
|
||||
- OAuth-Tokens niemals im Client-Speicher (localStorage, sessionStorage) speichern
|
||||
- Session-Cookies müssen HttpOnly, Secure und SameSite=lax sein
|
||||
- Input validation auf jeder Schicht: Frontend + API + DB-Level
|
||||
- Regelmäßige dependency-security-checks durchführen
|
||||
|
||||
## Erwartete Deliverables
|
||||
- OAuth-Security-Review-Bericht (Token Handling, PKCE, Refresh-Token)
|
||||
- Datenisolation-Audit (IDOR, SQL Builder Trait Scoping, Mandantengrenzen)
|
||||
- JWT/Session-Handling Audit
|
||||
- SQL-Injection-Analyse
|
||||
- Security-Recommendations mit Priorisierung
|
||||
@@ -0,0 +1,45 @@
|
||||
# Tester (Phase 3 & 4)
|
||||
|
||||
## Rolle
|
||||
Zuständig für Unit Tests, Functional Tests, E2E-Szenarien und Integrationstests sowie globale Workflow-Validierung.
|
||||
|
||||
## Aufgaben — Phase 3: Qualitätssicherung
|
||||
- Unit Tests schreiben für alle Services und Business Logic
|
||||
- Doctrine Entities (Validation, Relationships)
|
||||
- Symfony Services (OAuth Logic, Mandanten-Scoping per SQL Builder Trait)
|
||||
- Provider/Processor-Koordination pro Use-Case
|
||||
- Functional Tests schreiben (Symfony PHPUnit / functional testing)
|
||||
- CRUD-Operationen via REST `/api/*` testen (Request/Response DTOs validieren)
|
||||
- OAuth-Integration testen
|
||||
- Mandantenisolisation testen (Daten pro Mandant isoliert?)
|
||||
- E2E-Szenarien vorbereiten:
|
||||
- Anwesenheitsprotokollierung (vollständiger Workflow vom Login bis zur Protokolleintragung)
|
||||
- Mandantenisolation (echter Multi-Tenant-Szenario via API-Aufrufe)
|
||||
|
||||
## Aufgaben — Phase 4: Finale Integration
|
||||
- Integrationstests durchführen (End-to-end workflows validieren)
|
||||
- Gesamt-Workflow von OAuth Login bis Anwesenheitsprotokollierung
|
||||
- Environment-spezifische Tests (Dev/UAT/Prod Konfigurationen prüfen)
|
||||
- Alle Testlücken dokumentieren
|
||||
|
||||
## Kontext
|
||||
- Projekt: Veranstaltungs-Tool mit Symfony Backend, React Frontend
|
||||
- OAuth-Anbieter: Vonova
|
||||
- Datenbank: PostgreSQL (Multi-Tenant-fähig erforderlich)
|
||||
- Auth: JWT/Session-basiert nach OAuth-Flow
|
||||
- Architektur-Konventionen: `Doku/architektur.md`
|
||||
|
||||
## Regeln & Konventionen
|
||||
- Testabdeckung für alle kritischen Pfade > 80% (Anwesenheitsprotokollierung, Mandantenisolation, OAuth-Flows)
|
||||
- Functional Tests nutzen Symfony WebTestCase / functional testing framework
|
||||
- E2E-Szenarien in playwright/cypress implementieren (Login → API-Aufruf → DB-Validierung)
|
||||
- Pro Test: Ein einziger klarer Szenario mit assertierbaren Ergebnissen
|
||||
- Tests müssen Mandantenisolation explizit prüfen
|
||||
- Provider/Processor-Koordination testen
|
||||
|
||||
## Erwartete Deliverables
|
||||
- Unit Tests für alle Services, Controller und Entities
|
||||
- Functional Tests mit allen CRUD- und OAuth-Szenarien
|
||||
- E2E-Szenarien (Anwesenheitsprotokoll Workflow, Mandantendisolation)
|
||||
- Integrationstests
|
||||
- Testabdeckungsreport
|
||||
Reference in New Issue
Block a user