Rider Issue Reports

Um rider toca em "Report an Issue" no app movel, tira uma foto de um guidao bambo e envia. Trinta segundos depois, o celular do tecnico certo vibra com uma task repair fixada exatamente nesse veiculo. Esse e o fluxo de rider issue.

Onde isso vive no rider app

A tela e ReportIssueScreen.tsx na pasta mobile-app/src/screens/main/. Riders chegam la por:

• A tela de confirmacao pos-corrida ("How was your ride? Report an issue")
• O menu de seguranca da corrida ativa
• A tela de detalhe do veiculo antes do unlock

A tela tem quatro entradas:

1. Category picker - mechanical, electrical, cosmetic, safety, lost_and_found, cleanliness
2. Severity - minor, moderate, severe (autoavaliacao do rider)
3. Description - campo de texto livre
4. Photos - ate 4 anexos da camera ou biblioteca

O submit faz POST em /api/rider-issues com o token de auth do rider e o contexto da corrida ativa ou recem-encerrada.

O que acontece no servidor

A rota /api/rider-issues faz tres coisas nesta ordem:

1. Escreve uma linha rider_issues com category, severity, description, photos e contexto da corrida
2. Chama o handler onRiderIssueSubmitted do rule engine
3. O handler busca qualquer regra ativa com trigger_type = 'rider_issue' e cria uma task

A regra que trata rider issues e mais ou menos assim:

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

Voce pode escrever uma regra por categoria (mechanical, electrical, etc.) ou uma regra catch-all. A logica de deduplicacao impede duas tasks abertas contra o mesmo veiculo.

Escalacao de severidade por IA

Se o rider anexa uma foto, o rule engine passa a foto por um classificador de severidade por IA. O classificador da uma nota de 1 a 5, e:

• Severidade 4 ou maior eleva a priority da task para critical independente do default da regra
• Severidade 5 ainda dispara o auto-flip para maintenance imediatamente

A nota da IA fica em task_photos.ai_severity e aparece na pagina de detalhe da task do dashboard para o ops manager checar. Falsos positivos sao raros, mas nao zero - o modelo foi tunado de forma conservadora (mais "esta tudo ok" do que "esta quebrado") para evitar fadiga de alarme.

O que o rider ve apos enviar

O rider ve uma tela de confirmacao com:

• "Thanks - we got it"
• Um ID de task truncado para referencia
• Um tempo estimado ate resolucao baseado na config de SLA

Se o rider tem notificacao por email ativada, ele tambem recebe um email quando a task chega em verified para saber que o veiculo voltou ao servico.

Fila de triagem (roadmap Fase 5)

Hoje cada rider issue cria uma task imediatamente. O roadmap da Fase 5 adiciona uma fila de triagem que segura rider issues por 60 segundos antes de criar a task, para que ops possa interceptar lixo obvio (duplicatas, relatos de vandalismo sem foto, submits acidentais). Ate la, espere alguns "lol my friend did it" por semana - feche em massa pelo Kanban.

Riders nao conseguem abusar

Algumas regras de protecao:

• Um rider pode enviar no maximo 3 issue reports por corrida
• Um rider que envia 10 issues em 7 dias sem nenhum chegar a verified recebe rate-limit
• Issues contra um veiculo que o rider nao alugou sao rejeitados na camada de API

Esses limites vivem em /api/rider-issues e nao tem sido fonte de fricao para usuarios legitimos nas frotas piloto.

Integracao com refunds

As vezes um rider reporta um issue E merece um reembolso (ele pagou por um moped que estava quebrado). O fluxo de rider issue nao reembolsa automaticamente - reembolsos sempre passam por POST /api/rides/[id]/adjust-fare ou POST /api/rides/[id]/refunds. O ops manager toma a decisao do reembolso apos olhar o issue e a corrida.