TradoDesk verarbeitet sensible Finanzdaten und führt Aktionen auf Trading-Plattformen aus. Die höchste Priorität hat der Schutz vor:

1. Unbeabsichtigten Orders (Fat Finger / KI-Halluzination).
2. Abfluss von Screenshots oder Session-Cookies.
3. Injection von bösartigem Code in den Render-Prozess.

• contextIsolation: true: Render-Prozess hat keinen direkten Node.js Zugriff.
• nodeIntegration: false: Verhindert require() im UI-Code.
• sandbox: true: Standard Electron Sandbox.
• BrowserView Isolation: Der Broker-Tab läuft in einer getrennten Session-Partition (persist:broker_session), Cookies werden nicht mit dem Haupt-Agenten geteilt.

• Human-in-the-loop: Die Funktion place_order erfordert IMMER eine explizite Bestätigung im UI.
• Demo Mode: Der Betriebsmodus wird zentral in der App-Konfiguration geführt (config.demoMode) und kann zur zusätzlichen Blockierung riskanter Aktionen genutzt werden.
• Redaction: Screenshots werden nur flüchtig im Speicher gehalten (Base64) und nicht auf Disk geschrieben, es sei denn, der User exportiert sie explizit.

• API Keys liegen nicht im Klartext auf der Festplatte. Nutzung von OS Keyring oder AES-256 Encrypted File mit laufzeit-generiertem Salt.
• BrowserView-Cookies liegen isoliert in der Partition persist:broker_session und werden bei Logout gezielt entfernt.
• Layout-Persistenz ist rein lokal im Renderer (localStorage) und enthält nur UI-Zustand (keine Secrets).

Das System fängt Fehler auf globaler und Service-Ebene ab. Wiederholbare Fehler (z.B. 503 Service Unavailable, 429 Rate Limits, Netzwerk-Timeouts) werden automatisch mit exponentiellem Backoff (1s, 2s, 4s) erneut versucht. Dies stellt sicher, dass temporäre Verbindungsprobleme nicht zum Abbruch der User-Session führen.

Jede Transaktion (User-Input, API-Call, System-Fehler) wird mit einer eindeutigen UUID (correlation_id) versehen. Diese ID wird durch alle Schichten durchgereicht:

• Renderer: Erstellung der ID beim User-Event.
• Main Process: Logging mit ID.
• Automation: Zuordnung von Browser-Aktionen. Dies ermöglicht eine präzise Nachverfolgung von Fehlern über Prozessgrenzen hinweg, ohne dass personenbezogene Daten oder sensible Payload-Inhalte geloggt werden müssen.

Ein zentraler Logger sammelt Events aus allen Prozessen.

• Sanitization: Bevor ein Log geschrieben wird, werden sensible Keys (api_key, token, password) und große Payloads (Base64 Images > 200 chars) automatisch entfernt oder maskiert.
• Speicherorte:
  • console: Für Entwicklung (DevTools).
  • userData/logs/main.log: Logfile aus dem Main-Process für Post-Mortem-Analysen.
• Level:
  • FATAL: App unbenutzbar (Crash).
  • ERROR: Aktion fehlgeschlagen (z.B. API Error nach Retries).
  • WARN: Erwartete Abweichung (z.B. Retry aktiv).
  • INFO: Normaler Betrieb (Audit Trail).

• Renderer kann BrowserView-Geometrie nicht direkt manipulieren, sondern nur via validierte IPC-Aktion (BROKER_SET_BOUNDS).
• Broker-Statusänderungen aus dem UI laufen ausschließlich über validierte IPC-Aktion (BROKER_SET_STATUS).
• Session-Änderungen werden einseitig vom Main-Process als Event (BROKER_SESSION_UPDATED) in den Renderer gespiegelt.