RichardandClaude Opus 5
669676ac60
Alle acht Fenster laufen jetzt unter Avalonia: Launcher, Dashboard, Settings, Terminal, Server Jobs, Copytrading, ResolutionFarming, Supervisor, Accounting (+ Shutdown- und Allzweck-Dialog). - Copytrading: vier Tabs (Master-Trader mit Account-Zuweisung, Offene Trades, Geschlossene Trades mit Filterleiste, Account-Einstellungen). Zeilenfaerbung nach PnL laeuft ueber DataGrid.LoadingRow - greift damit auch bei virtualisierten Zeilen, anders als das fruehere Faerben in DataBindingComplete. - ResolutionFarming: Kandidaten, Positionen, Historie, Settings - je Konto. - Supervisor: Analyse-Chat gegen den Agenten (Tool-Fortschritt in der Statuszeile), Dossiers mit Markdown-Ansicht, Berichte, Counterfactuals. - Accounting: KPI-Kacheln, Monats-BWA, Ledger, Abruf/Status, PDF- und CSV-Export ueber den plattformneutralen Datei-Dialog. Der SettingsEditor traegt wie erwartet die drei restlichen PropertyGrid-Stellen (Master-Trader, Account-Einstellungen, ResolutionFarming) mit je einem Aufruf. ENTSCHEIDUNG - Modul-Fenster liegen in der App, nicht in den Modulen (begruendet in Views/Modules/README.md): Die App ist der Kompositionswurzel und referenziert ohnehin alle Module. So bleiben die Modulprojekte FREI VON AVALONIA, was fuer den kopflosen Linux-Betrieb den Ausschlag gibt - der Daemon soll keine GUI-Bibliothek mitschleppen. Verifiziert: kein Modul zieht Avalonia. Registrierung in Shell/ModuleViews.cs, und zwar nur fuer tatsaechlich geladene Module - ein per DisabledModules abgeschaltetes Modul bekommt gar kein Fenster. Nebenbei: eigene View-Model-Typen CopyOpenTradeRow/CopyClosedTradeRow statt des Modul-Modells ClosedTradeRow - sie tragen den aufgeloesten Master-Trader-Namen und die Zeilenfarbe, die es dort nicht gibt (und vermeiden die Namensmehrdeutigkeit). Verifiziert: Solution baut, 450 Tests gruen, --smoke-ui gruen (alle 8 Fenster + Launcher + Dialog + Editor-Pruefung), App laeuft real mit allen Trading-Diensten, Linux-Publish laeuft. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.2 KiB
Modul-Fenster
Die Fenster der Module liegen bewusst hier in der App und nicht in den Modulprojekten.
Warum: Die App ist der Kompositionswurzel – sie referenziert ohnehin alle vier Module. Damit
bleiben die Modulprojekte (Trading-Engine, Scanner, Supervisor, Accounting) frei von Avalonia.
Das ist für den kopflosen Linux-Betrieb (--headless) der entscheidende Punkt: der Daemon soll
keine GUI-Bibliothek mitschleppen. Zusätzlich können die Fenster so die gemeinsamen Bausteine der
Shell nutzen (WindowMenuBar, SettingsEditor, DialogWindow), ohne dass diese in eine eigene
Bibliothek ausgelagert werden müssen.
Folge: IPolyTraderModule.RegisterUi bleibt je Modul ein No-Op; registriert werden die Ansichten
in Shell/ModuleViews.cs. Die stabilen View-IDs (copytrading.main usw.) bleiben unverändert,
sodass Symbole, Reihenfolge und Launcher-Verhalten identisch sind.
Alternative, falls Module später doch ihre UI selbst mitbringen sollen: eine gemeinsame
Bibliothek PolyTrader.Ui.Shared mit den obigen Bausteinen anlegen und die Fenster in
PolyTrader.Modules.X.Ui-Projekte verschieben. Der Aufbau der Fenster bliebe dabei unverändert.