feat(Notion): Refactor product DBs for GTM strategy

- Implements a 3-tier database architecture (Canonical Products, Portfolio, Companies) to separate product master data from company-specific portfolio information.

- Upgrades import_competitive_radar.py to an intelligent "upsert" script that prevents duplicates by checking for existing entries before importing.

- This enables detailed GTM strategy tracking for RoboPlanet products while monitoring competitor portfolios.

- Updates documentation to reflect the new architecture and import process.

Notion_Dashboard.md

@@ -39,11 +39,12 @@ Die Schaltstelle für die hyper-personalisierte Ansprache.
 *   **Logik:** Trennung in **Satz 1** (Individueller Hook basierend auf der aktuellen Website-Analyse des Zielkunden) und **Satz 2** (Relationaler Lösungsbaustein basierend auf Branche + Produkt).
 *   **Voice-Ready:** Vorbereitung von Skripten für den zukünftigen Voice-KI-Einsatz im Vertrieb und Support.
 
-### 3.4 Competitive Radar (Market Intelligence v2.0)
-Automatisierte Überwachung der Marktbegleiter mit Fokus auf "Grounded Truth".
-*   **Funktion:** Kontinuierliches Scraping von Wettbewerber-Webseiten, gezielte Suche nach Referenzkunden und Case Studies.
-*   **Kill-Argumente & Landmines:** Erstellung von strukturierten Battlecards und spezifischen "Landmine Questions" für den Sales-Außendienst.
-*   **Relationaler Ansatz:** Trennung in vier verknüpfte Datenbanken (Firmen, Landmines, Referenzen, Produkte) für maximale Filterbarkeit und Übersicht.
+### 3.4 Competitive Radar & GTM Engine (Market Intelligence v3.0)
+Automatisierte Überwachung der Marktbegleiter *und* zentrale Steuerung der eigenen Go-to-Market-Strategien.
+*   **Architektur-Upgrade (Jan 2026):** Das System wurde auf eine 3-Tier-Architektur umgestellt, um zwischen dem **kanonischen Produkt** (was es ist) und dem **Portfolio-Eintrag** (wer es zu welchen Konditionen/mit welcher Strategie verkauft) zu unterscheiden.
+*   **Funktion (Market Intelligence):** Kontinuierliches Scraping von Wettbewerber-Webseiten zur Identifikation ihres Produkt-Portfolios, ihrer Referenzkunden und zur Erstellung von "Landmines" (Angriffsfragen).
+*   **Funktion (GTM Engine):** Für RoboPlanet-eigene Produkte dient das System als "Single Source of Truth". Es erfasst die komplette GTM-Strategie – von der technischen Analyse über die Definition der Zielbranchen (ICPs) und Schmerzpunkte bis hin zur Erstellung von Sales-Battlecards und ROI-Rechnern.
+*   **Relationaler Kern:** Das System besteht nun aus einem Netz von Datenbanken, dessen Herzstück die Triade `Canonical Products` ↔️ `Portfolio` ↔️ `Companies` ist. Dies ermöglicht es, ein Produkt (z.B. "Puma M20") einmal zentral zu definieren und dann spezifische Marketing- und Vertriebsstrategien für den Verkauf durch RoboPlanet anzuhängen, während gleichzeitig erfasst wird, welche Wettbewerber dasselbe Produkt führen.
 
 ### 3.5 Enrichment Factory & RevOps
 Datenanreicherung der CRM-Accounts.
@@ -61,13 +62,22 @@ Datenanreicherung der CRM-Accounts.
 3.  **Positioning:** KI matcht Specs gegen die **Market Psychology DB** in Notion.
 4.  **Generation:** Erstellung von Website-Inhalten (WordPress API) und Sales-Battlecards.
 
