RichardandClaude Opus 5
23794304e6
#155: Die 15 Build-Warnungen sind beseitigt, keine davon war ein echter Fehler. - CS8848 (DashboardWindow): Klammern um "as string" vor dem switch; die Auswertung war schon richtig, jetzt ist sie auch eindeutig lesbar - CS8602 (PdfExporter): Style "Normal" legt MigraDoc immer an - 13x CS8618: Felder, die nur der parameterlose XAML-Konstruktor offen laesst #50: Fluent zeichnet das Kalenderblatt im CalendarDatePicker als 0,5-px-Rahmen. Unter Linux (Skalierung 1,0) fiel er weg, uebrig blieben Tageszahl und Punkt. Eigener Style mit Kalenderblatt aus ganzen Pixeln. Auf der VM in beiden Farbschemata geprueft; der Kalender klappt weiterhin auf. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.