Ai/trade_web/docs/TRADING_COCKPIT_DOKUMENTATION.md

Trading Cockpit Dokumentation

Stand: 2026-05-24

Diese Dokumentation beschreibt den aktuellen technischen Stand der Trading-Cockpit-Web-App, die aus dem alten trade.txt/Tkinter-Programm in eine Python/Flask-Webanwendung umgebaut wurde.

Kurzstatus

Die App ist als Web-Cockpit lauffähig und auf pDocker deployed:

http://192.168.178.113:5050

Aktuelle Kernfunktionen:

• Live-Analyse über Binance-Spot-Kerzen
• Demo-Fallback, wenn Datenquellen nicht erreichbar sind
• Long- und Short-Signale
• Entscheidungsampel mit Entry, Stop, Ziel, R/R, Score und Confidence
• technische Indikatoren
• Makro- und Marktstrukturfilter
• Forecast-Ansicht mit Lernkurve
• Backtesting mit Gebühren, Spread und Slippage
• Optimizer mit Fortschritt, Quality-Gate, Out-of-sample und Walk-forward
• Paper-Orders
• Exchange-Guard, der echte Orders standardmäßig blockiert
• Docker/pDocker Betrieb

Start

Lokal:

cd /Users/metacube/Projects/Git/trade_web
python3 -m pip install -r requirements.txt
python3 app.py

Dann öffnen:

http://127.0.0.1:5050

Docker lokal:

docker compose build
docker compose up -d
docker compose ps
docker compose logs -f trading-web

Deployment

Zielsystem:

pDocker: 192.168.178.113
App-Pfad: /data/compose/trade_web
URL: http://192.168.178.113:5050
Container: trading-web

Deployment-Script:

./deploy_pdocker.sh

Beim manuellen Deployment wird config.json nicht überschrieben, wenn nur Codeänderungen ausgeliefert werden sollen. Die laufende Server-Konfiguration bleibt dadurch erhalten.

Git Ablage

Lokales Entwicklungsrepo:

/Users/metacube/Projects/Git/trade_web

GitHub-Ziel:

Repository: metacube2/Ai
Pfad: trade_web/
URL: https://github.com/metacube2/Ai/tree/main/trade_web

Hinweis:

• Das lokale trade_web-Repo bleibt als eigenständiges Arbeitsrepo bestehen.
• Auf GitHub wird der Projektstand im bestehenden Repository metacube2/Ai unter dem Unterordner trade_web/ abgelegt.
• Das lokale Ai-Repo unter /Users/metacube/Projects/Git/Ai kann unabhängig davon eigene offene Änderungen enthalten und wird für trade_web nicht automatisch verändert.

Architektur

Wichtige Dateien:

app.py                    Flask API und Routen
trading_engine.py         Indikatoren, Signalmodell, Forecast, Backtest, Optimizer
exchange.py               Exchange Safety Guard
storage.py                SQLite Persistenz
templates/index.html      HTML Layout
static/app.js             Frontend-Logik und SVG Charts
static/styles.css         UI Design
config.json               Symbol, Signalmodus, Risiko, Execution Safety
test_trading_engine.py    Regressionstests fuer Kernlogik
docker-compose.yml        Containerbetrieb
Dockerfile                Image Build

Persistenz:

/app/data/trade_web.sqlite3

Gespeichert werden:

• Backtest-Runs
• Optimizer-Runs
• Paper-Orders

UI Workflow

Tabs:

• Analyse: Ampel, Signal, Timeframes, Makro, Korrelationen
• Forecast: Forecast-Pfad, Unsicherheitsband, Lernkurve
• Optimieren: Backtest, Optimizer, Konvergenz, Historie
• Risiko: Risk-Plan, Health, Paper-Orders
• Methodik: Signalformel und TradingView-Formelcheck

Die Hauptampel zeigt:

• Entscheidung: Kaufen, Short, Beobachten, Short beobachten oder Warten
• Entry
• Stop
• Ziel
• Risk/Reward
• Score
• Confidence
• Signalblocker

Datenquellen

Technische Analyse:

• Binance Spot Klines
• Timeframes: 15m, 30m, 4h, 1d

Makro/Marktstruktur:

• DXY/UUP Proxy
• SPY/QQQ Risk-on/Risk-off
• TLT als Zinsdruck-/Realzins-Proxy
• BTC-Dominanz und Stablecoin-Liquiditaet ueber CoinGecko
• Funding Rate und Open Interest ueber Binance Futures
• News/Event-Risiko ueber RSS-Keyword-Scan

Wenn externe Daten nicht erreichbar sind, wird neutral oder mit Demo-Fallback weitergerechnet. Die App soll nicht blockieren, nur weil eine externe Quelle langsam ist.

Indikatoren

Berechnet werden:

• RSI 14
• MACD 12/26/9
• EMA20
• EMA50
• SMA200
• Volumen gegen SMA20
• Support/Resistance aus den letzten 30 Kerzen
• Fibonacci-Level
• W-Pattern
• Trendstatus
• Korrelationen gegen Benchmark-Assets

