- 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).
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
8 changed files with 1354 additions and 58 deletions
@@ -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.
## 📁 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
> - 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).
> * 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
> * 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
> * 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:
***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.
***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.
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}"}]}}]}
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
