Failed-Ticket Management: Diagnose, Retry und manuelle Eingriffe im Dashboard #59

New issue

Open

opened 2026-03-30 20:06:11 +00:00 by David · 0 comments

David commented

2026-03-30 20:06:11 +00:00

Collaborator

Beschreibung

Eine dedizierte Ansicht für fehlgeschlagene Tickets mit Diagnose-Tools, One-Click-Retry und manueller Eingriffsmöglichkeit. Aktuell gibt es nur einen Retry-Button ohne Kontext.

Hintergrund

Wenn Tickets fehlschlagen (Claude-Timeout, Git-Push-Fehler, Review-Reject nach 3 Runden), landen sie im Status failed mit einer oft abgeschnittenen Error-Message. Es gibt keine strukturierte Möglichkeit, den Fehler zu analysieren, die Ursache zu verstehen und gezielt zu reagieren.

Abgeleitet aus Issue #13 (Betriebskonzept), Bereich 3: Fehler-Workflow.

Akzeptanzkriterien

Dashboard-Tab "Fehlgeschlagen" mit allen failed-Tickets, sortiert nach Zeitpunkt
Pro Ticket: Failure-Stage anzeigen (bei welchem Schritt ist es fehlgeschlagen?)
Pro Ticket: Vollständigen Error-Log anzeigen (nicht abgeschnitten)
Pro Ticket: Letzte kontext.md und Pipeline-Log einsehbar
Aktionen pro Ticket:
- "Retry" (gleiche Konfiguration, neuer Versuch)
- "Retry mit Anpassung" (Enrichment-Formular öffnen, dann Retry)
- "Manuell lösen" (Ticket als manuell bearbeitet markieren + Notiz)
- "Verwerfen" (Ticket endgültig als unlösbar markieren)
Failure-Statistik: Häufigste Fehlerursachen als Übersicht

Technische Hinweise

Erweitern: frontend/src/pages/Dashboard.tsx — Tab "Fehlgeschlagen" mit Filter status=failed
Erweitern: frontend/src/pages/TicketDetail.tsx — Failure-Detailansicht mit Actions
Erweitern: backend/models/ticket.py — failure_stage (String: scoring/preparing/running/review/push), manually_resolved (Bool), resolution_notes (Text)
Erweitern: backend/api/tickets.py — POST /api/tickets/{id}/resolve-manually, POST /api/tickets/{id}/discard
Migration nötig: ja (neue Felder)

Aufwand: M

Abgeleitet aus #13

## Beschreibung Eine dedizierte Ansicht für fehlgeschlagene Tickets mit Diagnose-Tools, One-Click-Retry und manueller Eingriffsmöglichkeit. Aktuell gibt es nur einen Retry-Button ohne Kontext. ## Hintergrund Wenn Tickets fehlschlagen (Claude-Timeout, Git-Push-Fehler, Review-Reject nach 3 Runden), landen sie im Status `failed` mit einer oft abgeschnittenen Error-Message. Es gibt keine strukturierte Möglichkeit, den Fehler zu analysieren, die Ursache zu verstehen und gezielt zu reagieren. Abgeleitet aus Issue #13 (Betriebskonzept), Bereich 3: Fehler-Workflow. ## Akzeptanzkriterien - [ ] Dashboard-Tab "Fehlgeschlagen" mit allen `failed`-Tickets, sortiert nach Zeitpunkt - [ ] Pro Ticket: Failure-Stage anzeigen (bei welchem Schritt ist es fehlgeschlagen?) - [ ] Pro Ticket: Vollständigen Error-Log anzeigen (nicht abgeschnitten) - [ ] Pro Ticket: Letzte kontext.md und Pipeline-Log einsehbar - [ ] Aktionen pro Ticket: - "Retry" (gleiche Konfiguration, neuer Versuch) - "Retry mit Anpassung" (Enrichment-Formular öffnen, dann Retry) - "Manuell lösen" (Ticket als manuell bearbeitet markieren + Notiz) - "Verwerfen" (Ticket endgültig als unlösbar markieren) - [ ] Failure-Statistik: Häufigste Fehlerursachen als Übersicht ## Technische Hinweise - Erweitern: `frontend/src/pages/Dashboard.tsx` — Tab "Fehlgeschlagen" mit Filter `status=failed` - Erweitern: `frontend/src/pages/TicketDetail.tsx` — Failure-Detailansicht mit Actions - Erweitern: `backend/models/ticket.py` — `failure_stage` (String: scoring/preparing/running/review/push), `manually_resolved` (Bool), `resolution_notes` (Text) - Erweitern: `backend/api/tickets.py` — `POST /api/tickets/{id}/resolve-manually`, `POST /api/tickets/{id}/discard` - Migration nötig: ja (neue Felder) ## Aufwand: M _Abgeleitet aus #13_