-### B. Der Outbound-Prozess (Whale Hunting)
-1.  **Scanning:** Enrichment-Tool liest Ziel-Accounts aus SuperOffice.
-2.  **Hyper-Personalization:**
-    *   KI analysiert Kunden-Website -> Generiert **Satz 1** (Operative Herausforderung).
-    *   System zieht **Satz 2** aus der **Messaging Matrix** in Notion.
-3.  **CRM-Injection:** Der finale Text wird via API in SuperOffice injiziert.
-4.  **Execution:** Vertrieb sendet hochgradig relevante Mails direkt aus dem gewohnten CRM.
+### C. Der Market-Intelligence-Prozess (Inkrementeller Import)
+Nach der Umstrukturierung der Datenbanken wurde der Importprozess von einem reinen "Einmal-Import" zu einem intelligenten, zustandsbewussten Synchronisierungs-Workflow weiterentwickelt. Dies ist der Schlüssel, um das System als lebendes "Market Radar"-Tool zu nutzen.
+
+1.  **Trigger:** Manueller Start des `import_competitive_radar.py` Skripts mit einer neuen Analyse-JSON-Datei als Input.
+2.  **Phase 1: State Awareness (IST-Zustand lesen):**
+    *   Bevor das Skript die neue Datei liest, fragt es den aktuellen Stand in Notion ab.
+    *   Es erstellt drei "Caches" im Arbeitsspeicher: eine Liste aller existierenden Firmen, eine Liste aller `Canonical Products` und eine Liste aller `Portfolio`-Verknüpfungen (welche Firma verkauft welches Produkt).
+3.  **Phase 2: Abgleich & "Upsert" (SOLL-Zustand verarbeiten):**
+    *   Das Skript liest die neue JSON-Datei Wettbewerber für Wettbewerber.
+    *   **"Upsert" Logik:** Für jeden Eintrag (Firma, Produkt, Portfolio-Verknüpfung) prüft es gegen seine Caches, ob dieser bereits in Notion existiert.
+        *   **Fall A (Existiert bereits):** Der Eintrag wird übersprungen. Es werden keine Änderungen vorgenommen.
+        *   **Fall B (Existiert noch nicht):** Nur der fehlende Eintrag wird erstellt. Wenn z.B. das Produkt "BellaBot" schon existiert, aber die Firma "Robo-Heroes" neu ist, wird nur die neue Firma und die neue Portfolio-Verknüpfung ("Robo-Heroes verkauft BellaBot") angelegt.
+4.  **Ergebnis (Idempotenter Import):**
+    *   **Keine Duplikate:** Firmen und kanonische Produkte werden niemals doppelt erstellt.
+    *   **Inkrementelle Updates:** Nur neue Informationen werden hinzugefügt. Das System wächst mit jeder Analyse, anstatt überschrieben zu werden.
+    *   **Sicherheit:** Das Skript kann beliebig oft mit derselben Datei ausgeführt werden. Nach dem ersten Lauf wird es keine Änderungen mehr vornehmen, da es erkennt, dass alle Daten bereits synchronisiert sind.
 
 ---
 
@@ -84,19 +94,28 @@ Reduzierte Notion-Ansicht für Vertriebler vor Ort, die basierend auf dem Stando
 
 ---
 
-## 6. Notion Datenbank-Relationen (Technisches Mapping)
+## 6. Notion Datenbank-Relationen (Technisches Mapping - Architektur v3.0)
 
-Um die relationale Integrität zu wahren, sind folgende Datenbanken in Notion zwingend zu verknüpfen:
+Um die relationale Integrität zu wahren, sind folgende Datenbanken in Notion zwingend zu verknüpfen. Das Modell trennt zwischen anbieterneutralen Stammdaten (`Canonical Products`) und der anbieterspezifischen Vertriebssicht (`Portfolio`).
 
-*   **Product Master** $\leftrightarrow$ **Sector Master** (Welcher Roboter passt in welchen Markt?)
-*   **Messaging Matrix** $\leftrightarrow$ **Product Master** (Welche Lösung gehört zum Text?)
-*   **Messaging Matrix** $\leftrightarrow$ **Sector Master** (Welcher Schmerz gehört zu welcher Branche?)
-*   **Competitive Radar (Companies)** $\leftrightarrow$ **Competitive Radar (Landmines)** (Welche Angriffsfragen gehören zu welchem Wettbewerber?)
-*   **Competitive Radar (Companies)** $\leftrightarrow$ **Competitive Radar (References)** (Welche Kundenprojekte hat der Wettbewerber realisiert?)
-*   **Competitive Radar (Companies)** $\leftrightarrow$ **Competitive Radar (Products)** (Welche Produkte hat der Wettbewerber im Portfolio?)
-*   **The Brain** $\leftrightarrow$ **Product Master** (Welches Support-Wissen gehört zu welcher Hardware?)
-*   **GTM Workspace** $\leftrightarrow$ **Product Master** (Welche Kampagne bewirbt welches Gerät?)
-*   **Feature-to-Value Translator** $\leftrightarrow$ **Product Master** (Welcher Nutzen gehört zu welchem Feature?)
+*   **Kern-Relationen (Produkt & Markt):**
+    *   **Canonical Products** ↔️ **Portfolio** (Ein kanonisches Produkt kann in mehreren Portfolios sein)
+    *   **Companies** ↔️ **Portfolio** (Ein Unternehmen hat mehrere Produkte im Portfolio)
+    *   **Canonical Products** ↔️ **Product Categories** (Jedes Produkt gehört zu einer Kategorie)
+
+*   **GTM & Marketing-Relationen:**
+    *   **Canonical Products** ↔️ **Sector & Persona Master** (Welcher Roboter passt in welchen Markt?)
+    *   **Messaging Matrix** ↔️ **Canonical Products** (Welche Lösung gehört zum Text?)
+    *   **Messaging Matrix** ↔️ **Sector & Persona Master** (Welcher Schmerz gehört zu welcher Branche?)
+    *   **GTM Workspace** ↔️ **Canonical Products** (Welche Kampagne bewirbt welches Gerät?)
+    *   **Feature-to-Value Translator** ↔️ **Canonical Products** (Welcher Nutzen gehört zu welchem Feature?)
+
+*   **Competitive Intelligence-Relationen:**
+    *   **Companies** ↔️ **Competitive Radar (Landmines)** (Welche Angriffsfragen gehören zu welchem Wettbewerber?)
+    *   **Companies** ↔️ **Competitive Radar (References)** (Welche Kundenprojekte hat der Wettbewerber realisiert?)
+
+*   **Wissensmanagement-Relationen:**
+    *   **The Brain** ↔️ **Canonical Products** (Welches Support-Wissen gehört zu welcher Hardware?)
 
 ---