feat(repairs): add repair management foundation

ARCHITECTURE.md

@@ -177,6 +177,7 @@ Beispiele:
 - Kundenstatistiken nur mit `customers.read`
 - Benutzerstatistiken nur mit `users.read`
 - Rollenstatus nur mit `roles.read`
+- Reparaturkennzahlen nur mit `repairs.read`
 
 Nicht vorhandene Module wie Aufgaben, Tickets oder Projekte werden nicht mit Fake-Daten gefuellt. Stattdessen liefert das Dashboard leere Widgets mit klarer Meldung.
 
@@ -188,6 +189,60 @@ Athena ruft `GET /api/activity-feed` auf. Die BFF-Route ruft serverseitig Hermes
 
 Der Feed basiert auf persistenten Audit Logs und zeigt die letzten relevanten Aktivitaeten. Hermes filtert die Eintraege anhand der Berechtigungen des aktuellen Benutzers. Ein Benutzer sieht dadurch nur Aktivitaeten zu Bereichen, fuer die er Leserechte besitzt.
 
+## Reparaturmanagement
+
+Das Modul `Reparaturen` verwaltet interne Werkstattvorgaenge. Es liegt fachlich in Hermes und wird im Browser ausschliesslich ueber Athena erreicht.
+
+Datenfluss:
+
+```text
+Browser -> Athena /api/repairs... -> Hermes /repairs... -> PostgreSQL
+```
+
+Kernfunktionen:
+
+- Reparaturen manuell anlegen und bearbeiten
+- eindeutige Reparaturnummer im Format `R<jahr>-<laufende nummer sechsstellig>`, z. B. `R2026-000001`
+- Statusmodell von `new` bis `completed` oder `cancelled`
+- Statushistorie in `repair_status_history`
+- Audit Logs fuer Erstellung, Bearbeitung, Statuswechsel, Storno und Intake
+- Dashboard-Kennzahlen fuer neue Reparaturen, Diagnose, wartende Kundenfreigaben und abgeschlossene Reparaturen
+
+Tabellen:
+
+- `repairs`
+- `repair_status_history`
+- `repair_intake_events`
+- `repair_documents`
+
+Hermes-Endpunkte:
+
+- `GET /repairs`
+- `GET /repairs/{id}`
+- `POST /repairs`
+- `PUT /repairs/{id}`
+- `DELETE /repairs/{id}` als fachliches Storno
+- `PUT /repairs/{id}/status`
+- `GET /repairs/{id}/history`
+
+Athena-BFF-Routen spiegeln diese Endpunkte unter `/api/repairs...`. Mutierende Athena-Routen behalten die Same-Origin-Pruefung bei.
+
+### Website Repair Intake
+
+Hermes stellt `POST /public/repair-intake` fuer eine spaetere serverseitige Website-Anbindung bereit.
+
+Sicherheitsmodell:
+
+- keine Browser-Cookie- oder JWT-Authentifizierung
+- Token per Header `X-Olympus-Intake-Token`
+- Token aus `OLYMPUS_REPAIR_INTAKE_TOKEN`
+- keine CORS-Freigabe fuer Browser erforderlich
+- Token wird nicht geloggt
+
+Der Intake speichert immer ein `repair_intake_events`-Ereignis und erzeugt bei erfolgreicher Verarbeitung einen Reparaturdatensatz mit `source = website` und `status = new`.
+
+Eine spaetere Kundenportal-Statusseite ist architektonisch vorbereitet, aber noch nicht oeffentlich implementiert.
+
 ## RBAC: Rollen und Berechtigungen
 
 Olympus verwendet ein serverseitiges RBAC-System als Grundlage fuer alle CRM-Module.
@@ -774,6 +829,9 @@ docker-compose.yml
 `KNOWLEDGE_MAX_UPLOAD_MB`
 : Legacy-Fallback fuer die maximale Knowledge-Uploadgroesse.
 
+`OLYMPUS_REPAIR_INTAKE_TOKEN`
+: Server-zu-Server Token fuer `POST /public/repair-intake`. Dieser Wert darf nicht im Frontend oder in Logs erscheinen.
+
 ### Athena
 
 `HERMES_INTERNAL_URL`