KI-Workflow-
Orchestrierung

1.1 Was ist XteVision Prodigy?

XteVision Prodigy ist ein selbstgehosteter, visueller knotenbasierter AI-Workflow-Builder, entwickelt für Ingenieure, Forscher und Teams, die komplexe AI-Pipelines über ein intuitives Drag-and-Drop-Interface zusammenstellen möchten. Es bietet multi-modale AI-Unterstützung, langfristiges Gedächtnis (Wisdom), agentische Werkzeugaufrufe, RAG-Embeddings und Integration mehrerer AI-Backends—all laufend auf einem lokalen Netzwerk mit voller DatenOwnership.

1.2 Kernfähigkeiten

• Visueller Knoten-Editor — Drag-and-Drop-Leinwand zum Zusammensetzen von AI-Workflows
• Sitzungs-Authentifizierung — Benutzerregistrierung und -login für alle AI-Aktionen
• Langfristiges Gedächtnis (Wisdom) — PostgreSQL-gestützte Wissensbasis mit Auto-Recall und Auto-Store
• Agentischer Werkzeugaufruf — Websuche, Browser-Automatisierung, Datei-I/O, Datenbankabfragen und mehr
• RAG / Embeddings — Semantische Chunk-Auswahl mit nomic-embed-text über Ollama
• Multi-modale AI — Native Vision-Unterstützung (Qwen-VL, LLaVA, etc.) über Bildknoten
• Mehrere AI-Backends — MLX, LM Studio, Ollama und GitHub Copilot (Bridge)
• Dokumenten-Extraktion — PDF/DOCX/XLSX/PPTX/TXT/CSV-Parsing
• Datenbankintegration — direkte MySQL/MariaDB-Abfragen aus Workflow-Knoten
• Websuche — SearXNG-Metasearch mit konfigurierbaren Motoren und Sprache
• Auslöser-System — Blockiere jeden AI-Knoten mit einem booleschen Gate für bedingte Routing
• Plugin-getriebene Architektur — Erweiterbarer Knotenkatalog mit Manifest-basierter Entdeckung
• HUD-Konsole — Echtzeit-Head-Up-Display für Werkzeugaufrufe, Gedächtnis-Ereignisse, Fehler
• Workflow-Vorlagen — Fertige JSON-Workflows zur schnellen Bereitstellung

1.3 Zielgruppe

• KI-Ingenieure beim Aufbau mehrstufiger Pipelines
• Forschungsteams, die reproduzierbare AI-Workflows benötigen
• Unternehmen, die datenlokale AI-Orchestrierung benötigen
• Entwickler beim Prototyping agentischer Systeme
• Teams bei der Integration mehrerer AI-Backends (lokal + cloud)

2.1 High-Level-Architektur

┌─────────────────────────────────────────────────────────┐
│              Browser (Gerät im LAN)                  │
│                    HTTPS / LAN                            │
└──────────────────────┬──────────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────────┐
│           Kali-Linux-Server (192.168.1.4)                │
│  ┌──────────────────────────────────────────────────┐  │
│  │        proxy_server.py (Port 9999)                │  │
│  │  • Servingt UI (HTML/CSS/JS)                      │  │
│  │  • CORS-Proxy → KI-Backends                       │  │
│  │  • Auth (Sitzungs-Token in PostgreSQL)            │  │
│  │  • Wisdom-langfristiges Gedächtnis (PostgreSQL)   │  │
│  │  • DB-Abfrage (MySQL/MariaDB)                     │  │
│  │  • Dokumenten-Extraktion (PDF/DOCX/XLSX/etc.)     │  │
│  │  • Werkzeugausführung (Websuche, Browser, etc.)   │  │
│  └──────────────────────────────────────────────────┘  │
│  PostgreSQL (Port 5432)    SearXNG (Port 8888)          │
└──────────────────────┬─────────────────────────────────┘
                       │ LAN (192.168.10.3)
