Rider Issue Reports

Ein Rider tippt in der Mobile App auf "Report an Issue", knipst ein Foto eines wackelnden Lenkers und sendet ab. Dreissig Sekunden spaeter brummt das Smartphone des richtigen Tech mit einem repair-Task, der genau an dieses Fahrzeug gepinnt ist. Das ist der Rider Issue Flow.

Wo das in der Rider App lebt

Der Screen ist ReportIssueScreen.tsx im Ordner mobile-app/src/screens/main/. Rider erreichen ihn ueber:

• Den Post-Ride-Confirmation-Screen ("How was your ride? Report an issue")
• Das Safety-Menue waehrend einer aktiven Fahrt
• Die Fahrzeug-Detailseite vor dem Unlock

Der Screen hat vier Eingaben:

1. Category Picker - mechanical, electrical, cosmetic, safety, lost_and_found, cleanliness
2. Severity - minor, moderate, severe (Selbsteinschaetzung des Riders)
3. Description - Freitextfeld
4. Photos - bis zu 4 Anhaenge aus Kamera oder Library

Das Submit POSTet an /api/rider-issues mit dem Auth-Token des Riders und dem Kontext der aktiven oder eben beendeten Fahrt.

Was serverseitig passiert

Die Route /api/rider-issues macht in dieser Reihenfolge drei Dinge:

1. Schreibt eine rider_issues-Zeile mit Category, Severity, Description, Photos und Ride-Context
2. Ruft den Handler onRiderIssueSubmitted der Rule Engine auf
3. Der Handler sucht jede aktive Regel mit trigger_type = 'rider_issue' und erstellt einen Task

Die Regel, die Rider Issues behandelt, sieht so aus:

{
  "trigger_type": "rider_issue",
  "trigger_config": { "category": "mechanical" },
  "task_type": "repair",
  "default_priority": "high",
  "action_config": {
    "assign_by_proximity": true,
    "change_vehicle_status": "maintenance"
  }
}

Sie koennen eine Regel pro Category schreiben (mechanical, electrical, etc.) oder eine Catch-All-Regel. Die Dedup-Logik verhindert doppelte offene Tasks gegen dasselbe Fahrzeug.

KI-Schweregradeskalation

Haengt der Rider ein Foto an, laesst die Rule Engine es durch einen KI-Schweregradklassifikator laufen. Der Klassifikator bewertet den Schaden auf einer 1-5-Skala, und:

• Schweregrad 4 oder hoeher hebt die Task Priority auf critical, unabhaengig vom Default der Regel
• Schweregrad 5 loest zusaetzlich sofort den Auto-Flip auf maintenance aus

Die KI-Bewertung wird in task_photos.ai_severity gespeichert und auf der Dashboard-Task-Detail-Seite angezeigt, damit der Ops Manager sie pruefen kann. False Positives sind selten, aber nicht null - das Modell ist konservativ getunt (eher "alles in Ordnung" als "kaputt"), um Alarmmuedigkeit zu vermeiden.

Was der Rider nach dem Submit sieht

Der Rider sieht einen Bestaetigungsscreen mit:

• "Thanks - we got it"
• Eine gekuerzte Task-ID zur Referenz
• Eine geschaetzte Time-to-Resolution basierend auf der SLA-Konfiguration

Hat der Rider E-Mail-Benachrichtigungen aktiviert, bekommt er zusaetzlich eine E-Mail, sobald der Task auf verified geht, damit er weiss, dass das Fahrzeug wieder im Betrieb ist.

Triage Queue (Phase-5-Roadmap)

Aktuell erzeugt jedes Rider Issue sofort einen Task. Die Phase-5-Roadmap fuegt eine Triage Queue hinzu, die Rider Issues 60 Sekunden lang haelt, bevor der Task entsteht, damit Ops offensichtlichen Muell abfangen kann (Duplikate, Vandalismus-Meldungen ohne Foto, versehentliche Submits). Bis dahin rechnen Sie mit einer Handvoll "lol my friend did it"-Submits pro Woche - schliessen Sie sie per Bulk Close aus dem Kanban.

Rider koennen das System nicht ausnutzen

Ein paar Hardening-Regeln:

• Ein Rider kann pro Fahrt maximal 3 Issue Reports senden
• Ein Rider, der in 7 Tagen 10 Issues sendet, von denen keines verified erreicht, wird rate-limitiert
• Issues gegen ein Fahrzeug, das der Rider nicht gemietet hat, werden auf API-Ebene abgelehnt

Diese Limits liegen in /api/rider-issues und waren in den Pilotflotten kein Reibungspunkt fuer legitime Nutzer.

Zusammenspiel mit Refunds

Manchmal meldet ein Rider ein Issue UND verdient eine Rueckerstattung (er hat fuer ein Moped bezahlt, das sich als kaputt herausstellte). Der Rider Issue Flow loest keine automatische Rueckerstattung aus - Refunds gehen immer ueber POST /api/rides/[id]/adjust-fare oder POST /api/rides/[id]/refunds. Der Ops Manager trifft die Refund-Entscheidung nach Sichtung von Issue und Fahrt.