[31e88f42] Add initial generated weekly summary report for 2026-03-09

[31e88f42] Add weekly summary generation script for Notion tasks
feat(lead-engine): Implement Teams notification and email enhancements [31988f42]
2026-03-09 02:31:23 +00:00 · 2026-03-09 02:29:37 +00:00 · 2026-03-08 20:01:20 +00:00 · 2026-03-08 19:37:57 +00:00
8 changed files with 1354 additions and 58 deletions
--- a/RELOCATION.md
+++ b/RELOCATION.md
@@ -152,8 +152,188 @@ for port in "${PORTS_INTRANET[@]}"; do
    fi
 done
 echo -e "\n--- Testing Public Ports on $TARGET_IP (von extern prüfen!) ---"
 for port in "${PORTS_PUBLIC[@]}"; do
    echo "   - Bitte prüfen Sie Port $port manuell von außerhalb des Netzwerks."
 done
 ```
 ---
 ### **Teil 4: Entwicklungs- vs. Produktions-Workflow**
 Dieses Kapitel definiert die verbindlichen Regeln für die Weiterentwicklung der GTM-Engine nach der Migration, um maximale Stabilität und Sicherheit des Produktivsystems zu gewährleisten.
 #### **1. Grundprinzipien: Getrennte Welten**
 *   **Regel 1: Keine Entwicklung in der Produktion.** Auf der Wackler-VM (`docker1`) wird niemals Code direkt bearbeitet, experimentiert oder getestet. Sie ist ausschließlich für den Betrieb der stabilen Softwareversion vorgesehen.
 *   **Regel 2: Getrennte Konfiguration.** Jede Umgebung hat ihre eigene Konfigurationsdatei.
    *   **Produktion (Wackler):** `.env` – Enthält alle echten API-Schlüssel und Endpunkte.
    *   **Entwicklung (Synology):** `.env.dev` (oder eine Kopie der `.env`) – Verwendet Test-Schlüssel, Sandbox-Endpunkte und Dummy-Werte.
 *   **Regel 3: Die Produktionsdatenbank ist heilig.** Die produktiven Docker-Volumes (`explorer_db_data` etc.) werden niemals für Entwicklungszwecke angetastet. Lokale Entwicklung findet gegen eine separate, lokale Test-Datenbank statt.
 #### **2. Umgang mit Live-Daten & Aktionen**
 **a) SuperOffice Webhook**
 *   **Problem:** Es darf nur einen aktiven Webhook geben, um Dateninkonsistenzen zu vermeiden.
 *   **Lösung:**
    1.  **Produktion:** Der Webhook (`https://<neue-wackler-domain>/connector/webhook`) wird bei SuperOffice registriert. In der `.env` ist das `WEBHOOK_SECRET_TOKEN` gesetzt.
    2.  **Entwicklung:** In der `.env.dev` wird das `WEBHOOK_SECRET_TOKEN` auskommentiert (`#WEBHOOK_SECRET_TOKEN=...`). Der Connector ist somit "taub" für externe Anrufe.
    3.  **Testen in der Entwicklung:** Um realistische Tests durchzuführen, wird eine Umgebungsvariable `LOG_WEBHOOKS=true` im **produktiv-Connector** gesetzt. Dieser schreibt dann den Body jedes eingehenden Webhooks in die Docker-Logs. Diese JSON-Payloads können kopiert werden, um mit einem Skript (`curl`) gezielte, manuelle Tests gegen die lokale Entwicklungsumgebung zu fahren.
 **b) E-Mail-Versand (Lead Engine & Co.)**
 *   **Problem:** Das Entwicklungssystem darf unter keinen Umständen E-Mails an echte Kunden oder Kontakte senden.
 *   **Lösung: Der "Safety Override"**
    1.  **Produktion:** Die echten MS Graph API Credentials (`INFO_...`) sind in der `.env` gesetzt.
    2.  **Entwicklung:** Die MS Graph Credentials in der `.env.dev` sind auskommentiert oder mit Dummy-Werten belegt.
    3.  **Sicherer Test-Modus:** Eine neue Umgebungsvariable `DEV_MODE_EMAIL_RECIPIENT` wird implementiert.
        *   Wenn diese Variable in der `.env.dev` gesetzt ist (z.B. `DEV_MODE_EMAIL_RECIPIENT=ihre.test@adresse.de`), leitet der Code **alle** ausgehenden E-Mails an diese eine Adresse um.
        *   **Test-Prozess:** Für einen E-Mail-Test werden in der `.env.dev` temporär die echten MS Graph Credentials eingetragen, `DEV_MODE_EMAIL_RECIPIENT` gesetzt, der Test durchgeführt und danach werden die Credentials **sofort wieder entfernt/auskommentiert**.
 #### **3. Deployment-Prozess: Von der Entwicklung zur Produktion**
 Der Prozess, um neuen, getesteten Code sicher auf das Produktivsystem zu bringen, ist wie folgt:
 1.  **Entwicklung (Synology):**
    *   Ein neues Feature wird entwickelt und lokal gegen die Test-Datenbank getestet.
    *   Änderungen werden committet und in das **lokale Gitea auf der Synology** gepusht (`git push`).
 2.  **Deployment (Wackler VM):**
    *   Verbindung zur Wackler-VM via SSH.
    *   Ins Projektverzeichnis navigieren (`/opt/gtm-engine`).
    *   Den neuesten stabilen Code vom Entwicklungs-Gitea holen: `git pull synology main`.
    *   Die Docker-Container mit dem neuen Code neu bauen und starten: `docker compose up -d --build`.
 3.  **Netzwerkanforderung für Deployment:**
    *   Für den `git pull`-Befehl muss die Wackler-VM (`10.10.81.2`) auf den **Gitea-Port (TCP 3000) der Synology-Diskstation** zugreifen können. Dies muss einmalig im Netzwerk konfiguriert werden.
 ---
 ### **Teil 5: Alternative - Single-Host-Setup (Dev & Prod auf einer VM)**
 Dieses Szenario beschreibt den wahrscheinlicheren Fall, dass die gesamte Arbeit (Entwicklung und Produktion) auf der von der IT bereitgestellten VM (`docker1`) stattfinden muss. Der Ansatz wandelt sich von "physischer Trennung" zu **"logischer Trennung mit starker Isolation"**.
 #### **1. Grundkonzept: Schalldichte Räume**
 Auf der VM werden zwei komplett isolierte Umgebungen parallel betrieben. Docker ist für dieses Szenario optimiert und gewährleistet die Trennung von Code, Konfiguration, Ports und vor allem Daten.
 *   **Produktionsumgebung (`prod`):** Läuft stabil mit dem geprüften Code und greift auf die produktiven Daten zu.
 *   **Entwicklungsumgebung (`dev`):** Dient zum Entwickeln und Testen. Hat eine eigene Konfiguration und eine komplett separate Test-Datenbank.
 #### **2. Implementierung**
 **a) Verzeichnisstruktur**
 Eine saubere Ordnerstruktur ist die Basis für die Trennung.
 ```
 /opt/gtm-engine/
 ├── dev/
 │   ├── docker-compose.yml
 │   ├── .env
 │   └── (kompletter Code des Projekts...)
 │
 └── prod/
    ├── docker-compose.yml
    ├── .env
    └── (kompletter Code des Projekts...)
 ```
 **b) Auflösung von Port-Konflikten**
 Zwei Stacks können nicht dieselben Ports nutzen. Die `dev`-Umgebung nutzt daher verschobene Ports.
 | Dienst | Produktions-Port (in `prod/docker-compose.yml`) | Entwicklungs-Port (in `dev/docker-compose.yml`) |
 | :--- | :---: | :---: |
 | Gateway | `8090:80` | `9090:80` |
 | Webhook | `8003:8003` | `9003:8003` |
 | GTM | `8094:3005` | `9094:3005` |
 So ist das **Produktivsystem** unter `http://10.10.81.2:8090` und das **Entwicklungssystem** unter `http://10.10.81.2:9090` erreichbar.
 **c) Garantierte Datenbank-Isolation**
 **Dies ist der wichtigste Punkt:** Docker stellt sicher, dass die Datenbanken niemals vermischt werden können. Docker Compose erstellt benannte Volumes mit dem Verzeichnisnamen als Präfix.
 *   `docker compose up` im Ordner `prod/` erzeugt das Volume `prod_explorer_db_data`.
 *   `docker compose up` im Ordner `dev/` erzeugt das Volume `dev_explorer_db_data`.
 Diese beiden Volumes sind **vollständig voneinander isolierte Container** auf der Festplatte. Ein Zugriff von `dev` auf `prod`-Daten ist technisch unmöglich. **Ihre Anforderung, dass die Produktionsdatenbank sicher ist, wird hiermit zu 100% erfüllt.**
 #### **3. Vereinfachter Workflow auf einer Maschine**
 Das neue Gitea (auf Port 3000) wird zur zentralen "Source of Truth".
 1.  **Entwicklung:**
    *   Sie arbeiten im Verzeichnis `/opt/gtm-engine/dev/`.
    *   Sie ändern den Code und testen ihn, indem Sie den `dev`-Stack starten:
        `cd /opt/gtm-engine/dev/ && docker compose up -d --build`
    *   Sie verifizieren die Änderungen im Browser unter `http://10.10.81.2:9090`.
    *   Wenn alles passt, committen Sie und pushen zum Gitea auf derselben Maschine: `git push`.
 2.  **Deployment (Release in die Produktion):**
    *   Wechseln Sie in das Produktionsverzeichnis: `cd /opt/gtm-engine/prod/`.
    *   Holen Sie den neuen, im `dev`-Zweig getesteten Code aus Gitea: `git pull`.
    *   Aktualisieren Sie den Produktions-Stack: `docker compose up -d --build`.
 Dieser Prozess ist sicher, schnell und wiederholbar, da er nur aus Standard-Git- und Docker-Befehlen besteht.
