Files
IBKRTrader/src/IBKRTrader.Modules.Supervisor/Agent/ArchitectureContext.cs
T
RichardandClaude Opus 4.8 2a312ca035 R8: Accounting- + Supervisor-Modul + Core-Datenfundament (S-0)
Portierung der beiden fehlenden Grundbausteine aus PolytraderSharp (voller Ausbau).

Core S-0 (Datenfundament fuer Analyse/Forensik):
- core_decision_journal + core_order_events (+ ReasonCode/Decision/OrderEvent-Enums),
  IDecisionJournal/IOrderEventLog mit fehlertoleranten EF-Impls (Handel bricht nie).
- SignalId-Durchreichung TradeSignal -> ExecutionService -> core_trade_history;
  ExecutionService schreibt an jeder Verzweigung Journal/Order-Events.
- JSONL-Log-Sink (LogJson + Dual-Sink), pure Analytik: RealizedPnlEngine (FIFO),
  TradeAnalytics, DossierBuilder. Migration AddAnalysisFoundation.

Accounting-Modul (acc_): unabhaengiger IBKR-Kontoauszug (Activity Flex Query) hinter
Interfaces mit Offline-Null-Stubs -> append-only Ledger + Periodenabrechnung/BWA + FX
(USD/EUR) + CSV/PDF (PDFsharp/MigraDoc). Steuerschicht bewusst offen (Platzhalter-Tab).
Kein Handel. Migration InitialAccounting.

Supervisor-Modul (sup_): read-only OpenRouter-Agent (Function-Calling-Loop) + read-only
Tool-Registry (8 Tools) + Profile + Dossier-Browser + Counterfactual-Job (Stub) +
Tagesbericht/MCP-Light (opt-in). Migration InitialSupervisor.

Verdrahtung: Program.cs (beide Module + Icons), slnx/App/Tests-Referenzen,
provision-db.ps1, AppSettings-Sektionen, docs/konzepte, README.

Tests: 79 -> 117 gruen (FIFO/KPIs/Dossier/JSONL, Classifier/Engine/FX/Idempotenz,
OpenRouter/Registry/Agent/MCP, STA-Konstruktion beider neuen Fenster).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-31 09:25:18 +02:00

54 lines
2.8 KiB
C#
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
namespace IBKRTrader.Modules.Supervisor.Agent;
/// <summary>
/// Kuratiertes Architektur-/Verhaltensdokument von IBKRTrader der System-Kontext des Agenten
/// („so entscheidet und handelt die Software"). Bewusst destilliertes Verhalten statt Code-Dump; bei
/// Änderungen am Geld-Pfad mitpflegen. Inline gehalten (versioniert mit dem Code).
/// </summary>
public static class ArchitectureContext
{
public static string Load() => Text;
private const string Text =
"""
# IBKRTrader Architektur & Verhalten (Supervisor-Kontext)
## Grundaufbau
- Harter Core + unabhängige Strategie-Module + Launcher. Module referenzieren nur den Core, nie einander.
- Persistenz: EF Core / MariaDB. Core-Tabellen `core_*`, je Modul eigener Präfix (`ct_`, `acc_`, `sup_`).
- Generic Host; Worker/Services laufen als IHostedService.
## Handels-Pipeline (ExecutionService)
Module übergeben ein `TradeSignal` (Symbol, Side, SourceModule, optional LimitPrice/SuggestedNotional,
SignalId). Der Core prüft in fester Reihenfolge:
1. Globaler Hauptschalter `TradingEnabled` (Default AUS) sonst Decision=Skipped, Reason=TradingDisabled.
2. Kurs vom Broker fehlt er, Decision=Skipped, Reason=NoQuote.
3. Konto + bestehende Exposure/Position.
4. Risikoprüfung (RiskService) mit MaxTradePercent, MaxPositionPercentPerModule, MaxSlippagePercent
Ablehnung: Decision=Rejected, Reason=RiskRejected (Begründung im Message/ContextJson).
5. Order platzieren (Broker). Erfolg Decision=Executed, Reason=OrderPlaced; Fehler Decision=Failed,
Reason=OrderFailed. Order-Events (Placed/Filled/PlaceFailed) landen in core_order_events.
6. Buchung: Fill Position/Budget/Trade-Historie; die SignalId wird durchgereicht.
## Sicherer Standard
Broker ist standardmäßig `NullBrokerClient` (handelt nie), bis der echte IBKR-Adapter (TWS API / IB
Gateway) verifiziert ist. Ohne `TradingEnabled=true` wird nie gehandelt.
## Datenfundament für Analyse
- `core_decision_journal`: JEDE Entscheidung (Executed/Rejected/Skipped/Failed) mit ReasonCode, strukturiert.
- `core_order_events`: Order-Lifecycle als Daten.
- `core_trade_history`: gebuchte Fills (BUY/SELL), inkl. SignalId zur Korrelation.
- JSONL-Logs `Logs/{yyyy-MM-dd}.jsonl`: eine Zeile je Event (ts, level, source, cid=SignalId, message).
- Die SignalId verbindet Signal Entscheidung(en) Order(s) Trade Log-Zeilen (= das Dossier).
## Realisierte GuV / KPIs
Fills werden per FIFO-Lot-Matching (RealizedPnlEngine) zu realisierten Round-Trips; daraus KPIs
(NetPnl, Winrate, ProfitFactor). Long-only-Sicht.
## Module (aktuell)
- CongressTrading (`ct_`): kopiert US-Kongress-Aktien-Trades TradeSignal.
- Accounting (`acc_`): unabhängiger IBKR-Kontoauszug append-only Ledger + Abrechnung (KEIN Handel).
- Supervisor (`sup_`): DU read-only Analyse/Forensik über alle Module.
""";
}