┌──────────────────────▼─────────────────────────────────┐
│              Apple-Silicon-Mac                          │
│  ┌────────────┐ ┌──────────┐ ┌──────┐ ┌──────────┐   │
│  │ MLX-Server │ │LM Studio │ │Ollama│ │ Copilot  │   │
│  │ Port 5010  │ │Port 1234 │ │Port  │ │ Bridge   │   │
│  │            │ │          │ │11434 │ │Port 5015 │   │
│  └────────────┘ └──────────┘ └──────┘ └──────────┘   │
└───────────────────────────────────────────────────────┘

2.2 Kommunikationsfluss

1. Browser → Proxy-Server: HTTPS-Anfragen mit Sitzungs-Authentifizierung (X-Session-ID-Header)
2. Proxy-Server → KI-Backends: CORS-Proxy-Weiterleitung zu MLX, LM Studio, Ollama oder Copilot-Bridge
3. Proxy-Server → PostgreSQL: Wisdom-Gedächtnis, Benutzersitzungen, Wissensbasis-Abfragen
4. Proxy-Server → SearXNG: Websuche-Metasearch mit konfigurierbaren Motoren
5. Proxy-Server → Playwright: Browser-Automatisierung für agentische Web-Interaktionen
6. Proxy-Server → Browser: JSON-Antworten mit Workflow-Ausführungsergebnissen, SSE-Streaming

2.3 Bereitstellungsmodell

Prodigy ist für lokal-first, netzwerkzugängliche Bereitstellung ausgelegt:

• Proxy-Server läuft auf einer dedizierten Kali-Linux-Maschine (192.168.1.4)
• KI-Backends laufen auf Apple-Silicon-Mac (192.168.10.3) für optimale GPU/Neural Engine Auslastung
• Erreichbar von jedem Gerät im LAN über HTTPS
• Optionaler Reverse-Proxy für öffentlichen Zugriff (prodigy.xtevision.net)
• Alle Daten bleiben auf lokaler Infrastruktur (außer optionaler Copilot-Cloud-Zugang)

4.1 Voraussetzungen

• Kali-Linux / Debian-Server (192.168.1.4 empfohlen)
• Apple-Silicon-Mac (192.168.10.3 für KI-Backends)
• PostgreSQL (Port 5432, für Wisdom-Gedächtnis und Auth)
• SearXNG (Port 8888, optional für Websuche)
• Python 3.8+ (für Proxy-Server)

4.2 Server-Einrichtung (Kali-Linux)

Schritt 1: Python-Abhängigkeiten installieren

pip install psycopg2-binary pymysql pypdf python-docx openpyxl \
            python-pptx chardet bcrypt playwright

# Optional: Playwright-Browser ( für playwright_browse-Werkzeug)
playwright install chromium

# Optional: agent-browser CLI für reichhaltigere manuelle Browser-Automatisierung
npm install -g agent-browser

# Optional: OCR-Unterstützung innerhalb von Dokument-Knoten
sudo apt install tesseract-ocr poppler-utils

Schritt 2: Datenbank-Einrichtung

# Erstelle die Prodigy-PostgreSQL-Datenbank und -Tabellen
psql -U postgres -f postgres.sql

# Wende Auth-Sitzungs-Tabellen an
psql -U postgres -d prodigy -f sql_auth_setup.sql

Schritt 3: Server starten

cd /home/xteve/prodigy
./start.sh
# oder direkt:
python3 proxy_server.py

Schritt 4: Anwendung zugreifen

Lokal:     http://192.168.1.4:9999
Öffentlich:  https://prodigy.xtevision.net
Direkt:  http://192.168.1.4:9999

4.3 KI-Backend-Einrichtung (Apple-Silicon-Mac)

# MLX-Server
mlx_lm.server --model <model-path> --port 5010

# LM Studio (GUI - startet automatisch)

# Ollama
ollama serve  # port 11434

# GitHub Copilot-Bridge
cd /path/to/copilot
node copilot_bridge.mjs

4.4 Ersteinrichtung

