Der PropertyGrid-Ersatz ist EIN wiederverwendbares Steuerelement statt Handarbeit je Feld:
Controls/SettingsEditor zeigt ein beliebiges Einstellungsobjekt nach Richards Vorlage -
Kategorie-Ueberschrift, Beschriftung links, Feld rechts, Erklaerung klein darunter.
- SettingsModelBuilder liest die Attribute, die fuers PropertyGrid ohnehin gepflegt waren:
[Category] gruppiert, [DisplayName] beschriftet, [Description] wird zum Hinweistext,
[Browsable(false)] blendet aus (Watchdog-Token, Lizenzschluessel bleiben unsichtbar).
Ergebnis fuer ServerSettings: 6 Abschnitte, 15 Felder - ohne eine Zeile Feld-Code.
- Layout-Regel gewahrt: WELCHE Felder es gibt, kommt als Daten; WIE ein Feld aussieht,
steht deklarativ als DataTemplate je Feldtyp (Text/Zahl/Ja-Nein/Auswahl/Nur-Lese).
- Damit sind auch die drei restlichen PropertyGrid-Stellen (Account-Einstellungen,
Master-Trader, ResolutionFarming) mit je einem Aufruf erledigt.
SettingsWindow: Server-Settings + Polymarket-Accounts, Master-Key erzeugen,
OpenRouter-Key/Watchdog-Token setzen, Test-Heartbeat. Rueckmeldungen laufen ueber die
Statuszeile statt ueber Dialoge - nur echte Entscheidungen bekommen einen Dialog
(neu: Views/DialogWindow fuer Hinweis/Rueckfrage/maskierte Eingabe, Avalonia hat keine MessageBox).
Nebenbei einen offenen Punkt der Linux-Analyse erledigt: Schluesseldateien (master.key,
openrouter.key) werden jetzt per File.SetUnixFileMode auf 600 gesetzt. Auf Linux legt
File.WriteAllText sonst mit ueblicher umask 644 an - weltweit lesbar.
Lizenzdialog bewusst NICHT portiert: haengt am alten LicenseLabrador-SDK, das mit der
Deploymentcenter-Anbindung (P3c) ohnehin ersetzt wird - waere Wegwerfarbeit.
Smoke-UI prueft jetzt zusaetzlich die Feldzahl des Editors: ein Fenster kann fehlerfrei
konstruieren und trotzdem leer sein, wenn die Attribute verlorengehen.
Verifiziert: Solution baut, 442 Tests gruen, --smoke-ui gruen (5 Fenster + Editor-Pruefung),
Linux-Publish laeuft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drittes Fenster: KPI-Kacheln, drei Diagramme, Tradehistorie mit Suche/Filter und
Modul-Aktivierung. Aufbau nach docs/UI-SPEZIFIKATION-WinForms.md.
- Diagramme sind jetzt echte Steuerelemente (LiveCharts2) statt nach Bitmap gerenderter
ScottPlot-Bilder: interaktiv (Tooltips/Zoom) und ohne System.Drawing. Die Auswertung
kommt unveraendert aus TradeAnalytics - der Chart-Wechsel beruehrte keine Fachlogik.
Das war der Zweck der bestehenden Trennung und hat sich hier ausgezahlt.
- ModuleActivationInfo vom UI-Typ in den Core verschoben (PolyTrader.Core.Modularity):
Aussage ueber die Modularitaet, keine Darstellungsfrage - beide Shells brauchen sie.
- Modul-Tab listet auch NICHT geladene Module, sonst liessen sie sich nie reaktivieren.
Blockierte Module haben eine deaktivierte Schaltflaeche statt eines Hinweisdialogs;
der Grund steht ohnehin in der Spalte 'Hinweis'.
WICHTIG - Avalonia 12 -> 11.3.19 zurueckgenommen:
Der erste Wurf zog per Version='*' Avalonia 12.1.1. LiveCharts2 2.0.5 (die aktuellste
Version) ist gegen Avalonia 11 gebaut und bricht dort zur Laufzeit:
MissingFieldException 'Avalonia.Input.Gestures.PinchEvent'. Avalonia 12 ist dem
Chart-Oekosystem voraus. Jetzt 11.3.19 (DataGrid folgt eigener Reihe: 11.3.13).
Erst wieder anheben, wenn LiveCharts2 Avalonia 12 unterstuetzt.
Verifiziert: Solution baut, 442 Tests gruen, --smoke-ui gruen (alle 4 Fenster),
App laeuft real mit allen Trading-Diensten, publisht fuer linux-x64.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neues Projekt src/PolyTrader.App.Avalonia (net10.0, Avalonia 12.1.1, LiveCharts2 2.0.5)
- laeuft unter Windows und Linux aus derselben Quelle.
Enthalten:
- Program.cs mit bewusst getrenntem Aufbau: BuildHost() stellt Persistenz, Dienste und
Module ohne jeden UI-Bezug zusammen, erst Main haengt Avalonia daran. Damit ist der
kopflose Linux-Betrieb (--headless, Stufe L2) ohne Umbau erreichbar - der Schalter ist
bereits drin.
- AvaloniaUiHost als IModuleUiHost: gleiche Semantik wie die WinForms-Shell (ein Fenster
je View, offene nach vorn holen, alles maximiert).
- Fenster-Menueleiste vollstaendig DEKLARATIV (Controls/WindowMenuBar.axaml + ItemsSource
auf WindowMenuModel.Entries). Loest die alte Fassung ab, die menu.Items zur Laufzeit
leerte und neu befuellte - genau der Punkt, den die neue Layout-Regel verbietet.
- ViewIcons fuer Avalonia: dieselben Schluessel und dieselben PNGs wie zuvor, Core und
Module bleiben unveraendert.
- LauncherWindow, JobsWindow, ShutdownConfirmWindow (inkl. der 10-Sekunden-Sperre).
- --smoke-ui als Nachfolger der WinForms-Konstruktionspruefung; startet den Host bewusst
NICHT, damit ein reiner UI-Test nicht die Trading-Engine gegen echte Endpunkte anwirft.
Dabei aufgeraeumt:
- JobManager.Jobs: BindingList -> ObservableCollection. BindingList implementiert kein
INotifyCollectionChanged; neu registrierte Jobs waeren in Avalonia unsichtbar geblieben.
- StartupHydrationService aufgeteilt in CoreStateHydrationService (Core: Accounts +
Demo-Positionen) und CopyTradingHydrationService (Modul: Settings + Trader). Behebt einen
latenten Fehler: bei deaktiviertem Copytrading-Modul waeren die Accounts gar nicht mehr
hydriert worden, obwohl sie zum Core gehoeren.
Verifiziert: Solution baut, 442 Tests gruen, --smoke-ui gruen, die App laeuft real mit
Fenster und allen Trading-Diensten (Market-Sync, Master-Trader-Analyse, RF-Scanner),
und publisht fuer linux-x64.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Alle sieben Projekte auf net10.0 (App: net10.0-windows). Runtime 10.0.10 ist
installiert, 442 Tests gruen, Linux-Publish aller Nicht-App-Projekte laeuft.
EF Core 8 / Pomelo 8 bleiben bewusst stehen: net10.0 konsumiert net8.0-Bibliotheken
problemlos, und ein Provider-Wechsel hat wegen der Migrations-Implikationen eine
eigene Risikoflaeche - das gehoert in einen separaten, verifizierten Durchgang.
Sicherheitsfund nebenbei: Ab .NET 9 prueft NuGet standardmaessig auch transitive
Pakete. Damit wurde sichtbar, dass Nethereum 6.1.0 Newtonsoft.Json [11.0.2, 14.0.0)
zulaesst und ohne Pinnung auf 11.0.2 aufloest - bekannte Luecke hoher Schwere
(GHSA-5crp-9r3c-p9vr). Die App pinnte laengst 13.0.4, Core und Module nicht.
Jetzt im Core gepinnt, damit jeder Consumer sie bekommt (auch der kuenftige
Linux-Daemon). Danach 0 NU1903-Warnungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Variante B (Entscheidung Richard): Modul-UI entfernt statt in Zwischenprojekte
ausgelagert. Avalonia ist plattformuebergreifend, die neuen Ansichten kommen spaeter
direkt in die Modul-Projekte zurueck - kein Zwischenschritt, keine Wegwerfarbeit.
- 23 WinForms-Dateien aus den 4 Modulen entfernt (Spezifikation steht in
docs/UI-SPEZIFIKATION-WinForms.md, Originalcode im Tag winforms-final).
- RegisterUi ist jetzt je Modul ein dokumentierter No-Op: View-ID, Titel, Gruppe,
Order und der Tab-Aufbau stehen als XML-Doku drin, damit der Avalonia-Nachbau
die stabilen IDs und die Struktur uebernimmt.
- Alle 4 Modulprojekte + Testprojekt: net8.0 statt net8.0-windows, UseWindowsForms raus.
- P4 vorgezogen (war durch den Testprojekt-Wechsel faellig): PDFsharp-MigraDoc-GDI
-> PDFsharp-MigraDoc (Core-Build). Der Core-Build findet keine Systemschriften,
daher neu Logic/PdfFontResolver.cs: durchsucht die Schriftverzeichnisse des OS nach
Segoe UI/DejaVu/Liberation/Noto/Arial/FreeSans. Keine Schriftdateien im Repo noetig;
fehlt auf Linux alles, kommt eine klare Meldung mit apt-Hinweis statt eines
kryptischen Renderer-Fehlers.
Verifiziert: Core, alle 4 Module und das Testprojekt publishen fuer linux-x64, und
zwar ohne ein einziges Windows-spezifisches Paket in den deps.json. 442 Tests gruen
(inkl. PDF-Rendering) auf net8.0. Windows-App laeuft weiter mit den Core-Fenstern.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vor dem Entfernen der WinForms-UI: maschinell aus allen .Designer.cs extrahierte
Spezifikation aller 16 Fenster - Groessen, Tabs, Beschriftungen, Schaltflaechen und
saemtliche Grid-Spalten mit Reihenfolge, Format und Breite. Dazu uebergreifende
Gestaltungsregeln, Farbwerte der PnL-Zeilenfaerbung, Symbol-Schluessel je Fenster
und Verhaltensnotizen aus dem Code-Behind.
Damit laesst sich die Avalonia-UI moeglichst 1:1 nachbauen. Der Originalcode bleibt
zusaetzlich im Tag winforms-final; das Dokument empfiehlt, dort einmalig Screenshots
mit echten Daten zu ziehen (optischer Gesamteindruck, den kein Text ersetzt).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- TradeRowColoring liefert jetzt eine TradeRowTint-Kategorie (Loss/SmallWin/BigWin)
statt einer System.Drawing.Color. Die Schwellenlogik bleibt getestet, die konkrete
Farbe legt die UI fest (neu: Ui/TradeRowPalette.cs im CopyTrading-Modul).
Bessere Schichtung und Voraussetzung dafuer, dass das Modul spaeter net8.0 wird.
- TradeRowColoringTests prueft die Kategorie statt der Farbe (gleiche Abdeckung).
- Models/DashboardRow.cs: verwaistes using System.Drawing entfernt.
System.Drawing liegt damit ausschliesslich noch in UI-Ordnern - die Fachlogik in
Core und Modulen ist frei davon.
442 Tests gruen, --smoke-ui gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Core traegt keine WinForms-/System.Drawing-Abhaengigkeit mehr und baut als
plattformneutrales net8.0 (verifiziert: publish -r linux-x64 erfolgreich).
- ModuleView.CreateForm (Func<Form>) -> CreateView (Func<object>): die Shell kennt
ihr Toolkit und castet, der Core nicht. Avalonia kann denselben Contract nutzen.
- ModuleView.Icon (System.Drawing.Image, seit .NET 7 Windows-only) -> IconKey (string).
Aufloesung Schluessel->Bildressource neu in Ui/ViewIcons.cs, ersetzt Program.AssignMenuIcons.
- WindowMenu.cs (reine WinForms-Logik) aus dem Core nach Ui/ verschoben.
- WindowMenuTests entfernt: testet die eingefrorene WinForms-Menuelogik, die das
Testprojekt nach dem Core-Schnitt nicht mehr erreicht. Im Tag winforms-final erhalten;
das Avalonia-Gegenstueck bekommt eigene Tests (P6/P9).
Module und App bleiben vorerst net8.0-windows - ihre UI zieht erst mit der
Avalonia-Portierung um. Windows-App unveraendert lauffaehig (--smoke-ui gruen).
442 Tests gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- TraderMonitorService las API-Preise kulturabhaengig: unter de-DE wurde aus
"0.53" der Wert 53 (Faktor-100-Fehler im Einstandspreis). Nutzt jetzt den
bereits vorhandenen invarianten Helper ParseDecimal.
- Gleiche Fehlerklasse in PolymarketClobClient (6x) und MasterTraderAnalyticsJob
vorsorglich auf InvariantCulture gestellt.
- Neuer Regressionstest ApiNumberParsingTests (10 Faelle unter erzwungener de-DE-Kultur).
- Threema komplett entfernt (Entscheidung Richard): ThreemaService, vendorte
Bibliothek libs/Threema-MsgApi-Net-Core, ServerSettings-Block, DI-Verdrahtung.
- Ersetzt durch neutrale INotificationSink (No-Throw-Vertrag) + LogNotificationSink
als Uebergang; RocketChat/Telegram folgen spaeter.
- Entfernt nebenbei libsodium 1.0.16, die einzige Registry-Nutzung im Build,
den HttpListener-Webhook und System.Web.HttpUtility (alles Linux-Hindernisse).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PolyTrader.App.csproj verwies per ProjectReference nach
..\..\LicenseLabrador\client-dotnet\... und baute damit nur auf einer
Maschine, auf der das Schwester-Repo danebenliegt. Auf dem Zielland-System
waere der Build fehlgeschlagen.
Stattdessen liegt das SDK als versioniertes Paket in lib/nuget und wird
ueber die NuGet.Config-Quelle "local" aufgeloest. Ein DLL-Verweis haette
nicht gereicht: das Paket traegt die transitiven Abhaengigkeiten
(BouncyCastle, ProtectedData, System.Text.Json) in seinen Metadaten.
packageSourceMapping bindet LicenseLabrador.* fest an den lokalen Feed,
damit ein gleichnamiges Paket auf nuget.org unseres nicht verdraengt
(Dependency Confusion).
Enthaelt ausserdem die bereits vorgemerkte Umbenennung
LicenseDialog.Validate -> ValidateKey: der alte Name verdeckte
ContainerControl.Validate() (CS0108), ein Aufruf ueber eine Form-Referenz
haette einen Netzwerk-Call ausgeloest statt zu validieren.
Build und Tests gruen (438 Tests).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die urspruengliche Ideenliste (Menueleiste, sicheres Beenden, Modul-Aktivierung,
Watchdog, ClawdDotNet) ist vollstaendig abgearbeitet - UI-Slice 5 (039bc24),
Watchdog/Lizenz (ca750a0) und die ClawdDotNet-Uebernahme (bb103a5). Die Datei
wird als Nachweis mitgefuehrt, worauf diese Slices zurueckgehen; abgeloest wird
sie von docs/IDEENSAMMLUNG-Feldtest-2026-08.md, die auf diesen Dateinamen verweist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Laufende Sammlung von Richards Beobachtungen beim Einsatz von PolyTrader, je Punkt
Beobachtung -> Befund (im Code geprueft) -> Ansatz, mit stabilen IDs (L-1, ACC-1 ...)
als Referenz fuer spaetere Umsetzungs-Chats. Hier wird bewusst NICHT umgesetzt.
Querschnitts-Erkenntnis: ACC-1, RF-1 und teilweise CT-3 haben dieselbe Ursache -
Module wurden mit Null-Stubs statt echter Datenquellen fertiggestellt und mit
"Zielland" zurueckgestellt. Zielland-gebunden ist aber nur das Schreiben (Orders,
Signing, On-Chain-Tx); Lesen (Data-/Gamma-API, Alchemy-Logs, Balance) ist es nicht.
Loest die abgearbeitete Liste Ideen-fuer-Mittwoch.txt ab.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Slices W-A/W-B/W-C und L-A aus UMSETZUNGSPLAN-Watchdog-LicenseLabrador-Integration.
Watchdog (Dead-Man's-Switch, externer Server):
- WatchdogHeartbeatService als BackgroundService + DI-Singleton; jeder Sendeversuch
gekapselt, ein Ausfall des Watchdogs beeintraechtigt PolyTrader nie.
- Eigene Implementierung statt Test-Client des Fremdprojekts: TLS-Pruefung bleibt
aktiv, http:// nur fuer localhost (Agent-Token nicht im Klartext ins Netz).
- Status aus dem App-Log abgeleitet (Error mit 5-Minuten-Sticky-Fenster, entprellt),
Lifecycle-Events started/stopping.
- Konfiguration in ServerSettings; Agent-Token [Browsable(false)] mit maskierter
Eingabe + Statusanzeige, bei gesetztem Master-Key verschluesselt (enc:v1:).
Lizenz (LicenseLabrador, Ed25519):
- LicenseGate.RunStartupGate prueft beim Start; bei ungueltiger Lizenz wird die
Modulliste leer gebaut, sodass nur die Core-Shell (Terminal/Einstellungen)
startet. Bewusst kein Environment.Exit - ein Trading-Bot darf nicht mitten im
Lauf hart sterben. TamperSuspected gilt als nicht nutzbar.
- LicenseDialog (partial + .Designer.cs) fuer Start- und Verwalten-Modus, mit
Hardware-ID zum Kopieren; Smoke-UI konstruiert beide Modi headless.
- Master-Key wird jetzt VOR dem Host-Build geladen, da auch der Lizenzschluessel
entschluesselt werden muss; derselbe TerminalLogger wird als Singleton
weitergereicht, damit die Startmeldungen im Terminal-Fenster erscheinen.
Der Lizenz-SDK-Client wird per Cross-Repo-Projektreferenz auf
..\..\LicenseLabrador eingebunden, damit SDK-Fixes ohne Kopie einfliessen.
484 Zeilen Tests fuer den Heartbeat; Suite gruen (438 Tests).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Fenster-Menue: WindowMenu fuellt die oberste MenuStrip mit Top-Level-Eintraegen
nebeneinander (mit Icon) statt Untermenue "Fenster"; ModuleView.Icon zentral in der
App zugewiesen (AssignMenuIcons). Kein miFenster mehr im Launcher-Designer.
- Sicheres Beenden: ShutdownConfirmDialog (10s-Timer sperrt "Jetzt beenden", Abbrechen
jederzeit) via IModuleUiHost.RequestShutdown(). Nur der Launcher (Hauptprozess) bietet
"Beenden"; andere Fenster nur "Fenster schliessen" (kein App-Shutdown, Module laufen
weiter). Launcher-Schliessen-X routet ueber dieselbe Abfrage.
- Modul-Aktivierung (restart-basiert): ServerSettings.DisabledModules, in Program.Main
vor der DI-Registrierung gefiltert -> deaktivierte Module werden nicht geladen.
Dashboard-Tab "Module" zeigt Status + schaltet um (Hinweis: greift nach Neustart).
Optionaler IPolyTraderModule.GetActivationBlocker fuer "nicht aktivierbar"-Info.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Geschlossene Trades: Zeilenfaerbung nach PnL-% (TradeRowColoring, pur+getestet: <0 rot,
0-10% hellgruen, >10% gruen) via DataBindingComplete. Filter-Panel (Designer): Markt (Text),
Master-Trader (Combo, dynamisch), Ergebnis (Alle/Gewinner/Verlierer), Von/Bis (optionale
DateTimePicker mit Checkbox), Zuruecksetzen. Summary zeigt gefiltert/gesamt.
- Neuer Tab 'Offene Trades' (OpenTradesView, designerfaehig): alle offenen Positionen aus dem
Laufzeit-State mit Entry/Aktuell/Wert/Buchgewinn/-% und Status (offen/Exit laeuft), Zeilenfaerbung
nach Buchgewinn-%, Summenzeile. In CopyTradingMainForm zwischen Master-Trader und Geschlossene eingehaengt.
- Master-Trader-Grid: AutoSizeColumnsMode=Fill + FillWeights -> Spaltenbreiten teilen sich immer die
Breite (Fix der 'verbuggten' Breiten); RowHeader war bereits aus.
Tests: +8 (TradeRowColoring-Schwellen). Build 0 Fehler, 396 Tests gruen, --smoke-ui gruen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ShellUiHost injiziert das gemeinsame 'Fenster'-Menue beim Oeffnen zentral in jedes Fenster
(nur wenn keins eigenes vorhanden ist, z.B. Launcher). Damit erscheint das Menue auf allen
Core- und Modul-Fenstern ohne Achtfach-Designer-Duplikat, und jedes kuenftige Fenster bekommt
es automatisch. Inhaltliche Controls bleiben designerbasiert; das Nav-Menue ist Shell-Chrome.
Tests: +3 (WindowMenu.Populate: Inhalt Launcher/Views/Beenden, aktuelles Fenster fett+angehakt,
offenes angehakt, Klick navigiert). 389 Tests gruen, --smoke-ui gruen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- IModuleUiHost (Core) um Navigation erweitert: Views/IsOpen/OpenView/ActivateMain/OpenStateChanged
+ optionales Icon je ModuleView. So kann JEDES Fenster (auch Modul-Fenster, die nur Core kennen)
das gemeinsame Fenster-Menue bauen.
- WindowMenu (Core): baut das 'Fenster'-Dropdown (Launcher + alle Views + Beenden), haakt offene
Fenster an, markiert das aktuelle fett; Neuaufbau beim Aufklappen.
- ShellUiHost: SetMainWindow/ActivateMain; oeffnet ALLE Fenster jetzt MAXIMIERT (Vorgabe).
- Launcher: alle Modul-/Core-Buttons STATISCH im Designer (btn_copytrading/-resolutionfarming/
-supervisor ergaenzt), an View-IDs gebunden; fehlt eine View -> Button deaktiviert. Dynamischer
Laufzeit-Anhang ENTFERNT -> kein doppelter Accounting-Button mehr; leerer btn_accounting_Click raus.
Datei/Beenden -> Fenster-Menue (WindowMenu). Launcher startet maximiert (Sizable, MinSize 1280x720).
Build 0 Fehler, --smoke-ui alle 6 Views + Launcher gruen. Fenster-Menue auf den uebrigen Fenstern folgt (1b).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
RF-UI designerfaehig (Richards Vorgabe, letzter code-only-Altbestand):
- ResolutionFarmingMainForm auf partial + .Designer.cs umgestellt (4 Tabs Kandidaten/
Positionen/Historie/Settings, alle Controls im Designer; Verhalten unveraendert).
S-3 Counterfactual ('Was waere aus abgelehnten BUYs geworden?'):
- CounterfactualJob (alle 6h, API-gedrosselt): nimmt Rejected-BUY-Entscheidungen mit
abgelaufenem MarketEndDate aus dem Journal, prueft die Marktaufloesung
(ICounterfactualResolutionSource; live = Adapter um CheckMarketResolutionAsync) und
speichert IsWinner + hypothetischen PnL/Share (CounterfactualMath, pur) nach
sup_counterfactuals (unique je DecisionId -> idempotent). Migration generiert+angewendet.
- Agent-Tool query_counterfactuals + UI-Tab 'Counterfactual' (via Designer).
S-3 Threema-Tagesbericht:
- DailyReportService: taeglich zur konfigurierten Stunde (OPT-IN via
POLYTRADER_SUPERVISOR_DAILY=0-23) laesst der Agent einen 24h-Kurzbericht erstellen
(KPIs je Modul, Fehler, Reject-Haeufungen), sendet via Threema und legt ihn als
sup_report ab. Ohne OpenRouter-Key: stiller Skip mit Log.
Tests: +7 (CounterfactualMath, Job aufgeloest/unaufgeloest/idempotent, Tagesbericht
mit/ohne Key). Build 0 Fehler, 367 Tests gruen, --smoke-ui alle 5 Views gruen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Das Dashboard ist keine stumpfe Trade-Liste mehr, sondern ein Auswertungs-Fenster:
- ToolStrip (via Designer): Scope-Filter Konto/Modul/Live-Demo/Zeitraum + Aktualisieren.
- TabControl mit 2 Tabs:
- Dashboard: KPI-Kacheln (Netto-PnL/Winrate/Trades/O-PnL/Profit-Faktor) + 3 Charts
(Equity-Kurve, PnL je Modul, PnL je Tag) fuer den gewaehlten Scope.
- Tradehistorie: gefilterte Trade-Liste (Spalten via Designer) + Suche + Gewinner/Verlierer.
- Charts via ScottPlot CORE-Paket (nur SkiaSharp, .NET-nativ) -> als Bitmap in PictureBoxen
gerendert; KEINE OpenTK/.NET-Framework-Transitiven (bewusst nicht ScottPlot.WinForms).
- Auswertungslogik pur in TradeAnalytics (getestet). In-Memory-Filter auf gecachtem Recent-Set.
- Smoke-UI konstruiert die DashboardView jetzt direkt -> verifiziert das Chart-Rendering headless.
Build 0 Fehler, 331 Tests gruen, --smoke-ui: [OK] core.dashboard konstruiert (inkl. Charts).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- TerminalView: ContextMenuStrip (Kopieren/Alles auswaehlen/Alles kopieren/Terminal leeren)
am rtbTerminal - macht das Kopieren entdeckbar (Ctrl+C funktioniert zusaetzlich nativ).
- JobsView: ToolStrip 'toolStripJobs' (docked Top) mit Starter-Button 'Aktualisieren'
(dgvJobs.Refresh) - weitere Job-Steuerelemente folgen nach und nach.
Beide via Designer (.Designer.cs), Logik im Code-Behind. Build 0 Fehler, --smoke-ui ok.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Settings: neuer Toolbar-Button 'Master-Key erzeugen' (Tab General Settings, via Designer).
Erzeugt zufaelligen 32-Byte-AES-Key -> master.key (gitignored), nur aktiv wenn KEIN Key
existiert (Env-Var oder Datei), Lockout-Schutz + Backup-Warnung, danach deaktiviert.
- Einbezogen: laufende Designer-Umstrukturierung (SettingsView/LauncherForm: Button-Bilder
aus Properties.Resources statt eingebettet; dgv_accountlist im Launcher; DashboardView.resx).
- docs/steuer: US-CPA-Fragebogen als PDF.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- F5: Startwarnung, wenn der DB-Connection-String kein SslMode erzwingt (String selbst wird
nie geloggt). Eure Connection enthaelt bereits SslMode -> Warnung bleibt aus.
- F6: geprueft - keine Secret-Werte in Logs (nur Vorhandensein-Flags/Fehlermeldungen).
- Sicherheitskonzept: Status F1-F7 dokumentiert.
Build 0 Fehler, --smoke-ui ok.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Behebt den kritischsten Befund (Klartext-Private-Keys in remote-gehosteter MySQL):
- SecretProtection (Core/Security): AES-256-GCM, authenticated. Master-Key AUSSERHALB der DB
(env POLYTRADER_MASTER_KEY, sonst gitignorierte master.key). Format enc:v1:base64(nonce|tag|ct).
Alt-Klartext (ohne Praefix) wird gelesen und beim Speichern verschluesselt (selbstheilend).
Ohne Master-Key: Passthrough + deutliche Startwarnung (kein stiller Sicherheitsverlust).
- EncryptedStringConverter (EF ValueConverter) auf core_accounts.PrivateKey/ApiSecret/ApiPassphrase;
Spalten 256->512 verbreitert (Migration EncryptAccountSecretsWidenColumns, offline generiert).
- Program.cs: Master-Key vor der Hydration laden; nach Start einmalige/idempotente Re-Encryption
vorhandener Klartext-Credentials. Auch in --smoke-ui verdrahtet.
- CoreDbContextFactory nutzt jetzt fixe Server-Version (offline-Migrationsgenerierung, kein DB-Zugriff).
13 neue Krypto-Tests (Round-Trip, Nonce-Frische, Manipulations-/Falscher-Key-Erkennung, Passthrough,
Key-Formate). Build 0 Fehler, 324 Tests gruen, --smoke-ui ok (Warnung ohne Key wie erwartet).
AKTIVIERUNG (im Zielland): POLYTRADER_MASTER_KEY setzen (zufaelliger 32-Byte-Base64-Key, SEPARAT sichern!)
+ Migration anwenden (dotnet ef database update --context CoreDbContext). Danach Alchemy-/Mullvad-Secrets
aus F3 rotieren. WICHTIG: Master-Key-Verlust = Kein Zugriff auf die Keys mehr.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Der auskommentierte redeem_markets.py-Aufruf uebergab Private-Key + Secrets als
Prozess-Argumente (in der Prozessliste sichtbar). War deaktiviert, aber latentes Risiko
(reaktivierbar/falsches Muster) -> entfernt. Sicherheitshinweis fuer kuenftiges
Auto-Redeem hinterlegt (Secrets nie via argv; Redeem in .NET/Nethereum).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
F4: Newtonsoft.Json in der Threema-Lib von 11.0.2 (Advisory NU1903, high) auf 13.0.4
gehoben (= App-Version). Build ohne NU1903, 311 Tests gruen.
F3: hardcodierte Secrets aus ServerSettings-Defaults entfernt (Alchemy-API-Key in
PolygonRpcUrl, Mullvad-Account-ID) -> leere Defaults; echte Werte kommen aus
server_settings.xml (gitignored). WICHTIG (nicht im Code moeglich): beide Secrets
ROTIEREN, da sie in der Git-History liegen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Root aufgeraeumt: alle Konzept-/Plan-/Fach-Dokumente nach docs/ verschoben,
organisiert nach Typ (wie fuer ein separates Docs-Repo vorgeschlagen, aber bewusst
in diesem Repo, damit Plan->umsetzende-Commits nachvollziehbar bleiben):
- docs/konzepte/ (KONZEPT-*)
- docs/umsetzungsplaene/ (UMSETZUNGSPLAN-*)
- docs/ideen/ (fruehe Ideen, Platzhalter)
- docs/pruefplaene/ (PRUEFPLAN-*)
- docs/steuer/ (Steuer-/Buchhaltungs-Doks, z.B. US-CPA-Fragebogen)
- docs/README.md (Index/Konventionen)
Getrackte Plaene als Rename verschoben (History erhalten); zuvor untracked Konzept-/
Plan-Dateien jetzt versioniert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Phase RF-1 (read-only): Scanner holt bald aufloesende Favoriten von einer
IFarmingMarketSource, bewertet sie und schreibt JEDEN Kandidaten (akzeptiert wie
abgelehnt inkl. Grund) nach rf_candidates. Platziert keine Orders.
- MarketScannerService.Evaluate (pur/statisch, voll getestet): Filterkette mit
Reject-Grund = erster Fehlschlag (Preisband -> Kategorie -> Blacklist ->
Aufloesungsfenster -> Netto-Edge nach Fees). Cluster-Key + Score immer berechnet.
- ScanAccountAsync: Beschaffung -> Bewertung -> Persistenz. BackgroundService-Loop
(12min) ueber Accounts mit Settings; fehlertolerant.
- IFarmingMarketSource + ScannedMarket-DTO trennen die (live-/API-gebundene)
Beschaffung von der Bewertung -> Pipeline ohne echte Gamma/CLOB-API testbar.
- NullFarmingMarketSource als Default: Modul laeuft ohne Live-Anbindung (die im
Zielland registriert wird) und produziert dann korrekt keine Kandidaten.
Hinweis: Zur Laufzeit fragt der Scanner rf_settings ab; bis die Migration angewendet
ist, faengt der try/catch den fehlenden-Tabelle-Fehler ab (nur Log). Migration bewusst
separat anzuwenden.
7 neue Tests (Evaluate-Faelle + Orchestrierung). Build 0 Fehler, 296 Tests gruen, --smoke-ui ok.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Entities RfCandidate/RfPosition/RfClosedTrade (+ RfSettings aus Slice 1).
- ResolutionFarmingDbContext: Tabellen rf_settings/rf_candidates/rf_positions/
rf_closed_trades. Autoincrement-PKs (Identity) fuer Candidate/ClosedTrade von
Anfang an (Lehre aus dem CopyTrading-TradeId-Problem), zusammengesetzter PK
(AccountId,TokenId) fuer Positions, Indizes + Decimal-Precision.
- 4 Repos (Settings/Candidate/Position/ClosedTrade) mit serverseitigen Aggregaten
(RealizedPnlSince fuer Kill-Switch, CountOpenedSince fuer Tages-Drossel).
- Modul registriert DbContextFactory + Repos.
- Design-Time-Factory nutzt die fest gepinnte Server-Version -> Migration wurde
OHNE DB-Verbindung generiert (kein Zugriff auf die produktive DB). Anwenden per
'dotnet ef database update' bewusst im Zielland/lokal durch den Nutzer.
6 neue EF-InMemory-Repo-Tests. Build 0 Fehler, 289 Tests gruen, --smoke-ui ok.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Vorbereitung fuer das ResolutionFarming-Modul: FeeModel von
PolyTrader.Modules.CopyTrading.Logic nach PolyTrader.Core.Trading verschoben, damit
mehrere Strategiemodule dieselbe Fee-Logik nutzen koennen (Module duerfen nicht
voneinander abhaengen -> geteiltes gehoert in den Core). CopyTrading-Referenzen +
FeeModelTests auf den Core-Namespace umgestellt. Rein mechanisch, verhaltensneutral.
Build 0 Fehler, 244 Tests gruen, --smoke-ui ok.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
