Plan Bewerbungen

Plan D — Bewerbungs-Lifecycle

Issue-Level-Detail zu Cluster D aus dem Master-Plan. Stand: 2026-06-10 (beta.100/101).

Status-Zusammenfassung

D1-D19 sind ✅ (Bewerbungs-Lifecycle stabil und produktiv, ~92 Bewerbungen in der Real-DB; D17-D19 aus beta.83-90). D20-D22 sind ✅ — Recherche-Persistenz-Cluster, aufgenommen am 2026-06-03, abgeschlossen: D20 in beta.97 (#672), D21+D22 in beta.98 (#673/#674, neue Tabelle research_notes, Schema v46; siehe unten). D23 ✅ (beta.100, #683).

Ergaenzungen seit beta.74

Nr	Funktion	Issue	Beta	Code
D17	nachfass_planen Dubletten-Check — kein zweiter Termin pro Bewerbung am selben Tag	#665	83	tools/bewerbungen.py
D18	Follow-up Direkt-Abhaken-Button in „Offene Aktionen" / Timeline	#665	85/90	ApplicationsPage.jsx (completeFollowUp)
D19	Generisches Task/Todo-System: tasks-Tabelle (Schema v45) + 4 MCP-Tools + REST-API + Frontend-Sektion	#666	85/90	tools/tasks.py, database.py, ApplicationsPage.jsx

Schluessel-Module

Modul	Pfad	Verantwortung
Bewerbungs-Tools	tools/bewerbungen.py (~1800 LOC)	CRUD + Status-Lifecycle + Notizen
Bewerbungs-Wizard	tools/workflows.py	Anschreiben + Doku + Status in einem Rutsch
Export	tools/export_tools.py, export.py, export_report.py	PDF/DOCX/ZIP/HTML-Protokoll
Kontakte	tools/kontakte.py (~600 LOC), services/contact_colors.py	Recruiter/Hiring-Manager mit Kategorien
Mail-Auto-Klassifikation	services/email_service.py	Auto-Status-Erkennung (eingehende Mails)

Schluessel-Issues

Issue	Thema	Status
#313	Bewerbungs-Bericht-Export (PDF/XLSX/HTML-Protokoll)	✅
#317	Duplikat-Pruefung beim Anlegen (2-stufig)	✅
#446	stelle_bearbeiten	✅
#471	Stellenangebot-vs.-Bewerbung-Duplikat	✅
#472	n:m Bewerbung ↔ Stelle	✅
#563	Kontakte aus Bewerbungen + Mails extrahieren	✅
#567	Nur laufende Bewerbungen blocken bei Duplikat-Pruefung	✅
#607	Kontakt-Kategorien	✅
#631	bewerbung_event_datum_setzen	✅
#642	Phantom-Bewerbungen aus CV-Dateinamen verhindert	✅
#650	Nachfass-Trigger bei Status ohne Update >7d (D15)	✅

Tests

• tests/test_v17_phantom_applications_642.py
• Zahlreiche in tests/test_v16*_*.py und tests/test_v170_*.py

Offen: Recherche-Persistenz (D20-D22) — aufgenommen 2026-06-03

Gefunden waehrend einer Firmenrecherche zu einer aktiven Bewerbung: recherche_speichern() legt das Ergebnis nicht dort ab, wo das Frontend es liest. Befund per Direkt-SQL verifiziert.

Nr	Issue	Problem	Soll
D20	#672	recherche_speichern schreibt als JSON-Schluessel in applications.fit_analyse, ignoriert kategorie. Frontend-Feld "FIRMEN-RECHERCHE" liest aber jobs.research_notes -> Recherche unsichtbar, kollidiert mit Fit-Analyse	Routing nach Kategorie: firmenrecherche -> jobs.research_notes, fit -> applications.fit_analyse. Erfolgsmeldung nur bei Schreiben ins anzeigbare Zielfeld, Zielfeld benennen
D21	#673	Nur firmenrecherche hat ein Anzeigefeld; skillgap/gehalt/markt/allgemein haben keinen Ort	Eigener Abschnitt "Recherchen" in bewerbung_details() + Timeline-Ansicht, listet alle gespeicherten Recherchen mit Kategorie + Datum
D22	#674	Speichern ist Zwei-Schritt (Recherche-Tool, dann separat recherche_speichern), fehleranfaellig	Recherche-Tools (firmen_recherche, branchen_trends, skill_gap_analyse, fit_analyse) optional bewerbung_id/job_hash annehmen und direkt korrekt persistieren. Vorschlag: dedizierte Tabelle research_notes(profile_id, bewerbung_id?, job_hash?, kategorie, text, created_at)

Reihenfolge: D20 (Routing fixen) -> D22 (saubere Ablage/Tabelle) -> D21 (Anzeige). Beachtet n:m (#472): bei firmenrecherche muss die Zielstelle eindeutig sein.

Manueller Workaround bereits angewendet (eine Bewerbung): Recherche-Text aus fit_analyse extrahiert, nach jobs.research_notes umgezogen, fit_analyse auf NULL. DB-Sicherung vorher. Schreiben lief NICHT ueber das Anti-DB-Bypass-Pattern (#514) — bewusste Ausnahme zur Reparatur eines Tool-Bugs, kein Normalbetrieb.

Offen: D24 — Kontakte-Untermenue „Referenzen" (#740) — aufgenommen 2026-07-02

Kontakte als Referenzgeber markieren (Art aus Whitelist + Zeitraum + Bemerkung, optional Bewerbungs-/Projektbezug), filtern und als Referenzliste (DOCX/PDF) exportieren. Datenmodell-Entscheid aus der Vorab-Analyse: eigene Tabelle contact_references (Migration v49) — contact_links scheidet aus (harte target_kind-Whitelist in db.link_contact, NOT-NULL-Ziel verhindert globale Referenzen, keine Felder fuer Art/Zeitraum). Stolpersteine: Fresh-Install-Parity (_migrate UND SCHEMA_SQL, siehe A19/#738), FastAPI-Route-Ordering unter /api/contacts/... (#578), Verhaeltnis zur bestehenden System-Kategorie referenz (Tabelle = Quelle der Wahrheit, Kategorie = Auto-Tag), DSGVO-Maskierungs-Option im Export („Kontaktdaten auf Anfrage"). Geplant fuer v1.8. Aufwand L (Migration + 5 Tools + Frontend-Untermenue + Export).

Naechste Iteration

Issue-Level-Detail pro Status-Uebergang ist Roadmap. Aktuell ist der Cluster stabil und produktiv im Einsatz.

---

Wiki-Anchor: Tab-Bewerbungen, Workflows.