feat(requests): request list with errors, retries and reprocessing

[Fluory]

Warum

Fixes #26 · Epic #18 · Basis main (#42 ist gemergt; vorher gestapelt auf claude/feat-review-line-items-25).

Arbeitsstand

• Ziel: Sachbearbeitung sieht auf einen Blick, welche Anfragen Aufmerksamkeit brauchen, und stößt fehlgeschlagene erneut an.
• Nicht-Ziele: firmenübergreifende Ops-Dashboards.
• Erledigt: Listenfilter (Status, mögliches Duplikat) im requests-Modul, Exportzustände im export-Modul, Seite /requests mit Versuchen, letztem Fehler inkl. Stufe, nächstem Versuch (Verarbeitung und Export), Filtern und „Erneut verarbeiten" (Server Action); Zeilenlogik als reine Funktion requestRowView; Tests; Doku; frischer Review eingearbeitet; verify:full grün; CI check grün.
• Offen: Merge (freigegeben durch den Orchestrator, Reihenfolge des Stapels).
• Annahmen: keine Paginierung im Pilot (Folge-Issue feat(requests): paginate the request list #48).
• Nächster kleinster Schritt: Merge nach grünem check gegen main; danach feat(intake,review): duplicate handling in the UI #44.

Was ist passiert (Klartext)

Die Anfragenliste zeigt jetzt je Anfrage die Anzahl der Versuche, den letzten Fehler in verständlichen Worten samt Stufe (Verarbeitung oder Export) und wann der nächste automatische Versuch kommt – auch wenn der Export ans ERP gerade wiederholt wird. Man kann nach Status und nach möglichen Duplikaten filtern. Fehlgeschlagene Anfragen haben einen Knopf „Erneut verarbeiten" – der Statuswechsel, der neue Auftrag und der Protokolleintrag passieren in einem Schritt.

Plan-Pflicht (SYSTEM.md §4)

• Kein Auslöser – keine Modulgrenze, öffentliche API, Migration, Auth/Rechte, kein Zahlungs-/Daten-/Infrapfad, höchstens zwei Module, keine Architekturvarianten, umkehrbar
• Auslöser zutreffend – Impact Manifest ausgefüllt (Plan vor Code)

Impact Manifest

• Betroffene Module: requests (listRequests mit Filter, recordExportRetry), export (listExportRecords; Export-Job schreibt den nächsten Versuch), app (Seite /requests, Server Action reprocessAction, row-view.ts); Reprocess selbst existiert seit feat(jobs,extraction): process requests in the worker with retries and visible errors #7/feat(export): export approved requests exactly once to the ERP mock #9 im jobs-Modul.
• Schnittstellen / Datenänderungen: keine Migration; Server Action nutzt feste Meldungscodes.
• Akzeptanzkriterien: alle aus feat(requests): request list with errors, retries and reprocessing #26 – siehe Nachweis.
• Testplan: Integration mit Zuständen über die echte Statusmaschine; Reprocess über die Server Action selbst (nur next/headers gefälscht); Unit für requestRowView.
• Verifizierte Fakten: reprocessRequest erledigt Statuswechsel, Job und Audit in einer Transaktion (Stufe processing → NEW, export → APPROVED).
• Offene Annahmen: –
• Nicht-Ziele: siehe oben.
• Risiken und Rollback: mandantenbezogen (RLS), Fehlertexte ohne Inhalte; Rollback per Revert.

Geändert

• src/features/requests/{repository,index}.ts, src/features/export/{repository,export-job,index}.ts
• src/app/requests/{page.tsx,actions.ts,row-view.ts,row-view.test.ts}
• Tests: tests/integration/request-list.test.ts
• Doku: docs/technical/{architecture,operations}.md, CHANGELOG.md

Nachweis (SYSTEM.md §11)

• verify:changed: typecheck, lint, Unit row-view 4/4, Integration request-list 6/6
• verify: grün (lokal auf der Stapelspitze feat(observability): correlated structured logs and full health #45, die diesen PR enthält: lint, typecheck, Unit 154/154, Integration 114/114, depcruise, build, audit ohne high); CI check auf dem aktuellen Head grün
• verify:full / E2E-Spec: grün (beide Smoke-Flows, Eval-Gate PASSED)
• Akzeptanzkriterien feat(requests): request list with errors, retries and reprocessing #26: Liste mit Status, Versuchen, lesbarem Fehler, nächstem Versuch → „lists status, attempts, readable last error…" + „shows an export that is retrying…"; Reprocess atomar + auditiert → „reprocess (server action): ERROR(processing) → NEW…" und „ERROR(export) → APPROVED…"; Dead-Letter als ERROR mit Stufe → Anzeige Stufe + Tests aus feat(jobs,extraction): process requests in the worker with retries and visible errors #7/feat(export): export approved requests exactly once to the ERP mock #9; Filter Status + Duplikat → „filters by status and by possible duplicate"
• Manueller Prüfnachweis: Filter ist ein natives GET-Formular (Tastatur), leere Liste mit eigenem Text, Knöpfe mit aria-label inkl. Betreff
• Frischer Review: erledigt (0 Blocker · 3 should-fix · 4 nits, alle eingearbeitet oder begründet) – siehe PR-Kommentar

Doku-Entscheidung (genau eine)

• Keine langlebige Doku betroffen – Begründung: –
• Doku betroffen und im selben PR aktualisiert:
  • Produktdoku (P0: README): –
  • Technische Doku: docs/technical/operations.md
  • Architekturkarte: docs/technical/architecture.md
  • ADR: –
  • CHANGELOG [Unreleased] (sichtbares Feature oder Verhalten – im selben PR, nie „später")

Entferntes oder Umbenanntes: nichts entfernt

Dateigrößen und neue Bausteine (SYSTEM.md §7)

Dateien über 500 Zeilen im Diff (Ausnahmen: generierter Code, Lockfiles, Fixtures, Migrationen, Schemas, Ressourcen, Doku, Konfiguration):

• keine
• bewusst belassen – Begründung: –
• im selben PR nach fachlicher Verantwortung geteilt
• Folge-Issue –

Über 800 Zeilen mit neuer Fachlogik oder über 1000 Zeilen (P1/P2): nicht betroffen

Neue Shared-Komponente, Utility-Datei, Adapter oder fachlicher Service:

• nein
• ja – gesucht nach: vorhandener Reprocess-Logik; gefunden: jobs/reprocessRequest – wiederverwendet

Subagent-Einsätze

• Frischer Review: unabhängiger read-only Subagent (review-pr + Security-Regel).

Risiken / offene Punkte

• Keine Paginierung (Pilotmengen) – Folge-Issue feat(requests): paginate the request list #48.
• Direkt nach einem Reprocess aus ERROR(export) zeigt die Zeile kurz den letzten Export-Fehler, bis der neue Versuch läuft – bewusst belassen (zutreffende letzte Ursache).

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01DJ5vaKvTYiMvdngT4d3xo1

[Fluory]

Frischer Review (unabhängiger Subagent, read-only aus Git-Refs, review-pr + Security-Regel)

Ergebnis: 0 Blocker · 3 should-fix · 4 nits. Bestätigt: Firma nur aus der Session, Reprocess-Autorisierung + Atomarität (Statuswechsel, Job, Audit in einer Transaktion), kein N+1, Query-Parameter gegen Allow-Lists, Filter mit Labels, Status als Text.

#	Schwere	Befund	Auflösung
1	should-fix	„Nächster Versuch" nie für Export-Wiederholungen (nur Verarbeitung schrieb nextRetryAt)	runExportJob schreibt nach fail() den nächsten Termin aus pg-boss (recordExportRetry, nur solange APPROVED); Integrationstest „shows an export that is retrying…"
2	should-fix	Veralteter Export-Fehler/Versuche nach Reprocess; ERROR(export) zeigte Verarbeitungsversuche	Zeilenlogik als reine Funktion requestRowView: Ursache nur für fehlernde/wiederholende Anfragen, Export-Versuche bei Export-Fehlern. Bewusst belassen: direkt nach einem Reprocess aus ERROR(export) zeigt die APPROVED-Zeile den letzten Export-Fehler, bis der neue Versuch läuft (Sekunden) – das ist die zutreffende letzte Ursache
3	should-fix	Anzeige-Logik ungetestet	Unit-Tests für requestRowView (4) + Integrationsfall APPROVED mit laufender Export-Wiederholung
4	nit	„keine Stacktraces"-Check prüfte nur selbst gesetzte Texte	entfernt (Texte kommen aus describeFailure/describeExportFailure, dort getestet)
5	nit	gleichlautende „Erneut verarbeiten"-Knöpfe	aria-label mit Betreff
6	nit	Stufe doppelt angezeigt	Stufe einmal: im Status bei ERROR, als Präfix bei Wiederholungen
7	nit	keine Paginierung	für den Pilot ok – Folgeaufgabe

---

Generated by Claude Code