Plan Dokumente

Plan E — Dokumenten-Pipeline

Issue-Level-Detail zu Cluster E aus dem Master-Plan. Stand: 2026-07-02 (v1.7.3).

Status-Zusammenfassung

Cluster E komplett: 14 von 14 ✅ (inkl. E17, v1.7.3). Phase 1 (#658, beta.78), Phase 2 (#657, beta.79), Phase 3 (#643, beta.80), Matching- Haertung E17 (#743, v1.7.3) abgeschlossen.

Phase 3 abgeschlossen (beta.80, E11, #643)

/dokumente_verarbeiten routet jetzt nach doc_type und triggert pro Typ die passende PBP-Aktion — statt nur "Profildaten extrahieren".

Neuer Routing-Plan dokumente_routing_plan_erstellen(archiv=False) gruppiert alle noch-nicht-fertig-verarbeiteten Docs nach abgeleiteter Aktion (profil_extraktion, termin_anlegen, bewerbung_status_setzen, eingangsbestaetigung, bewerbung_erfassen, noop_korrespondenz_abschliessen).

dokumente_batch_analysieren(routing_modus=True) (Opt-in) sendet pro Doku einen routing-Hint mit konkreter Aktion mit. Default routing_modus=False bleibt das alte Profildaten-Verhalten.

Neuer Wrapper dokument_aktion_ausfuehren(dokument_id, aktion, args) delegiert an die bestehenden MCP-Tools (meeting_hinzufuegen, bewerbung_status_aendern, bewerbung_erstellen) — inklusive aller Lifecycle-Hooks (Auto-Veralten aus #657 greift automatisch beim Status-Wechsel). Setzt am Ende immer extraction_status='angewendet'.

Rauschen-Heuristik services/document_handlers.is_pure_notification() erkennt LinkedIn-/XING-Digest-Mails und Mail-Robot-Pushes. Hook im Mail-Import (dashboard.py:_build_email_document_context + Ordner-Import + Mail-Upload): Treffer → direkt lifecycle='archiviert'. Reversibel via dokument_reaktivieren. Konservativ-defensiv (klare Treffer nur), Umlaut-normalisiert, keine externen Calls — alles lokal.

MCP-Tool-Count: 159 → 161. Tests: +16 in tests/test_v17_routing_643.py. Volle Suite: 1526 passed, 1 skipped. Cluster E komplett abgeschlossen.

Phase 2 abgeschlossen (beta.79, E16, #657)

documents bekommt die orthogonale Spalte lifecycle mit drei Werten: aktiv (Default) / archiviert (manuell ausgeblendet) / veraltet (auto beim Bewerbungs-Statuswechsel auf abgelehnt/abgelaufen/zurueckgezogen). Schema v43 → v44, additiv, idempotent, mit automatischem Backup vor Migration.

Default-Filter lifecycle='aktiv' in den drei Read-Tools (analyse_plan_erstellen, dokumente_batch_analysieren, dokumente_zur_analyse). Mit archiv=True werden archivierte/veraltete Docs wieder einbezogen — analog zu bewerbungen_anzeigen(archiv=True).

Drei neue MCP-Tools: dokument_archivieren(grund=''), dokument_reaktivieren, dokumente_bulk_archivieren(filter_doc_type, filter_extraction_status, dry_run=True, max_treffer=200). Alle drei sind DB-only — physische Dateien werden NIE angefasst. Reversibel.

Auto-Veralten-Hook in bewerbung_status_aendern: bei End-Stati werden die mit der Bewerbung verknuepften Docs auf lifecycle=veraltet gesetzt. Schema- Hinweis: documents.linked_application_id ist 1:1, "exklusiv" ist damit schemamaessig garantiert.

MCP-Tool-Count: 156 → 159. Tests: +18 in tests/test_v17_lifecycle_657.py.

Phase 1 abgeschlossen (beta.78, E15, #658)

basis_analysiert/analysiert-Korrespondenz lief in einen Halbschritt-Stuck: extraktion_anwenden() wurde nur für Profildaten getriggert, Mails ohne Profilbezug (Absagen, Einladungen, Recruiter-Anfragen, Benachrichtigungen) blieben dauerhaft im Analyse-Plan. beta.78 löst das in drei kleinen Schritten:

1. _run_auto_deep_analysis setzt jetzt angewendet statt analysiert. Der Halbschritt analysiert war redundant — wenn das LLM ein Doku gesehen hat, ist der Auto-Pfad für Korrespondenz fertig. (dashboard.py:7836,7844)
2. Neues MCP-Tool dokumente_korrespondenz_abschliessen(dry_run=True). Räumt Altlasten ab: findet alle sonstiges/recruiter_anfrage/absage/... im basis_analysiert/analysiert-Bucket und hebt sie auf angewendet. DB-only, physische Dateien bleiben unberührt. (tools/dokumente.py)
3. Whitelist _DOC_STATUS_VALUES erweitert. dokument_status_setzen() akzeptiert jetzt auch basis_analysiert, analysiert, analysiert_leer, duplikat, verworfen — vorher waren nur 4 Werte erlaubt, obwohl der Auto-Pfad mehr vergibt.

Phase 2 (E16, #657) baut darauf auf: orthogonale lifecycle-Spalte (aktiv/archiviert/veraltet), dokument_archivieren/reaktivieren, Auto-Veralten beim Bewerbungs-Statuswechsel. Phase 3 (#643) routet nach doc_type und triggert typspezifische Aktionen.

Schluessel-Module

Modul	Pfad	Verantwortung
Dokumenten-Tools	tools/dokumente.py	Upload + Klassifikation + Verknuepfung
Profil-Extraktion	tools/profil.py + services/llm_service.py	Skills/Stationen aus CV via Ollama
Mail-Service	services/email_service.py	.msg/.eml-Parser, IMAP-Polling
Auto-Klassifikation	dashboard.py:_run_auto_classify_emails + _run_auto_classify_documents	Hintergrund-Step

Schluessel-Issues

Issue	Thema	Status
#441	Doku-Integrity-Check mit Auto-Fix	✅
#606	Auto-Extract Kontakte	✅
#634	/dokumente_verarbeiten Routing-Prompt	✅
#640	Tiefenanalyse nach Basis-Extraktion	✅
#642	Phantom-Bewerbungen aus CV-Dateinamen verhindert	✅
#644	email_verknuepfen mit getrennten ID-Raeumen	✅
#649	Few-Shot fuer Recruiter-Anfrage-Klassifikator (E13)	✅
#651	Auto-Tiefenanalyse-Step (E12)	✅
#655	Doku-Typen erweitern + Per-Typ-Handler-System (E14)	✅
#658	Korrespondenz-Docs bleiben auf basis_analysiert haengen (E15)	✅
#657	Lifecycle-Spalte aktiv/archiviert/veraltet (E16)	✅
#643	Doku-Routing nach doc_type + typspezifische Aktionen (E11)	✅
#686	analyse_plan_erstellen matcht Dokumente gegen bestehende Bewerbungen (bewerbungs_zuordnungen, Dublettenschutz; Firmenerkennung auch aus dem Inhalt)	✅ (beta.101)

Tests

• tests/test_v17_phantom_applications_642.py
• tests/test_v17_email_verknuepfen_644.py
• tests/test_v170_beta22_*.py
• tests/test_v17_doc_lifecycle_658.py (E15, beta.78)
• tests/test_v17_optimierungen_beta76.py (E12 + #658-Adaption)
• tests/test_v17_lifecycle_657.py (E16, beta.79)
• tests/test_v17_routing_643.py (E11, beta.80)

E17 — Auto-Matching haerten (#743) — ✅ (v1.7.3)

User-Fund vom 2026-07-02: eingehende Vermittler-Mails (Hays, SThree) wurden mit Konfidenz 70% an inhaltlich fremde, laengst abgeschlossene Bewerbungen gehaengt. Befund der Code-Analyse: es sind zwei Matcher beteiligt —

Sub	Baustein	Code	Problem / Soll
E17.1	Status-Daempfung	database.py:auto_assign_document, services/email_service.py:match_email_to_application	Bewerbungen mit Archiv-Status (abgelehnt/zurueckgezogen/abgelaufen) matchen gleichberechtigt (Status wirkt nur als Tie-Break, #389). Soll: Archiv-Status nie auto-verknuepfen, nur als Vorschlag; im E-Mail-Matcher Auto-Match auf Archiv-Bewerbungen nur bei exaktem kontakt_email-Match
E17.2	Schwellen-Angleich	database.py:auto_assign_document (Auto-Link ab 0.7, reiner Dateiname-Firmenname)	Die gemeldeten 70% stammen aus DIESEM aelteren Matcher (#177) — #523 hat nur den E-Mail-Matcher auf 0.90 gehoben. Soll: 0.7-Zweig wird reiner Vorschlag, Auto-Link erst ab 0.9
E17.3	Ambiguitaets-Check	services/email_service.py (Domain-Signale)	Bei Vermittler-Agenturen ist die Sender-Domain nicht diskriminierend (jede Mail kommt von derselben Domain). Soll: teilen sich mehrere Bewerbungen denselben Match-Key, Auto-Match nur bei eindeutigem inhaltlichem Signal (Ansprechpartner/Titel), sonst unverknuepft
E17.4	Transparenz	tools/dokumente.py:analyse_plan_erstellen (#686)	Zuordnungs-Vorschlaege auf abgeschlossene Bewerbungen bekommen einen Warnhinweis

Leitprinzip bleibt #523: „im Zweifel unverknuepft". Bestandsdaten werden NICHT automatisch aufgeraeumt (manuelle Korrektur via dokument_entverknuepfen). Regression abgesichert: Absage-Mails an noch aktive Bewerbungen matchen weiterhin; eine aktive + eine alte abgelehnte Bewerbung derselben normalen Firma blockt den Auto-Match NICHT (Ambiguitaet zaehlt nur zulaessige Kandidaten). Umgesetzt in v1.7.3, Tests: tests/test_v173_matching_743.py (21 Tests). Vermittler-Domain-Liste: RECRUITER_DOMAIN_KEYWORDS in services/email_service.py (erweiterbar).

Naechste Iteration

Cluster E ist mit E17 (v1.7.3) wieder komplett. Weitere Iterationen koennten betreffen:

• Frontend-UI fuer Routing-Plan + Aktion-Ausfuehrer + Archiv-Toggle. Aktuell laeuft alles ueber den Claude-Workflow + MCP-Tools.
• LLM-basierte Klassifikation im Routing — aktuell rein regex/keyword- basiert. Falls die Trefferquote zu niedrig wird, koennte ein Ollama-Schritt zwischen E12 (Tiefenanalyse) und E11 (Routing) eingezogen werden.
• Erweiterung der Rauschen-Heuristik um weitere Quellen-Pattern, sobald False-Negatives auffallen. Aktuell konservativ-defensiv.

---

Wiki-Anchor: Tab-Dokumente, Profil-aus-Dokumenten.