TradingView/Pine-Abgleich:

• RSI entspricht ta.rsi(close, 14) mit Wilder-RMA
• MACD entspricht ta.macd(close, 12, 26, 9)
• EMA entspricht ta.ema(close, length)
• SMA entspricht ta.sma(close, length)

Ein echter 1:1-Vergleich mit TradingView ist nur moeglich, wenn Symbol, Boerse, Timeframe und Kerzenschlusszeit identisch sind.

Signalmodell

Das Signalmodell ist bidirektional:

• bullish Setup -> Long/BUY-Kandidat
• bearish Setup -> Short/SELL-Kandidat

Moegliche Signaltypen:

STRONG_BUY
BUY
WEAK_BUY
NONE
WEAK_SELL
SELL
STRONG_SELL

Long-Geometrie:

Entry = aktueller Preis
Stop  = Support
Ziel  = Resistance
R/R   = (Ziel - Entry) / (Entry - Stop)

Short-Geometrie:

Entry = aktueller Preis
Stop  = Resistance
Ziel  = Support
R/R   = (Entry - Ziel) / (Stop - Entry)

Ein Signal wird nur aktiv, wenn:

• Score die Schwelle erreicht
• Risk/Reward positiv und ausreichend ist
• Modusfilter erlaubt
• Makrofilter nicht blockiert
• Entry/Stop/Ziel geometrisch korrekt sind

Signalmodi

balanced:

• weniger streng
• mehr Signale
• gut fuer Exploration und Backtestvergleich

high_precision:

• verlangt Multi-Timeframe-Bestaetigung
• verlangt hoeheres R/R
• blockiert ueberkaufte Longs bzw. ueberverkaufte Shorts

lux_style:

• trend-, momentum-, volumen- und breakout-orientiert
• long und short getrennt geprueft
• keine LuxAlgo-Kopie und keine proprietaere LuxAlgo-Logik

Aktuelle Logikfixes

Gefundene und behobene Fehler:

• Das System konnte zuerst nur Long-Signale ausgeben. Bearishe Setups wurden dadurch faelschlich NONE/Warten.
• Short-Signale wurden ergaenzt: WEAK_SELL, SELL, STRONG_SELL.
• Short-R/R wird jetzt korrekt mit Stop oberhalb und Ziel unterhalb berechnet.
• Paper-Orders und Risk-Plan kennen jetzt BUY und SELL.
• RSI unter 50 wurde vorher teilweise long-gruen bewertet. Jetzt ist RSI < 50 bearish, RSI > 50 bullish.
• RSI bei konstantem Markt war falsch moeglich als 100. Jetzt ist flacher RSI korrekt 50.
• Backtest konnte 1d-Daten mit Zukunftsblick verwenden. Jetzt werden Tageskerzen nur bis zur aktuellen Backtest-Kerze verwendet.
• Lux/Precision Backtest wurde durch fehlende 15m/30m-Historie zu hart blockiert. Im historischen 4h-Backtest wird dafuer ein 4h-Proxy verwendet.

Backtesting

API:

/api/backtest
/api/backtest?symbols=BTCUSDT,ETHUSDT&candles=360&horizon=12

Der Backtest simuliert:

• Long- und Short-Trades
• Entry
• Stop
• Target
• Timeout-Exit
• Gebuehren
• Slippage
• Spread

Metriken:

• Trades
• Wins/Losses
• Winrate
• Total Return
• Average Trade
• Profit Factor
• Max Drawdown
• Equity Curve
• Drawdown Curve
• Sample Trades

Chart:

• Candlestick-Daten
• Entry-Linien
• Stop-Linien
• Target-Linien
• Trade-Marker

Wichtig: Historische Makrodaten sind nur als Proxy-Schicht vorhanden. Technischer Backtest ist nutzbar, Makro-Historie ist keine vollstaendige institutionelle Makro-Rekonstruktion.

Optimizer

Der Optimizer testet Parameterkombinationen:

• Signal-Schwellen
• R/R-Schwellen
• RSI-Schwellen
• Indikatorgewichte
• Symbolparameter

Bewertet wird mit:

• Training Score
• Out-of-sample Score
• Walk-forward Score
• Quality-Gate
• Robustheitsreport
• Monte-Carlo-Unterseite
• Verlustserien
• Konvergenzverlauf

Ein Vorschlag wird nur uebernehmbar, wenn das Quality-Gate bestanden ist.

Forecast

Forecast-Ansicht:

• historische 4h-Kerzen
• Forecast-Pfad
• Unsicherheitsband
• Lernkurve
• Forecast-Fehler je Lernfenster

Der Forecast ist statistisch:

• Drift aus den letzten Returns
• Volatilitaet aus den letzten Returns
• Unsicherheitsband ueber Volatilitaet und Horizont

