Troubleshooting Auftraege

Wenn auf dem Auftrags-Board etwas falsch aussieht, liegt die Ursache fast immer in einem der folgenden Muster. Gehen Sie diese Liste durch, bevor Sie ein Support-Ticket eroeffnen.

Ein Task haengt in Created und die Regel haette ihn erstellen sollen

Drei Dinge pruefen:

1. Ist die Regel aktiv? Oeffnen Sie /dashboard/task-rules und pruefen Sie, ob der Toggle eingeschaltet ist. Inaktive Regeln feuern nicht.
2. Lief der Cron ueberhaupt? Schauen Sie in task_rule_runs nach dem letzten Eintrag der Regel. Ist er aelter als der Schedule, ist der Cron nicht gelaufen - pruefen Sie vercel.json fuer die Cron-Konfig und Ihre Vercel-Deployment-Seite auf Fehler.
3. Hat die Regel null Fahrzeuge getroffen? Klicken Sie den Test-Button. Liefert der Dry-Run null Treffer, ist Ihre Trigger-Konfig zu eng.

Das Fahrzeug ist nicht auf maintenance geflippt, obwohl ich einen kritischen Task erstellt habe

Zwei Ursachen:

• Aktive Fahrt - Der Auto-Flip-Trigger unterbricht keine Fahrt. Ist vehicles.status = 'in_use', wartet der Flip bis zum Fahrtende. Der Task ist trotzdem erstellt; das Fahrzeug geht nur erst beim Fahrtende auf maintenance.
• Priority unter high - Nur high und critical loesen den Flip aus. Bei medium bleibt das Fahrzeug verfuegbar.

Ein Tech sagt, er kann nicht auf Start tippen

Der Start-Button ist fotopflichtig. Der Tech muss zuerst ein before-Foto erfassen oder anhaengen. Tippt er im Offline-Modus, ist der Foto-Upload moeglicherweise nur in der Queue - er muss das Foto im Abschnitt "Photos" des Task Detail sehen, bevor der Button aktiv wird.

Hat er ein Foto und der Button bleibt grau, pruefen Sie:

• Ist er der aktuelle Assignee? Hat ein Manager den Task neu zugewiesen, kann nur der neue Assignee Start druecken.
• Ist der Task im Zustand assigned? Bei created (unassigned) ist der Button versteckt.

Ein Tech wollte Resolve und bekam "already closed by ___"

Das ist die Konfliktloesung der Offline-Queue. Der Tech hat den Task offline resolved, aber der Manager hat ihn serverseitig zuerst force-closed. Der Client sieht beim Sync eine 409 und zeigt die Meldung. Die Fotos des Tech werden trotzdem an den geschlossenen Task gespeichert (Client-Wins bei Fotos und Notizen), sodass kein Beleg verloren geht.

Verify-Button ist grau fuer einen Manager

Zwei Gruende:

1. Task ist nicht im Zustand resolved - Verify setzt Resolve voraus. Die State Machine ueberspringt nichts.
2. Manager-Rolle stimmt nicht - Nur ops_manager und lead_tech koennen verifizieren. Ein normaler tech oder junior_tech kann es nicht, auch nicht bei eigener Arbeit.

Doppelte Tasks am selben Fahrzeug

Das System blockt Duplikate desselben task_type, nicht ueber Types hinweg. Ein Fahrzeug kann also gleichzeitig einen offenen repair, einen battery_swap und einen cleaning haben. Das ist Absicht.

Sehen Sie Duplikate desselben Type, pruefen Sie:

• Einer ist verified, aber nicht closed - verified Tasks gelten fuer Dedup als geschlossen. Sehen Sie beide, refreshen Sie; einer ist auf dem Weg zu closed.
• Eine Regel feuerte, bevor der bestehende Task geladen war - Race Condition, sehr selten. Das Duplikat manuell schliessen.

Tasks werden nicht per Proximity zugewiesen

assign_by_proximity liest users.last_lat und users.last_lng, um den naechsten Tech zu waehlen. Zwei Dinge pruefen:

1. Teilen Ihre Techs den Standort? Die operator-app POSTet im Foreground alle paar Minuten an /api/operator/location. Hat ein Tech Location Services aus, ist er fuer Proximity-Assignment unsichtbar.
2. Sind die Spalten gefuellt? Query SELECT last_lat, last_lng, last_lat_at FROM users WHERE id IN (your tech IDs). Ist last_lat_at aelter als eine Stunde, wird der Tech nicht gewaehlt.

Der Fallback, wenn kein Tech in Reichweite ist, ist den Task unassigned (Created) zu lassen, damit jeder Tech ihn annehmen kann.

Ein Vendor bekommt keine Magic-Link-E-Mail

Drei Dinge pruefen:

1. E-Mail-Zustellung - Magic-Link-E-Mails gehen ueber Resend. Pruefen Sie das Resend-Dashboard auf Delivery- und Bounce-Status.
2. Vendor-Zeile ohne E-Mail - vendors.contact_email ist das Ziel. Ist es NULL, wird keine E-Mail gesendet.
3. Token bereits verwendet - Magic Links sind 7-Tage-Single-Task-Tokens. Hat der Vendor schon akzeptiert, ist der Link nicht laenger "neu" - er sollte die URL nach dem ersten Oeffnen bookmarken.

Fotos werden aus der operator-app nicht hochgeladen

Fotos werden zuerst lokal unter ${FileSystem.documentDirectory}task-photos/<task_id>/ gecached und beim Reconnect hochgeladen. Meldet ein Tech "Fotos haengen":

1. Pruefen Sie die Upload-Progress-Anzeige im Task Detail Screen
2. Erzwingen Sie Sync ueber Settings -> Sync Pending Items in der operator-app
3. Schlaegt das fehl, pruefen Sie die Supabase-Storage-Permissions des Geraets - der Bucket task-photos braucht authentifizierten Upload

Fallback: Der Tech schickt die Fotos per SMS an den Ops Manager, der sie aus dem Dashboard anhaengt.

"Cannot create task - duplicate" aus der API

Das POST an /api/tasks antwortet mit 200 und skipped_duplicate: true, wenn ein offener Task desselben Type existiert. Das ist ein Feature, kein Bug. Um einen zweiten Task gegen dasselbe Fahrzeug zu erstellen:

• Schliessen Sie den ersten, oder
• Nutzen Sie einen anderen task_type, oder
• Warten Sie bis der erste verified ist (das zaehlt fuer Dedup als geschlossen)

SLA-Breach-Notifications sind zu laut

Drei Stellschrauben:

1. Low/Medium-SLAs lockern - ist low auf 24h gesetzt und Sie haben 200 Low-Priority-Tasks, werden Sie viel verstossen. Defaults sind 7 Tage fuer low, 72h fuer medium.
2. Slack auf Low-Priority-Regeln abschalten - auf Regeln, die Slack nicht verdienen, action_config.notify_slack: false.
3. Auf das Batching warten - Expo Push batcht Verstoesse in Digests bei 5-in-10-Minuten. Slack batcht nicht.