marcus/pdf-umbenenner
1
0
Fork 0
Code Issues 14 Releases 2 Activity

Feature: Manuelle Dateinamen-Eingabe fuer nicht verarbeitete Dateien (FAILED/SKIPPED) #31

New Issue
Closed
opened 2026-04-24 13:22:32 +02:00 by marcus · 2 comments
marcus commented 2026-04-24 13:22:32 +02:00
Owner
Copy Link
Copy Source

Beschreibung

Aktuell ist der Dateiname-Editor nur bei erfolgreich verarbeiteten Dateien (Status DONE) aktiv. Bei FAILED- und SKIPPED-Eintraegen ist das Feld deaktiviert, ohne Erklaerung und ohne Alternative.

Gewuenschter Workflow

Der Benutzer soll auch bei nicht verarbeiteten Dateien eingreifen koennen:

  1. Datei B.pdf konnte nicht verarbeitet werden (FAILED oder SKIPPED) -> keine Kopie im Zielordner
  2. Der Benutzer gibt manuell einen Dateinamen ein
  3. Die Anwendung legt eine Kopie der Quelldatei mit dem manuell eingegebenen Namen im Zielordner an
  4. Der Status des Eintrags wird auf DONE gesetzt

Der Benutzer uebernimmt damit die Rolle der KI und hilft der Anwendung, doch noch ein sinnvolles Ergebnis zu produzieren.

Unterschied zu DONE-Fall

Fall Zieldatei vorhanden? Aktion
DONE Ja Vorhandene Datei im Zielordner umbenennen
FAILED / SKIPPED Nein Quelldatei kopieren mit manuell eingegebenem Namen in Zielordner

Offene UX-Frage

Noch zu entscheiden: Ob ein eigener Button ('Kopie erstellen') oder derselbe Button ('Dateiname uebernehmen') mit interner Fallunterscheidung sinnvoller ist. Das ist vor der Implementierung zu klaeren.

Status-Aenderung

Nach erfolgreicher manueller Kopie wird der Eintrag auf Status DONE gesetzt. Der urspruengliche FAILED/SKIPPED-Grund bleibt intern in der DB erhalten (Audit-Trail), ist aber fuer den Benutzer nicht mehr im Vordergrund.

Prioritaet

Mittel – wichtiges UX-Feature fuer den vollstaendigen Review-Zyklus.

## Beschreibung Aktuell ist der Dateiname-Editor nur bei erfolgreich verarbeiteten Dateien (Status DONE) aktiv. Bei FAILED- und SKIPPED-Eintraegen ist das Feld deaktiviert, ohne Erklaerung und ohne Alternative. ## Gewuenschter Workflow Der Benutzer soll auch bei nicht verarbeiteten Dateien eingreifen koennen: 1. Datei B.pdf konnte nicht verarbeitet werden (FAILED oder SKIPPED) -> keine Kopie im Zielordner 2. Der Benutzer gibt manuell einen Dateinamen ein 3. Die Anwendung legt eine Kopie der Quelldatei mit dem manuell eingegebenen Namen im Zielordner an 4. Der Status des Eintrags wird auf DONE gesetzt Der Benutzer uebernimmt damit die Rolle der KI und hilft der Anwendung, doch noch ein sinnvolles Ergebnis zu produzieren. ## Unterschied zu DONE-Fall | Fall | Zieldatei vorhanden? | Aktion | |---|---|---| | DONE | Ja | Vorhandene Datei im Zielordner umbenennen | | FAILED / SKIPPED | Nein | Quelldatei kopieren mit manuell eingegebenem Namen in Zielordner | ## Offene UX-Frage Noch zu entscheiden: Ob ein eigener Button ('Kopie erstellen') oder derselbe Button ('Dateiname uebernehmen') mit interner Fallunterscheidung sinnvoller ist. Das ist vor der Implementierung zu klaeren. ## Status-Aenderung Nach erfolgreicher manueller Kopie wird der Eintrag auf Status DONE gesetzt. Der urspruengliche FAILED/SKIPPED-Grund bleibt intern in der DB erhalten (Audit-Trail), ist aber fuer den Benutzer nicht mehr im Vordergrund. ## Prioritaet Mittel – wichtiges UX-Feature fuer den vollstaendigen Review-Zyklus.
marcus commented 2026-04-27 07:42:06 +02:00
Author
Owner
Copy Link
Copy Source

Produkttest-Befund: Fallunterscheidung verfeinert

Die ursprüngliche Issue-Beschreibung behandelt FAILED und SKIPPED gleich. Das ist nicht korrekt – es gibt zwei grundlegend verschiedene Fälle:

Fall A: SKIPPED

  • Datei wurde in einem früheren Lauf bereits erfolgreich verarbeitet
  • Zieldatei existiert bereits im Zielordner
  • Benutzeraktion: Umbenennen wie beim DONE-Fall (Datei liegt schon vor)
  • Info für Benutzer: „Bereits verarbeitet am [Datum] als: [dateiname.pdf]"

Fall B: FAILED

  • Datei konnte nicht verarbeitet werden (z.B. ungültige/leere PDF)
  • Zieldatei existiert noch nicht im Zielordner
  • Benutzeraktion: Manuellen Dateinamen eingeben → Kopie ins Zielverzeichnis
  • Info für Benutzer: Fehlergrund anzeigen (warum hat die KI versagt?)
  • Nicht trivial: Eine kaputte PDF kann nicht gelesen werden – der Benutzer übernimmt vollständig die Rolle der KI

Erforderliche Programm-Logik