1. Konto registrieren: Klicken Sie auf „Registrieren“ im Login-Bildschirm, um einen Benutzer zu erstellen
2. Login: Authentifizieren Sie sich mit Ihren Anmeldedaten (Sitzungs-Token im sessionStorage gespeichert)
3. KI-Backends konfigurieren: Bearbeiten Sie config.json zum Setzen von Backend-URLs und Standardmodellen
4. Workflow-Vorlage importieren: Nutzen Sie die Import-Schaltfläche zum Laden einer fertigen Workflow aus workflows/
5. Knoten testen: Fügen Sie einen Input-Knoten → AI-Knoten → Exit-Knoten hinzu und klicken Sie dann auf Ausführen

5.1 Verzeichnislayout

prodigy/
├── index.html                    # Haupt-UI-Einstiegspunkt
├── styles.css                    # Anwendungsstile (Hell/Dunkel-Modi)
├── config.json                   # Laufzeit-Konfiguration (Backends, SearXNG, Embedding, Wisdom-DB)
├── proxy_server.py               # Python-HTTP-Server (Port 9999)
├── copilot_bridge.mjs            # GitHub Copilot ↔ OpenAI-Bridge (Port 5015)
├── start.sh                      # Bequemlichkeits-Startskript
├── postgres.sql                  # PostgreSQL-Schema (knowledge_base, users, sessions)
├── sql_auth_setup.sql            # Auth-Tabellen-Einrichtung
├── js/
│   ├── main.js                   # Einstiegspunkt
│   ├── state.js                  # Globaler Zustand & Backend-Konfiguration
│   ├── constants.js              # NODE_TYPES-Enum, Throttle-Werte
│   ├── utils.js                  # fetchWithTimeout, Abort-Controller, URL-Helfer
│   ├── logic/
│   │   ├── execution.js          # Kern-Workflow-Engine — alle Knoten-Ausführungslogik
│   │   └── workflow.js           # Speichern / Laden / Import / Export
│   └── ui/
│       ├── auth.js               # Login / Registrierung-UI
│       ├── connections.js        # SVG-Verbindung-Zeichnung
│       ├── dashboard.js          # Dashboard & Workflow-Generierung
│       ├── node_manager.js       # Knoten-Erstellung, Einstellungspanels
│       ├── playground.js         # Leinwand, Drag, Pan, Resize
│       └── priority_manager.js   # Ausführungsreihenfolge Drag-and-Drop
├── workflows/                    # Fertige Workflow-Vorlagen
│   ├── incident_triage_escalation.json
│   ├── customer_support_triage.json
│   ├── competitive_intel_brief.json
│   ├── sql_ops_assistant.json
│   ├── deep_research_sweep.json
│   ├── schema_migration_checklist.json
│   ├── db_incident_response.json
│   ├── xlsx2wisdom.json
│   ├── marketing.json
│   ├── software.json
│   ├── agency.json
│   └── developer/                # Software-Liefer-Agentur-Vorlagen
│       ├── software_development_agency_sota.json
│       ├── software_development_agency_enterprise_saas.json
│       ├── software_development_agency_ai_agent_platform.json
│       ├── software_development_agency_regulated_internal_tool.json
│       └── software_development_agency_parallel_specialists.json
├── plugins/                      # Knoten-Plugins (eingebaut + Manifest)
└── logs/
    └── app.log                   # Anwendungslog

5.2 Modul-Abhängigkeiten

main.js (Bootstrap)
  ├── state.js
  ├── constants.js
  ├── utils.js
  ├── logic/execution.js → state.js, constants.js, utils.js
  ├── logic/workflow.js → state.js, utils.js
  ├── ui/auth.js → state.js, utils.js
  ├── ui/connections.js → state.js, playground.js
  ├── ui/dashboard.js → state.js, workflow.js, node_manager.js
  ├── ui/node_manager.js → state.js, constants.js, execution.js
  ├── ui/playground.js → state.js, connections.js, constants.js
  └── ui/priority_manager.js → state.js, workflow.js

7.1 Input / Output-Knoten

