docs: RESTORED complete MIGRATION_PLAN with full logic and tasks
This commit is contained in:
@@ -1,69 +1,174 @@
|
||||
# Migrations-Plan: Legacy GSheets -> Company Explorer (Robotics Edition v0.8.5)
|
||||
|
||||
**Kontext:** Strategische Neuausrichtung der Lead-Analyse für RoboPlanet.
|
||||
**Zentrale Philosophie:** Trennung von CRM-Historie ("Was wir wissen") und KI-Recherche ("Was aktuell wahr ist").
|
||||
**Kontext:** Neuanfang für die Branche **Robotik & Facility Management**.
|
||||
**Ziel:** Ablösung von Google Sheets/CLI durch eine Web-App ("Company Explorer") mit SQLite-Backend.
|
||||
|
||||
## 14. Detaillierte Logik der neuen Datenfelder (v2.0)
|
||||
## 1. Strategische Neuausrichtung
|
||||
|
||||
Um Gemini CLI (dem Bautrupp) die Umsetzung zu ermöglichen, hier die semantische Bedeutung und Implementierungs-Logik der neuen Spalten:
|
||||
| Bereich | Alt (Legacy) | Neu (Robotics Edition) |
|
||||
| :--- | :--- | :--- |
|
||||
| **Daten-Basis** | Google Sheets | **SQLite** (Lokal, performant, filterbar). |
|
||||
| **Ziel-Daten** | Allgemein / Kundenservice | **Quantifizierbares Potenzial** (z.B. 4500m² Fläche, 120 Betten). |
|
||||
| **Branchen** | KI-Vorschlag (Freitext) | **Strict Mode:** Mapping auf definierte Notion-Liste (z.B. "Hotellerie", "Automotive"). |
|
||||
| **Bewertung** | 0-100 Score (Vage) | **Data-Driven:** Rohwert (Scraper/Search) -> Standardisierung (Formel) -> Potenzial. |
|
||||
| **Analytics** | Techniker-ML-Modell | **Deaktiviert**. Fokus auf harte Fakten. |
|
||||
| **Operations** | D365 Sync (Broken) | **Excel-Import & Deduplizierung**. Fokus auf Matching externer Listen gegen Bestand. |
|
||||
|
||||
### 14.1 Qualitäts- & Abgleich-Metriken (Tabelle `companies`)
|
||||
## 2. Architektur & Komponenten-Mapping
|
||||
|
||||
Das System wird in `company-explorer/` neu aufgebaut. Wir lösen Abhängigkeiten zur Root `helpers.py` auf.
|
||||
|
||||
### A. Core Backend (`backend/`)
|
||||
|
||||
| Komponente | Aufgabe & Neue Logik | Prio |
|
||||
| :--- | :--- | :--- |
|
||||
| **Database** | Ersetzt `GoogleSheetHandler`. Speichert Firmen & "Enrichment Blobs". | 1 |
|
||||
| **Importer** | Ersetzt `SyncManager`. Importiert Excel-Dumps (CRM) und Event-Listen. | 1 |
|
||||
| **Deduplicator** | Ersetzt `company_deduplicator.py`. **Kern-Feature:** Checkt Event-Listen gegen DB. Muss "intelligent" matchen (Name + Ort + Web). | 1 |
|
||||
| **Scraper (Base)** | Extrahiert Text von Websites. Basis für alle Analysen. | 1 |
|
||||
| **Classification Service** | **NEU (v0.7.0).** Zweistufige Logik: <br> 1. Strict Industry Classification. <br> 2. Metric Extraction Cascade (Web -> Wiki -> SerpAPI). | 1 |
|
||||
| **Marketing Engine** | Ersetzt `generate_marketing_text.py`. Nutzt neue `marketing_wissen_robotics.yaml`. | 3 |
|
||||
|
||||
**Identifizierte Hauptdatei:** `company-explorer/backend/app.py`
|
||||
|
||||
### B. Frontend (`frontend/`) - React
|
||||
|
||||
* **View 1: Der "Explorer":** DataGrid aller Firmen. Filterbar nach "Roboter-Potential" und Status.
|
||||
* **View 2: Der "Inspector":** Detailansicht einer Firma. Zeigt gefundene Signale ("Hat SPA Bereich"). Manuelle Korrektur-Möglichkeit.
|
||||
* **Identifizierte Komponente:** `company-explorer/frontend/src/components/Inspector.tsx`
|
||||
* **View 3: "List Matcher":** Upload einer Excel-Liste -> Anzeige von Duplikaten -> Button "Neue importieren".
|
||||
* **View 4: "Settings":** Konfiguration von Branchen, Rollen und Robotik-Logik.
|
||||
* **Frontend "Settings" Komponente:** `company-explorer/frontend/src/components/RoboticsSettings.tsx`
|
||||
|
||||
### C. Architekturmuster für die Client-Integration
|
||||
|
||||
Um externen Diensten (wie der `lead-engine`) eine einfache und robuste Anbindung an den `company-explorer` zu ermöglichen, wurde ein standardisiertes Client-Connector-Muster implementiert.
|
||||
|
||||
| Komponente | Aufgabe & Neue Logik |
|
||||
| :--- | :--- |
|
||||
| **`company_explorer_connector.py`** | **NEU:** Ein zentrales Python-Skript, das als "offizieller" Client-Wrapper für die API des Company Explorers dient. Es kapselt die Komplexität der asynchronen Enrichment-Prozesse. |
|
||||
| **`handle_company_workflow()`** | Die Kernfunktion des Connectors. Sie implementiert den vollständigen "Find-or-Create-and-Enrich"-Workflow: <br> 1. **Prüfen:** Stellt fest, ob ein Unternehmen bereits existiert. <br> 2. **Erstellen:** Legt das Unternehmen an, falls es neu ist. <br> 3. **Anstoßen:** Startet den asynchronen `discover`-Prozess. <br> 4. **Warten (Polling):** Überwacht den Status des Unternehmens, bis eine Website gefunden wurde. <br> 5. **Analysieren:** Startet den asynchronen `analyze`-Prozess. <br> **Vorteil:** Bietet dem aufrufenden Dienst eine einfache, quasi-synchrone Schnittstelle und stellt sicher, dass die Prozessschritte in der korrekten Reihenfolge ausgeführt werden. |
|
||||
|
||||
## 3. Umgang mit Shared Code (`helpers.py` & Co.)
|
||||
|
||||
Wir kapseln das neue Projekt vollständig ab ("Fork & Clean").
|
||||
|
||||
* **Quelle:** `helpers.py` (Root)
|
||||
* **Ziel:** `company-explorer/backend/lib/core_utils.py`
|
||||
* **Aktion:** Wir kopieren nur relevante Teile und ergänzen sie (z.B. `safe_eval_math`, `run_serp_search`).
|
||||
|
||||
## 4. Datenstruktur (SQLite Schema)
|
||||
|
||||
### Tabelle `companies` (Stammdaten & Analyse)
|
||||
* `id` (PK)
|
||||
* `name` (String)
|
||||
* `website` (String)
|
||||
* `crm_id` (String, nullable - Link zum D365)
|
||||
* `industry_crm` (String - Die "erlaubte" Branche aus Notion)
|
||||
* `city` (String)
|
||||
* `country` (String - Standard: "DE" oder aus Impressum)
|
||||
* `status` (Enum: NEW, IMPORTED, ENRICHED, QUALIFIED)
|
||||
* **NEU (v0.7.0):**
|
||||
* `calculated_metric_name` (String - z.B. "Anzahl Betten")
|
||||
* `calculated_metric_value` (Float - z.B. 180)
|
||||
* `calculated_metric_unit` (String - z.B. "Betten")
|
||||
* `standardized_metric_value` (Float - z.B. 4500)
|
||||
* `standardized_metric_unit` (String - z.B. "m²")
|
||||
* `metric_source` (String - "website", "wikipedia", "serpapi")
|
||||
|
||||
### Tabelle `signals` (Deprecated)
|
||||
* *Veraltet ab v0.7.0. Wird durch quantitative Metriken in `companies` ersetzt.*
|
||||
|
||||
### Tabelle `contacts` (Ansprechpartner)
|
||||
* `id` (PK)
|
||||
* `account_id` (FK -> companies.id)
|
||||
* `gender`, `title`, `first_name`, `last_name`, `email`
|
||||
* `job_title` (Visitenkarte)
|
||||
* `role` (Standardisierte Rolle: "Operativer Entscheider", etc.)
|
||||
* `status` (Marketing Status)
|
||||
|
||||
### Tabelle `industries` (Branchen-Fokus - Synced from Notion)
|
||||
* `id` (PK)
|
||||
* `notion_id` (String, Unique)
|
||||
* `name` (String - "Vertical" in Notion)
|
||||
* `description` (Text - "Definition" in Notion)
|
||||
* `metric_type` (String - "Metric Type")
|
||||
* `min_requirement` (Float - "Min. Requirement")
|
||||
* `whale_threshold` (Float - "Whale Threshold")
|
||||
* `proxy_factor` (Float - "Proxy Factor")
|
||||
* `scraper_search_term` (String - "Scraper Search Term")
|
||||
* `scraper_keywords` (Text - "Scraper Keywords")
|
||||
* `standardization_logic` (String - "Standardization Logic")
|
||||
|
||||
### Tabelle `job_role_mappings` (Rollen-Logik)
|
||||
* `id` (PK)
|
||||
* `pattern` (String - Regex für Jobtitles)
|
||||
* `role` (String - Zielrolle)
|
||||
|
||||
## 7. Historie & Fixes (Jan 2026)
|
||||
|
||||
* **[CRITICAL] v0.7.4: Service Restoration & Logic Fix (Jan 24, 2026)**
|
||||
* **[STABILITY] v0.7.3: Hardening Metric Parser & Regression Testing (Jan 23, 2026)**
|
||||
* **[STABILITY] v0.7.2: Robust Metric Parsing (Jan 23, 2026)**
|
||||
* **[STABILITY] v0.7.1: AI Robustness & UI Fixes (Jan 21, 2026)**
|
||||
* **[MAJOR] v0.7.0: Quantitative Potential Analysis (Jan 20, 2026)**
|
||||
* **[UPGRADE] v0.6.x: Notion Integration & UI Improvements**
|
||||
|
||||
## 14. Upgrade v2.0 (Feb 18, 2026): "Lead-Fabrik" Erweiterung
|
||||
|
||||
Dieses Upgrade transformiert den Company Explorer in das zentrale Gehirn der Lead-Generierung (Vorratskammer).
|
||||
|
||||
### 14.1 Detaillierte Logik der neuen Datenfelder
|
||||
|
||||
Um Gemini CLI (dem Bautrupp) die Umsetzung zu ermöglichen, hier die semantische Bedeutung der neuen Spalten:
|
||||
|
||||
#### Tabelle `companies` (Qualitäts- & Abgleich-Metriken)
|
||||
|
||||
* **`confidence_score` (FLOAT, 0.0 - 1.0):**
|
||||
* **Bedeutung:** Vertrauensindex der KI-Klassifizierung.
|
||||
* **UI-Logik:**
|
||||
* `>= 0.8`: Status "Grün". Vertrauenswürdige Daten.
|
||||
* `0.5 - 0.79`: Status "Gelb". Erfordert manuellen Check (Review).
|
||||
* `< 0.5`: Status "Rot". KI-Ergebnis unsicher.
|
||||
* **Hintergrund:** Verhindert, dass Sniper-Texte auf Basis falscher Branchen-Zuordnungen generiert werden.
|
||||
* **Logik:**
|
||||
* `> 0.8`: Auto-Approve (Daten werden als valide angesehen).
|
||||
* `0.5 - 0.8`: Review Required (Gelbe Flagge in der UI).
|
||||
* `< 0.5`: Low Confidence (Rote Flagge, manueller Eingriff zwingend).
|
||||
* **Ziel:** Effizienz durch Filterung auf qualitativ hochwertige Leads.
|
||||
|
||||
* **`data_mismatch_score` (FLOAT, 0.0 - 1.0):**
|
||||
* **Bedeutung:** Metrik für die Abweichung zwischen SuperOffice-Bestand und Web-Recherche.
|
||||
* **Rechenweg:** Die KI vergleicht Name, Adresse und Website.
|
||||
* `0.0`: Identisch (Voll-Treffer).
|
||||
* `0.5`: Teil-Mismatch (z.B. Firma heißt im Web leicht anders oder ist innerhalb der Stadt umgezogen).
|
||||
* `1.0`: Voller Mismatch (Zwei komplett verschiedene Firmen).
|
||||
* **UI-Ziel:** Im Inspector soll bei Werten `> 0.3` eine Warnung erscheinen: *"Achtung: Stammdaten weichen von Recherche ab!"*
|
||||
* **Bedeutung:** Mathematische/KI-Bewertung der Abweichung zwischen CRM-Bestandsdaten und neu gefundenen Web-Daten.
|
||||
* **Logik:**
|
||||
* `0.0`: Exakter Match.
|
||||
* `0.1 - 0.3`: Fuzzy Match (z.B. Abkürzungen \"Str.\" vs \"Straße\").
|
||||
* `> 0.5`: Kritische Abweichung (Möglicher Umzug oder falsche Website-Zuordnung).
|
||||
* **UI-Ziel:** Diese Fälle müssen im Inspector farblich hervorgehoben werden.
|
||||
|
||||
* **`crm_name`, `crm_address`, `crm_website`, `crm_vat`:**
|
||||
* **Zweck:** Read-Only Snapshot aus SuperOffice.
|
||||
* **Wichtig:** Diese Felder werden nie durch die Web-Recherche überschrieben. Sie dienen dem Side-by-Side Vergleich.
|
||||
* **Zweck:** Diese Felder sind Read-Only Snapshots aus dem SuperOffice-Export. Sie dienen ausschließlich dem Vergleich.
|
||||
* **Regel:** Die KI überschreibt NIEMALS diese Felder.
|
||||
|
||||
* **Status-Flags:**
|
||||
* **`website_scrape_status`**: Zeigt an, ob die Firmenwebsite erfolgreich ausgelesen wurde (`SUCCESS`, `FAILED`, `BLOCKED`).
|
||||
* **`wiki_search_status`**: Dokumentiert, ob ein Wikipedia-Eintrag gefunden wurde (`FOUND`, `NOT_FOUND`).
|
||||
|
||||
### 14.2 Strategie-Parameter (Tabelle `industries`)
|
||||
#### Tabelle `industries` (Strategie-Parameter)
|
||||
|
||||
* **`pains` / `gains`:**
|
||||
* Enthalten formatierte Textblöcke.
|
||||
* **Struktur:**
|
||||
`[Primary Product: Cleaning]`
|
||||
`- Pain A`
|
||||
`- Pain B`
|
||||
|
||||
`[Secondary Product: Service]`
|
||||
`- Pain C`
|
||||
* **Anforderung:** Das Frontend muss diese Blöcke sauber formatiert (whitespace-aware) anzeigen.
|
||||
|
||||
* Diese Felder enthalten strukturierte Textblöcke (getrennt durch `[Primary Product]` und `[Secondary Product]`).
|
||||
* **Verwendung:** Basis für die Sniper-Mail-Generierung.
|
||||
* **`ops_focus_secondary` (BOOLEAN):**
|
||||
* **Strategischer Hebel:** Wenn auf `True` gesetzt, muss die Lead-Engine für operative Rollen (z.B. "Pflegedienstleitung") automatisch das Sekundärprodukt wählen, da hier der "Teller-Transport" wichtiger ist als die "Bodenreinigung".
|
||||
* **Logik:** Wenn `True`, muss die Lead-Engine für operative Rollen automatisch das Sekundärprodukt wählen.
|
||||
|
||||
---
|
||||
|
||||
## 15. Anweisungen für Gemini CLI (Arbeitspakete)
|
||||
## 15. Offene Arbeitspakete (Bauleitung)
|
||||
|
||||
### Task 1: UI-Implementierung "Data Match & Strategy"
|
||||
Anweisungen für den \"Bautrupp\" (Gemini CLI).
|
||||
|
||||
### Task 1: UI-Implementierung \"Data Match & Strategy\"
|
||||
|
||||
**1. Inspector.tsx (Account Detail):**
|
||||
* Implementiere eine `CRMComparisonCard`.
|
||||
* Vergleiche `crm_name` vs `name` und `crm_website` vs `website`.
|
||||
* Erstelle eine Komponente `CRMComparisonCard`.
|
||||
* Vergleiche `crm_name` mit `name` und `crm_website` mit `website`.
|
||||
* Visualisiere den `data_mismatch_score` als Ampel oder Score-Balken.
|
||||
* **Fix:** Korrigiere den Aufruf der `ContactsManager` Komponente (erwartet `contacts` Array).
|
||||
* **Wichtig:** Entferne ungenutzte Imports wie `Save` oder `Calendar`, um Build-Fehler zu vermeiden!
|
||||
* **Fix:** Korrigiere den Aufruf der `ContactsManager` Komponente (erwartet `contacts={data.contacts}`).
|
||||
|
||||
**2. RoboticsSettings.tsx (Settings):**
|
||||
* Erweitere die `Industries`-Tabelle um die Spalten `Pains`, `Gains`, `Priorität` und `Secondary Product`.
|
||||
* Ermögliche das Ein-/Auskappen von langen Pain-Texten zur besseren Übersicht.
|
||||
* Erweitere die Industries-Tabelle um die Anzeige von Pains, Gains und Priority.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,69 +1,174 @@
|
||||
# Migrations-Plan: Legacy GSheets -> Company Explorer (Robotics Edition v0.8.5)
|
||||
|
||||
**Kontext:** Strategische Neuausrichtung der Lead-Analyse für RoboPlanet.
|
||||
**Zentrale Philosophie:** Trennung von CRM-Historie ("Was wir wissen") und KI-Recherche ("Was aktuell wahr ist").
|
||||
**Kontext:** Neuanfang für die Branche **Robotik & Facility Management**.
|
||||
**Ziel:** Ablösung von Google Sheets/CLI durch eine Web-App ("Company Explorer") mit SQLite-Backend.
|
||||
|
||||
## 14. Detaillierte Logik der neuen Datenfelder (v2.0)
|
||||
## 1. Strategische Neuausrichtung
|
||||
|
||||
Um Gemini CLI (dem Bautrupp) die Umsetzung zu ermöglichen, hier die semantische Bedeutung und Implementierungs-Logik der neuen Spalten:
|
||||
| Bereich | Alt (Legacy) | Neu (Robotics Edition) |
|
||||
| :--- | :--- | :--- |
|
||||
| **Daten-Basis** | Google Sheets | **SQLite** (Lokal, performant, filterbar). |
|
||||
| **Ziel-Daten** | Allgemein / Kundenservice | **Quantifizierbares Potenzial** (z.B. 4500m² Fläche, 120 Betten). |
|
||||
| **Branchen** | KI-Vorschlag (Freitext) | **Strict Mode:** Mapping auf definierte Notion-Liste (z.B. "Hotellerie", "Automotive"). |
|
||||
| **Bewertung** | 0-100 Score (Vage) | **Data-Driven:** Rohwert (Scraper/Search) -> Standardisierung (Formel) -> Potenzial. |
|
||||
| **Analytics** | Techniker-ML-Modell | **Deaktiviert**. Fokus auf harte Fakten. |
|
||||
| **Operations** | D365 Sync (Broken) | **Excel-Import & Deduplizierung**. Fokus auf Matching externer Listen gegen Bestand. |
|
||||
|
||||
### 14.1 Qualitäts- & Abgleich-Metriken (Tabelle `companies`)
|
||||
## 2. Architektur & Komponenten-Mapping
|
||||
|
||||
Das System wird in `company-explorer/` neu aufgebaut. Wir lösen Abhängigkeiten zur Root `helpers.py` auf.
|
||||
|
||||
### A. Core Backend (`backend/`)
|
||||
|
||||
| Komponente | Aufgabe & Neue Logik | Prio |
|
||||
| :--- | :--- | :--- |
|
||||
| **Database** | Ersetzt `GoogleSheetHandler`. Speichert Firmen & "Enrichment Blobs". | 1 |
|
||||
| **Importer** | Ersetzt `SyncManager`. Importiert Excel-Dumps (CRM) und Event-Listen. | 1 |
|
||||
| **Deduplicator** | Ersetzt `company_deduplicator.py`. **Kern-Feature:** Checkt Event-Listen gegen DB. Muss "intelligent" matchen (Name + Ort + Web). | 1 |
|
||||
| **Scraper (Base)** | Extrahiert Text von Websites. Basis für alle Analysen. | 1 |
|
||||
| **Classification Service** | **NEU (v0.7.0).** Zweistufige Logik: <br> 1. Strict Industry Classification. <br> 2. Metric Extraction Cascade (Web -> Wiki -> SerpAPI). | 1 |
|
||||
| **Marketing Engine** | Ersetzt `generate_marketing_text.py`. Nutzt neue `marketing_wissen_robotics.yaml`. | 3 |
|
||||
|
||||
**Identifizierte Hauptdatei:** `company-explorer/backend/app.py`
|
||||
|
||||
### B. Frontend (`frontend/`) - React
|
||||
|
||||
* **View 1: Der "Explorer":** DataGrid aller Firmen. Filterbar nach "Roboter-Potential" und Status.
|
||||
* **View 2: Der "Inspector":** Detailansicht einer Firma. Zeigt gefundene Signale ("Hat SPA Bereich"). Manuelle Korrektur-Möglichkeit.
|
||||
* **Identifizierte Komponente:** `company-explorer/frontend/src/components/Inspector.tsx`
|
||||
* **View 3: "List Matcher":** Upload einer Excel-Liste -> Anzeige von Duplikaten -> Button "Neue importieren".
|
||||
* **View 4: "Settings":** Konfiguration von Branchen, Rollen und Robotik-Logik.
|
||||
* **Frontend "Settings" Komponente:** `company-explorer/frontend/src/components/RoboticsSettings.tsx`
|
||||
|
||||
### C. Architekturmuster für die Client-Integration
|
||||
|
||||
Um externen Diensten (wie der `lead-engine`) eine einfache und robuste Anbindung an den `company-explorer` zu ermöglichen, wurde ein standardisiertes Client-Connector-Muster implementiert.
|
||||
|
||||
| Komponente | Aufgabe & Neue Logik |
|
||||
| :--- | :--- |
|
||||
| **`company_explorer_connector.py`** | **NEU:** Ein zentrales Python-Skript, das als "offizieller" Client-Wrapper für die API des Company Explorers dient. Es kapselt die Komplexität der asynchronen Enrichment-Prozesse. |
|
||||
| **`handle_company_workflow()`** | Die Kernfunktion des Connectors. Sie implementiert den vollständigen "Find-or-Create-and-Enrich"-Workflow: <br> 1. **Prüfen:** Stellt fest, ob ein Unternehmen bereits existiert. <br> 2. **Erstellen:** Legt das Unternehmen an, falls es neu ist. <br> 3. **Anstoßen:** Startet den asynchronen `discover`-Prozess. <br> 4. **Warten (Polling):** Überwacht den Status des Unternehmens, bis eine Website gefunden wurde. <br> 5. **Analysieren:** Startet den asynchronen `analyze`-Prozess. <br> **Vorteil:** Bietet dem aufrufenden Dienst eine einfache, quasi-synchrone Schnittstelle und stellt sicher, dass die Prozessschritte in der korrekten Reihenfolge ausgeführt werden. |
|
||||
|
||||
## 3. Umgang mit Shared Code (`helpers.py` & Co.)
|
||||
|
||||
Wir kapseln das neue Projekt vollständig ab ("Fork & Clean").
|
||||
|
||||
* **Quelle:** `helpers.py` (Root)
|
||||
* **Ziel:** `company-explorer/backend/lib/core_utils.py`
|
||||
* **Aktion:** Wir kopieren nur relevante Teile und ergänzen sie (z.B. `safe_eval_math`, `run_serp_search`).
|
||||
|
||||
## 4. Datenstruktur (SQLite Schema)
|
||||
|
||||
### Tabelle `companies` (Stammdaten & Analyse)
|
||||
* `id` (PK)
|
||||
* `name` (String)
|
||||
* `website` (String)
|
||||
* `crm_id` (String, nullable - Link zum D365)
|
||||
* `industry_crm` (String - Die "erlaubte" Branche aus Notion)
|
||||
* `city` (String)
|
||||
* `country` (String - Standard: "DE" oder aus Impressum)
|
||||
* `status` (Enum: NEW, IMPORTED, ENRICHED, QUALIFIED)
|
||||
* **NEU (v0.7.0):**
|
||||
* `calculated_metric_name` (String - z.B. "Anzahl Betten")
|
||||
* `calculated_metric_value` (Float - z.B. 180)
|
||||
* `calculated_metric_unit` (String - z.B. "Betten")
|
||||
* `standardized_metric_value` (Float - z.B. 4500)
|
||||
* `standardized_metric_unit` (String - z.B. "m²")
|
||||
* `metric_source` (String - "website", "wikipedia", "serpapi")
|
||||
|
||||
### Tabelle `signals` (Deprecated)
|
||||
* *Veraltet ab v0.7.0. Wird durch quantitative Metriken in `companies` ersetzt.*
|
||||
|
||||
### Tabelle `contacts` (Ansprechpartner)
|
||||
* `id` (PK)
|
||||
* `account_id` (FK -> companies.id)
|
||||
* `gender`, `title`, `first_name`, `last_name`, `email`
|
||||
* `job_title` (Visitenkarte)
|
||||
* `role` (Standardisierte Rolle: "Operativer Entscheider", etc.)
|
||||
* `status` (Marketing Status)
|
||||
|
||||
### Tabelle `industries` (Branchen-Fokus - Synced from Notion)
|
||||
* `id` (PK)
|
||||
* `notion_id` (String, Unique)
|
||||
* `name` (String - "Vertical" in Notion)
|
||||
* `description` (Text - "Definition" in Notion)
|
||||
* `metric_type` (String - "Metric Type")
|
||||
* `min_requirement` (Float - "Min. Requirement")
|
||||
* `whale_threshold` (Float - "Whale Threshold")
|
||||
* `proxy_factor` (Float - "Proxy Factor")
|
||||
* `scraper_search_term` (String - "Scraper Search Term")
|
||||
* `scraper_keywords` (Text - "Scraper Keywords")
|
||||
* `standardization_logic` (String - "Standardization Logic")
|
||||
|
||||
### Tabelle `job_role_mappings` (Rollen-Logik)
|
||||
* `id` (PK)
|
||||
* `pattern` (String - Regex für Jobtitles)
|
||||
* `role` (String - Zielrolle)
|
||||
|
||||
## 7. Historie & Fixes (Jan 2026)
|
||||
|
||||
* **[CRITICAL] v0.7.4: Service Restoration & Logic Fix (Jan 24, 2026)**
|
||||
* **[STABILITY] v0.7.3: Hardening Metric Parser & Regression Testing (Jan 23, 2026)**
|
||||
* **[STABILITY] v0.7.2: Robust Metric Parsing (Jan 23, 2026)**
|
||||
* **[STABILITY] v0.7.1: AI Robustness & UI Fixes (Jan 21, 2026)**
|
||||
* **[MAJOR] v0.7.0: Quantitative Potential Analysis (Jan 20, 2026)**
|
||||
* **[UPGRADE] v0.6.x: Notion Integration & UI Improvements**
|
||||
|
||||
## 14. Upgrade v2.0 (Feb 18, 2026): "Lead-Fabrik" Erweiterung
|
||||
|
||||
Dieses Upgrade transformiert den Company Explorer in das zentrale Gehirn der Lead-Generierung (Vorratskammer).
|
||||
|
||||
### 14.1 Detaillierte Logik der neuen Datenfelder
|
||||
|
||||
Um Gemini CLI (dem Bautrupp) die Umsetzung zu ermöglichen, hier die semantische Bedeutung der neuen Spalten:
|
||||
|
||||
#### Tabelle `companies` (Qualitäts- & Abgleich-Metriken)
|
||||
|
||||
* **`confidence_score` (FLOAT, 0.0 - 1.0):**
|
||||
* **Bedeutung:** Vertrauensindex der KI-Klassifizierung.
|
||||
* **UI-Logik:**
|
||||
* `>= 0.8`: Status "Grün". Vertrauenswürdige Daten.
|
||||
* `0.5 - 0.79`: Status "Gelb". Erfordert manuellen Check (Review).
|
||||
* `< 0.5`: Status "Rot". KI-Ergebnis unsicher.
|
||||
* **Hintergrund:** Verhindert, dass Sniper-Texte auf Basis falscher Branchen-Zuordnungen generiert werden.
|
||||
* **Logik:**
|
||||
* `> 0.8`: Auto-Approve (Daten werden als valide angesehen).
|
||||
* `0.5 - 0.8`: Review Required (Gelbe Flagge in der UI).
|
||||
* `< 0.5`: Low Confidence (Rote Flagge, manueller Eingriff zwingend).
|
||||
* **Ziel:** Effizienz durch Filterung auf qualitativ hochwertige Leads.
|
||||
|
||||
* **`data_mismatch_score` (FLOAT, 0.0 - 1.0):**
|
||||
* **Bedeutung:** Metrik für die Abweichung zwischen SuperOffice-Bestand und Web-Recherche.
|
||||
* **Rechenweg:** Die KI vergleicht Name, Adresse und Website.
|
||||
* `0.0`: Identisch (Voll-Treffer).
|
||||
* `0.5`: Teil-Mismatch (z.B. Firma heißt im Web leicht anders oder ist innerhalb der Stadt umgezogen).
|
||||
* `1.0`: Voller Mismatch (Zwei komplett verschiedene Firmen).
|
||||
* **UI-Ziel:** Im Inspector soll bei Werten `> 0.3` eine Warnung erscheinen: *"Achtung: Stammdaten weichen von Recherche ab!"*
|
||||
* **Bedeutung:** Mathematische/KI-Bewertung der Abweichung zwischen CRM-Bestandsdaten und neu gefundenen Web-Daten.
|
||||
* **Logik:**
|
||||
* `0.0`: Exakter Match.
|
||||
* `0.1 - 0.3`: Fuzzy Match (z.B. Abkürzungen \"Str.\" vs \"Straße\").
|
||||
* `> 0.5`: Kritische Abweichung (Möglicher Umzug oder falsche Website-Zuordnung).
|
||||
* **UI-Ziel:** Diese Fälle müssen im Inspector farblich hervorgehoben werden.
|
||||
|
||||
* **`crm_name`, `crm_address`, `crm_website`, `crm_vat`:**
|
||||
* **Zweck:** Read-Only Snapshot aus SuperOffice.
|
||||
* **Wichtig:** Diese Felder werden nie durch die Web-Recherche überschrieben. Sie dienen dem Side-by-Side Vergleich.
|
||||
* **Zweck:** Diese Felder sind Read-Only Snapshots aus dem SuperOffice-Export. Sie dienen ausschließlich dem Vergleich.
|
||||
* **Regel:** Die KI überschreibt NIEMALS diese Felder.
|
||||
|
||||
* **Status-Flags:**
|
||||
* **`website_scrape_status`**: Zeigt an, ob die Firmenwebsite erfolgreich ausgelesen wurde (`SUCCESS`, `FAILED`, `BLOCKED`).
|
||||
* **`wiki_search_status`**: Dokumentiert, ob ein Wikipedia-Eintrag gefunden wurde (`FOUND`, `NOT_FOUND`).
|
||||
|
||||
### 14.2 Strategie-Parameter (Tabelle `industries`)
|
||||
#### Tabelle `industries` (Strategie-Parameter)
|
||||
|
||||
* **`pains` / `gains`:**
|
||||
* Enthalten formatierte Textblöcke.
|
||||
* **Struktur:**
|
||||
`[Primary Product: Cleaning]`
|
||||
`- Pain A`
|
||||
`- Pain B`
|
||||
|
||||
`[Secondary Product: Service]`
|
||||
`- Pain C`
|
||||
* **Anforderung:** Das Frontend muss diese Blöcke sauber formatiert (whitespace-aware) anzeigen.
|
||||
|
||||
* Diese Felder enthalten strukturierte Textblöcke (getrennt durch `[Primary Product]` und `[Secondary Product]`).
|
||||
* **Verwendung:** Basis für die Sniper-Mail-Generierung.
|
||||
* **`ops_focus_secondary` (BOOLEAN):**
|
||||
* **Strategischer Hebel:** Wenn auf `True` gesetzt, muss die Lead-Engine für operative Rollen (z.B. "Pflegedienstleitung") automatisch das Sekundärprodukt wählen, da hier der "Teller-Transport" wichtiger ist als die "Bodenreinigung".
|
||||
* **Logik:** Wenn `True`, muss die Lead-Engine für operative Rollen automatisch das Sekundärprodukt wählen.
|
||||
|
||||
---
|
||||
|
||||
## 15. Anweisungen für Gemini CLI (Arbeitspakete)
|
||||
## 15. Offene Arbeitspakete (Bauleitung)
|
||||
|
||||
### Task 1: UI-Implementierung "Data Match & Strategy"
|
||||
Anweisungen für den \"Bautrupp\" (Gemini CLI).
|
||||
|
||||
### Task 1: UI-Implementierung \"Data Match & Strategy\"
|
||||
|
||||
**1. Inspector.tsx (Account Detail):**
|
||||
* Implementiere eine `CRMComparisonCard`.
|
||||
* Vergleiche `crm_name` vs `name` und `crm_website` vs `website`.
|
||||
* Erstelle eine Komponente `CRMComparisonCard`.
|
||||
* Vergleiche `crm_name` mit `name` und `crm_website` mit `website`.
|
||||
* Visualisiere den `data_mismatch_score` als Ampel oder Score-Balken.
|
||||
* **Fix:** Korrigiere den Aufruf der `ContactsManager` Komponente (erwartet `contacts` Array).
|
||||
* **Wichtig:** Entferne ungenutzte Imports wie `Save` oder `Calendar`, um Build-Fehler zu vermeiden!
|
||||
* **Fix:** Korrigiere den Aufruf der `ContactsManager` Komponente (erwartet `contacts={data.contacts}`).
|
||||
|
||||
**2. RoboticsSettings.tsx (Settings):**
|
||||
* Erweitere die `Industries`-Tabelle um die Spalten `Pains`, `Gains`, `Priorität` und `Secondary Product`.
|
||||
* Ermögliche das Ein-/Auskappen von langen Pain-Texten zur besseren Übersicht.
|
||||
* Erweitere die Industries-Tabelle um die Anzeige von Pains, Gains und Priority.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user