Das Programm muss erkennen, ob zwischen Quelldatei und Zielordner bereits eine Beziehung besteht (DB-Abfrage), und darauf basierend den passenden Fall A oder B anwenden.

Akzeptanzkriterien (ergänzt)

  1. Fall A (SKIPPED, Zieldatei vorhanden): Umbenennen wie DONE, Hinweis auf früheren Lauf
  2. Fall B (FAILED, keine Zieldatei): Manueller Name → Kopie ins Ziel, Fehlergrund sichtbar
  3. Fallunterscheidung erfolgt automatisch anhand DB-Zustand, nicht manuell durch Benutzer
## Produkttest-Befund: Fallunterscheidung verfeinert Die ursprüngliche Issue-Beschreibung behandelt FAILED und SKIPPED gleich. Das ist nicht korrekt – es gibt zwei grundlegend verschiedene Fälle: ### Fall A: SKIPPED - Datei wurde in einem **früheren Lauf bereits erfolgreich verarbeitet** - Zieldatei existiert **bereits** im Zielordner - Benutzeraktion: Umbenennen wie beim DONE-Fall (Datei liegt schon vor) - Info für Benutzer: „Bereits verarbeitet am [Datum] als: [dateiname.pdf]" ### Fall B: FAILED - Datei konnte nicht verarbeitet werden (z.B. ungültige/leere PDF) - Zieldatei existiert **noch nicht** im Zielordner - Benutzeraktion: Manuellen Dateinamen eingeben → Kopie ins Zielverzeichnis - Info für Benutzer: Fehlergrund anzeigen (warum hat die KI versagt?) - Nicht trivial: Eine kaputte PDF kann nicht gelesen werden – der Benutzer übernimmt vollständig die Rolle der KI ### Erforderliche Programm-Logik Das Programm muss erkennen, ob zwischen Quelldatei und Zielordner bereits eine Beziehung besteht (DB-Abfrage), und darauf basierend den passenden Fall A oder B anwenden. ### Akzeptanzkriterien (ergänzt) 1. Fall A (SKIPPED, Zieldatei vorhanden): Umbenennen wie DONE, Hinweis auf früheren Lauf 2. Fall B (FAILED, keine Zieldatei): Manueller Name → Kopie ins Ziel, Fehlergrund sichtbar 3. Fallunterscheidung erfolgt automatisch anhand DB-Zustand, nicht manuell durch Benutzer
marcus commented 2026-04-27 08:11:00 +02:00
Author
Owner
Copy Link
Copy Source

Ergänzung nach Code-Analyse

Claude Code hat den Domain-Code analysiert. Ergebnis: Die Unterscheidung existiert bereits – aber sie wird zur GUI hin weggeworfen.

Was der Code bereits hat

Im Domain-Code gibt es zwei saubere Zustände:

  • ProcessingStatus.SKIPPED_ALREADY_PROCESSED – Dokument erfolgreich übersprungen (Zieldatei liegt vor)
  • ProcessingStatus.SKIPPED_FINAL_FAILURE – Dokument aufgegeben (alle Retries ausgeschöpft)

Das Problem

Die Observer-Schnittstelle DocumentCompletionStatus kollabiert beide zu einem einzigen SKIPPED. Die GUI sieht damit nicht mehr, welcher Fall vorliegt. Das ist die eigentliche Ursache für das schlechte UX-Verhalten.

Konsequenz für die Implementierung

Keine neue Architektur nötig – die Information existiert bereits. Sie muss nur durchgereicht werden:

  1. DocumentCompletionStatus um SKIPPED_ALREADY_PROCESSED und SKIPPED_FINAL_FAILURE erweitern (statt des pauschalen SKIPPED)
  2. GUI reagiert auf beide Fälle unterschiedlich:
    • SKIPPED_ALREADY_PROCESSED → Umbenennen möglich (Zieldatei liegt vor), Hinweis auf früheren Lauf
    • SKIPPED_FINAL_FAILURE → Manueller Name → Kopie ins Ziel, Fehlergrund sichtbar
## Ergänzung nach Code-Analyse Claude Code hat den Domain-Code analysiert. Ergebnis: Die Unterscheidung existiert bereits – aber sie wird zur GUI hin weggeworfen. ### Was der Code bereits hat Im Domain-Code gibt es zwei saubere Zustände: - `ProcessingStatus.SKIPPED_ALREADY_PROCESSED` – Dokument erfolgreich übersprungen (Zieldatei liegt vor) - `ProcessingStatus.SKIPPED_FINAL_FAILURE` – Dokument aufgegeben (alle Retries ausgeschöpft) ### Das Problem Die Observer-Schnittstelle `DocumentCompletionStatus` kollabiert beide zu einem einzigen `SKIPPED`. Die GUI sieht damit nicht mehr, welcher Fall vorliegt. Das ist die eigentliche Ursache für das schlechte UX-Verhalten. ### Konsequenz für die Implementierung Keine neue Architektur nötig – die Information existiert bereits. Sie muss nur durchgereicht werden: 1. `DocumentCompletionStatus` um `SKIPPED_ALREADY_PROCESSED` und `SKIPPED_FINAL_FAILURE` erweitern (statt des pauschalen `SKIPPED`) 2. GUI reagiert auf beide Fälle unterschiedlich: - `SKIPPED_ALREADY_PROCESSED` → Umbenennen möglich (Zieldatei liegt vor), Hinweis auf früheren Lauf - `SKIPPED_FINAL_FAILURE` → Manueller Name → Kopie ins Ziel, Fehlergrund sichtbar
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Assignees
Clear assignees
marcus
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marcus/pdf-umbenenner#31
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?