7.2 Datenbank-Knoten

7.3 Web / Suche-Knoten

7.4 AI / Reasoning-Knoten

7.5 Rolle / Agentur-Knoten

7.6 Logik / Steuerung-Knoten

7.7 Projekt / Kommunikations-Knoten

7.8 Industrielle / Spezialisierte Knoten

8.1 Plugin-Schnittstelle (IProdigyNode)

Alle Knotentypen werden über das Plugin-Register definiert. Jeder Knoten-Plugin liefert Metadaten wie:

• id — eindeutige Kennung für den Knotentyp
• nodeType — Enum-Wert für die Ausführungs-Routing
• title — Anzeigename in der Symbolleiste und Knoten-Einstellungspanels
• description — vom Dashboard-Architekten bei der Angabe verwendet, welche Knotentypen verfügbar sind
• ports — Eingangs- und Ausgangsport-Definitionen für Verbindungs-Validierung
• runtime capabilities — Werkzeugaufruf, Wisdom-Integration, RAG-Unterstützung, etc.

8.2 Standardfähigkeiten

class IProdigyNode:
    def Initialize(self, config): ...
    def Execute(self, input_data, ctx): ...
    def Report(self): ...
    def Hibernate(self): ...
    def UpdateConfig(self, new_config): ...

8.3 Plugin-Lebenszyklus

1. Entdeckung: Plugins werden beim Server-Start aus dem plugins/-Verzeichnis geladen
2. Registrierung: Jedes Plugin registriert sich beim zentralen Knotenkatalog
3. Ausführung: Die Workflow-Engine routet die Ausführung je nach nodeType zum passenden Plugin
4. Hot-Swapping: Plugins können ohne Neustart des Servers neu geladen werden (WIP)

8.4 Dashboard-Integration

Die Dashboard-Workflow-Architekten liest das Live-Plugin-Register und nutzt das description-Feld jedes Plugins beim Generieren von Workflows. Dies hält generierte Workflows mit dem tatsächlichen Knotenkatalog, einschließlich neuerer Rolle-Knoten und zukünftiger Manifest-Plugins, auf dem Laufenden.

9.1 Backend-Konfiguration

Backends werden in config.json unter dem backends-Schlüssel konfiguriert. Jedes Backend hat eine URL und ein Standardmodell.

9.2 Dashboard-Routing-Policy

• Standard für Workflow-Generierung: ollama mit gemini-3-flash-preview:latest (kostengünstig)
• Private Quellen (hochgeladene Dokumente, DB-Knoten, Wisdom, Projektarbeiten): zuerst zu lokalen Backends geroutet
• Public-sichere Coding-Aufgaben: Bevorzugung von GitHub Copilot-Kostenmodellen vor Premium-Modellen
• Gemischte Sensitivität-Workflows: Prodigy fügt lokalen KI-Decider + Logic Switch vor Cloud-Knoten ein, um unsichere Inhalte zu gate
• Lokale schwere AI-Arbeit: sequenziert statt parallel ausgegeben, um den gemeinsamen VRAM-Budget auf Apple Silicon zu respektieren

9.3 GitHub Copilot-Bridge

Die Bridge übersetzt OpenAI-kompatible Anfragen in GitHub Copilot SDK-Aufrufe und läuft separat auf der Apple-Silicon-Mac:

cd /path/to/copilot
node copilot_bridge.mjs

# Konfigurationspfad bei Bedarf überschreiben:
COPILOT_BRIDGE_CONFIG_PATH=/path/to/copilot_bridge.config.json node copilot_bridge.mjs

Verfügbare Copilot-Modelle

Die Bridge unterstützt sowohl Streaming (stream: true) als auch nicht-streamende Anfragen und wiederverwendet Sitzungen pro Modell, um den pro-Anfrage-Handshake-Overhead zu vermeiden.

Bridge-Lokale Browser-Werkzeuge

