# 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