Das ist keine Garantie und kein Deep-Learning-Modell. Die Lernkurve zeigt, ob das gewaehlte Fenster historisch weniger Fehler erzeugt.

Risk-Plan

Berechnet wird:

• Entry
• Stop
• Target
• Richtung
• Risiko pro Trade
• Positionsgroesse
• Notional
• Blocker

Risk-Konfiguration in config.json:

{
  "risk_per_trade_pct": 0.5,
  "max_position_pct": 25,
  "max_daily_loss_pct": 2,
  "max_drawdown_pct": 12,
  "max_open_positions": 3,
  "cooldown_after_losses": 3,
  "slippage_bps": 5,
  "spread_bps": 4,
  "taker_fee_bps": 10,
  "maker_fee_bps": 6
}

Paper-Trading

Paper-Order Endpunkte:

GET  /api/paper/orders
POST /api/paper/order

Paper-Orders speichern:

• Symbol
• Side: BUY oder SELL
• Quantity
• Entry
• Stop
• Target
• Risk Amount
• Signal
• Risk Plan

Live-Exchange-Sicherheit

Echte Orders sind bewusst blockiert.

Default:

{
  "mode": "paper",
  "kill_switch": true,
  "allow_live_orders": false,
  "require_manual_confirm": true,
  "api_key_env": "",
  "api_secret_env": ""
}

Exchange-Guard:

GET  /api/exchange/status
POST /api/exchange/order

Vor echtem Live-Trading waeren noetig:

• Testnet zuerst
• API-Key ohne Withdrawal-Rechte
• Secret-Verwaltung ueber ENV/Secret Store
• Tick-Size/Step-Size/Min-Notional Regeln
• Order-Limits
• Positionslimits
• Reconnect- und Retry-Handling
• Rate-Limit-Handling
• Audit-Log
• manuelle Freigabe oder klarer Autotrade-Modus

Aktuell ist der Live-Connector vorbereitet, sendet aber keine echten Exchange-Orders.

API Uebersicht

GET  /
GET  /api/config
POST /api/config
GET  /api/analyze
GET  /api/backtest
GET  /api/forecast
GET  /api/optimize
POST /api/optimize/start
GET  /api/optimize/status/<job_id>
POST /api/optimize/cancel/<job_id>
POST /api/optimize/apply
GET  /api/history
GET  /api/health
GET  /api/paper/orders
POST /api/paper/order
GET  /api/exchange/status
POST /api/exchange/order

Tests

Vorhandene Tests:

test_trading_engine.py

Aktuell abgedeckt:

• SMA/EMA/RSI/MACD Basics
• RSI bei flachem Markt
• Returns, Performance, Korrelation
• Long/Short-R/R gegen Signaloutput
• bearish Setup wird STRONG_SELL

Ausfuehrung, wenn pytest installiert ist:

python3 -m pytest test_trading_engine.py

Fallback ohne pytest:

python3 - <<'PY'
import test_trading_engine as tests
for name in sorted(dir(tests)):
    if name.startswith("test_"):
        getattr(tests, name)()
        print(name, "ok")
PY

Syntaxchecks:

python3 -m py_compile app.py trading_engine.py storage.py exchange.py test_trading_engine.py
node --check static/app.js

Bekannte Grenzen

Die App ist ein Analyse- und Paper-Trading-System, kein garantierter Profit-Bot.

Bekannte Grenzen:

• kein vollstaendiger historischer News-/Funding-/Dominanz-Datensatz im Backtest
• Forecast ist einfach-statistisch
• kein produktiver WSGI-Server, aktuell Flask/Werkzeug im Container
• keine echte Binance/Bitget-Orderausfuehrung aktiv
• keine persistente Candle-Cache-Schicht
• Optimizer kann bei vielen Symbolen langsam werden
• keine Purged/Embargoed Cross-Validation
• keine Liquidation-Heatmap
• kein professioneller Wirtschaftskalender

Empfohlene naechste Schritte

Prioritaet hoch:

• Gunicorn/Waitress statt Flask Dev Server
• Candle-Cache in SQLite
• mehr Regressionstests fuer Long/Short/Backtest
• UI-Anzeige fuer Long- und Short-Kandidat nebeneinander

Prioritaet mittel:

• historische Funding/OI-Daten
• historische BTC-Dominanz und Stablecoin-Liquiditaet
• Export von Backtests als CSV/JSON
• gespeicherte Optimizer-Jobs mit Resume

Prioritaet niedrig:

• Bitget-Connector
• echte Exchange-Ausfuehrung mit Testnet
• fortgeschrittene Forecast-Modelle

Wichtige Sicherheitsregel

Live-Trading darf erst aktiviert werden, wenn Testnet, Key-Scope, Order-Limits, Fehlerhandling und manuelle Freigabe sauber umgesetzt und getestet sind.

Bis dahin bleibt das System bewusst bei Analyse, Backtest, Optimierung und Paper-Trading.