• playwright_browse — high-level Browser-/Lese-Werkzeug über den Apple-Silicon-Playwright-HTTP-Bridge bei /browse
• agent_browser — low-level strukturierte Browser-Automatisierung für open/click/fill/press/wait/snapshot/get/is-Aktionen

10.1 Basis-Fluss

1. Knoten hinzufügen: Klicken Sie auf die Symbolleisten-Schaltflächen, um Knoten zur Leinwand hinzuzügen
2. Knoten verbinden: Ziehen Sie von einem Ausgangsport (unten am Knoten) zu einem Eingangsport (oben), um Knoten zu verbinden
3. Ausführen: Klicken Sie auf Ausführen oder aktivieren Sie Auto-Ausführen (führt bei jeder Änderung 2 Sekunden lang erneut aus)

10.2 Beispiel-Workflows

Websuche → AI-Zusammenfassung

[Input: Thema] → [SearXNG] → [AI: Ergebnisse zusammenfassen] → [Exit]

Vision-Analyse

[Bild-Hochladen] → [AI (Vision-Modell)] → [Exit]

Dokumenten-F&A mit langfristigem Gedächtnis

[Dokument] → [AI (mit Wisdom-Recall an)] → [Wisdom-Knoten: Ergebnis speichern] → [Exit]

Bedingtes Routing

[Input] → [AI Decider] → true-Port  → [AI: Erfolg behandeln] → [Exit]
                       → false-Port → [AI: Fehler behandeln] → [Exit]

10.3 Auslöser-Gates

Verbindet die Ausgabe eines beliebigen Knotens mit dem Auslöser-Port eines AI / Brainstorm / Translator / Decider-Knotens. Der nachgelagerte Knoten führt nur aus, wenn das Auslöser-Signal auf true auswertet.

10.4 Workflow-Persistenz

• Auto-Speichern: Workflows speichern sich auf jede Änderung in localStorage
• Export: Download des aktuellen Workflows als JSON-Datei
• Import: Laden eines Workflows aus beliebiger JSON-Datei

10.5 Workflow-Vorlagen

Fertige Vorlagen befinden sich in workflows/. Import über die Import-Schaltfläche in der Symbolleiste.

10.6 Entwicklungs-Agentur-Vorlagen

Die Kategorie workflows/developer/ enthält Software-Liefer-Agentur-Vorlagen. Sie alle sperren zuerst ein Projekt-Codebase mit einem Projekt-Knoten vor der Interpretierung des Kunden-Entwurfs und nutzen Rolle-Knoten plus Governance-Gates, um mehrdeutige Anfragen bei komplexen Kundenanfragen zu reduzieren.

11.1 Übersicht

AI-Knoten können automatisch relevante Einträge aus der PostgreSQL-knowledge_base-Tabelle vor der Inferenz abrufen und neue Fakten nach einem erfolgreichen Lauf Speichern.

11.2 So funktioniert es

• Recall: Nutzt eine parametrisierte ILIKE-Volltextsuche — injection-safe
• Speichern: Automatisch durch AI-Knoten getriggert, wenn „Auto-Store zu Wisdom“ aktiviert ist
• Direkter Zugang: Sie können auch einen dedizierten Wisdom-Knoten zum direkten Lesen oder Schreiben nutzen
• Benutzerisolation: Wisdom-Zeilen werden pro authifiziertem Benutzer gehalten; der Proxy scopeft knowledge_base und messages-Abfragen auf den aktuellen Benutzer
• Sicherheit: users, sessions, pg_* und information_schema werden durch den Wisdom-Abfrage-Endpunkt nicht exponiert

11.3 Konfiguration

Wisdom wird in config.json unter dem wisdom-Schlüssel konfiguriert:

{
  "wisdom": {
    "host": "192.168.1.4",
    "port": 5432,
    "database": "prodigy",
    "user": "prodigy_user",
    "password": "your-password"
  }
}

11.4 Legacy-geteilte Zeilen

Wenn Sie bereits Legacy-geteilte Wisdom-Zeilen hat, führen Sie docs/sql_wisdom_user_isolation.sql aus und entscheiden, ob Sie diese alten Zeilen einem bestimmten Besitzer zurückfüllen sollen oder sie für normale Benutzer unzugänglich lassen.

