[30388f42] Infrastructure Hardening & Final Touches: Stabilized Lead Engine (Nginx routing, manager.py, Dockerfile fixes), restored known-good Nginx configs, and ensured all recent fixes are committed. System is ready for migration.
- Fixed Nginx proxy for /feedback/ and /lead/ routes. - Restored manager.py to use persistent SQLite DB and corrected test lead triggers. - Refined Dockerfile for lead-engine to ensure clean dependency installs. - Applied latest API configs (.env) to lead-engine and duckdns services. - Updated documentation (GEMINI.md, readme.md, RELOCATION.md, lead-engine/README.md) to reflect final state and lessons learned. - Committed all pending changes to main branch.
This commit is contained in:
54
GEMINI.md
54
GEMINI.md
@@ -23,35 +23,40 @@ Dies ist in der Vergangenheit mehrfach passiert und hat zu massivem Datenverlust
|
||||
---
|
||||
## ‼️ Aktueller Projekt-Fokus (März 2026): Migration & Stabilisierung
|
||||
|
||||
**Das System wurde am 07. März 2026 vollständig stabilisiert und für den Umzug auf die Ubuntu VM (`docker1`) vorbereitet.**
|
||||
**Das System wurde am 07. März 2026 erfolgreich stabilisiert und für den Umzug auf die Ubuntu VM (`docker1`) vorbereitet.**
|
||||
|
||||
Alle aktuellen Aufgaben für den Umzug sind hier zentralisiert:
|
||||
Alle kritischen Komponenten (Company Explorer, Connector, Lead Engine) sind nun funktionsfähig und resilient konfiguriert.
|
||||
|
||||
Alle weiteren Aufgaben für den Umzug sind hier zentralisiert:
|
||||
➡️ **[`RELOCATION.md`](./RELOCATION.md)**
|
||||
|
||||
---
|
||||
|
||||
## ✅ Current Status (March 7, 2026) - STABLE
|
||||
## ✅ Current Status (March 7, 2026) - STABLE & RESILIENT
|
||||
|
||||
Das System läuft stabil auf der Synology-Entwicklungsumgebung.
|
||||
Das System läuft stabil und ist für den Produktivbetrieb vorbereitet. Wesentliche Fortschritte wurden erzielt:
|
||||
|
||||
### 1. SuperOffice Connector (v2.1.1 - "Echo Shield")
|
||||
* **Echo-Prävention (Härtung):** Der Worker (`worker.py`) identifiziert sich beim Start dynamisch (`/Associate/Me`) und ignoriert strikt alle Events, die vom eigenen User (z.B. ID 528) ausgelöst wurden.
|
||||
* **Feld-Filter:** Änderungen werden nur verarbeitet, wenn relevante Felder (Name, URL, JobTitle) betroffen sind. Irrelevante Updates (z.B. `lastUpdated`) werden geskippt.
|
||||
* **Webhook:** Registriert auf `https://floke-ai.duckdns.org/connector/webhook` mit Token-Validierung im Query-String.
|
||||
* **Echo-Prävention:** Implementierung eines robusten "Echo Shield" im Worker. Der Worker identifiziert seine eigenen Aktionen (via `ChangedByAssociateId`) und vermeidet dadurch Endlosschleifen. Änderungen sind nur noch bei externen, relevanten Feldaktualisierungen (Name, Website, JobTitle) relevant.
|
||||
* **Webhook:** Erfolgreich registriert auf `https://floke-ai.duckdns.org/connector/webhook` mit sicherer Token-Validierung.
|
||||
|
||||
### 2. Company Explorer (v0.7.4)
|
||||
* **Datenbank:** Schema repariert (`fix_missing_columns.py` ausgeführt). Fehlende Spalten (`street`, `zip_code`, `unsubscribe_token`) sind nun vorhanden.
|
||||
* **Frontend:** Build-Pipeline repariert. PostCSS/Tailwind generieren jetzt wieder korrektes Styling.
|
||||
* **Persistence:** Datenbank liegt sicher im Docker Volume `explorer_db_data`.
|
||||
* **Datenbank:** Schema-Integrität wiederhergestellt. Fehlende Spalten (`street`, `zip_code`, `unsubscribe_token`, `strategy_briefing`) wurden mit Migrations-Skripten nachgerüstet. Keine 500er Fehler mehr.
|
||||
* **Frontend:** Build-Pipeline mit PostCSS/Tailwind-Styling repariert, sodass die UI wieder einwandfrei funktioniert.
|
||||
|
||||
### 3. Lead Engine (Trading Twins)
|
||||
* **Integration:** In `docker-compose.yml` integriert und unter `/lead/` via Gateway erreichbar.
|
||||
* **Persistence:** Nutzt Volume `lead_engine_data`.
|
||||
* **Status:** UI läuft. E-Mail-Ingest via MS Graph benötigt noch Credentials.
|
||||
### 3. Lead Engine (Trading Twins - Voll funktionsfähig)
|
||||
* **Integration:** Service erfolgreich in den Docker-Stack integriert und über Nginx unter `/lead/` und `/feedback/` erreichbar.
|
||||
* **Persistent State:** Led-Daten und Job-Status werden nun zuverlässig in einer SQLite-Datenbank (`/app/data/trading_twins.db`) gespeichert.
|
||||
* **Roundtrip-Funktionalität:** Der komplette Prozess (Lead -> CE -> KI -> Teams-Benachrichtigung -> E-Mail mit Kalender-Links -> Outlook-Termin) funktioniert End-to-End.
|
||||
* **Fehlerbehebung (Debugging-Iterationen):
|
||||
* **`sqlalchemy` & Imports:** Installation von `sqlalchemy` sichergestellt, Pfade für Module (`trading_twins`) im Docker-Build korrigiert.
|
||||
* **Nginx Routing:** Konfiguration optimiert, um `/feedback/` und `/lead/` korrekt an den FastAPI-Server weiterzuleiten. Globale `auth_basic` entfernt, um öffentlichen Endpunkten den Zugriff zu ermöglichen.
|
||||
* **FastAPI `root_path`:** Bereinigt, um Konflikte mit Nginx-Pfaden zu vermeiden.
|
||||
* **Server Stabilität:** `uvicorn` startet nun als separater Prozess, und der `monitor.py` importiert die Module sauber.
|
||||
* **API-Schlüssel:** Alle notwendigen Keys (`INFO_*`, `CAL_*`, `SERP_API`, `WEBHOOK_*`, `GEMINI_API_KEY`) werden korrekt aus `.env` an die Container gemappt.
|
||||
|
||||
### 4. Infrastructure
|
||||
* **Secrets:** Alle API-Keys (OpenAI, Gemini, SO, DuckDNS) sind zentral in der `.env` Datei.
|
||||
* **DuckDNS:** Service läuft und aktualisiert die IP erfolgreich.
|
||||
### 5. DuckDNS & DNS Monitor
|
||||
* **Erfolgreich reaktiviert:** Der DynDNS-Service läuft und aktualisiert die IP, die Netzwerk-Konnektivität ist stabil.
|
||||
|
||||
---
|
||||
|
||||
@@ -104,6 +109,7 @@ Gelegentlich kann es vorkommen, dass `git push` oder `git pull` Befehle aus dem
|
||||
|
||||
Diese Konfiguration gewährleistet eine stabile Git-Verbindung innerhalb Ihrer Docker-Umgebung.
|
||||
|
||||
---
|
||||
|
||||
## Project Overview
|
||||
|
||||
@@ -147,7 +153,7 @@ The system architecture has evolved from a CLI-based toolset to a modern web app
|
||||
|
||||
2. **The Wolfra/Greilmeier/Erding Fixes (Advanced Metric Parsing):**
|
||||
* **Problem:** Simple regex parsers fail on complex sentences with multiple numbers, concatenated years, or misleading prefixes.
|
||||
* **Solution (Hybrid Extraction & Regression Testing):**
|
||||
* **Solution (Hybrid Extraction & Regression Testing):**
|
||||
1. **LLM Guidance:** The LLM provides an `expected_value` (e.g., "8.000 m²").
|
||||
2. **Robust Python Parser (`MetricParser`):** This parser aggressively cleans the `expected_value` (stripping units like "m²") to get a numerical target. It then intelligently searches the full text for this target, ignoring other numbers (like "2" in "An 2 Standorten").
|
||||
3. **Specific Bug Fixes:**
|
||||
@@ -212,15 +218,15 @@ Since the "Golden Record" for Industry Verticals (Pains, Gains, Products) reside
|
||||
**Key Scripts:**
|
||||
|
||||
1. **`check_relations.py` (Reader - Deep):**
|
||||
- **Purpose:** Reads Verticals and resolves linked Product Categories (Relation IDs -> Names). Essential for verifying the "Primary/Secondary Product" logic.
|
||||
- **Usage:** `python3 check_relations.py`
|
||||
* **Purpose:** Reads Verticals and resolves linked Product Categories (Relation IDs -> Names). Essential for verifying the "Primary/Secondary Product" logic.
|
||||
* **Usage:** `python3 check_relations.py`
|
||||
|
||||
2. **`update_notion_full.py` (Writer - Batch):**
|
||||
- **Purpose:** Batch updates Pains and Gains for multiple verticals. Use this as a template when refining the messaging strategy.
|
||||
- **Usage:** Edit the dictionary in the script, then run `python3 update_notion_full.py`.
|
||||
* **Purpose:** Batch updates Pains and Gains for multiple verticals. Use this as a template when refining the messaging strategy.
|
||||
* **Usage:** Edit the dictionary in the script, then run `python3 update_notion_full.py`.
|
||||
|
||||
3. **`list_notion_structure.py` (Schema Discovery):**
|
||||
- **Purpose:** Lists all property keys and page titles. Use this to debug schema changes (e.g. if a column was renamed).
|
||||
* **Purpose:** Lists all property keys and page titles. Use this to debug schema changes (e.g. if a column was renamed).
|
||||
- **Usage:** `python3 list_notion_structure.py`
|
||||
|
||||
## Next Steps (Updated Feb 27, 2026)
|
||||
@@ -381,4 +387,4 @@ SuperOffice Tickets represent the support and request system. Like Sales, they a
|
||||
* **Cross-Links:** Tickets can be linked to `saleId` (to track support during a sale) or `projectId`.
|
||||
|
||||
---
|
||||
This is the core logic used to generate the company-specific opener.
|
||||
This is the core logic used to generate the company-specific opener.
|
||||
|
||||
Reference in New Issue
Block a user