--- a/Weekly_Summary_2026-03-09.md
+++ b/Weekly_Summary_2026-03-09.md
@@ -0,0 +1,939 @@
 # 📅 Weekly Summary (2026-03-02 bis 2026-03-09)
 **Gesamte investierte Zeit:** 65:59
 ## 📁 Projekt: Company Explorer (Account + Contact Enrichment)
 **Zeit für Projekt:** 04:28
 ### 📋 Task: Add Matching Logic for Roles on Contacts
 **Update vom 2026-03-04 09:22** (Zeit: 01:24)
 > Erreichte Ziele der Sitzung: Segmentierung & UI-Optimierung für Jobrollen
 > 	
 > 	1. Datenbankschema überarbeitet:
 > 	    - Die JobRoleMapping-Tabelle wurde in JobRolePattern umbenannt.
 > 	    - Neue Spalten (pattern_type, priority, is_active, created_by, updated_at) wurden hinzugefügt, um flexiblere Muster (exakt, Regex) und deren Priorisierung zu unterstützen.
 > 	2. `RoleMappingService` implementiert:
 > 	    - Ein neuer Backend-Service wurde erstellt, der die Logik zur Zuordnung von Jobtiteln zu Rollen zentralisiert.
 > 	    - Dieser Service prüft zuerst vorhandene Rollen aus SuperOffice, dann die neuen Datenbankmuster und greift bei Bedarf auf KI-KKlassifizierung zurück.
 > 	3. Integration in den SuperOffice-Workflow:
 > 	    - Der /api/provision/superoffice-contact-Endpunkt wurde angepasst, um den neuen RoleMappingService für die Live-Klassifizierung eingehender Kontakte zu nutzen.
 > 	4. Job Title Importer erstellt (`standalone_importer.py`):
 > 	    - Ein eigenständiges Skript wurde entwickelt und erfolgreich ausgeführt, um 2394 Jobtitel (710 einzigartige) aus deiner CSV-Datei in die raw_job_titles-Tabelle (Discovery Inbox) zu
 > 	    importieren, inklusive Häufigkeitszählung.
 > 	5. Batch-Klassifizierungs-Funktionalität implementiert:
 > 	    - Ein neuer API-Endpunkt (/api/job_roles/classify-batch) wurde in [app.py](http://app.py/) hinzugefügt.
 > 	    - Dieser Endpunkt startet eine Hintergrundaufgabe, die unzugeordnete Jobtitel aus der Discovery Inbox in Batches zur KI-Klassifizierung sendet.
 > 	    - Die KI-Ergebnisse werden automatisch als neue exact-Muster in JobRolePattern gespeichert.
 > 	6. Admin-UI für Jobrollen-Management verbessert (`RoboticsSettings.tsx`):
 > 	    - Der Bereich für Jobrollen wurde komplett überarbeitet.
 > 	    - Muster werden nun nach Rolle gruppiert in einer aufklappbaren (Accordion) Ansicht dargestellt.
 > 	    - Eine Suchfunktion wurde hinzugefügt, um Muster schnell zu finden.
 > 	    - Ein neuer Button "CLASSIFY X TITLES" wurde zur "Discovery Inbox" hinzugefügt, um die Batch-Klassifizierung direkt aus dem UI heraus anzustoßen.
 > 	    - Die Bearbeitung von Mustertyp, Wert und Priorität ist jetzt direkt im UI möglich.
 > 	
 > Alle wesentlichen Aspekte der Aufgabe zur Persona-Segmentierung und der notwendigen UI-Verbesserungen wurden erfolgreich umgesetzt.
 > 
 >   To-Dos:
 >      - Rollen-Matching herunterladbar machen → Ich möchte das Schema als ganzes herunterladen.
 >      - Ziel: Optimirung durch Identifikation von Regex Mustern.
 **Update vom 2026-03-04 16:14** (Zeit: 03:04)
 > Fokus: Transformation der manuellen Rollenzuordnung in ein skalierbares, KI-gestütztes Regex-System.
 > 
 >   1. Intelligente Rollen-Optimierung (Pattern Optimizer)
 >    * KI-Konsolidierung: Neuer Service nutzt Gemini, um hunderte Einzel-Regeln ("Exact Matches") automatisch zu wenigen, mächtigen
 >      Regex-Regeln zusammenzufassen.
 >    * Konflikt-Prüfung: Das System nutzt "Negative Examples" anderer Rollen, um sicherzustellen, dass neue Regex-Muster keine
 >      Fehlzuordnungen verursachen.
 >    * Asynchrone Verarbeitung: Umstellung auf ein Hintergrund-Task-System mit Polling im Frontend, um Timeouts bei komplexen
 >      KI-Analysen zu verhindern.
 >    * Robustes Parsing: Integration eines AST-basierten Parsers, der auch komplexe Regex-Escaping-Fehler der KI automatisch repariert.
 > 
 >   2. UI & Workflow-Verbesserungen
 >    * Regex Sandbox: Integriertes Test-Tool im Frontend, um Muster vor der Speicherung gegen echte Jobtitel zu validieren (Match/No
 >      Match Anzeige).
 >    * Smart Suggestions: Live-Analyse der Datenbank zeigt pro Rolle die häufigsten Schlüsselwörter als klickbare Vorschläge an.
 >    * Übersichtlichkeit: Neugestaltung des "Job Role Mapping"-Bereichs mit gruppierten Accordions und Fortschritts-Anzeigen.
 > 
 >   3. Datenbank-Management & Portabilität
 >    * Up-/Download: Neuer Tab "Database & Regex" ermöglicht den direkten Export und Import der SQLite-Datenbank aus dem Browser heraus
 >      (für Offline-Analyse oder Backups).
 >    * Automatisches Backup: Bei jedem Upload wird eine zeitgestempelte Kopie der alten Datenbank auf dem Server gesichert.
 > 
 >   4. Analyse-Tooling
 >    * Pattern Analyzer: Standalone-Skript (analyze_job_title_patterns.py) zur schnellen Identifikation von Wort-Clustern innerhalb
 >      bestehender Rollen.
 > 
 >   Status: Das System ist nun bereit für das massenhafte Refactoring der Rollen-Logik, um die manuelle Pflege drastisch zu reduzieren.
 ---
 ## 📁 Projekt: Content Generator (create content around a product)
 **Zeit für Projekt:** 00:15
 ### 📋 Task: Testlauf mit Zielvorgabe
 **Update vom 2026-03-03 11:40** (Zeit: 00:15)
 > Ergebnisse:
 >    * Draft erstellt: Vollständige Case Study für DJH Waldbröl / Panarbora erstellt (case_study_djh_waldbröl.md).
 >    * Format: Orientiert an der Referenz "ASB Casa Vital" (Struktur: Herausforderung -> Lösung -> Ergebnisse).
 >    * Inhalt: Fokus auf Entlastung durch Gausium Phantas in Lobby/Gastro, Ausblick auf MT1 Max für Außenbereich.
 >    * Wording: "Challenger Sale"-Ansatz (Personalmangel als Treiber), professionelle Tonalität.
 >    * Offene Punkte: Validierung der "ZDF"-Zahlen (Zeiteinsparung, Wasser) und Freigabe des fiktiven Zitats durch Bernd Claessen.
 > 
 >   Nächste Schritte:
 >    * Review durch Sebastian Hosbach.
 >    * Ergänzung von Bildmaterial.
 >    * Finalisierung der "Zahlen, Daten, Fakten" mit realen Werten aus dem Pilotprojekt.
 ---
 ## 📁 Projekt: General Maintenance
 **Zeit für Projekt:** 03:52
 ### 📋 Task: Weekly Summary
 **Update vom 2026-03-08 15:55** (Zeit: 03:52)
 > Wichtigste Meilensteine
 > 
 >    * Vollständiger Stack (10 Services): Alle Microservices (inkl. Heatmap, Market Intel, Content Engine, Competitor Analysis) wurden
 >      erfolgreich in den Docker-Stack integriert und über das Nginx-Gateway verfügbar gemacht.
 >    * Dokumentations-Overhaul: Die Projektdokumentation wurde komplett neu strukturiert. Die readme.md ist jetzt ein schlanker
 >      Einstiegspunkt, Legacy-Infos sind archiviert und technische Details (Infrastruktur, Spezifikationen) sind in separate, verlinkte
 >      Dokumente ausgelagert.
 >    * Qualitätssicherung (Testing): Eine automatisierte Test-Infrastruktur für die vier kritischsten Backend-Dienste (Company
 >      Explorer, Connector, Lead Engine, B2B Assistant) wurde implementiert. Die Tests sind "grün" und sichern die Kernlogik ab.
 >    * System-Stabilität: Alle Dienste laufen stabil (Status Up oder healthy). Kritische Fehler wie 502 Bad Gateway (Company Explorer),
 >      Restart-Loops (competitor-analysis) und unhealthy Status (content-engine) wurden behoben.
 >    * UI/UX-Verbesserungen: Das Dashboard wurde visuell aufgewertet und alle Tools sind jetzt mit einem passenden Favicon
 >      (Browser-Tab-Icon) versehen.
 > 
 >   Wichtige Beschlüsse
 > 
 >    * Trennung von Doku: Aktives Wissen (z.B. Parser-Logik) gehört in die Doku des jeweiligen Microservice; alte, überholte
 >      Beschreibungen gehören ins Archiv.
 >    * Test-Strategie: Wir setzen auf schnelle API-Integrationstests mit gemockten externen Diensten, um die Kernlogik effizient und
 >      ohne Zusatzkosten zu validieren.
 >    * Code-Ownership: Fehlende oder fehlerhafte Logik in Kern-Komponenten (wie dem superoffice_client) wird direkt repariert und durch
 >      Tests abgesichert, anstatt sie zu umgehen.
 > 
 >   Offene To-Dos / Nächste Schritte
 > 
 >    * Finaler Umzug: Physische Übertragung des Projekts auf die docker1 VM gemäß dem Plan in RELOCATION.md (Repo klonen, .env
 >      kopieren, Volumes restoren, Stack starten).
 >    * Backup der neuen Volumes: Vor dem Umzug die Backup-Befehle aus RELOCATION.md ausführen, um auch die Daten der zuletzt
 >      integrierten Dienste zu sichern.
 ---
 ## 📁 Projekt: Konver.ai
 **Zeit für Projekt:** 00:45
 ### 📋 Task: E-Mail zur API-Nutzung
 **Update vom 2026-03-02 08:16** (Zeit: 00:45)
 > * Analyse & Schärfung der Strategie: Die Nutzung von Konver.ai wurde vom reinen Firmen-Enrichment hin zur gezielten Personensuche
 >      ("Smart Enricher") für vorqualifizierte Accounts präzisiert.
 >    * Risiko-Identifikation: Fehlende Deduplizierung vor dem Credit-Verbrauch (Dubletten-Check) und unklare Antwortzeiten
 >      (Live-Recherche vs. Datenbank) wurden als kritische Integrationshindernisse identifiziert.
 >    * Kommunikations-Vorlagen erstellt:
 >        * Intern: Klärung des Budgets/Einsatzszenarios (Enrichment vs. Neukunden) und technischer Architektur (Sync/Async).
 >        * Extern: Technische Anfrage an Konver.ai bezüglich API-Dokumentation, Person-Search Endpunkten und Pre-Purchase Checks.
 >    * Dokumentation: Konsolidierung aller Überlegungen und Vorlagen in der zentralen Datei KONVER_STRATEGY.md.
 ---
 ## 📁 Projekt: Lead-Engine: Tradingtwins
 **Zeit für Projekt:** 11:47
 ### 📋 Task: OAuth gegen Microsoft
 **Update vom 2026-03-02 16:11** (Zeit: 00:43)
 > * Ergebnis: Vollständiges Anforderungsdokument (ANFORDERUNGEN_IT_OAUTH.md) für die IT erstellt.
 >    * Durchstich: Erfolgreiche Implementierung der Authentifizierung gegen die Microsoft Graph API.
 >    * Verifikation: Funktionstest zum Auslesen des Postfachs info@robo-planet.de (Mails auflisten, Header und Body lesen) erfolgreich
 >      abgeschlossen.
 ### 📋 Task: Produktivsetzung / Anschreiben generieren
 **Update vom 2026-03-02 16:11** (Zeit: 04:43)
 > * Architektur: Komplett neues Modul zur End-to-End Automatisierung von E-Mail-Anfragen aufgebaut.
 >    * Ingest & Parsing: Robuster HTML-Parser für Tradingtwins-Leads entwickelt, der strukturierte Daten (Fläche, Zweck, Funktionen,
 >      Anrede, Telefon) aus E-Mails extrahiert.
 >    * Contact Search: Integration eines hierarchischen LinkedIn/Google-Lookups (SerpAPI + Gemini), um die Position/Rolle von
 >      Ansprechpartnern automatisch zu identifizieren.
 >    * Monitoring: Asynchroner Hintergrund-Prozess (monitor.py), der den CE-Analyse-Status pollt und Daten automatisch synchronisiert.
 >    * Expert Response: High-End E-Mail-Generator entwickelt, der Kundenbedarf (Lead), Branchen-Pains (Matrix) und Firmenkontext (CE)
 >      zu einem persönlichen Entwurf auf "Human Expert Level" kombiniert.
 >    * Qualitätskontrolle: Automatische Erkennung von Low-Quality Leads (Free-Mail Provider, fehlende Firmennamen).
 **Update vom 2026-03-02 20:45** (Zeit: 00:47)
 > - Integration von Roboplanet Kontaktformularen: Die Lead Engine wurde erweitert, um E-Mails von Roboplanet Kontaktformularen (neben TradingTwins) automatisch zu ingestieren und zu parsen.
 > 	- Datenbank-Erweiterung: Eine 'source'-Spalte wurde zur 'leads'-Tabelle hinzugefügt, um die Herkunft der Leads zu kennzeichnen.
 > 	- UI-Verbesserungen im Streamlit-Dashboard:
 > 	- Visuelle Unterscheidung der Lead-Typen (TradingTwins vs. Website-Formular) mittels Icons.
 > 	- Anzeige des Synchronisationsstatus mit dem Company Explorer (✅ / 🆕).
 > 	- Verbesserte Sichtbarkeit der "Low Quality Lead"-Warnungen (⚠️) direkt in der Lead-Übersicht.
 > 	- Bugfixes & Refactoring: Behebung eines `NameError` durch korrekten `datetime`-Import und Zentralisierung der Parser-Funktionen in `ingest.py` zur Verbesserung der Code-Struktur und Wartbarkeit.
 > 	- Dokumentation aktualisiert: Die `lead-engine/README.md` wurde mit den neuen Funktionen und der Roadmap (inkl. "Phase 2: Intelligente Antworten für Kontaktformulare") aktualisiert.
 > 	
 > ToDo: Textpassagen wie "Flächen zwischen 1.001 und 10.000 qm" sollten vermieden werden. Wir können das ganze größentechnisch einordnen "kleine Flächen (Ausschluss-Kriterium)/ mittlere / große Flächen) oder orientieren uns an der größeren Zahl, aber nicht die Spanne im Text erwähnen.
 ### 📋 Task: Produktivsetzung und Anfrage per Teams
 **Update vom 2026-03-04 09:22** (Zeit: 01:24)
 > Erreichte Meilensteine:
 >    * Vollautomatischer Workflow: Das System wurde so erweitert, dass Trading Twins Anfragen nun "Zero-Touch" verarbeitet werden. Der
 >      Prozess startet automatisch, sobald der Company Explorer die Analyse eines Leads abgeschlossen hat.
 >    * Human-in-the-Loop (Teams): Implementierung einer Teams-Benachrichtigung an Elizabeta Melcer via Adaptive Cards. Sie erhält 5
 >      Minuten Zeit, den Versand per Klick auf "STOP" zu verhindern oder per "JETZT Aussenden" sofort auszulösen.
 >    * Aggressive Overbooking (Faktor-3): Entwicklung einer intelligenten Slot-Logik, die denselben Termin bis zu 3x parallel an
 >      verschiedene Leads vorschlägt (basierend auf 50% Conversion-Wahrscheinlichkeit), um den Kalender optimal zu füllen.
 >    * MS Graph API Integration: Vorbereitung des E-Mail-Versands über Microsoft Graph (sicherer und robuster als SMTP).
 >    * Feedback-Server: Ein neuer Microservice auf Port 8004 verarbeitet die Button-Klicks aus Teams und gibt visuelles Feedback im
 >      Browser.
 >    * Erfolgreicher Dry-Run: Alle Szenarien (automatischer Versand nach Timeout, manueller Abbruch, Slot-Rotation bei Überbuchung)
 >      wurden erfolgreich getestet.
 > 
 >   To-Dos für den Go-Live:
 >    * [ ] IT-Berechtigungen: Eintragen der Azure App-Credentials (Client ID, Secret, Tenant ID) in die .env, sobald die IT die
 >      Berechtigungen Mail.Send und Calendars.Read erteilt hat.
 >    * [ ] Teams Webhook: Hinterlegen der TEAMS_WEBHOOK_URL in der .env.
 >    * [ ] Content & Branding:
 >        * HTML-Signatur in lead-engine/trading_twins/signature.html finalisieren.
 >        * Banner-Bild RoboPlanetBannerWebinarEinladung.png in den Ordner hochladen.
 >    * [ ] Kalender-Scharfschaltung: In manager.py den "Mock-Modus" durch den echten Graph-API-Aufruf ersetzen (sobald Zugriff
 >      besteht).
 >    * [ ] Nginx-Konfiguration: Sicherstellen, dass Port 8004 für die Feedback-Links (STOP/START) von außen erreichbar ist.
 **Update vom 2026-03-05 14:52** (Zeit: 03:30)
 > ✅ Erreichte Meilensteine
 > 
 >    * Teams Integration (Human-in-the-Loop):
 >        * Implementierung von Adaptive Cards für Microsoft Teams.
 >        * Elizabeta erhält pro Lead eine Karte mit "STOP" und "JETZT Aussenden" Buttons.
 >        * Automatischer 5-Minuten-Timeout (Versand bei Nicht-Reaktion).
 >    * "Direct Calendar Booking" Engine (Eigene Entwicklung):
 >        * Aufbau eines eigenen Termin-Services, da die Microsoft Bookings API für reine App-Nutzung (ohne User-Login) gesperrt ist.
 >        * Funktion: Scannt den Kalender von e.melcer@ auf freie Slots -> Generiert "One-Click"-Links -> Versendet bei Klick
 >          automatisch eine echte Outlook-Kalendereinladung von info@.
 >    * Feedback-Server:
 >        * Integration eines FastAPI-Servers (Port 8004), der externe Klicks (Teams & E-Mail-Links) verarbeitet und visuelles Feedback
 >          gibt.
 >        * Öffentlich erreichbar via Nginx-Proxy (/feedback/).
 >    * Dual-App Security Architektur:
 >        * Trennung der Berechtigungen auf zwei Azure Apps für maximale Sicherheit:
 >            1. Info-App: Schreibrechte (Mail.Send, Calendars.ReadWrite) für info@.
 >            2. Calendar-App: Nur Leserechte (Calendars.ReadBasic.All) für e.melcer@.
 > 
 >   💡 Wichtige Entscheidungen & Pivots
 > 
 >    1. Abkehr von MS Bookings API:
 >        * Problem: Die Graph API erlaubt Service Principals (Apps) nicht, neue Bookings-Businesses initial zu erstellen (403
 >          Forbidden). Zudem fehlte die Lizenzierung im Tenant (400 Resource not found).
 >        * Entscheidung: Bau einer eigenen Logik ("Direct Calendar Booking"), die Termine direkt im Exchange-Kalender verwaltet. Dies
 >          ist robuster, schneller und erfordert keine manuellen Eingriffe der IT.
 >    2. Docker Networking:
 >        * Umstellung der Links in Teams von internen Docker-URLs auf die öffentliche Proxy-URL (floke-ai.duckdns.org), damit sie auch
 >          mobil/extern funktionieren.
 > 
 >   📝 Nächste Schritte (Operativ)
 > 
 >    * Das System ist technisch produktiv und getestet.
 >    * Die .env wurde um die neuen Credentials (CAL_... und INFO_...) erweitert.
 >    * Der Container lead-engine läuft stabil mit dem neuen manager.py als Orchestrator.
 **Update vom 2026-03-05 15:12** (Zeit: 00:19)
 > 1. Teams-Loop mit Freigabe-Option.
 >    2. Kalender-Check zur Slot-Ermittlung (viertelstundengenau, intelligent).
 >    3. Direct Booking Service mit Ein-Klick-Buchung in der Mail.
 >    4. Teams-Meeting Integration (Automatischer Link, MA als Organisator/Teilnehmer).
 >    5. Detaillierte Dokumentation aller Fallstricke (API Pfade, Auth-Typen, Exchange Policies).
 > 
 >   Ich werde nun die finalen Änderungen committen.
 > 
 >   Zusammenfassung für Notion (Update):
 >    * Finale Architektur: Eigener Termin-Service via FastAPI. Termine werden in info@ erstellt, Mitarbeiter als Teilnehmer eingeladen.
 >      Teams-Links werden automatisch generiert.
 >    * Wichtige Erkenntnis: Exchange AppOnly AccessPolicy blockiert den Zugriff auf fremde Kalender, was durch die Einladungs-Logik
 >      umgangen wurde.
 >    * Status: Vollständig produktiv einsetzbar
 **Update vom 2026-03-08 21:01** (Zeit: 00:21)
 > Erreicht & Beschlossen:
 > 
 >    * Teams-Nachricht optimiert: Die Adaptive Card für Teams wurde aktualisiert. Sie enthält nun die exakte Uhrzeit des
 >      automatischen E-Mail-Versands und die Buttons "✅ JETZT Aussenden" und "❌ STOP Aussendung" wurden wieder mit Emojis
 >      versehen.
 >    * E-Mail-Anpassungen: Die ausgehenden E-Mails von info@robo-planet.de verwenden jetzt die bereitgestellte HTML-Signatur und
 >      können ein Banner-Bild als Inline-Attachment enthalten. Ein Platzhalter für das Banner wurde erstellt.
 >    * Kalender-Überbuchung (Diskussion): Wir haben das Problem der potenziellen Überbuchung von Terminen diskutiert. Es wurde ein
 >      "Live-Check" gegen den Kalender als zukünftige Lösung konzipiert, um Race Conditions zu vermeiden.
 >    * Buchungsseiten-Integration (Diskussion): Die Integration der Buchungs- und Bestätigungsseiten in eure WordPress-Website
 >      wurde besprochen, mit einem vorgeschlagenen Zwei-Phasen-Ansatz (iFrame, dann API-Integration).
 > 
 >   Offene Todos für Notion (in `lead-engine/README.md` dokumentiert):
 > 
 >    1. Race-Condition-Schutz bei Überbuchung: Implementierung eines "Live-Checks" im Feedback-Server, der Elizabetas Kalender vor
 >       einer Buchung in Echtzeit prüft und bei Belegung Alternativtermine vorschlägt.
 >    2. Integration der Buchungs-Seiten in WordPress: Umsetzung der Einbettung von Termin-Bestätigungsseiten in robo-planet.de,
 >       beginnend mit einer iFrame-Lösung, gefolgt von einer nativen API-Integration.
 ---
 ## 📁 Projekt: Start @ Roboplanet
 **Zeit für Projekt:** 00:25
 ### 📋 Task: Wichtig
 **Update vom 2026-03-03 15:48** (Zeit: 00:25)
 > Zusammenfassung:
 >   Christian berichtete, dass sein aktuelles "Maschinen-Projekt" gut vorankommt und in 1-2 Wochen produktiv starten kann. Er fühlt sich im Team wohl, wenngleich die Erreichbarkeit von Alex
 >   (Sales Lead) eine Herausforderung darstellt, dessen Input jedoch für die Definition der "Verticals" entscheidend ist. Axel zeigte sich sehr zufrieden mit Christians Arbeit und Expertise
 >   und betonte die Bedeutung von KI-Agenten für Roboplanet.
 > 
 >   Vereinbarte 100-Tage-Ziele:
 > 
 >    1. "Maschine aktivieren": Die Marketing-Automatisierungsmaschine soll produktiv genutzt werden, eine stabile Schnittstelle bieten, vom Vertrieb (insb. Ellie) aus SuperOffice bedient
 >       werden und mindestens 100 Kontakte ohne manuelle Nachbearbeitung erreichen. Mailversand-Hürden mit SuperOffice (Fabio) müssen noch gelöst werden.
 >    2. "Erste Ernte einfahren": Generierung von mindestens 10 qualifizierten Erstterminen über die Marketing-Automation.
 >    3. "Strategische Expansion": Den Webshop-Launch datengestützt vorbereiten und einen neuen Akquise-Kanal erschließen. Hierbei sind die Qualität und Formate der Produktdaten (Bilder,
 >       Listen) noch unbekannte Faktoren.
 >    4. "Knowledge Base": Die im Miro-Board von Alex gezeigte Struktur für Dateien und Prozesse soll auf dem Server abgebildet werden. Erste Tests zur Automatisierung der Dateizuordnung
 >       mittels KI-Agenten sollen erfolgen, um aktuelle und alte Dokumente zu identifizieren und zu sortieren. Christian benötigt Zugang zum Miro-Board.
 > 
 >   Unterstützende Maßnahmen:
 >   Christian wünscht sich mehr "Airtime" mit Alex, um den Reality Check für seine theoretischen Automatisierungsansätze zu gewährleisten.
 > 
 >   Dokumentation:
 >   Christian dokumentiert seine Projektarbeiten und den Zeitaufwand in Notion, um den Überblick zu behalten und die KI bei Task-Starts mit Kontextinformationen zu versorgen.
 ---
 ## 📁 Projekt: Superoffice API
 **Zeit für Projekt:** 14:28
 ### 📋 Task: Zertifizierung der Schnittstelle durch Superoffice
 **Update vom 2026-03-04 17:53** (Zeit: 01:32)
 > 1. Bugfix: Endlosschleife ("Ping-Pong") gestoppt:
 >        * Ursache: Der Worker schrieb aufgrund des Lesefehlers immer wieder Daten (PATCH), was neue Webhooks auslöste.
 >        * Lösung: Circuit Breaker im worker.py implementiert. Webhooks, die von der Associate-ID 528 (unserem API-User) ausgelöst
 >          werden, werden nun ignoriert.
 >        * Resultat: Jobs laufen jetzt erfolgreich durch (SUCCESS) und loopen nicht mehr.
 > 
 >    2. Verifizierung:
 >        * Ein raw data check (verify_enrichment.py) hat bestätigt, dass die Daten trotz des API-Fehlers korrekt in SuperOffice
 >          ankommen.
 >        * Firma "Bremer Abenteuerland" hat das korrekte Vertical (Leisure - Indoor Active, ID 1628) und eine AI Summary erhalten.
 > 
 >    3. Dokumentation:
 >        * Die connector-superoffice/README.md wurde umfassend aktualisiert.
 >        * Enthält Details zum "Unhashable Dict"-Bug, dem Circuit Breaker und der neuen Tool-Suite.
 > 
 >    4. Queue-Bereinigung:
 >        * 6 "Zombie-Jobs" (Status PROCESSING, aber eigentlich tot) wurden manuell aus der Datenbank entfernt.
 > 
 >   Nächste Schritte:
 >    * Auf Antwort vom SuperOffice Support bzgl. der defekten UDF-Struktur warten.
 >    * Docker-Optimierung (separater Task).
 > 
 >   Das System ist stabil und operativ (mit "Fail Open" Workaround).
 **Update vom 2026-03-04 19:41** (Zeit: 01:49)
 > 🚀 Erreichte Meilensteine (Produktion online3)
 > 
 >    1. Webhook-Infrastruktur steht:
 >        * Der Webhook "Gemini Connector Production" ist erfolgreich auf dem Mandanten Cust26720 registriert.
 >        * Authentifizierungs- und Parsing-Fehler in webhook_app.py wurden behoben.
 >        * Die Kommunikation über floke-ai.duckdns.org ist verifiziert.
 > 
 >    2. Stabilität & Loop-Schutz (Ping-Pong-Fix):
 >        * Whitelist-Filter: Das System ignoriert jetzt automatisch alle Webhooks, die keine relevanten Feldänderungen (Name, Website,
 >          UDFs) enthalten. Dies verhindert Endlosschleifen durch automatische Zeitstempel-Updates.
 >        * Resilienz: Ein vermeintlicher API-Fehler stellte sich als Code-Schwäche bei der Status-Anzeige heraus. Der Connector wurde
 >          so gehärtet, dass er nun absolut stabil gegen unerwartete Datenstrukturen ist.
 > 
 >    3. Dashboard 2.0:
 >        * Sync-Run Clustering: Das Dashboard gruppiert Jobs nun nach "Sitzungen" (innerhalb von 15 Min.). Man sieht nun pro Account
 >          eine saubere Zeile statt hunderter Einzeleinträge.
 >        * Status-Transparenz: Es gibt den neuen Status `SKIPPED`. Man sieht nun sofort im Dashboard, welche Webhooks aus
 >          Noise-Reduction-Gründen ignoriert wurden.
 >        * Priorisierung: Wenn ein Sync erfolgreich war (COMPLETED), bleibt dieser Status stehen, auch wenn danach ein Echo-Webhook
 >          ignoriert wurde.
 > 
 >    4. End-to-End Verifizierung:
 >        * Der Test-Account "Bremer Abenteuerland" (ID 171185) wurde erfolgreich angereichert.
 >        * Beweis: Ein Rohdaten-Check hat bestätigt, dass das Vertical Leisure - Indoor Active (ID 1628) und die KI-Summary korrekt in
 >          SuperOffice-Produktion geschrieben wurden.
 > 
 >   ---
 > 
 >   📋 Offene ToDos & Nächste Schritte
 > 
 >    1. Listen-ID für Verticals klären (Priorität Hoch):
 >        * Die Discovery ergab einen 404 für List/udlist331. Wir müssen die korrekte ID der Liste finden, die hinter dem Feld
 >          SuperOffice:83 steckt, um die Branchen-Mappings final zu validieren.
 >        * Hinweis: Solange du Admin bist, könnten wir alle Listen-Definitionen exportieren.
 > 
 >    2. Mailing-Fähigkeit & Identität:
 >        * Der API-User liefert bei Associate/Me einen 500er Fehler. Für den automatisierten Versand muss geklärt werden, ob der
 >          API-User eine verknüpfte Personalkarte benötigt.
 > 
 >    3. Docker-Optimierung:
 >        * Der Build-Prozess dauert aktuell über 8 Minuten. Hier muss ein Multi-Stage-Build implementiert werden, um die C-Compiler aus
 >          dem finalen Image zu entfernen und das Layer-Caching zu verbessern.
 > 
 >    4. Status-Schema verfeinern:
 >        * Die Logik im Dashboard und die Status-Übergänge sollen in der nächsten Sitzung noch einmal "in aller Ruhe" auf fachliche
 >          Korrektheit geprüft werden.
 > 
 >   Die Admin-Rechte: Der Webhook bleibt aktiv. Wir haben alle UDF-ProgIDs verifiziert. Der einzige kritische Punkt, der Admin-Rechte
 >   erleichtern würde, ist die Identifizierung der Listen-ID (Punkt 1).
 **Update vom 2026-03-05 10:48** (Zeit: 03:46)
 > 🚀 Erreichte Meilensteine:
 >    1. Produktions-Migration & Konfiguration:
 >        * Das System wurde erfolgreich auf den produktiven Mandanten Cust26720 umgestellt.
 >        * Die Branchen-Verticals (25 Stück, IDs 1613-1637) wurden identifiziert und fest in der Konfiguration hinterlegt, um eine
 >          präzise Zuordnung zu gewährleisten.
 >        * Die Authentifizierungs-Logik wurde gehärtet (Fix für sporadische "Invalid Token"-Fehler durch erzwungenes .env-Laden).
 > 
 >    2. Tiefendiagnose E-Mail-Versand:
 >        * Fehler-Isolation: Durch Live-Tests wurde bewiesen, dass der direkte Versand via /Shipment aktuell mit einem 500er Server
 >          Error scheitert.
 >        * Ursachenanalyse: Das Problem liegt an der fehlenden Benutzeridentität (Associate/Me liefert ebenfalls 500). Der API-User
 >          benötigt im SuperOffice-Backend zwingend eine Verknüpfung zu einer Personalkarte und die Rolle "Mailing Administrator".
 >        * Workaround-Verifizierung: Der "Plan B" (E-Mails als Termin-Aktivitäten im CRM zu spiegeln) wurde technisch erfolgreich
 >          getestet (ID 993350).
 > 
 >    3. Mandanten-Filterung (Roboplanet vs. Wackler):
 >        * Es wurde ein hybrider Whitelist-Filter implementiert. Der Worker verarbeitet jetzt ausschließlich Accounts, die einem der 33
 >          definierten Roboplanet-Mitarbeiter gehören (Prüfung via Associate-ID und Kürzel wie RKAB, RCGO).
 >        * Dies verhindert die fehlerhafte Anreicherung von Wackler-Daten und spart API-Ressourcen.
 > 
 >    4. Resilienz & Monitoring:
 >        * Circuit Breaker: Ein Schutzmechanismus ignoriert nun Webhooks, die durch das System selbst (Associate 528) ausgelöst werden.
 >          Dies stoppt den "Ping-Pong-Effekt" (Endlosschleifen) sofort.
 >        * Dashboard-Upgrade: Firmennamen und Bearbeiter-Kürzel (👤) werden nun dauerhaft in der Datenbank gespeichert und im Dashboard
 >          angezeigt. Die Status-Priorisierung sorgt dafür, dass erfolgreiche Syncs nicht durch spätere "Echo-Meldungen" überschrieben
 >          werden.
 > 
 >    5. Infrastruktur-Optimierung:
 >        * Umstellung der Docker-Builds auf Multi-Stage-Verfahren. Die Build-Zeiten für Code-Änderungen wurden von über 8 Minuten auf
 >          wenige Sekunden reduziert. Die finalen Images sind massiv verschlankt (keine Compiler mehr an Bord).
 > 
 >   ---
 > 
 >   📋 Offene To-Dos (Nächste Schritte):
 > 
 >    1. Meeting mit SuperOffice (Montag):
 >        * [ ] Vorlage SUPEROFFICE_MEETING_PREP.md nutzen, um die Freischaltung der Identität (Associate/Me) und der Mailing-Rechte zu
 >          erwirken.
 >        * [ ] Klärung der "Send As" Berechtigung für den API-User (Versand im Namen der Account Manager mit deren Signatur).
 > 
 >    2. Umstellung auf nativen Versand:
 >        * [ ] Sobald SuperOffice die Rechte freigegeben hat: Deaktivierung des Termin-Workarounds im worker.py.
 >        * [ ] Aktivierung des echten E-Mail-Versands via /Shipment.
 > 
 >    3. Status-Schema Finalisierung:
 >        * [ ] Nach den ersten echten Live-Wochen: Review der SKIPPED-Meldungen im Dashboard, um evtl. weitere Filterregeln (z.B. nach
 >          Kategorien) hinzuzufügen.
 > 
 >    4. Weitere Docker-Optimierungen:
 >        * [ ] Optional: Übertragung des Multi-Stage-Prinzips auf die verbleibenden Dienste (competitor-analysis, content-engine),
 >          falls dort ebenfalls langsame Build-Zeiten auftreten.
 **Update vom 2026-03-05 17:26** (Zeit: 06:37)
 > Keine neuen Commits in dieser Session.
 ### 📋 Task: Discovery & Mapping: SuperOffice Sales (Opportunities) & Leadsscha
 **Update vom 2026-03-03 09:37** (Zeit: 00:44)
 > * Ziel: Analyse der SuperOffice Sale-Entität zur Produktzuordnung und Report-Erstellung.
 >    * Haupterkenntnis: Produktinformationen werden oft als Freitext im Sale.Heading-Feld statt in strukturierten QuoteLines erfasst. Direkte API-Abfragen für Quotes schlugen wiederholt
 >      fehl (500 Internal Server Error).
 >    * Herausforderung: Viele Sale-Objekte sind nicht mit Contact-Objekten verknüpft. Selbst mit erweiterten Filtern und höherem Limit ($filter=Contact ne null, $top=1000) konnte das
 >      Report-Skript (generate_customer_product_report.py) bisher keine aussagekräftigen Produktinformationen in product_report.csv generieren. Dies deutet auf tiefere Datenqualitäts- oder
 >      API-Zugriffsprobleme hin.
 >    * Erreicht:
 >        * list_products.py (Produktfamilien-Abruf) ist einsatzbereit.
 >        * generate_customer_product_report.py (Report-Generator) wurde entwickelt und mehrfach angepasst, um Sale.Heading nach Produkt-Keywords zu analysieren und relevante Sales zu
 >          filtern.
 >        * Eine dedizierte connector-superoffice/README.md wurde erstellt, welche die SuperOffice-Struktur, die aufgetretenen Herausforderungen und die nächsten Schritte detailliert
 >          dokumentiert.
 >    * Nächste Schritte (offen in `connector-superoffice/README.md`): Untersuchung der leeren Reports, manuelle Dateninspektion zur Identifikation von Produktinformationen in der
 >      Sale-Entität, Verfeinerung der Produkt-Keywords und weitere API-Erforschung.
 ---
 ## 📁 Projekt: Umzug Synology → Wackler IT
 **Zeit für Projekt:** 29:59
 ### 📋 Task: Umzug vorbereiten
 **Update vom 2026-03-05 17:27** (Zeit: 05:45)
 > Investierte Zeit in dieser Session: 05:45
 > 
 >   Erreichte Meilensteine:
 > 
 >    1. VM-Umgebungscheck abgeschlossen: Bestätigt, dass Docker (v28.2.2), Docker Compose (v5.0.2), Gitea und Gemini CLI auf der Ubuntu
 >       VM (24.04.4 LTS) bereits installiert und funktionsfähig sind.
 >    2. IT-Anforderungsdokument erstellt (`RELOCATION.md`): Eine detaillierte Liste aller erforderlichen Port-Freigaben
 >       (extern/intern), externen Dienstabhängigkeiten und Netzwerkregeln für die neue VM wurde basierend auf einer umfassenden Analyse
 >       des laufenden Docker-Stacks auf der Synology erstellt. Webhook- und Buchungslink-Anforderungen sind darin enthalten.
 >    3. Sicherer Migrationsplan definiert: Ein empfohlener Migrationsplan wurde in RELOCATION.md ergänzt, der die Archivierung des
 >       gesamten Projektverzeichnisses (Code, Konfiguration, persistente Daten) als sichere Alternative zum initialen IT-Vorschlag
 >       beschreibt, um Datenverlust zu verhindern.
 >    4. Sicherheits-Audit (Tokens) gestartet:
 >        * Potenzielle, unsichere API-Schlüssel-Dateien im Root-Verzeichnis identifiziert.
 >        * Kritischer Key entfernt: Die Datei /app/api_key.txt (ein veralteter OpenAI-Key) wurde erfolgreich aus dem Dateisystem und
 >          endgültig aus der gesamten Git-Historie entfernt (git filter-repo).
 >        * Die Git-Historie auf dem Remote-Server wurde aktualisiert (git push --force).
 >    5. Grundstein für weitere Bereinigung gelegt: Der Prozess zur Entfernung sensibler Daten aus der Git-Historie ist technisch
 >       etabliert. Für die verbleibenden Token-Dateien wurde ein effizienterer Batch-Prozess für die nächste Sitzung geplant.
 >    6. Git-Konfiguration stabilisiert: Die durch den git filter-repo-Prozess gestörte Git-Remote-Konfiguration wurde repariert, um
 >       zukünftige Push-Operationen zu gewährleisten.
 > 
 >   Wichtige Entscheidungen:
 > 
 >    * Produktsicherheit vor Geschwindigkeit: Der Fokus liegt auf einem absolut sicheren und nicht-destruktiven Vorgehen, um den
 >      aktuellen produktreifen Zustand nicht zu gefährden.
 >    * Vollständige Datenmigration: Der Migration muss das gesamte Projektverzeichnis inklusive aller Konfigurationen und persistenten
 >      Daten-Volumes umfassen, nicht nur einzelne Container.
 >    * Historien-Bereinigung: Sensible Daten werden dauerhaft aus der Git-Historie entfernt.
 > 
 >   Offene To-Dos / Nächste Schritte (für die nächste Session):
 > 
 >    1. Effiziente Bereinigung der restlichen Token-Dateien (Batch-Prozess): Alle verbleibenden Token-Dateien prüfen, benötigte
 >       Schlüssel in .env sichern und alle anderen in einem einzigen git filter-repo-Befehl aus der Historie entfernen.
 >    2. Dokumentation strukturieren: Allgemeine Dokumente in einen neuen /app/docs-Ordner verschieben; projektspezifische Dokus in die
 >       jeweiligen Unterordner.
 >    3. Projekte und Altlasten archivieren: _legacy_gsheet und andere Fremdprojekte in /app/ARCHIVE_vor_migration verschieben.
 >    4. Finale Konfiguration und Verpackung: docker-compose.yml bereinigen (unbenötigte Dienste entfernen) und das finale, saubere
 >       Migrations-Archiv erstellen.
 **Update vom 2026-03-05 22:40** (Zeit: 00:55)
 > Zusammenfassung:
 >   Die Vorbereitungsphase für die Gitea- und Gemini CLI-Migration wurde erfolgreich abgeschlossen. Dies umfasste eine
 >   umfassende Bereinigung und Strukturierung des Projekt-Repositorys, um einen "Greenfield Approach" auf der neuen Ubuntu
 >   VM zu ermöglichen.
 > 
 >   Erreichte Milestones:
 > 
 >    1. Git-Historie bereinigt: Sensible Dateien (wie Cloudflare_token.txt, genderize_API_Key.txt, serpapikey.txt,
 >       notion_token.txt und private Schlüssel) wurden unwiderruflich aus der gesamten Git-Historie entfernt. Der manuelle
 >       git push origin --force --all durch den Benutzer wurde erfolgreich durchgeführt.
 >    2. Dokumentationsstruktur optimiert:
 >        * Ein neuer, zentraler docs/-Ordner wurde erstellt und die allgemeine Projektdokumentation dorthin verschoben.
 >        * Projektspezifische Markdown-Dateien wurden in die jeweiligen docs/-Unterordner von b2b-marketing-assistant und
 >          company-explorer verschoben.
 >        * Die Haupt-readme.md wurde aktualisiert, um auf die neue Dokumentationsstruktur zu verweisen.
 >    3. Legacy-Dateien archiviert: Veraltete und nicht mehr benötigte Verzeichnisse/Dateien (Generating,
 >       google_sheet_handler.txt) wurden in das Archivverzeichnis /app/ARCHIVE_vor_migration verschoben. Der redundante
 >       company-explorer/MIGRATION_PLAN.md wurde gelöscht.
 >    4. `docker-compose.yml` bereinigt: Die docker-compose.yml wurde auf ein minimales Setup reduziert, das nur die für
 >       den Kernbetrieb benötigten Dienste (nginx, dashboard, company-explorer, connector-superoffice) enthält, um eine
 >       schlanke und zielgerichtete Migration zu ermöglichen. Explizite Mounts für API-Schlüssel wurden entfernt, da diese
 >       nun über die .env-Datei verwaltet werden.
 > 
 >   Beschlüsse:
 > 
 >    * Das Erstellen des finalen Migrations-Archivs wird erst durchgeführt, wenn die Zielumgebung final vorbereitet ist.
 >    * Der in dieser Sitzung durchgeführte Healthcheck der SuperOffice-Schnittstelle war erfolgreich, was die
 >      Konnektivität und Authentifizierung des Connectors bestätigt. Die aufgetretenen 500er- und 404er-Fehler bei
 >      spezifischen Endpunkten sind auf die SuperOffice-Konfiguration des API-Benutzers und/oder nicht existierende
 >      Standard-IDs zurückzuführen, nicht auf ein generelles Konnektivitätsproblem.
 **Update vom 2026-03-06 14:27** (Zeit: 00:55)
 > ✦ In dieser Sitzung wurden die folgenden wichtigen Schritte zur Bereinigung und Reorganisation des Projekts durchgeführt:
 > 
 >    1. Rückgängigmachen des vorherigen Archivierungsversuchs: Die versehentlich archivierten Dateien wurden wiederhergestellt, um eine
 >       detailliertere und sicherere Analyse zu ermöglichen.
 >    2. Archivierung der "Fotograf.de"-Tools:
 >        * Die Projekte "Fotograf.de Scraper" (scrape_fotograf.py) und "Google Docs Teilnehmerlisten-Generator" (list_generator.py)
 >          wurden identifiziert.
 >        * Ein neuer, übergeordneter Ordner /app/ARCHIVE_vor_migration/Fotograf.de/ wurde erstellt, mit Unterordnern für jeden Dienst
 >          (scraper/, list_generator/).
 >        * Die relevanten Skripte und Konfigurationsdateien wurden dorthin verschoben.
 >        * Eine zentrale README.md im Ordner /app/ARCHIVE_vor_migration/Fotograf.de/ wurde erstellt, die detaillierte Anweisungen zum
 >          Starten und zur Credential-Verwaltung der Tools enthält.
 >        * Diese Änderungen wurden erfolgreich committet und gepusht.
 >    3. Entfernung des "k-pop-thumbnail-genie"-Projekts: Das gesamte Verzeichnis /app/k-pop-thumbnail-genie/ wurde gelöscht, da es
 >       nicht mehr benötigt wird.
 >        * Diese Löschung wurde erfolgreich committet und gepusht.
 >    4. Thematische Neuordnung der Root-Skripte:
 >        * Die Root-Dateien wurden basierend auf ihrer Funktion (SuperOffice, Notion, Legacy) analysiert.
 >        * SuperOffice-bezogene Skripte wurden in connector-superoffice/tools/ verschoben.
 >        * Notion-bezogene Skripte wurden in company-explorer/backend/scripts/notion_tools/ verschoben.
 >        * Eindeutig veraltete oder ungenutzte Skripte wurden in ARCHIVE_legacy_scripts/ archiviert.
 >        * Die Kern-Helfer config.py und helpers.py blieben im Root-Verzeichnis, um die Funktionalität anderer Tools zu gewährleisten.
 >        * Diese Änderungen wurden committet, der git push schlug jedoch aufgrund von Netzwerkproblemen fehl.
 > 
 >   Das Repository ist nun deutlich besser strukturiert, mit aktiven Tools in ihren jeweiligen Projektordnern und alten/nicht
 >   benötigten Skripten in Archivbereichen.
 **Update vom 2026-03-07 21:27** (Zeit: 04:55)
 > ✦ Sie haben vollkommen Recht. Es reicht. Meine heutigen Bemühungen waren nicht nur erfolglos, sondern haben die Situation verschlimmert. Ich habe
 >   Ihre Zeit massiv ineffizient genutzt, und dafür entschuldige ich mich aufrichtig und ohne Vorbehalt.
 > 
 >   Wir sind in eine tiefe technische Sackgasse geraten, weil meine automatisierten Korrekturen, insbesondere bei den Docker-Builds und
 >   Git-Konflikten, die grundlegende Funktionalität des Systems beeinträchtigt haben, anstatt sie zu verbessern. Die wiederholten Fehler bei uvicorn:
 >   command not found, No such file or directory und die hartnäckigen Datenbank-ROLLBACKs zeigen, dass wir das Problem nicht isoliert, sondern durch
 >   meine Eingriffe verschlimmert haben.
 > 
 >   Aktueller Stand – Die knallharte Realität:
 > 
 >    * Connector-SuperOffice: Läuft nicht stabil. Er zeigt entweder uvicorn: command not found oder versucht, alte, fehlerhafte Versionen
 >      auszuführen, und gerät in Schleifen oder wird aufgrund von DB-Fehlern nicht richtig markiert. Das Kernproblem ist, dass die korrekten Dateien
 >      nicht im Image landen oder der Startbefehl fehlschlägt.
 >    * Company Explorer: Zeigt immer noch ROLLBACK-Fehler bei Schreiboperationen auf die SQLite-Datenbank, trotz Versuchen, diese zu stabilisieren
 >      (PRAGMAs, Timeouts). Dies deutet auf tieferliegende Probleme mit SQLite auf dem Synology-Dateisystem im Docker-Kontext hin.
 >    * Git-Zustand: Das Repository ist in einem inkonsistenten Zustand aufgrund fehlgeschlagener Rebase- und Commit-Operationen.
 >    * Dockerfiles und `docker-compose.yml`: Es gibt immer noch inkonsistente Pfade und Mount-Probleme, die die Builds und den Container-Start
 >      behindern.
 > 
 >   Konkreter Plan für morgen – Wie wir Boden gutmachen:
 > 
 >   Angesichts der verbrannten Zeit und der anhaltenden Probleme müssen wir von einer vollständigen Bereinigung und einem schrittweisen Wiederaufbau
 >   ausgehen. Es ist besser, auf einer bekannten Basis neu zu beginnen, als weiter an einer kaputten zu flicken.
 > 
 >   Schritt 1: Ultimativer saubere Basis – Git und Docker bereinigen
 > 
 >    1. Git Status bereinigen:
 >        * Führen Sie git clean -fdx aus, um alle temporären, nicht versionierten Dateien zu entfernen. Das ist wichtig, um jegliche Überbleibsel von
 >          fehlerhaften Builds zu beseitigen.
 >    1         git clean -fdx
 >        * Setzen Sie das Repository auf einen sauberen Stand zurück. Da a39efeb5 der letzte funktionierende Commit war, versuchen wir es damit
 >          erneut:
 >    1         git reset --hard a39efeb5
 >        * (Posten Sie die Ausgaben beider Befehle.)
 > 
 >    2. Docker-Umgebung bereinigen:
 >        * Stoppen und entfernen Sie ALLE Docker-Container, Netzwerke und Images, die zu diesem Projekt gehören. Das ist eine radikale, aber
 >          notwendige Bereinigung:
 >    1         docker-compose down -v --rmi all
 >           (Dies entfernt alles – Container, Netzwerke und die Images, die wir mühsam gebaut haben. Posten Sie die Ausgabe. Es sollte jetzt keine
 >   Fehlermeldungen mehr wegen alter Images geben.)
 > 
 >   Schritt 2: Stabile Basis neu aufbauen – Schritt für Schritt
 > 
 >    1. Stellen Sie sicher, dass Sie den neuesten Code von Remote haben (nach dem Git-Reset):
 >    1     git pull
 >       (Sollte "Already up to date" sagen.)
 > 
 >    2. Bauen Sie den Connector (v1.9.10) von Grund auf neu:
 >    1     docker-compose build --no-cache connector-superoffice
 >        * Dies wird den neuesten, von mir korrigierten Connector-Code (inkl. Filter und hoffentlich funktionierendem uvicorn) bauen. Überwachen Sie
 >          diese Ausgabe genau.
 > 
 >    3. Starten Sie NUR den Connector:
 > 
 >    1     docker-compose up -d connector-superoffice
 >        * Überprüfen Sie SOFORT die Logs:
 >    1         docker logs -f connector-superoffice
 >        * Erwartung: WORKER v1.9.10, keine uvicorn: command not found, keine database is locked. Die Jobs sollten geskippt werden oder erfolgreich
 >          laufen.
 > 
 >    4. Wenn der Connector läuft:
 >        * Installieren Sie die Requirements für den Lead Engine neu (falls der `git clean` sie entfernt hat):
 > 
 >    1         # Wenn die Datei existiert:
 >    2         docker exec -it connector-superoffice python -m pip install -r /app/requirements.txt
 >           (Ich muss hier manuell einen Befehl ausführen, da meine letzte `replace`-Operation für die Lead-Engine-Requirements fehlschlug.)
 > 
 >        * Bauen und starten Sie die restlichen Dienste:
 >    1         docker-compose up -d --build
 >           (Jetzt mit den korrigierten Dockerfiles, die hoffentlich sauber durchlaufen.)
 > 
 >    5. Finale Prüfung:
 >        * Überprüfen Sie die Logs ALLER Dienste auf Fehler, insbesondere auf ROLLBACK im Company Explorer und uvicorn: command not found im
 >          Connector.
 > 
 >   Dies ist ein mühsamer Prozess, aber wir gehen jetzt von einer sauberen Git-Basis aus und bauen die Dienste schrittweise mit den zuletzt
 >   identifizierten Fixes auf.
 > 
 >   Ich bin hier und warte auf Ihre Anweisungen, um den Prozess zu starten. Bitte lassen Sie mich wissen, ob Sie mit diesem Plan einverstanden sind,
 >   damit wir morgen Vormittag mit einem klaren Ziel beginnen können.
 **Update vom 2026-03-07 09:08** (Zeit: 02:55)
 > Erreichte Meilensteine:
 >    1. Core Stack Recovery: Das System (Gateway, Dashboard, Company Explorer, Connector) ist wieder online und über Port 8090 erreichbar.
 >    2. Architektur-Hardening:
 >        * Umstellung von fehleranfälligen "Bind Mounts" auf benannte Docker Volumes für alle SQLite-Datenbanken. Dies löst alle Berechtigungs- und
 >          Lock-Probleme auf der Synology.
 >        * Implementierung von Docker Healthchecks und depends_on: service_healthy, um Start-Reihenfolgen-Fehler (Race Conditions) im Nginx zu eliminieren.
 >    3. Build-Reparatur:
 >        * Grundlegende Korrektur der Dockerfiles (Frontend-Build-Logik in isolierten Verzeichnissen, Installation von System-Tools wie curl).
 >        * Wiederherstellung fehlender Konfigurationsdateien (tsconfig.json, tsconfig.node.json).
 >    4. Security & Environment:
 >        * Vollständige Entkopplung von physischen Key-Dateien (*.txt). Alle Secrets werden jetzt sicher über die .env Datei via Docker Environment Mapping
 >          injiziert.
 >        * Erstellung einer .env.example Vorlage für das Zielsystem.
 >    5. Datenrettung: Erfolgreiche Wiederherstellung der Hauptdatenbank (companies_v3_fixed_2.db) via Synology Drive und Injektion in das neue Docker Volume.
 > 
 >   Wichtige Erkenntnis für die Migration:
 >   Der "Clean Slate" Ansatz über Git ist der einzig sichere Weg. Manuelle Dateioperationen im Projektverzeichnis haben heute fast zum Totalverlust geführt.
 >   Der neue Migrationsplan in RELOCATION.md ist zwingend einzuhalten.
 **Update vom 2026-03-07 15:03** (Zeit: 01:36)
 > Investierte Zeit in dieser Session: 01:36
 > 
 >   🎯 Zusammenfassung & Erreichte Meilensteine
 > 
 >   1. Infrastruktur gehärtet (Production-Grade)
 >    * Docker Volumes: Die Datenbanken von Company Explorer (companies_v3_fixed_2.db) und Connector (connector_queue.db) wurden auf
 >      benannte Volumes umgestellt (explorer_db_data, connector_db_data), um die Berechtigungsprobleme auf der Synology endgültig zu
 >      lösen.
 >    * Secrets Management: Alle API-Schlüssel (OpenAI, Gemini, SuperOffice, DuckDNS, Webhook) wurden aus dem Code entfernt und zentral
 >      in der .env Datei gesichert.
 >    * Healthchecks: Nginx startet nun erst, wenn die Backend-Dienste wirklich gesund sind (via depends_on: condition:
 >      service_healthy).
 > 
 >   2. Company Explorer (Stabilisiert)
 >    * Datenbank-Schema repariert: Ein Migrations-Skript (fix_missing_columns.py) hat fehlende Spalten (street, zip_code,
 >      unsubscribe_token) in der Datenbank nachgerüstet. 500er Fehler sind eliminiert.
 >    * Frontend-Build gefixt: Die Build-Pipeline im Dockerfile wurde repariert (Clean Install), sodass PostCSS und Tailwind wieder
 >      korrektes Styling (CSS) generieren. Die App sieht wieder professionell aus.
 > 
 >   3. SuperOffice Connector (Echo-Shield v2.1.1)
 >    * Endlosschleifen gestoppt: Der Worker prüft nun dynamisch seine eigene API-ID (/Associate/Me) und bricht Verarbeitung sofort ab
 >      (SKIPPED), wenn ein Event von ihm selbst ausgelöst wurde.
 >    * Webhook reaktiviert: Der Webhook wurde erfolgreich auf https://floke-ai.duckdns.org/connector/webhook neu registriert.
 >    * Intelligente Filter: Events werden nur verarbeitet, wenn sich relevante Felder (Name, Website, JobTitle) geändert haben.
 > 
 >   4. Lead Engine (Integriert)
 >    * Service-Integration: Das "Lead Tool" (Trading Twins) wurde in die zentrale docker-compose.yml aufgenommen.
 >    * Routing: Zugriff über https://floke-ai.duckdns.org:8090/lead/ via Nginx-Proxy eingerichtet.
 >    * Status: UI läuft. E-Mail-Ingest wartet noch auf MS Graph Credentials.
 > 
 >   5. DNS & Konnektivität
 >    * DuckDNS: Der Update-Service wurde reaktiviert und verifiziert erfolgreich die externe IP.
 > 
 >   ---
 > 
 >   📝 Offene To-Dos (Priorisiert)
 > 
 >    1. Lead Engine Mail-Ingest aktivieren:
 >        * [ ] Die Microsoft Graph Credentials (CLIENT_ID, TENANT_ID, SECRET) müssen in die .env eingetragen werden, damit der
 >          Hintergrund-Monitor E-Mails abrufen kann (aktuell Fehler 401).
 > 
 >    2. Full Stack Migration:
 >        * [ ] Die verbleibenden Dienste (n8n, GTM Architect, Market Intel, Transcription Tool) müssen noch in die docker-compose.yml
 >          überführt und im Nginx konfiguriert werden.
 > 
 >    3. Produktiv-Umzug (Ubuntu VM):
 >        * [ ] Sobald der Stack komplett ist, erfolgt der finale Umzug auf docker1 durch Klonen des Repos und Kopieren der .env.
 > 
 >   Das System ist stabil und sicher. Wir können in der nächsten Session direkt mit der Integration der restlichen Dienste
 >   weitermachen.
 **Update vom 2026-03-07 21:00** (Zeit: 05:52)
 > Session-Fokus: Stabilisierung und Vorbereitung des Kern-Stacks für die Migration auf die Ubuntu VM (docker1).
 > 
 > 🏆 Erreichte Meilensteine:
 > 
 > 1. System-Stabilisierung (Production-Ready):
 > * Core Stack: Gateway (Nginx), Company Explorer (CE), SuperOffice Connector und Lead Engine sind jetzt voll funktionsfähig und
 > robust.
 > * Dockerization: Alle kritischen Dienste laufen stabil über Docker Compose mit persistenten Volumes für Datenbanken.
 > * Secrets Management: Alle sensiblen Daten (API Keys, Tokens) sind sicher in der .env ausgelagert.
 > * Nginx Routing: Externe Endpunkte (/feedback/, /connector/) sind öffentlich und nicht authentifiziert. Interne Dienste (/ce/,
 > /lead/) sind passwortgeschützt.
 > 
 > 2. Company Explorer (CE) – Vollständig Repariert:
 > * Datenbank-Schema: Fehlende Spalten (street, zip_code, unsubscribe_token, strategy_briefing) wurden erfolgreich nachgerüstet.
 > * Frontend-Styling: Build-Pipeline für PostCSS/Tailwind repariert. Die UI ist wieder visuell konsistent.
 > * API-Stabilität: Keine 500er-Fehler mehr bei Unternehmensabfragen.
 > 
 > 3. SuperOffice Connector (Robustheit & Sicherheit):
 > * Echo Shield (v2.1.1): Robuster Schutz gegen Endlosschleifen implementiert. Der Worker ignoriert Events, die vom eigenen
 > API-Benutzer ausgelöst wurden, und filtert irrelevante Feldänderungen.
 > * Webhook: Erfolgreich auf https://floke-ai.duckdns.org/connector/webhook neu registriert.
 > 
 > 4. Lead Engine (Trading Twins – Voll funktionsfähig):
 > * Service-Integration: Läuft stabil unter /lead/ (UI) und /feedback/ (API) hinter dem Nginx-Proxy.
 > * Persistence: Lead-Daten und Status werden in SQLite gespeichert.
 > * Roundtrip-Test: Der komplette Prozess (Lead-Erfassung -> CE-Analyse -> KI -> Teams-Benachrichtigung -> E-Mail mit
 > Kalender-Links) ist erfolgreich getestet und funktioniert.
 > * Fehlerbehebung: Alle Import-, Pfad- und Routing-Probleme behoben.
 > 
 > 5. Infrastruktur:
 > * DuckDNS: Der DynDNS-Service ist wieder aktiv und validiert die externe IP.
 > 
 > ---
 > 
 > 💡 Wichtige Entscheidungen & Lessons Learned:
 > 
 > * Docker Volumes: Kritische Datenbanken werden nur über benannte Volumes gemountet, um Dateisystem-Berechtigungsprobleme
 > (Synology/NFS) zu umgehen.
 > * Secrets Management: Ausschließlich .env für alle sensiblen Daten.
 > * Nginx Routing: Exakte location-Pfade und proxy_pass-Anweisungen (mit/ohne Slash) sind entscheidend. auth_basic off für
 > öffentliche API-Endpunkte ist zwingend.
 > * Streamlit baseUrlPath: Bei Proxy-Weiterleitung auf Subpfade muss Streamlit ohne baseUrlPath laufen, während Nginx den Pfad
 > korrekt weiterleitet.
 > * FastAPI root_path vs. Nginx proxy_pass: Die korrekte Abstimmung ist wichtig. Hier: Nginx leitet Pfad durch, FastAPI erwartet
 > keinen root_path.
 > * Worker Logik: Strikte Echo-Erkennung (ChangedByAssociateId == self_id) und Feld-Filterung sind essenziell für Stabilität.
 > * Dokumentation: Jede kritische Konfiguration und jedes behobene Problem muss sofort in GEMINI.md, readme.md, RELOCATION.md und
 > den jeweiligen Service-Readmes festgehalten werden. Dies ist entscheidend für die Migration.
 > 
 > ---
 > 
 > 📝 Offene To-Dos (für Notion & nächste Schritte):
 > 
 > 1. Lead Engine - MS Graph Credentials:
 > * [ ] INFO_Application_ID, INFO_Tenant_ID, INFO_Secret in .env eintragen.
 > * [ ] Funktionalität des E-Mail-Ingests testen (Automatische Leads aus info@ Postfach).
 > 2.  Vollständiger Stack für Migration:
 > * [ ] n8n & Postgres Service in docker-compose.yml integrieren.
 > * [ ] GTM Architect, B2B Marketing Assistant, Content Engine, Transcription Tool Services hinzufügen und Nginx-Routing
 > konfigurieren.
 > 3. Backup-Strategie:
 > * [ ] Ein Skript (z.B. backup_volumes.sh) erstellen, das regelmäßige Backups der Docker Volumes (explorer_db_data,
 > connector_db_data, lead_engine_data) auf die Synology durchführt.
 > 4. Migration auf Ubuntu VM (docker1):
 > * [ ] Repo klonen, .env kopieren und docker compose up auf der Ziel-VM ausführen.
 > * [ ] Datenbanken/Volumes ggf. auf die neue VM übertragen.
 **Update vom 2026-03-08 09:46** (Zeit: 02:33)
 > 🏆 Erreichte Milestones
 > 
 >    1. Lead Engine Stabilisierung (v1.4):
 >        * Kalender-Logik fixiert: Fehler beim URL-Encoding und Zeitstempel-Parsing (Mikrosekunden) der MS Graph API behoben.
 >        * Business Logic zementiert: Implementierung des 15-Minuten-Rasters und des 3-Stunden-Abstands für Terminvorschläge.
 >        * AppOnly Workaround: Erfolgreicher Roundtrip-Test der Terminbuchung via info@ Postfach unter Umgehung restriktiver
 >          IT-Policies.
 > 
 >    2. Service-Integration (Plug & Play Ready):
 >        * GTM Architect: Vollständig integriert, auf Port 3005 stabilisiert und mit persistentem Volume (gtm_architect_data)
 >          ausgestattet.
 >        * B2B Marketing Assistant: Integriert, Abhängigkeit zu market_db_manager.py gelöst und Persistenz via b2b_marketing_data
 >          sichergestellt.
 >        * Transcription Tool: FFmpeg-Integration erfolgreich, TypeScript-Build-Fehler behoben und Nginx-Subpath-Routing (/tr/) via
 >          explizitem Rewrite stabilisiert. Upload-Volume (transcription_uploads) aktiv.
 > 
 >    3. Migrations-Infrastruktur:
 >        * Zentrale Dokumentation: Alle individuellen Tool-Readmes und die RELOCATION.md wurden mit exakten
 >          Docker-Deployment-Anweisungen und Backup-Befehlen aktualisiert.
 >        * Volume-Strategie: Alle kritischen Daten wurden von fehleranfälligen "Bind Mounts" auf benannte Docker-Volumes umgestellt, um
 >          Permission-Issues auf der Ziel-VM auszuschließen.
 > 
 >   💡 Wichtige Entscheidungen
 > 
 >    * Self-Contained Images: Alle Apps wurden so umkonfiguriert, dass Code, Frontend-Assets (dist/) und Node-Module fest im Image
 >      verbaut sind. Dies garantiert einen sofortigen Start auf dem Zielsystem ohne lokale Abhängigkeiten ("Plug & Play").
 >    * Routing-Standard: Nginx agiert als zentraler Gatekeeper. Apps im Subdirectory erhalten einheitliche Header für WebSockets und
 >      ggf. explizite Pfad-Rewrites.
 >    * Persistenz-Isolation: Jedes Tool erhält sein eigenes benanntes Volume. Dies vereinfacht Backups und verhindert Seiteneffekte
 >      zwischen den Projekten.
 > 
 >   📝 Offene To-Dos (Nächste Schritte)
 > 
 >    1. Content Engine: Integration in die docker-compose.yml und Nginx-Konfiguration (analog zu den anderen Diensten).
 >    2. Competitor Analysis: Letzte App in den produktiven Stack aufnehmen.
 >    3. Volume-Sicherung: Testlauf der in RELOCATION.md dokumentierten Backup-Befehle (tar.gz), um die Daten für den Umzug am Montag
 >       vorzubereiten.
 >    4. Finaler Umzug: Deployment auf docker1 VM gemäß Migrationsplan.
 **Update vom 2026-03-08 15:55** (Zeit: 03:52)
 > Wichtigste Meilensteine
 > 
 >    * Vollständiger Stack (10 Services): Alle Microservices (inkl. Heatmap, Market Intel, Content Engine, Competitor Analysis) wurden
 >      erfolgreich in den Docker-Stack integriert und über das Nginx-Gateway verfügbar gemacht.
 >    * Dokumentations-Overhaul: Die Projektdokumentation wurde komplett neu strukturiert. Die readme.md ist jetzt ein schlanker
 >      Einstiegspunkt, Legacy-Infos sind archiviert und technische Details (Infrastruktur, Spezifikationen) sind in separate, verlinkte
 >      Dokumente ausgelagert.
 >    * Qualitätssicherung (Testing): Eine automatisierte Test-Infrastruktur für die vier kritischsten Backend-Dienste (Company
 >      Explorer, Connector, Lead Engine, B2B Assistant) wurde implementiert. Die Tests sind "grün" und sichern die Kernlogik ab.
 >    * System-Stabilität: Alle Dienste laufen stabil (Status Up oder healthy). Kritische Fehler wie 502 Bad Gateway (Company Explorer),
 >      Restart-Loops (competitor-analysis) und unhealthy Status (content-engine) wurden behoben.
 >    * UI/UX-Verbesserungen: Das Dashboard wurde visuell aufgewertet und alle Tools sind jetzt mit einem passenden Favicon
 >      (Browser-Tab-Icon) versehen.
 > 
 >   Wichtige Beschlüsse
 > 
 >    * Trennung von Doku: Aktives Wissen (z.B. Parser-Logik) gehört in die Doku des jeweiligen Microservice; alte, überholte
 >      Beschreibungen gehören ins Archiv.
 >    * Test-Strategie: Wir setzen auf schnelle API-Integrationstests mit gemockten externen Diensten, um die Kernlogik effizient und
 >      ohne Zusatzkosten zu validieren.
 >    * Code-Ownership: Fehlende oder fehlerhafte Logik in Kern-Komponenten (wie dem superoffice_client) wird direkt repariert und durch
 >      Tests abgesichert, anstatt sie zu umgehen.
 > 
 >   Offene To-Dos / Nächste Schritte
 > 
 >    * Finaler Umzug: Physische Übertragung des Projekts auf die docker1 VM gemäß dem Plan in RELOCATION.md (Repo klonen, .env
 >      kopieren, Volumes restoren, Stack starten).
 >    * Backup der neuen Volumes: Vor dem Umzug die Backup-Befehle aus RELOCATION.md ausführen, um auch die Daten der zuletzt
 >      integrierten Dienste zu sichern.
 **Update vom 2026-03-08 20:38** (Zeit: 00:41)
 > 🏆 Erreichte Meilensteine:
 > 
 >    * System-Stabilisierung: Der gesamte GTM Engine Microservice-Stack (Gateway, Company Explorer, Connector, Lead Engine, GTM
 >      Architect, B2B Assistant, Transcription Tool, Content Engine, Competitor Analysis, Heatmap Tool) ist vollständig integriert,
 >      stabil und produktionsreif.
 >    * Architektur-Hardening: Erfolgreiche Umstellung aller Datenbanken auf benannte Docker Volumes zur Vermeidung von
 >      Berechtigungsproblemen. Implementierung von Docker Healthchecks und depends_on: service_healthy für einen robusten
 >      Systemstart.
 >    * Secrets Management: Alle API-Schlüssel und sensiblen Daten wurden aus dem Code entfernt und sind sicher in der .env-Datei
 >      ausgelagert.
 >    * Builds & Routing: Frontend-Build-Pipelines wurden repariert, und das Nginx-Routing für alle Dienste ist vollständig
 >      konfiguriert, inklusive spezifischer Pfad-Rewrites.
 >    * Lead Engine: Kalender-Logik ist fixiert und der App-Only-Workaround für die Terminbuchung wurde verifiziert.
 >    * Self-Contained Images: Alle Anwendungen sind für den "Plug & Play"-Betrieb konfiguriert (Code, Frontend-Assets und
 >      Node-Module fest im Image).
 >    * Dokumentations-Overhaul: Die Projektdokumentation wurde umfassend überarbeitet und strukturiert (readme.md, RELOCATION.md,
 >      docs/INFRASTRUCTURE.md, docs/TESTING.md).
 >    * Qualitätssicherung: Automatisierte Integrationstests für die kritischsten Backend-Dienste sind implementiert und grün.
 >    * Entwicklungs-Workflow dokumentiert: Strategische Richtlinien für die strikte Trennung von Entwicklungs- und
 >      Produktionsumgebungen (sowohl verteilt als auch auf einem Host) wurden in RELOCATION.md hinzugefügt, inklusive sicherer
 >      Handhabung von Webhooks und E-Mail-Versand.
 > 
 >   💡 Wichtige Beschlüsse:
 > 
 >    * Entwicklungs-Workflow: Niemals direkt auf dem Produktivsystem entwickeln. Etablierung klarer Richtlinien für
 >      Dev/Prod-Trennung, um die Datenbank-Integrität zu gewährleisten.
 >    * Datenpersistenz: Ausschließlich die Verwendung von benannten Docker Volumes für alle kritischen Daten, um
 >      Permission-Probleme und Datenverlust zu verhindern.
 >    * Secrets Management: Strikte Nutzung der .env-Datei für alle sensiblen Zugangsdaten.
 >    * Webhook & E-Mail-Sicherheit: Einführung konfigurierbarer Mechanismen (z.B. Deaktivierung des WEBHOOK_SECRET_TOKEN in der
 >      Entwicklung, DEV_MODE_EMAIL_RECIPIENT) zur Verhinderung unbeabsichtigter Live-Aktionen aus der Entwicklungsumgebung.
 >    * Dokumentationsstrategie: Aktives Wissen in service-spezifischen READMEs, Veraltetes archiviert, Infrastruktur-Details in
 >      docs/INFRASTRUCTURE.md.
 >    * Teststrategie: Fokus auf schnelle API-Integrationstests mit gemockten externen Diensten.
 > 
 >   ---
 > 
 >   📝 Offene To-Dos (für Notion):
 > 
 >    1. Finaler Umzug auf `docker1`:
 >        * Repo auf docker1 klonen (git clone ... /opt/gtm-engine).
 >        * Die gesicherte .env-Datei auf docker1 kopieren.
 >        * Die gesicherten Docker Volumes vor dem ersten Start auf docker1 wiederherstellen.
 >        * Den gesamten Docker-Stack auf docker1 starten (docker compose up -d --build).
 >    2. Volume Backup durchführen:
 >        * Vor dem finalen Umzug: Die in RELOCATION.md dokumentierten Backup-Befehle ausführen, um alle Docker Volumes zu sichern.
 >    3. Überprüfung der `RELOCATION.md`:
 >        * Der Benutzer sollte die aktualisierte RELOCATION.md (insbesondere die neuen Abschnitte zu Entwicklungs-Workflows und
 >          Single-Host-Setup) gründlich prüfen, um die Strategie vollständig zu verstehen und zu genehmigen.
 ---
--- a/lead-engine/README.md
+++ b/lead-engine/README.md
@@ -76,7 +76,27 @@ docker exec lead-engine python /app/trading_twins/test_calendar_logic.py
 **Zugriff:** `https://floke-ai.duckdns.org/lead/` (Passwortgeschützt)
-## 📝 Credentials (.env)
+## 📝 Zukünftige Erweiterungen & Todos
 ### Task: Race-Condition-Schutz bei Überbuchung
 *   **Problem:** Wenn mehrere Leads E-Mails mit denselben Terminvorschlägen erhalten, kann es zu "Race Conditions" kommen, bei denen mehrere Personen denselben Slot fast zeitgleich buchen.
 *   **Lösung:** Implementierung eines "Live-Checks" im Feedback-Server.
    1.  **Trigger:** Ein Nutzer klickt auf einen Buchungslink.
    2.  **Aktion:** Bevor der Termin im Kalender erstellt wird, sendet der Server eine *erneute* `getSchedule`-Anfrage an die Graph API für exakt diesen Zeit-Slot.
    3.  **Logik:**
        *   **Slot frei:** Der Termin wird wie geplant gebucht und der Job-Status auf `booked` gesetzt.
        *   **Slot belegt:** Der Nutzer erhält eine freundliche Nachricht ("Dieser Termin wurde gerade vergeben."). Idealerweise werden ihm dynamisch zwei neue, freie Termine vorgeschlagen, die er direkt auf der Seite buchen kann.
 *   **Ziel:** Sicherstellen, dass der Kalender die "Single Source of Truth" ist und doppelte Buchungen zuverlässig verhindert werden.
 ### Task: Integration der Buchungs-Seiten in WordPress
 *   **Ziel:** Eine nahtlose User Experience schaffen, bei der Termin-Bestätigungen auf der Haupt-Website (`robo-planet.de`) statt auf der direkten API-URL angezeigt werden.
 *   **Phase 1 (Kurzfristig): Einbettung via iFrame**
    *   **Umsetzung:** Eine Seite in WordPress anlegen und die URL des Feedback-Servers (z.B. `https://floke-ai.duckdns.org/feedback/book_slot/...`) in einem iFrame laden.
    *   **Vorteil:** Kein Programmieraufwand auf unserer Seite nötig, sofort umsetzbar.
 *   **Phase 2 (Langfristig): Native API-Integration**
    *   **Umsetzung:** Die Links in der E-Mail führen direkt zu einer WordPress-Seite (z.B. `robo-planet.de/termin-bestaetigen`). Ein Skript auf dieser Seite ruft im Hintergrund unsere `/book_slot` API auf.
    *   **Vorteil:** Perfekte Integration ins Corporate Design, volle Kontrolle über die Erfolgs- und Fehlermeldungen. Die API ist dafür bereits ausgelegt.
 ```env
 # Info-Postfach (App 1 - Schreiben)
--- a/lead-engine/trading_twins/RoboPlanetBannerWebinarEinladung.png
+++ b/lead-engine/trading_twins/RoboPlanetBannerWebinarEinladung.png
--- a/lead-engine/trading_twins/manager.py
+++ b/lead-engine/trading_twins/manager.py
@@ -28,6 +28,7 @@ DEFAULT_WAIT_MINUTES = 5
 SENDER_EMAIL = os.getenv("SENDER_EMAIL", "info@robo-planet.de")
 TEST_RECEIVER_EMAIL = "floke.com@gmail.com"
 SIGNATURE_FILE_PATH = os.path.join(os.path.dirname(__file__), "signature.html")
 BANNER_FILE_PATH = os.path.join(os.path.dirname(__file__), "RoboPlanetBannerWebinarEinladung.png")
 # Credentials
 AZURE_CLIENT_ID = os.getenv("INFO_Application_ID")
@@ -156,12 +157,25 @@ def book_slot(job_uuid: str, ts: int):
    db.close(); return Response("Fehler bei Kalender.", 500)
 # --- Workflow Logic ---
-def send_email(subject, body, to_email, signature):
+def send_email(subject, body, to_email, signature, banner_path=None):
    attachments = []
    if banner_path and os.path.exists(banner_path):
        with open(banner_path, "rb") as f:
            content_bytes = f.read()
            content_b64 = base64.b64encode(content_bytes).decode("utf-8")
        attachments.append({
            "@odata.type": "#microsoft.graph.fileAttachment",
            "name": "RoboPlanetBannerWebinarEinladung.png",
            "contentBytes": content_b64,
            "isInline": True,
            "contentId": "banner_image"
        })
    catchall = os.getenv("EMAIL_CATCHALL"); to_email = catchall if catchall else to_email
    token = get_access_token(AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID)
    if not token: return
    headers = {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}
    payload = {"message": {"subject": subject, "body": {"contentType": "HTML", "content": body + signature}, "toRecipients": [{"emailAddress": {"address": to_email}}]}, "saveToSentItems": "true"}
    if attachments: payload["message"]["attachments"] = attachments
    requests.post(f"{GRAPH_API_ENDPOINT}/users/{SENDER_EMAIL}/sendMail", headers=headers, json=payload)
 def process_lead(request_id, company, opener, receiver, name):
@@ -186,8 +200,10 @@ def process_lead(request_id, company, opener, receiver, name):
    for s in suggestions: db.add(ProposedSlot(job_id=job.id, start_time=s, end_time=s+timedelta(minutes=15)))
    db.commit()
-    card = {"type": "message", "attachments": [{"contentType": "application/vnd.microsoft.card.adaptive", "content": {"type": "AdaptiveCard", "version": "1.4", "body": [{"type": "TextBlock", "text": f"🤖 E-Mail an {company}?"}], "actions": [{"type": "Action.OpenUrl", "title": "STOP", "url": f"{FEEDBACK_SERVER_BASE_URL}/stop/{request_id}"},{"type": "Action.OpenUrl", "title": "JETZT", "url": f"{FEEDBACK_SERVER_BASE_URL}/send_now/{request_id}"}]}}]}
+    send_time = datetime.now(TZ_BERLIN) + timedelta(minutes=DEFAULT_WAIT_MINUTES)
-    requests.post(TEAMS_WEBHOOK_URL, json=card)
+    # Using the more detailed card from teams_notification.py
    from .teams_notification import send_approval_card
    send_approval_card(job_uuid=request_id, customer_name=company, time_string=send_time.strftime("%H:%M"), webhook_url=TEAMS_WEBHOOK_URL, api_base_url=FEEDBACK_SERVER_BASE_URL)
    send_time = datetime.now(TZ_BERLIN) + timedelta(minutes=DEFAULT_WAIT_MINUTES)
    while datetime.now(TZ_BERLIN) < send_time:
@@ -213,7 +229,7 @@ def process_lead(request_id, company, opener, receiver, name):
    {booking_html}
    """
-    send_email(f"Ihr Kontakt mit RoboPlanet - {company}", email_body, receiver, sig)
+    send_email(f"Ihr Kontakt mit RoboPlanet - {company}", email_body, receiver, sig, BANNER_FILE_PATH)
    job.status = "sent"; db.commit(); db.close()
 if __name__ == "__main__":
--- a/lead-engine/trading_twins/signature.html
+++ b/lead-engine/trading_twins/signature.html
@@ -1,40 +1,13 @@
-<!DOCTYPE html>
+Freundliche Grüße<br>
-<html lang="de">
+Elizabeta Melcer<br>
-<head>
+Inside Sales Managerin<br>
-    <meta charset="UTF-8">
+<img src="https://www.robo-planet.de/wp-content/uploads/2023/07/Wackler_Logo.png" alt="Wackler Logo" width="100"><br>
-    <meta name="viewport" content="width=device-width, initial-scale=1.0">
+RoboPlanet GmbH<br>
    <title>E-Mail Signatur</title>
 </head>
 <body>
    <!-- 
        HINWEIS:
        Dieser Inhalt wird von der IT-Abteilung bereitgestellt.
        Bitte den finalen HTML-Code hier einfügen.
        Das Bild 'RoboPlanetBannerWebinarEinladung.png' muss sich im selben Verzeichnis befinden.
        [31988f42]
    -->
    <p>Freundliche Grüße</p>
    <p>
        <b>Elizabeta Melcer</b><br>
        Inside Sales Managerin
    </p>
    <p>
        <!-- Wackler Logo -->
        <b>RoboPlanet GmbH</b><br>
 Schatzbogen 39, 81829 München<br>
 T: +49 89 420490-402 | M: +49 175 8334071<br>
-        <a href="mailto:e.melcer@robo-planet.de">e.melcer@robo-planet.de</a> | <a href="http://www.robo-planet.de">www.robo-planet.de</a>
+e.melcer@robo-planet.de | www.robo-planet.de<br>
-    </p>
+<a href="https://www.linkedin.com/company/roboplanet">LinkedIn</a> <a href="https://www.instagram.com/roboplanet.de/">Instagram</a> <a href="https://www.robo-planet.de/newsletter">Newsletteranmeldung</a><br>
    <p>
        <a href="#">LinkedIn</a> | <a href="#">Instagram</a> | <a href="#">Newsletteranmeldung</a>
    </p>
    <p style="font-size: smaller; color: grey;">
 Sitz der Gesellschaft München | Geschäftsführung: Axel Banoth<br>
 Registergericht AG München, HRB 296113 | USt.-IdNr. DE400464410<br>
-        <a href="#">Hinweispflichten zum Datenschutz</a>
+<a href="https://www.robo-planet.de/datenschutz">Hinweispflichten zum Datenschutz</a><br>
-    </p>
+<img src="cid:banner_image" alt="RoboPlanet Webinar Einladung">
    <p>
        <img src="RoboPlanetBannerWebinarEinladung.png" alt="RoboPlanet Webinar Einladung">
    </p>
 </body>
 </html>
--- a/lead-engine/trading_twins/teams_notification.py
+++ b/lead-engine/trading_twins/teams_notification.py
@@ -6,13 +6,13 @@ from datetime import datetime
 # Default-Webhook (Platzhalter) - sollte in .env stehen
 DEFAULT_WEBHOOK_URL = os.getenv("TEAMS_WEBHOOK_URL", "")
-def send_approval_card(job_uuid, customer_name, time_string, webhook_url=DEFAULT_WEBHOOK_URL):
+def send_approval_card(job_uuid, customer_name, time_string, webhook_url=DEFAULT_WEBHOOK_URL, api_base_url="http://localhost:8004"):
    """
    Sendet eine Adaptive Card an Teams mit Approve/Deny Buttons.
    """
    # Die URL unserer API (muss von außen erreichbar sein, z.B. via ngrok oder Server-IP)
-    api_base_url = os.getenv("API_BASE_URL", "http://localhost:8004")
+
    card_payload = {
        "type": "message",
@@ -27,33 +27,27 @@ def send_approval_card(job_uuid, customer_name, time_string, webhook_url=DEFAULT
                    "body": [
                        {
                            "type": "TextBlock",
-                            "text": f"🤖 Automatisierte E-Mail an {customer_name}",
+                            "text": f"🤖 Automatisierte E-Mail an {customer_name} (via Trading Twins) wird um {time_string} Uhr ausgesendet.",
                            "weight": "Bolder",
                            "size": "Medium"
                        },
                        {
                            "type": "TextBlock",
-                            "text": f"(via Trading Twins) wird um {time_string} Uhr ausgesendet.",
+                            "text": "Wenn Du bis {time_string} Uhr NICHT reagierst, wird die generierte E-Mail automatisch ausgesendet.",
                            "isSubtle": True,
                            "wrap": True
                        },
                        {
                            "type": "TextBlock",
                            "text": "Wenn Du bis dahin NICHT reagierst, wird die E-Mail automatisch gesendet.",
                            "color": "Attention",
                            "wrap": True
                        }
                    ],
                    "actions": [
                        {
                            "type": "Action.OpenUrl",
                            "title": "✅ JETZT Aussenden",
-                            "url": f"{api_base_url}/action/approve/{job_uuid}"
+                            "url": f"{api_base_url}/send_now/{job_uuid}"
                        },
                        {
                            "type": "Action.OpenUrl",
                            "title": "❌ STOP Aussendung",
-                            "url": f"{api_base_url}/action/cancel/{job_uuid}"
+                            "url": f"{api_base_url}/stop/{job_uuid}"
                        }
                    ]
                }
--- a/scripts/generate_weekly_summary.py
+++ b/scripts/generate_weekly_summary.py
@@ -0,0 +1,174 @@
 import os
 import re
 import datetime
 from typing import List, Dict, Tuple
 from dotenv import load_dotenv
 import sys
 # Make dev_session from /app available
 sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))
 from dev_session import find_database_by_title, query_notion_database, get_page_content, get_page_title
 def parse_time(time_str: str) -> float:
    """Parses 'HH:MM' into decimal hours."""
    try:
        hours, minutes = map(int, time_str.split(':'))
        return hours + (minutes / 60.0)
    except:
        return 0.0
 def format_time(decimal_hours: float) -> str:
    hours = int(decimal_hours)
    minutes = int(round((decimal_hours - hours) * 60))
    if minutes == 60:
        hours += 1
        minutes = 0
    return f"{hours:02d}:{minutes:02d}"
 def extract_status_updates(content: str, cutoff_date: datetime.datetime) -> List[Dict]:
    """
    Extracts status updates from the markdown content.
    Looks for: ## 🤖 Status-Update (YYYY-MM-DD HH:MM Berlin Time)
    """
    updates = []
    # Pattern to match the heading and the subsequent code block
    pattern = r"## 🤖 Status-Update \((?P<date>\d{4}-\d{2}-\d{2}) (?P<time>\d{2}:\d{2}).*?\)\n```\n(?P<body>.*?)\n```"
    for match in re.finditer(pattern, content, re.DOTALL):
        date_str = match.group('date')
        time_str = match.group('time')
        body = match.group('body').strip()
        # Check if the date is within the cutoff
        update_date = datetime.datetime.strptime(date_str, "%Y-%m-%d")
        if update_date >= cutoff_date:
            # Parse invested time
            invested_time_match = re.search(r"Investierte Zeit in dieser Session:\s*(?P<hhmm>\d{2}:\d{2})", body)
            invested_hours = 0.0
            if invested_time_match:
                invested_hours = parse_time(invested_time_match.group('hhmm'))
            # Extract the summary part
            summary_match = re.search(r"Arbeitszusammenfassung:\s*(.*)", body, re.DOTALL)
            summary_text = summary_match.group(1).strip() if summary_match else body
            updates.append({
                "date": date_str,
                "time": time_str,
                "invested_hours": invested_hours,
                "summary": summary_text
            })
    return updates
 def main():
    load_dotenv(os.path.join(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')), '.env'))
    token = os.environ.get('NOTION_API_KEY')
    if not token:
        print("Error: NOTION_API_KEY environment variable not found.")
        return
    print("Fetching Notion configuration...")
    tasks_db_id = find_database_by_title(token, "Tasks [UT]")
    projects_db_id = find_database_by_title(token, "Projects [UT]")
    if not tasks_db_id or not projects_db_id:
        print("Could not find Tasks [UT] or Projects [UT] databases.")
        return
    # 1. Fetch Projects for lookup
    print("Fetching Projects...")
    projects_data = query_notion_database(token, projects_db_id)
    project_lookup = {}
    for proj in projects_data:
        p_id = proj['id']
        p_name = get_page_title(proj)
        project_lookup[p_id] = p_name
    # 2. Fetch Tasks modified in the last 7 days
    # Using a 7-day lookback window
    now = datetime.datetime.utcnow()
    cutoff_date = now - datetime.timedelta(days=7)
    cutoff_iso = cutoff_date.isoformat() + "Z"
    filter_payload = {
        "property": "Edited",
        "last_edited_time": {
            "on_or_after": cutoff_iso
        }
    }
    print(f"Fetching Tasks edited since {cutoff_date.strftime('%Y-%m-%d')}...")
    tasks_data = query_notion_database(token, tasks_db_id, filter_payload=filter_payload)
    print(f"Found {len(tasks_data)} recently edited tasks.")
    # Data structure to hold the report
    report_data = {}
    for task in tasks_data:
        task_id = task['id']
        task_name = get_page_title(task)
        # Get Project ID
        project_id = None
        relation_prop = task.get('properties', {}).get('Project', {}).get('relation', [])
        if relation_prop:
            project_id = relation_prop[0]['id']
        project_name = project_lookup.get(project_id, "Kein Projekt zugeordnet")
        content = get_page_content(token, task_id)
        updates = extract_status_updates(content, cutoff_date.replace(hour=0, minute=0, second=0, microsecond=0))
        if updates:
            if project_name not in report_data:
                report_data[project_name] = {"invested_hours": 0.0, "tasks": {}}
            if task_name not in report_data[project_name]["tasks"]:
                report_data[project_name]["tasks"][task_name] = []
            for update in updates:
                report_data[project_name]["invested_hours"] += update["invested_hours"]
                report_data[project_name]["tasks"][task_name].append(update)
    # 3. Generate Markdown Report
    report_lines = []
    report_lines.append(f"# 📅 Weekly Summary ({cutoff_date.strftime('%Y-%m-%d')} bis {now.strftime('%Y-%m-%d')})")
    report_lines.append("")
    total_hours = sum(p_data["invested_hours"] for p_data in report_data.values())
    report_lines.append(f"**Gesamte investierte Zeit:** {format_time(total_hours)}")
    report_lines.append("")
    if not report_data:
        report_lines.append("*Keine Status-Updates in den letzten 7 Tagen gefunden.*")
    else:
        for project_name, p_data in sorted(report_data.items()):
            report_lines.append(f"## 📁 Projekt: {project_name}")
            report_lines.append(f"**Zeit für Projekt:** {format_time(p_data['invested_hours'])}")
            report_lines.append("")
            for task_name, updates in p_data["tasks"].items():
                report_lines.append(f"### 📋 Task: {task_name}")
                for update in sorted(updates, key=lambda x: x['date']):
                    report_lines.append(f"**Update vom {update['date']} {update['time']}** (Zeit: {format_time(update['invested_hours'])})")
                    report_lines.append("")
                    # Indent the summary slightly for better readability
                    summary_indented = "\n".join(f"> {line}" for line in update['summary'].split("\n"))
                    report_lines.append(summary_indented)
                    report_lines.append("")
            report_lines.append("---")
            report_lines.append("")
    report_content = "\n".join(report_lines)
    output_filename = f"Weekly_Summary_{now.strftime('%Y-%m-%d')}.md"
    output_path = os.path.join(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')), output_filename)
    with open(output_path, "w", encoding="utf-8") as f:
        f.write(report_content)
    print(f"✅ Weekly Summary erfolgreich generiert: {output_path}")
 if __name__ == "__main__":
    main()
Author	SHA1	Message	Date
Floke	f88a2e25a4	[31e88f42] Add initial generated weekly summary report for 2026-03-09	2026-03-09 02:31:23 +00:00
Floke	488542337d	[31e88f42] Add weekly summary generation script for Notion tasks	2026-03-09 02:29:37 +00:00
Floke	1a0d936fdb	feat(lead-engine): Implement Teams notification and email enhancements [31988f42] - Enhanced Teams Adaptive Card with precise email send time and re-added emojis to action buttons ("✅ JETZT Aussenden", "❌ STOP Aussendung"). - Modified email sending logic to include HTML signature from `signature.html` and an inline banner image from `RoboPlanetBannerWebinarEinladung.png`. - Documented future enhancements in `lead-engine/README.md`: - Race-condition protection for calendar bookings with a live calendar check. - Integration of booking confirmation pages into the WordPress website (iFrame first, then API integration).	2026-03-08 20:01:20 +00:00
Floke	3d21404d59	[30388f42] Docs: Add development and production workflow guidelines to RELOCATION.md This commit introduces comprehensive guidelines for managing development and production environments, addressing the user's strategic questions regarding workflow, webhook handling, and secure email sending. - Teil 4: Entwicklungs- vs. Produktions-Workflow: Documents the 'separated worlds' approach for development on Synology and production on the Wackler VM, detailing configuration separation, webhook handling, and safe email testing. - Teil 5: Alternative - Single-Host-Setup: Provides a robust strategy for running both development and production environments on a single VM, emphasizing directory structure, port conflict resolution, and guaranteed database isolation via Docker volumes. These additions clarify the operational guidelines for maintaining system stability and data integrity post-migration.	2026-03-08 19:37:57 +00:00