12.1 Verfügbare Werkzeuge

12.2 Werkzeug-Ausführungsfluss

1. AI-Knoten fordert einen Werkzeugaufruf bei der Inferenz an
2. Proxy-Server validiert den Werkzeugnamen und die Parameter
3. Werkzeug führt serverseitig aus (Playwright, Dateisystem, Datenbank, etc.)
4. Ergebnisse kehren zum AI-Knoten für weiteres Reasoning zurück
5. Alle Werkzeug-Ereignisse werden auf der HUD-Konsole protokolliert

12.3 Browser-Automatisierung

Zwei Stufen von Browser-Automatisierung sind auf der Apple-Silicon-Host verfügbar:

• playwright_browse: Nutzt den lokalen HTTP-Browser-Bridge, der in copilot_bridge.config.json konfiguriert ist. High-level-API für Navigation und Lesen gererteter Seiten.
• agent_browser: Nutzt die agent-browser CLI. Low-level strukturierte Automatisierung für open/click/fill/press/wait/snapshot/get/is-Aktionen. Nutzt optional CDP, wenn playwrightCdpTarget oder PLAYWRIGHT_CDP_TARGET konfiguriert ist.

13.1 Sitzungs-Authentifizierung

• Benutzerregistrierung und -login über den Login-Bildschirm
• Sitzungs-Token im sessionStorage gespeichert (bei Tab-Schließen gelöscht)
• Token als X-Session-ID-Header bei jeder Anfrage gesendet
• Passwörter mit bcrypt in PostgreSQL gehasht

13.2 Datenisolation

• Wisdom-Zeilen werden pro authifiziertem Benutzer scopeft
• Wissensbasis- und Nachrichten-Abfragen werden automatisch nach Benutzer-ID gefiltert
• Systemtabellen (users, sessions, pg_*, information_schema) werden durch Abfrage-Endpunkte niemals exponiert

13.3 Backend-Routing-Datenschutz

• Prodigy behandelt MLX, LM Studio und Ollama als lokal/pivat Backends
• GitHub Copilot wird als Dritt-Anbieter behandelt und muss nur public-sichere Inhalte empfangen
• Private Quellen (hochgeladene Dokumente, DB-Knoten, Wisdom, Projektarbeiten) werden zuerst zu lokalen Backends geroutet
• Wenn ein Workflow sensible Eingaben mit Dritt-Anbieter-KI-Schritten mischt, fügt Prodigy einen lokalen AI Decider + Logic Switch ein, um unsichere Inhalte zu gate

13.4 Mehrthread-Sicherheit

Der Server ist mehrthreadig — jede Anfrage läuft in ihrem eigenen Thread, sodass langlaufende AI-Inferenz-Aufrufe die UI oder andere Anfragen nicht blockieren. Anfragen-Größenbegrenzung: 200 MB (für Dokument-Hochladungen).

14.1 Endpunkte

14.2 Auth-Header

GET /health
X-Session-ID: your-session-token

14.3 AI-Anfrage-Format

POST /ai
Content-Type: application/json
X-Session-ID: your-session-token

{
  "action": "ai_inference",
  "backend": "mlx",
  "model": "your-model",
  "prompt": "Ihr Prompt hier",
  "tools": ["web_search", "fetch_webpage"],
  "wisdom_recall": true,
  "wisdom_store": true
}

14.4 Proxy-Anfrage-Format

POST /proxy
Content-Type: application/json
X-Session-ID: your-session-token

{
  "url": "https://api.example.com/data",
  "method": "GET",
  "headers": {}
}

15.1 Hauptkonfigurations-Abschnitte

config.json trägt die verwaltbaren Standardwerte für:

