[NIEDRIG] Log-Meldung "keine Metadaten im Dateinamen erkannt" ist fachlich falsch beschriftet

[TillQuandel]

Prio: NIEDRIG

Befund: Die Meldung „[0/7] PDF-Enrichment — keine Metadaten im Dateinamen erkannt…" wird nicht durch einen fehlgeschlagenen Dateiname-Parse ausgelöst, sondern durch die Prüfung des eingebetteten PDF-Info-Dicts (pdf_meta) auf Author/Year. Der Dateiname selbst wird an dieser Stelle noch gar nicht angefasst — er wird später von pdf_enrich.enrich() korrekt geparst (auch bei exakt Zotero-konformem Format „Autor - Jahr - Titel"). Funktional entsteht kein Datenverlust, die Meldung ist aber irreführend formuliert.

Beleg:

• Lauf 1b (Jockisch): Dateiname Jockisch - 2010 - Das Technologieakzeptanzmodell.pdf (exakt Zotero-Format) löst trotzdem die Meldung aus, weil das PDF kein Info-Dict mit Author/Year hat (Metadata: ? | ? | ? | 21 S.). Direkt danach im Log: „→ Zotero-Dateiname: Jockisch (2010) -- Das Technologieakzeptanzmodell" — der Dateiname wurde also doch korrekt geparst.
• Code: generative/orchestrator.py:2015-2022 (Prüfung von pdf_meta.get("Author")/.get("Year"), löst die irreführende Meldung aus), generative/pipeline/pdf_chunker.py:508-534 (pdf_metadata(), Quelle von pdf_meta — liest PDF-Info-Dict, nicht Dateiname), generative/tools/pdf_enrich.py:559-565 (_parse_filename_dynamic, parst den Dateinamen später korrekt).
• Gleiches Muster in Lauf 2, 3, 4, 5 beobachtet (durchgängig, nicht Lauf-1b-spezifisch).

Wirkung: Rein kosmetisch/Observability — kein Datenverlust, aber irreführend beim Log-Lesen (suggeriert einen Parser-Fehler, der nicht vorliegt).

Fix-Richtung: Meldungstext präzisieren, z. B. „keine eingebetteten PDF-Metadaten (Autor+Jahr) gefunden — versuche Enrichment über Dateiname/CrossRef".

Quelle: Testlauf-Serie 2026-07-14; Details im OneDrive-Serienordner.