• backends.*: KI-URLs und Standardmodelle
• embedding: Embedding-Endpunkt, Modell und Chunk-Einstellungen
• wisdom: PostgreSQL/Wisdom-Verbindungs-Standards
• defaults.mysql: Standard-MYSQL/MariaDB-Knotenwerte
• defaults.wisdom: Standard-Wisdom-Knotenwerte
• searxng: URL plus Such-Motoren und Sprache
• proxy: Proxy-Port, Sandbox-Wurzel, Playwright-CDP-Basis und Allowlists

15.2 SearXNG-Konfiguration

Jeder SearXNG-Knoten hat zwei optionale Dataset-Attribute, die direkt im Knoten-Einstellungspanel gesetzt werden können:

Diese fallen auf config.searxng.engines / config.searxng.language zurück, wenn sie nicht am Knoten gesetzt sind.

15.3 Embedding-Konfiguration

{
  "embedding": {
    "endpoint": "http://192.168.10.3:11434/api/embeddings",
    "model": "nomic-embed-text",
    "chunkSize": 500,
    "chunkOverlap": 50
  }
}

16.1 Konfiguration

Der Kommunikator-Knoten liest Standardwerte aus einem optionalen notifications-Block in config.json. Knoten-Felder können diese Werte zur Laufzeit überschreiben.

{
  "notifications": {
    "defaults": {
      "channel": "email",
      "emailTo": "team@example.com",
      "emailSubject": "Prodigy Update",
      "telegramChatId": "123456789"
    },
    "smtp": {
      "host": "smtp.example.com",
      "port": 587,
      "user": "mailer@example.com",
      "password": "",
      "fromAddress": "mailer@example.com",
      "starttls": true,
      "ssl": false,
      "timeout": 30
    },
    "telegram": {
      "botToken": "<telegram-bot-token>",
      "chatId": "123456789",
      "parseMode": "Markdown",
      "disablePreview": false
    }
  }
}

16.2 Unterstützte Kanäle

• E-Mail: SMTP mit STARTTLS-Unterstützung, konfigurierbare Timeout
• Telegram: Bot-Token-basierte Nachrichten mit Markdown-Parsing

17.1 Übersicht

Der eingebaute PLC / SPS-Knoten unterstützt ein Runtime-Modell der zweiten Stufe, das auf industrielles Prototyping abzielt:

• Dynamische benannte Sensor- und Aktuator-Pins, die direkt als Graph-Verbindungen gerendert werden
• Zurückgehaltenem Zustand, der im Workflow-Snapshot persistiert wird
• Mehrere Ausführungsmotoren

17.2 Ausführungsmotoren

17.3 PLC-Bridge-Konfiguration

Für die Strukturierten Text-Bereitstellung und Modbus/OpenPLC-Bridge, fügen Sie einen optionalen plc-Block zu config.json hinzu:

{
  "plc": {
    "openplcApiUrl": "http://192.168.1.50:8080/api",
    "modbusHost": "192.168.1.50",
    "modbusPort": 502,
    "inputCoilOffset": 0,
    "outputCoilOffset": 100
  }
}

Das Backend-Proxy nutzt diese Konfiguration für ST-Hochladen und Modbus-I/O-Synchronisierung. Dies ist für die remote-Linux/OpenPLC-Seite gedacht; der Browser spricht niemals direkt mit Modbus.

17.4 Toradex-Board-Zugang

Das VPN-verbundene Torizon-Board wird separat vom PLC-Bridge konfiguriert, damit der SSH-Zugang getestet werden kann, bevor Kamera oder LiDAR-Hardware vorhanden ist:

Das Admin-Config-Overlay zeigt diese Felder an und enthält eine Aktion Board-Zugang testen. Diese Sonde prüft zuerst die reine TCP-Erreichbarkeit des SSH-Ports und versucht dann bei konfiguriertem Benutzer einen nicht- интеракtiven SSH-Login.

18.1 Neuen Knoten hinzufügen

1. Erstellen Sie eine neue Plugin-Datei in plugins/
2. Implementieren Sie die IProdigyNode-Schnittstelle
3. Registrieren Sie das Plugin im Katalog
4. Starten Sie den Server neu (oder Hot-Reload, wenn aktiviert)

18.2 Plugin-Vorlage

class MyCustomNode:
    id = "my_custom_node"
    nodeType = "MY_CUSTOM"
    title = "My Custom Node"
    description = "Does something awesome"

    def Initialize(self, config):
        self.config = config

    def Execute(self, input_data, ctx):
        # Process input
        result = "Output based on: " + input_data
        return result

    def Report(self):
        return {"status": "ok"}

    def Hibernate(self):
        pass

    def UpdateConfig(self, new_config):
        self.config = new_config

18.3 Frontend-Erweiterungen

Das Frontend ist modular. Wichtige Erweiterungspunkte:

• js/constants.js: Neue Knotentypen zum Enum hinzufügen
• js/ui/node_manager.js: Einstellungspanels für neue Knoten hinzufügen
• js/logic/execution.js: Ausführungslogik für neue Knotentypen hinzufügen
• js/ui/playground.js: Benutzerdefiniertes Rendering für neue Knoten-Visuellen

18.4 Tastenkürzel

19.1 Server startet nicht

• Port-Konflikt: Bearbeiten Sie PORT = 9999 in proxy_server.py
• Fehlende Pakete: Führen Sie den pip-Install-Befehl aus dem Voraussetzungs-Abschnitt aus

19.2 Login / Auth-Fehler

• Stellen Sie sicher, dass postgres.sql und sql_auth_setup.sql auf der prodigy-Datenbank angewendet wurden
• Verifizieren Sie, dass PostgreSQL auf 192.168.1.4:5432 läuft und die prodigy-DB existiert

19.3 AI-Knoten nicht ansprechend

• Prüfen Sie, ob das Backend erreichbar ist: curl http://192.168.10.3:5010/v1/models
• Verifizieren Sie, dass der Modellname zu dem passt, was das Backend meldet
• Prüfen Sie die HUD-Konsole (unten am Bildschirm) auf Fehlermeldungen

19.4 Copilot-Bridge verbindet sich nicht

• Stellen Sie sicher, dass Sie auf dem Mac im copilot-CLI eingeloggt sind: copilot auth login
• Starten Sie die Bridge neu: node copilot_bridge.mjs
• Bridge-Gesundheitsprüfung: curl http://192.168.10.3:5015/health
• Verifizieren Sie, dass Browser-Automatisierung auf dem Mac installiert ist, wenn Sie Copilot-Browser-Werkzeuge nutzen: agent-browser --help
• Falls nötig, weisen Sie die Bridge mit PLAYWRIGHT_CDP_TARGET auf einen anderen Browser-Endpunkt oder mit AGENT_BROWSER_BIN einen anderen CLI-Pfad

19.5 Dokumenten-Lade-Fehler

• Installieren Sie PDF-Unterstützung: pip install pypdf
• Legacy-Formate (.doc, .xls, .ppt) werden nicht unterstützt — konvertieren Sie zu .docx/.xlsx/.pptx
• Scannede PDFs benötigen OCR: sudo apt install tesseract-ocr poppler-utils
• Setzen Sie die OCR-Sprache: export TESSERACT_LANG=eng (oder eng+chi_sim) bevor Sie den Server starten

19.6 Wisdom-Recall liefert nichts

• Prüfen Sie, ob die knowledge_base-Tabelle in der prodigy-PostgreSQL-Datenbank existiert
• Verifizieren Sie die Wisdom-Konfiguration (Host/Port/DB/Benutzer) in config.json

19.7 SearXNG liefert keine Ergebnisse

• Bestätigen Sie, dass SearXNG läuft: curl http://192.168.1.4:8888/search?q=test&format=json
• Passen Sie Motoren/Sprache im SearXNG-Knoten-Einstellungspanel an

19.8 Verdrechter Text (Chinesisch / Russisch / etc.)

Das Proxy-Server autodetectiert Kodierungen über chardet. Falls die Probleme bestehen, prüfen Sie das deklarierte Charset der Quell-Website.