main
195
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 RichardandClaude Opus 5
|
c863bf5fce |
Plattform-Fundament im Core: Vertraege, Registry, Global-Adapter (#623)
Neue neutrale Handelsvertraege (Maerkte, Orderbuch, Orders, Portfolio, Gebuehren) hinter IPlatformAdapter, aufgeloest ueber IPlatformRegistry je Konto. Polymarket Global ist eine duenne Huelle um die bestehenden Dienste; PolymarketClobClient bleibt unveraendert. Das Gateway lehnt ab, was die heutige Anbindung nicht sauber kann (Post-only, IOC/GTD, falsche Plattform), bevor etwas an den CLOB geht. core_accounts und core_markets bekommen die Spalte Platform (Vorgabe polymarket-global), core_markets den Schluessel (Platform, Id). core_positions bleibt: die Plattform folgt aus dem Konto. Noch nutzt kein Modul die Vertraege - das Handelsverhalten ist unveraendert. Vor dem ersten Start auf dem Server: dotnet ef database update --project src/PolyTrader.Core (Migration AddPlatformColumns). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
05979406c7 |
Konzept Mehrere Handelsplattformen: Polymarket US, spaeter Kalshi (#622-#629)
Ein Kunde mit US-Wohnsitz soll ueber Polymarket US handeln - eine eigene, CFTC-regulierte Boerse, an der die heutige CLOB-Anbindung nicht verwendbar ist. Das Konzept macht Plattform zu einem Begriff im Core, laesst Module ihre Plattformen erklaeren und haelt Strategievarianten je Plattform im Modul. Begruendungen zu #622-#629 in docs/ROADMAP.md, Bauanleitung in docs/archiv/konzepte/KONZEPT-Multi-Plattform.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
94716157cf |
Adapter-Selbsttest: 16 Werkzeuge statt 15
dc_finding_summary ist dazugekommen; die Zahl in der Anleitung war veraltet und macht beim Pruefen unnoetig stutzig. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
4142d0c1c9 |
Begruendung zu #621: Management-Center-Anbindung
Die Betriebsfreigabe wird im Projekt polytrader-managementcenter gebaut; wirken muss sie hier. #621 ist ausschliesslich der Einbau auf der Client-Seite und steht auf deferred, bis SDK (#613) und Freigabe (#614) dort stehen. Damit faellt zugleich die Entscheidung vom 31.07.2026 gegen eine Laufzeit-Revalidierung - fuer die Lizenz bleibt sie gueltig, fuer die Betriebsfreigabe nicht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
5419348a38 |
Version 0.3.0
Release vor dem naechsten Test (Richard, 15.09.2026): enthaelt #582, #583, #587, #600, #155, #50, #410 und die WebUI-Paritaet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
c343dd57f8 |
Fenstersymbol unter Linux: _NET_WM_ICON selbst setzen
#410: Avalonia 11.3.19 laedt Icon="..." korrekt, schreibt _NET_WM_ICON aber nie auf das X11-Fenster - Fensterliste und Alt-Tab zeigten kein Symbol. Richards Entscheidung vom 15.09.2026: nicht auf Avalonia 12 warten. LinuxWindowIcon haengt sich klassenweit an Window.WindowOpenedEvent und setzt die Eigenschaft ueber eine eigene libX11-Verbindung (64 und 32 px aus icon.png). Nur Linux, nur X11; scheitert es, einmal eine Warnung ins Log, nie ein Abbruch. Zu entfernen, sobald Avalonia es selbst tut. Auf der VM geprueft: Hauptfenster und Beenden-Dialog tragen _NET_WM_ICON (64 x 64), keine Warnung im Log. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
cec8b91ebd |
Desktop beendet sich auf SIGTERM, statt bis zum SIGKILL weiterzulaufen
#600: Die ConsoleLifetime des Hosts faengt SIGTERM ab und ruft StopApplication. Die Avalonia-Oberflaeche hing nicht daran - Main wartete weiter auf sie, und systemctl stop, Abmelden oder Herunterfahren endeten mit SIGKILL. App.axaml.cs haengt AvaloniaUiHost.ShutdownFromHost an ApplicationStopping: Die Oberflaeche schliesst sich ohne Sicherheitsabfrage (der Stopp von aussen ist selbst die Anweisung), danach laeuft der geordnete Dienst-Stopp aus Program.Main. Auf der Linux-VM geprueft: SIGTERM -> beendet nach 1 s, "Dienste in 0,1 s beendet"; Gegenprobe "Beenden" in der Oberflaeche ebenso. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
23794304e6 |
Build ohne Warnungen, Kalendersymbol unter Linux sichtbar
#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> |
||
|
RichardandClaude Opus 5
|
b4d8a2a647 |
Update-Pruefung regelmaessig und ab Werk an, Installation nur auf Klick
Richards Vorgabe vom 14.09.2026 (#587): Updates nie automatisch installieren, aber regelmaessig pruefen und darauf hinweisen. Bisher pruefte der Desktop genau einmal beim Start, das WebUI nur beim Seitenaufruf, und ab Werk gar nicht (UpdateCheckEnabled=false). Eine wochenlang laufende oder frisch installierte Anwendung erfuhr nie von einem neuen Release. - UpdateCheckEnabled ab Werk true, neu UpdateCheckIntervalHours (6, 1..168) - UpdateCheckBackgroundService: erste Pruefung nach 30 s, dann im Takt; laeuft auch ohne WebUI und kopflos; Hinweis im Log einmal je neuer Fassung - Registrierung ueber AddPolyTraderUpdateCheck, nicht mehr am WebUI - Desktop-Banner haengt an UpdateStatusService.Checked; "Spaeter" blendet bis zur naechsten neueren Fassung aus - WebUI-Banner holt alle 10 Minuten den vorgehaltenen Stand Auf der Linux-VM geprueft: 0.1.9 ohne Handeinstellung erkennt 0.2.0, ein Hinweis im Log, Banner erscheint, "Spaeter" blendet aus, Beenden in 0,1 s. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
14c89aea7d |
Beenden haengt nicht mehr, Update-Agent startet erst nach Bestaetigung
Beim Updatetest auf der Linux-VM (14.09.2026) zeigte sich zweierlei: 1. Nach "Beenden" blieb der Prozess unbegrenzt stehen - Fenster offen, Port zu, Main-Thread in host.StopAsync(...).GetResult(), selbst SIGTERM ohne Wirkung. Betraf jedes Beenden der Oberflaeche, nicht nur den Update-Weg. Der Main-Thread traegt nach StartWithClassicDesktopLifetime noch Avalonias SynchronizationContext, dessen Dispatcher nicht mehr pumpt. Der Stopp laeuft jetzt per Task.Run ohne diesen Kontext, mit Obergrenze 45 s und Log der Dauer. 2. Der update-agent startete schon beim Klick auf "Installieren". Seine 40 s Wartefrist verstrichen waehrend Download und 10-Sekunden-Sperre, er brach ohne Update ab. Er startet jetzt erst nach bestaetigtem Beenden, Frist 120 s. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
0f18f562c7 |
Release 0.2.0 vorbereiten: update-agent ins Paket, Release-Skripte
Das 0.1.0-Paket enthielt keinen update-agent. "Jetzt installieren" sucht ihn ueber UpdateClient.ResolveAgentPath() neben der Anwendung - ohne ihn konnte sich keine Installation selbst aktualisieren. - BundleUpdateAgent (App-csproj): legt den Agenten beim Publish fuer eine Laufzeitkennung neben die Anwendung; fuer ein Release ein Abbruch, wenn er fehlt - scripts/release.ps1: unveraenderte Vorlage des Deploymentcenters - scripts/publish-release.ps1: holt den Agenten mit Pruefsumme aus installer.json und legt die Packager-Konfiguration neben pack-and-deploy - Version 0.2.0 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
86b497bdbf |
Desktop: Passwortabfrage vor Konten, Geheimnissen und WebUI-Zugang
Umsetzung von #567. Entscheidung Richard, 13.09.2026: Geheimnisse verwalten wir ausschliesslich im Desktop, und selbst dort erst nach zusaetzlicher Passwortabfrage. Bisher sah und aenderte jeder, der die Desktop-Oberflaeche offen vor sich hatte: - Polymarket-Konten mit ApiKey, ApiSecret, ApiPassphrase und PrivateKey - Master-Key, OpenRouter-Key, Watchdog-Token und Lizenzschluessel - Mullvad-Account und Polygon-RPC-URL mit Alchemy-Key, offen im Editor - das WebUI-Token, per "Anzeigen" lesbar Jetzt gesperrt, bis entsperrt: - Tab "Polymarket Accounts": Gesperrt stehen die Konten gar nicht im visuellen Baum. Das Raster bleibt leer, der Editor mit den Private Keys ebenfalls; nichts ist nur verdeckt. - Master-Key erzeugen, OpenRouter-, Watchdog- und Lizenzschluessel setzen. - Mullvad-Account und Polygon-RPC-URL: mit [SensitiveSetting] markiert und im Editor ausgeblendet. - WebUI-Zugang: Gesperrt steht das Token nicht einmal maskiert im Feld. Speichern ist mitgesperrt, weil es den Feldinhalt als Token schreibt; gesperrt und leer haette es das Token geloescht. - Frei bleiben Lizenzpruefung und Test-Heartbeat, weil sie keinen Schluessel zeigen. Kern im Core (PolyTrader.Core.Security), weil nur dort testbar: - SettingsPasswordStore: PBKDF2-HMAC-SHA256, 600 000 Iterationen, Salt, eigene Datei settings-password.json neben master.key, atomar geschrieben und nur fuer den Besitzer lesbar. Nicht in server_settings.xml, die seit #561 das WebUI mitschreibt. Ein vorhandenes Passwort wird nie ueberschrieben. - SettingsLock: - erstes Festlegen mit Wiederholung und mindestens 10 Zeichen - zwei freie Fehlversuche, danach 5 s bis 5 min Wartezeit, in der auch das richtige Passwort nicht geprueft wird - Sperre nach 5 Minuten ohne geschuetzte Aktion und beim Verlassen der Einstellungen - eine unlesbare Passwortdatei entsperrt nie und gilt auch nicht still als "kein Passwort" - Protokoll ohne eingegebene Werte Oberflaeche: PasswordDialog deklarativ in .axaml, Sperr-Leiste ueber den Tabs. Die PBKDF2-Pruefung dauert etwa eine halbe Sekunde und laeuft nicht im UI-Thread. Grenzen: - Die Sperre schuetzt gegen jemanden an einer entsperrten Desktop-Sitzung. Wer Dateizugriff hat, liest master.key selbst. Deshalb gibt es kein "Passwort vergessen": Wer settings-password.json loeschen kann, braucht keins. - Die Wartezeit nach Fehlversuchen beginnt nach einem Neustart von vorn. - "Datenbankeinstellungen": Eine Ansicht dafuer gibt es im Desktop nicht; die Verbindungszeichenfolge steht nur in appsettings.Local.json. Entsteht eine, gehoert sie hinter dieselbe Sperre. Tests: 20 fuer Passwortdatei und Sperre (Festlegen, Fehlversuche, Wartezeit, Leerlauf, unlesbare Datei, Aendern, Iterationszahl aus der Datei, Dateirechte) und 5 fuer die Markierung der Geheimnisfelder. Die Oberflaeche selbst wird auf der VM abgenommen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
1a09d99a63 |
ServerSettingsFile: Plattformwarnung CA1416 beseitigt
Nachtrag zu #560 (
|
||
|
RichardandClaude Opus 5
|
30891c1bce |
WebUI: Hellmodus, Supervisor-Verlauf leeren, API-Status beschriftet
Umsetzung von #566. Hell-/Dunkelmodus Das WebUI hatte nur eine dunkle Palette. Jetzt gibt es "System", "Hell" und "Dunkel" als Umschalter in der Kopfleiste. Die Wahl gilt je Browser; ohne gespeicherte Wahl folgt das WebUI dem Betriebssystem. data-theme auf <html> ueberstimmt prefers-color-scheme in beide Richtungen. Ein kleines Skript im <head> setzt die Wahl vor dem ersten Zeichnen, sonst blitzte beim Laden kurz das falsche Schema auf; die Login-Seite macht es genauso. Kontrast der hellen Palette auf Weiss: - Text 8:1 - gedaempfter Text 6,3:1 - Akzent, Gewinn, Verlust und Warnung je mindestens 4,5:1 Fuenf feste Farben haetten im Hellmodus gebrochen und sind jetzt Tokens: - #11111b als Schrift auf Akzentfarbe (Primaerknopf, Profil-Hover, aktive Waehrung): im Hellmodus dunkel auf dunklem Blau. - rgba(255,255,255,0.02 bis 0.08) fuer Zeilen-Hover und Trennlinien: auf Weiss unsichtbar. Das Terminal bleibt in beiden Modi dunkel und bringt seine Palette lokal mit. Es hatte einen festen dunklen Hintergrund, erbte aber var(--text), und das waere im Hellmodus dunkle Schrift auf Schwarz geworden. Die uebrigen festen Farben sind halbtransparente Toenungen und Schatten, die auf beiden Gruenden funktionieren. Supervisor "Verlauf leeren" wie im Desktop. Geleert wird nur die Unterhaltung im Browser, die Begruessung kommt zurueck, gespeicherte Berichte bleiben erhalten. Statusanzeige Der WSS-Punkt ist jetzt beschriftet, "WSS aktiv" oder "Polling", wie "API: ..." in der Statusleiste des Desktops. Dazu kommt "Module x/y". Reine Oberflaeche, keine Aenderung am Server. Die Pruefung erfolgt im Browser auf der VM. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
bc96807d81 |
WebUI: Update-Status anzeigen, installiert wird im Desktop
Umsetzung von #565. GET /api/updates liefert die laufende Fassung (BuildInfo), die verfuegbare, den Hinweis auf ein Sicherheitsupdate und den Changelog. Geprueft wird mit demselben Aufruf wie beim Start des Desktops (UpdateClient gegen das Deploymentcenter). Den Lizenzschluessel fuer den Paketabruf liest der Server, er verlaesst ihn nicht. Zwischenspeicher: UpdateStatusService haelt das Ergebnis 30 Minuten vor. "Jetzt pruefen" umgeht das, aber fruehestens nach 60 Sekunden; bis dahin kommt der vorige Stand mit der Wartezeit zurueck. Gleichzeitige Aufrufe loesen eine einzige Pruefung aus. Ohne das fragte jeder Seitenaufruf, jedes offene Browserfenster, das Deploymentcenter. Die Pruefung liegt hinter IUpdateChecker und ist damit ohne Netz testbar. Kein Installieren ueber das WebUI, und ein Test haelt fest, dass es keine solche Route gibt: Die Installation startet den Update-Agent und beendet danach die Anwendung und mit ihr den Webserver. Richards Vorgabe beschraenkt das Beenden ueber das WebUI auf das Trading (#563). Oberflaeche: - Karte "Version & Updates" in den Einstellungen, mit "Jetzt pruefen". - Im Dashboard ein Banner wie im Desktop-Launcher, sobald ein Update vorliegt. Er verweist zur Installation auf den Desktop. Nicht durch Unit-Tests abgedeckt: DeploymentcenterUpdateChecker selbst, weil er ueber das Netz geht. Er wird auf der VM gegen das echte Deploymentcenter geprueft. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
0067e0b761 |
WebUI: Log-Viewer fuer vergangene Tage und Kopieren
Umsetzung von #564. Das WebUI zeigte bisher nur den Live-Stream seit dem Prozessstart. GET /api/logs lieferte den Verlauf im Speicher, die Oberflaeche nutzte ihn nicht. Der Desktop hat einen Log-Viewer ueber die Tagesdateien. Den gibt es jetzt auch im WebUI. - GET /api/logs/files listet die vorhandenen Tage (Logs/yyyy-MM-dd.jsonl), neueste zuerst. Die .log-Textdateien und fremde Dateien bleiben aussen vor. - GET /api/logs/file filtert nach Level, Korrelations-ID und Text, alle ohne Gross-/Kleinschreibung. Hoechstens 20000 Treffer wie im Desktop, dazu Seitenaufteilung. Unlesbare Zeilen werden uebersprungen und gezaehlt. - Der Dateiname entsteht aus dem geprueften Datum, nie aus der Eingabe. "../../etc/passwd" kommt deshalb gar nicht erst in den Pfad; die Tests halten das fest. - Gelesen wird mit FileShare.ReadWrite, weil der Logger laufend an die Tagesdatei anhaengt. Oberflaeche: "Live" und "Log-Viewer (vergangene Tage)" als Unter-Tabs. "Alles kopieren" im Live-Tab, "Seite kopieren" im Viewer. navigator.clipboard gibt es nur in sicheren Kontexten, ueber LAN/VPN laeuft das WebUI aber per http. Dafuer gibt es einen Rueckweg ueber ein unsichtbares Textfeld, sonst schluege das Kopieren dort still fehl. Logzeilen werden per textContent eingesetzt, nicht per innerHTML: Logtexte enthalten, was andere eingegeben haben. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
c1e13f5441 |
WebUI: Server-Einstellungen ohne Geheimnisse bearbeiten
Umsetzung von #561. Entscheidung Richard, 13.09.2026: Alles, was keine Geheimnisse beruehrt, soll ueber das WebUI gehen; Geheimnisse ausschliesslich im Desktop. Eine ausdrueckliche Freigabeliste (ServerSettingsCatalog) statt Reflection. Der Desktop zeigt per Reflection alles, was ServerSettings hat. Uebernaehme das WebUI das, stuende jedes kuenftige Feld automatisch im Netz, auch ein Geheimnis. Bearbeitbar, je Feld mit Pruefung: - Farbschema und Zeitzone: nach Neustart - VPN an/aus und VPN-Standort: sofort - Blockchain-Listener: nach Neustart - Polymarket-WSS: sofort - Watchdog an/aus, Source, Instance und Intervall: sofort "Sofort" und "nach Neustart" sind am Code belegt, nicht am Feldnamen geraten. Zeitzone und Blockchain-Listener werden nur beim Start gelesen, das Farbschema haelt der ThemeManager. Nur im Desktop, Aenderungsversuch 403 und protokolliert: - Geheimnisse: Mullvad-Account, Polygon-RPC-URL (enthaelt den Alchemy-Key), Watchdog-Token, Lizenzschluessel - Watchdog-URL: an diese Adresse geht der Watchdog-Token, wer sie aendert, bekommt ihn - Mullvad-CLI-Pfad: dieses Programm wird ausgefuehrt Von den Geheimnissen zeigt das WebUI nur, ob sie gesetzt sind. OpenRouter- und Master-Key werden dafuer nicht gelesen. Gefunden dabei: MullvadVpnService baut die Kommandozeile als eine Zeichenkette ("relay set location <Wert>"). Der VPN-Standort nimmt deshalb nur Mullvad- Kennungen an (cz, cz-prg). "cz account login 999" wird abgelehnt, ein Test haelt das fest. Source und Instance gehen als JSON ans Deploymentcenter und sind auf Kennungszeichen begrenzt. POST prueft alle Werte zuerst und schreibt dann alles oder nichts, ueber ServerSettingsFile. Danach zieht er den laufenden Stand nach: das Singleton, MullvadVpnService.ReloadSettings und WatchdogHeartbeatService.ReloadSettings. Desktop - bisher schrieb er eine WebUI-Aenderung still zurueck: Die Einstellungen wurden einmal beim Oeffnen geladen, und "Speichern", "Watchdog-Token setzen" und "Lizenzschluessel setzen" schrieben jeweils das ganze alte Objekt zurueck. Jetzt: - Speichern vergleicht innerhalb der Dateisperre den Dateistand vom Laden und verweigert, wenn sich die Datei inzwischen geaendert hat. - Token und Lizenzschluessel schreiben nur noch ihr eigenes Feld. - Eine unlesbare Datei sperrt das Speichern, statt Vorgaben zu zeigen, die beim Speichern die Schluessel geloescht haetten. Die WebUI-Ansicht zeigt je Feld den Wirkungsvermerk und schickt nur, was geaendert wurde. Der Leak-Test legt seine Kanarienwerte jetzt auch in die Einstellungsdatei, sonst liefe die neue Route gegen eine leere Datei. Nicht durch Unit-Tests abgedeckt: die Desktop-Aenderung an SettingsWindow (Oberflaechenklasse). Sie wird mit der Sichtpruefung auf der VM abgenommen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
68d8d6f8d2 |
Module im WebUI aktivieren und deaktivieren
Umsetzung von #560. Die Ansicht "Moduleinstellungen" zeigte bisher nur an, ob ein Modul laeuft. Jetzt laesst sich dort wie im Modul-Tab des Desktops festlegen, welche Module beim naechsten Start geladen werden. POST /api/modules/{name}/enabled nimmt den gewuenschten Zustand ausdruecklich entgegen ({"enabled": true|false}) und schaltet nicht einfach um. Zwei Klicks aus zwei Fenstern heben sich damit nicht auf, und ein wiederholter Aufruf aendert nichts mehr. Fehlerfaelle: - Unbekanntes Modul: 404. - Modul mit Aktivierungs-Blocker: 409. - Fehlender Zustand: 400. Die Pruefung war zuerst lueckenhaft, der Test hat es gefunden: Mit "bool Enabled" machte ein leerer Rumpf {} daraus false, und ein unvollstaendiger Aufruf haette das Modul deaktiviert. Gemeinsame Quelle statt Kopien: - KnownModules: Die Modulliste stand viermal im Code (Program, CoreViews, ModuleViews, hartkodiert im WebUI). Der Start registriert jetzt die eine Liste. - ModuleActivationView: Die Statusregeln des Desktops ("Aktiv - stoppt nach Neustart" usw.) liegen im Core. Desktop und WebUI zeigen dasselbe. ServerSettingsFile - gefunden, bevor das WebUI in die Datei schreiben durfte: ServerSettings.Load verschluckt jeden Lesefehler und liefert Vorgaben. "Frisch lesen, ein Feld aendern, speichern" haette eine gesperrte oder beschaedigte server_settings.xml durch Vorgaben ersetzt, und mit ihr Lizenzschluessel, Watchdog-Token, Mullvad-Account und Alchemy-Key. Genau so schrieb auch der Modul-Schalter des Desktops. ServerSettingsFile: - liest streng und schreibt bei unlesbarer Datei nichts, - schreibt atomar ueber eine Nachbardatei, - erhaelt unter Linux die Dateirechte, - serialisiert Aenderungen prozessweit. Der Desktop-Schalter benutzt ihn jetzt ebenfalls. Tests: Lizenzschluessel, Token und Alchemy-Key bleiben beim Umschalten in der Datei; eine kaputte Datei bleibt Byte fuer Byte unveraendert und die Anzeige bietet dann kein Umschalten an; Blocker, 404, 400, Idempotenz; die Statustabelle; strenges Lesen, atomares Schreiben und Rechte am Dateiobjekt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
6498a3d0ec |
Pause stoppt jetzt auch Verkaufsleitern und Auto-Redeem
Behebt #570. "Trading pausieren" hielt drei Wege nicht an, die Orders am CLOB platzieren: 1. SellLadderService: Eine laufende Verkaufsleiter preiste alle 5 s weiter nach, storniert und neu platziert. Sie pruefte weder Pause noch Modus. Die Engine ignoriert bei Pause zwar alle Signale, die bereits laufende Leiter lief aber ungebremst. 2. TraderMonitorService: Der REST-Pre-Redeem feuert aus der Positions-Synchronisierung, die bewusst auch bei Pause weiterlaeuft. Er pruefte nur LiveTradingMode. 3. PolymarketWssClient: Die Pause wurde nur beim Verbindungsaufbau geprueft. Auf einer bereits offenen Verbindung loesten Kursmeldungen den Auto-Redeem weiter aus. Die Ursache ist allen gemeinsam: Jeder Dienst hat seine Sperre selbst nachgebaut, und jeder hat etwas anderes vergessen. Die Regeln liegen jetzt an einer Stelle, in TradingGate, und alle drei benutzen sie: - Verkaufsleiter: Pause oder Modus des Kontotyps "Inaktiv" friert sie ein, bei "Nur Verkauf" laeuft sie weiter. Das entspricht der Engine. - Pre-Redeem (REST und WSS): wie bisher nur bei Modus Aktiv, jetzt zusaetzlich nicht bei Pause. Eine eingefrorene Leiter storniert nichts und platziert nichts. Das gilt auch am Floor, wenn dort die ruhende Order fehlt. Die ruhende GTC-Order bleibt am Buch, genau wie beim Beenden der Anwendung. LastActionAt bleibt unveraendert, nach der Freigabe geht es an der aktuellen Stufe weiter. Protokolliert wird einmal beim Einfrieren und einmal beim Fortsetzen, nicht alle 5 s. CLOB-kritisch, deshalb: - Vor der Aenderung gesichert unter agentspace/scripts/backups/*.vor-570-*.bak. - Orderaufbau und Preislogik sind nicht angefasst. Der Diff umfasst eine Sperre und drei Bedingungen. - Die Sperre steht vor dem ersten CLOB-Zugriff. Die Harness von SellLadderServiceTests setzt jetzt Live = Aktiv. Mit dem Standard Inaktiv waere Floor_replaces_order rot geworden, und Floor_holds_... waere gruen geblieben, aber aus dem falschen Grund: keine Order, weil eingefroren, nicht weil die Order noch ruht. Neu in SellLadderFreezeTests: Pause, Inaktiv, "Nur Verkauf", Floor im eingefrorenen Zustand, Fortsetzen an der aktuellen Stufe, dazu die Entscheidungstabellen von TradingGate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
d33d695db5 |
WebUI: Trading beenden, ohne die Anwendung zu beenden
Umsetzung von #563. Entscheidung Richard, 13.09.2026: Beenden soll ueber das WebUI gehen, aber beschraenkt auf das Trading. Ein Ende der ganzen Anwendung naehme den Webserver mit; danach waere das WebUI nicht mehr erreichbar. POST /api/dashboard/stop-trading setzt Live- und Demo-Modus auf Inaktiv und schaltet die Pause ein. Damit halten CopyTrading und ResolutionFarming (#569) an, wie beim Ende der Anwendung. Offene Orders an der Boerse werden bewusst nicht storniert: Das tut auch das Beenden der App nicht, und ein Eingriff in die CLOB-Integration gehoert nicht in einen Notschalter. Der Dialog sagt das ausdruecklich. Die Route verlangt {"confirmed": true}. Ein Aufruf ohne Absicht, etwa aus einem alten Skript, beendet nichts. Der Vorgang wird als Warnung protokolliert, mit den Modi vorher. Im Dashboard steht unter der Notfall-Pause jetzt "Trading beenden ...". Der Dialog ist wie im Desktop 10 Sekunden gesperrt, Abbrechen und Esc gehen jederzeit. Wieder aufgenommen wird nur ueber die Modus-Schalter. Die Pause aufzuheben genuegt nicht, das haelt ein Test fest. Offen bis #570: Laufende Verkaufsleitern und der REST-Pre-Redeem pruefen die Pause nicht. Der Inaktiv-Modus, den dieser Knopf setzt, sperrt den Pre-Redeem bereits; die Leitern friert erst #570 ein. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
99172a6be2 |
WebUI gibt keine Geheimnisse mehr heraus und aendert keine Zugangseinstellungen
Behebt #562. Entscheidung Richard, 13.09.2026: Geheimnisse verwalten wir ausschliesslich im Desktop. Bis dahin lieferte GET /api/settings/webui das Zugangs-Token im Klartext. Ueber das WebUI liessen sich ausserdem ein Token setzen, ein neues erzeugen und LocalOnly abschalten. Wer das Token hatte, konnte das WebUI damit ueber unverschluesseltes HTTP ins Netz oeffnen, sich den Zugang verlegen oder sich selbst aussperren. Jetzt: - GET /api/settings/webui liefert Enabled, Port, LocalOnly und vom Token nur hasToken. - POST /api/settings/webui und /webui/generate-token antworten mit 403 und protokollieren den Versuch. Sie bleiben als ausdrueckliche Ablehnung stehen: Ohne eigene Route faengt die Fallback-Route den POST ab und antwortet mit 200, ein altes Skript hielte das fuer einen Erfolg. - Die WebUI-Einstellungsansicht zeigt den Zugang nur noch an. Gepflegt wird er im Desktop unter Einstellungen -> WebUI. WebUiSecretsTests zaehlt alle GET-Routen selbst auf und prueft jede Antwort gegen Kanarienwerte. Geprueft werden ApiKey, ApiSecret, ApiPassphrase und PrivateKey eines Kontos, Mullvad-Account, Alchemy-Key, Watchdog-Token, Lizenzschluessel und das WebUI-Token. Eine neue Route, die ein Konto oder die Server-Einstellungen serialisiert, faellt damit auf, ohne dass jemand an diesen Test denken muss. Gegen die alte Route schlug er fehl ("GET /api/settings/webui liefert ein Geheimnis aus"), jetzt ist er gruen. Ausserdem festgehalten: /api/accounts kennt nur GET. Polymarket-Konten bleiben im WebUI lesbar und nicht aenderbar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
2278d1ccf3 |
ResolutionFarming haelt sich an Pause und Handelsmodi
Behebt #569. GlobalTradingPaused, LiveTradingMode und DemoTradingMode wertete bisher allein CopyTrading aus. Die Farming-Ausfuehrung pruefte nur RfSettings.Enabled und eroeffnete weiter Positionen, auch wenn "Trading pausieren" gedrueckt war oder der Demo-Modus auf Inaktiv stand. Der Pause-Knopf hielt damit nur die Haelfte an. Echtes Geld war noch nicht betroffen: RF fuehrt nur Demo-Konten aus, die Live-Ausfuehrung wird als Zielland-Arbeit uebersprungen. Mit der Live-Anbindung haette eine Pause ohne Wirkung vor echten Positionen gestanden. Jetzt gelten dieselben Regeln wie im CopyTrading. Die Pause sperrt, und der Modus des Kontotyps (Demo oder Live) muss auf Aktiv stehen. "Nur Verkauf" sperrt ebenfalls, denn Farming kauft ausschliesslich. Protokolliert wird nur der Wechsel zwischen gesperrt und frei, nicht jeder Fuenf-Minuten-Durchlauf. VERHALTENSAENDERUNG: Demo-Farming eroeffnet nur noch bei Demo-Modus = Aktiv. Bisher lief es unabhaengig vom Modus, und der steht nach jedem Start auf Inaktiv. Bewusst nicht gesperrt ist die Aufloesungsueberwachung. Sie bucht nur Maerkte ab, die bereits aufgeloest sind, und sendet keine Orders. Hielte man sie an, wiche der ausgewiesene PnL von der Wirklichkeit ab. Der Scanner schreibt nur Kandidaten und bleibt ebenfalls aktiv. Der Schleifenrumpf liegt jetzt als RunCycle() vor und ist damit testbar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
b70d5e5f00 |
WebUI-Tests rufen jetzt echte Routen auf
Behebt #568. Keine der Testdateien mit "EndpointsTests" im Namen hat je einen Endpunkt aufgerufen. CopyTradingAndResolutionFarmingEndpointsTests beruehrte gar keinen Produktionscode: Die Tests summierten Listen im Test und verglichen das Ergebnis mit sich selbst. Modules_KnownModules pruefte, ob ein Array seine eigenen Elemente enthaelt. Settings_UpdateRequest pruefte die Portbegrenzung an einer im Test nachgebauten Lambda. Solche Tests bleiben gruen, egal was der Endpunkt tut. Neu startet WebUiTestHost das WebUI in einem Testserver (Microsoft.AspNetCore.TestHost) und spricht es ueber HTTP an. Damit der Test die Kette aus dem Betrieb prueft und keine nachgebaute, liegt sie jetzt in UsePolyTraderWebPipeline(): statische Dateien, Token-Pruefung, alle Routen. ConfigurePolyTraderWeb ruft genau diese Methode. Ersetzt wird nur, was ausserhalb des Prozesses liegt - Kestrel durch den Testserver, MySQL durch den InMemory-Provider. Die acht CopyTrading/ResolutionFarming-Tests pruefen dieselben Absichten wie vorher, jetzt an der Antwort der Route. Neu hinzugekommen sind Tests fuer: - Zugangssperre: ohne Token, mit falschem Token, ohne konfiguriertes Token - die Modulliste - Job-Umschalten samt 404 - die Ablehnung einer leeren Supervisor-Frage Die beiden Tests, die schon echten Code prueften, bleiben. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
2c0ab79dcd |
WebUI-Kopfleiste: Aufklappmenues statt elf Tabs
Umsetzung von #541, folgt auf #532. Elf Tabs nebeneinander waren nicht mehr zu ueberblicken. Die Leiste hat jetzt vier Eintraege, gruppiert nach dem, was man dort tut: - Dashboard - Analytics: Analytics, Accounting, Supervisor - Module: Moduleinstellungen (die allgemeine Modulansicht), danach alle Module - Einstellungen: Einstellungen, Jobs, Konten, Terminal / Logs Supervisor und Accounting stehen unter Analytics und zusaetzlich in der Modulliste, weil dort alle Module stehen sollen. Hervorgehoben wird das Oberelement nur an ihrem Hauptplatz (Analytics); der zweite Zugang traegt data-secondary. Sonst leuchteten bei geoeffnetem Supervisor zwei Menues. switchView() findet den aktiven Eintrag jetzt ueber data-view statt ueber eine Teilzeichenkette im onclick-Attribut. Das alte Verfahren hing am Zufall der Namen: Eine Ansicht, deren Name in einer anderen enthalten ist, haette beide markiert. Die Modulliste zeigt den Zustand aus /api/modules: Ein deaktiviertes Modul erscheint ausgegraut mit "deaktiviert" und ist nicht anklickbar, statt in eine leere Ansicht zu fuehren. Ein Modul, das der Server fuehrt, fuer das es im WebUI aber keine Ansicht gibt, wird mit "keine Ansicht" gelistet. Bedienbar mit Maus und Tastatur: Klick ausserhalb und Esc schliessen (Esc gibt den Fokus ans Oberelement zurueck), Pfeil nach unten oeffnet und springt in das Menue, Pfeiltasten laufen um und ueberspringen deaktivierte Eintraege, Tab verlaesst das Menue. aria-haspopup, aria-expanded und aria-current sind gesetzt. Unter 760 px haengen die Menues an der ganzen Leiste statt am Eintrag. Bei 400 px ragte "Module" sonst 35 px ueber den rechten Rand. Ein Nachmessen per Skript taugt dagegen nicht: In der Mobilansicht waechst der Layout-Viewport mit dem Ueberstand mit, und die Messung meldet genau dann "passt". Die Modulansicht heisst jetzt wie ihr Menueeintrag "Moduleinstellungen". Geprueft auf der Linux-Test-VM im Browser: Alle 12 Eintraege schalten die richtige Ansicht und heben das richtige Oberelement hervor, das Menue schliesst danach; Tastaturbedienung, deaktiviertes und unbekanntes Modul (simuliert) verhalten sich wie beschrieben. Vermessen bei 400, 700, 768 und 1024 px: kein Menue ragt aus dem Fenster, die Seite scrollt nie waagerecht. 556 von 556 Tests bestanden. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
4c556be57d |
Einstellungen: erst schreiben, dann uebernehmen
Behebt #534. Die vier schreibenden Endpunkte verschluckten die Ausnahme des Repositories und meldeten anschliessend unbedingt Erfolg. Das Verschlucken war unschoen; die Reihenfolge war gefaehrlich: copyState wurde auch dann geaendert, wenn die Datenbank abgelehnt hatte. Das Modul handelte danach mit Risikolimits, die nirgends standen, und nach dem naechsten Neustart konnte niemand mehr rekonstruieren, womit es gehandelt hatte. Neu geht der Schreibvorgang zuerst, und der Hauptspeicher wird nur nachgezogen, wenn er gelang. Sonst 500 mit Klartext und unveraenderter Zustand. Fehlt die Ablage ganz, ist die Aenderung ebenso rein fluechtig — auch das wird abgelehnt, mit 503. Betroffen: CopyTrading-Kontoeinstellungen, ResolutionFarming-Kontoeinstellungen, Master-Trader anlegen/aendern, Master-Trader loeschen. Dass alle vier denselben Helfer (PersistenceGuard) benutzen, ist der eigentliche Punkt: Aus je eigenem try/catch je Endpunkt ist die Ungleichheit ueberhaupt erst entstanden. Bewusst anders behandelt bleibt das Archivieren eines Supervisor-Berichts: Die Antwort des Agenten steht dort bereits und hat Geld gekostet: sie wegen eines fehlgeschlagenen Archiveintrags zu verwerfen, waere schlimmer als der fehlende Eintrag, und an diesem Schreibvorgang haengt kein Verhalten des Systems. Stillschweigend verschwindet er aber nicht mehr, sondern wird protokolliert. In der Oberflaeche zeigten die Schreibwege bisher nur "HTTP 500" an und verschenkten damit genau die Begruendung, die der Server jetzt mitliefert. errorText() liest sie aus der Antwort. Entscheidung von Richard: ablehnen statt fluechtig uebernehmen. Damit sind waehrend eines Datenbankausfalls keine Aenderungen an den Einstellungen mehr moeglich; das Handeln selbst laeuft weiter. Geprueft auf der Linux-Test-VM mit angehaltener MariaDB: alle drei Schreibwege antworten mit 500 und nennen den Grund, das Limit bleibt bei 11,25 statt auf 99,99 zu springen, der Phantom-Trader entsteht weder im Hauptspeicher noch in der Datenbank, jeder Fehlschlag steht im Protokoll. Nach dem Wiederanlauf speichert es wieder. 556 von 556 Tests bestanden (5 neue). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
72ad38518b |
EZB-Tageskurse selbst abrufen, Kopfleiste umbrechen lassen
Behebt #532 und #533. #532 — Kopfleiste bricht um statt zu scrollen Mit elf Ansichten brauchte die Leiste 1623 px. Darunter scrollte sie seitlich weg, ohne dass ein Hinweis darauf sichtbar war: Wer einen rechten Tab anklickte, verlor "Dashboard" aus dem Blick und fand den Weg zurueck nicht mehr. Statt overflow-x nun flex-wrap auf Leiste und Kopfzeile. Geprueft von 1920 bis 768 px — nichts wird mehr abgeschnitten, der Koerper scrollt nie waagerecht. #533 — Kurse holen, statt EUR still auf null zu setzen Die Tabelle acc_fx_rates gab es seit A-2, befuellt hat sie nie jemand. Deshalb war EUR nicht verfuegbar, und der PDF-Export machte daraus wortlos einen Beleg mit lauter Nullbetraegen. Neu holt EcbFxRateSource die amtlichen Referenzkurse ueber die EZB-Daten-API (Reihe EXR/D.USD.EUR.SP00.A, CSV). FxRateSyncService stoesst das beim ersten Ingest-Lauf des Tages an: erstmalig 400 Tage rueckwirkend, danach nur noch der Rand. Die Kurse werden gespeichert, nicht bei Bedarf geholt — eine Abrechnung fuer einen vergangenen Monat muss den Kurs von damals nehmen und beim naechsten Aufruf dasselbe Ergebnis liefern. Zwei Fallen, die dabei zu umgehen waren: - Die Reihe liefert USD je EUR (1 EUR = 1,1652 USD), FxRate.UsdToEur meint die Gegenrichtung. Wer das verwechselt, bekommt eine Abrechnung, die um rund 35 % danebenliegt und trotzdem plausibel aussieht. Gespeichert wird der Kehrwert. - Die CSV-Antwort enthaelt in TITLE_COMPL ein Komma innerhalb von Anfuehrungszeichen; naives Splitten verschoebe die Spalten. Die Warnung erscheint, sobald der verwendete Kurs mehr als drei Tage vor dem Stichtag liegt. Drei Tage, weil genau so gross die planmaessige Wochenendluecke ist: Der Freitagskurs gilt bis Montag und ist dabei kein Mangel. Der Beleg bleibt trotzdem erzeugbar — die Warnung steht sichtbar darauf und im WebUI ueber der Abrechnung. Nur ohne jeden Kurs lehnt der Export jetzt mit 400 ab, statt Nullbetraege auszugeben. PDF und CSV laufen deshalb nicht mehr ueber window.open: Eine nackte JSON-Fehlermeldung in einem neuen Reiter ist keine Antwort. downloadExport() holt die Datei, meldet Fehler im Klartext und stoesst sonst den Download an. Nebenbei im Testlauf gefunden und behoben: Der manuelle Anstoss aus dem WebUI und die stuendliche Schleife trafen sich in derselben Sekunde — im Log standen "280 Kurse uebernommen" und "53 Kurse uebernommen" untereinander, beide hatten die EZB gefragt. SyncDailyAsync serialisiert jetzt und prueft den Tag ein zweites Mal innerhalb der Sperre. Geprueft auf der Linux-Test-VM gegen die echte EZB-API: 280 Kurse vom 06.08.2025 bis 09.09.2026 uebernommen, Umrechnung stimmt (1/1,1652 = 0,858222), eine Maerz-Abrechnung nimmt den Kurs vom 31.03. und nicht den heutigen, das Warnbanner erscheint ab dem vierten Tag, der Export verweigert ohne Kurs und liefert sonst ein gueltiges PDF. 551 von 551 Tests bestanden (18 neue). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
dcc764dec1 |
WebUI: Module, Analytics und Buchhaltung als eigene Ansichten
Das WebGUI konnte bisher Dashboard, Konten, Jobs, Logs und Einstellungen.
Die vier Strategie- und Analysemodule waren nur in der Avalonia-Oberflaeche
erreichbar - wer den Server aus der Ferne bediente, sah sie nicht.
Fuenf neue Endpunktgruppen holen sie herein:
/api/analytics KPIs, Equity-Kurve, PnL je Modul und Tag,
durchsuchbare Trade-Historie mit Seitenlauf
/api/modules/copytrading Master-Trader (CRUD), offene und
geschlossene Trades, Risikolimits je Konto
/api/modules/resolutionfarming Scanner-Kandidaten, Positionen, Historie,
Farming-Parameter je Konto
/api/modules/supervisor Profile, Agentenfragen, Berichtsarchiv,
Signal-Dossiers, Counterfactuals
/api/modules/accounting BWA-Periodenabrechnung, Ledger-Journal,
PDF- und CSV-Export, Ingest-Laeufe
Dazu im Bestand:
- Dashboard bekommt /overview-widgets: Modul-KPIs (heute/7T/30T), auffaellige
Trades der letzten 24 Stunden, Warnungen und Fehler des Tages, den letzten
Supervisor-Bericht.
- Die Kontenliste zeigt 3-Tage-PnL, Winrate, Gesamtergebnis und die
beteiligten Module statt nur Salden.
- Jobs lassen sich ueber /toggle und /state ein- und ausschalten, nicht nur
ausloesen.
Die Oberflaeche bleibt ohne Fremdbibliotheken: alle Diagramme sind Inline-SVG,
kein CDN, kein npm. Alle neuen Pfade liegen unter /api/ und damit hinter der
bestehenden Token-Pruefung.
Zwei Fehler nebenbei behoben:
- AccountingReportService.ResolveCurrency lief in eine NullReferenceException,
wenn der FX-Dienst nicht gesetzt war. Betrifft jeden EUR-Aufruf ohne
geladene EZB-Kurse.
- Ein Master-Trader, dessen Name ein Apostroph enthaelt, hatte einen toten
Loeschen-Knopf: escapeHtml laesst ' unberuehrt, und im onclick-Attribut
beendete das Zeichen das JavaScript-Literal vorzeitig. Laengerer Text mit
Anfuehrungszeichen konnte darueber eigenen Code einschleusen. Neu setzt
jsArg() den Wert als JSON-Literal ein; geprueft mit
O'Brien "quote" <b>bold</b> \ backslash.
McpLightServerTests weicht jetzt aus, wenn HttpListener mangels URL-ACL nicht
binden darf, statt den Lauf scheitern zu lassen.
Geprueft auf der Linux-Test-VM (Ubuntu 26.04, .NET 10): Build ohne Fehler,
533 von 533 Tests bestanden, alle 11 Ansichten und 15 Unteransichten geladen,
alle Endpunkte mit 200 beantwortet, Schreibwege bis in die Datenbank
nachverfolgt, PDF- und CSV-Export gueltig, SSE-Logstrom live.
Offene Befunde aus der Abnahme liegen als #532 (Kopfleiste laeuft unter
1623 px ueber), #533 (EUR-PDF ohne EZB-Kurse liefert Nullbetraege) und #534
(Einstellungen melden Erfolg trotz gescheitertem Speichern) im Bugtracker.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Richard
|
78a2f85b94 | Standardport für WebUI von 5001 auf 6001 geändert | ||
|
Richard
|
10f928eb4e | Paralleles WebGUI mit Kestrel, Token-Sicherung und SSE-Logs implementiert | ||
|
RichardandClaude Opus 5
|
28b3aedec7 |
Vier Befunde der Sichtpruefung behoben: Farbschema, Grids, Diagramme, Kontrast
#383 Farbschema "System" kehrte sein Versprechen um. ThemeManager.IsDark verglich ActualThemeVariant der Anwendung mit Dark; bei "System" steht dort Default, waehrend die Fenster selbst nach hell oder dunkel aufloesen. IsDark war damit im Auslieferungszustand immer false - Symbol, Beschriftung und Toggle() haengen alle an diesem Wert. Gelesen wird jetzt die angeforderte Variante, bei "System" die Betriebssystem-Einstellung. Derselbe Fehler steckte in Brush(): die Methode suchte bei "System" in den hellen Farben, waehrend dunkel gezeichnet wurde - betroffen war genau das, wofuer es sie gibt (Zeilenfarben, KPI-Vorzeichen). Neu ist ausserdem, dass eine Umstellung am Betriebssystem ThemeChanged ausloest, solange "System" gilt. #384 Sternspalten quetschten die Endspalten weg. Der Merksatz aus #56 galt bisher nur fuer gridTraders. Angewandt auf gridOpen und gridClosed sowie auf die uebrigen Grids, deren Spaltensumme den sichtbaren Bereich uebersteigt (gridTrades, gridJobs, gridLedger, gridCandidates, gridPositions, gridHistory). Auto statt Stern, dazu MaxWidth 360 - anders als "Name" in #56 traegt "Markt" ganze Fragesaetze und wuerde die Zahlenspalten sonst aus dem Blick schieben. Grids mit weniger Spalten als Platz behalten ihre Sternspalte. #385 Gewinntage wurden rot gezeichnet. Eine ColumnSeries hat genau ein Fill fuer alle ihre Balken; gefaerbt wurde deshalb nach der Summe ueber alle Tage. Jetzt zwei Reihen an denselben Positionen - Gewinne in der einen, Verluste in der anderen, Luecken als null. "PnL je Modul" faerbt ebenfalls nach Vorzeichen: zwei Diagramme nebeneinander mit verschiedenen Leseweisen waeren schlechter als beide ohne. #386 Drei Kleinigkeiten. Die Equity-Achse beschriftete zehn Teilstriche mit zwei Daten - unter drei Tagen kommt jetzt die Uhrzeit dazu, darueber gilt hoechstens ein Teilstrich je Tag. "Deaktivierte Module" sah aus, als fehle das Bedienelement: leere Nur-Lese-Felder zeigen jetzt "—" in einer abgesetzten Flaeche. Die Abschnittsbeschriftungen der Seitenleiste lagen bei 3,65:1 statt der geforderten 4,5:1 (im Bild sogar 1,83:1, weil 10 px mit Sperrung ausduennen) - AppCaptionTextBrush erreicht 4,61:1 hell und 6,21:1 dunkel und bleibt deutlich leiser als die Eintraege darunter. Build gruen, 486 Tests gruen. Die Sichtpruefung auf der Linux-VM steht noch aus; die drei rein visuellen Punkte sind aus dem Quelltext begruendet, nicht im Bild belegt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
53231d62bc |
Testen laeuft jetzt ueber das Deploymentcenter; Befunde in den Bugtracker
Die Testanleitung im PolyTrader-Repo ist nur noch ein Zeiger auf die massgebliche Fassung in Deploymentcenter/docs/TESTUMGEBUNG.md, plus dem, was PolyTrader-eigen ist: Display :99, Datenbank polytrader_test, Dienstkonto, Publish-Verzeichnis, /tmp-Praefix. Die Anleitung galt immer projektuebergreifend und lag nur hier, weil sie beim ersten Linux-Lauf von PolyTrader entstand. Eine Tabelle loest die alten Abschnittsnummern auf, damit vorhandene Verweise lesbar bleiben. Befundbericht: Nachtrag 6 haelt die Gegenprobe am Bild vom 28.08.2026 fest - den ersten Lauf nach dem neuen Verfahren. Linux-Build 0 Fehler / 15 Warnungen wie unter Windows, 484 Tests gruen, --smoke-ui unter xvfb-run -n 99 durchgaengig gruen. B-6, B-7, B-11, B-13, B-14 und die B-12-Selbstheilung sind damit auf der Zielplattform bestaetigt; B-9 hat sich als kein Fehler entpuppt, und die Spaltenumstellung hatte einen eigenen Fehler erzeugt. Damit ist dieser Bericht abgeschlossen. Was offen bleibt, steht ab jetzt im Bugtracker (Items #50-#52 und #56 fuer polytrader, #53-#55 und #57 fuer deploymentcenter) statt in Befundberichten - dort geht es nicht mehr verloren, und Befunde an fremden Projekten landen dort, wo jemand sie beheben kann. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
57cfca5fe9 |
Testlauf, dem man glauben kann: Zeitzonen-Tests und Schluss mit Nebenlaeufigkeit
Zwei Tests zur Zeitzonen-Umstellung aus dem letzten Commit: der Zeitstempel eines Logeintrags traegt den Versatz der ANZEIGE-Zone (nicht den des Systems), und die abgelegte JSONL-Zeile traegt ihn mit. Sie liegen bewusst in AppTimeZoneTests - dort steht der uebrige Zeitzonen-Zustand, und innerhalb einer Klasse laufen Tests nacheinander. Das genuegte aber nicht. Von sechs Laeufen fiel einer um und liess sich danach nicht wieder einfangen. Die Ursache ist kein einzelner Test, sondern die Bauart: Mehrere Bausteine halten prozessweiten Zustand, den Tests bewusst umstellen - AppTimeZone, SecretProtection, die Diagnosezaehler von AccountIdSetJson. xUnit fuehrt Testklassen standardmaessig nebenlaeufig aus, also sieht eine Klasse mitten im eigenen Lauf, was eine andere gerade umgestellt hat. Neu ist das nicht, aber die Zeitzonen-Umstellung hat es verschaerft: Seit die Logzeitstempel der Anzeige-Zeitzone folgen, haengt jedes LogMessageEventArgs an AppTimeZone - waehrend AppTimeZoneTests dieselbe Einstellung nach Auckland und zurueck dreht. Deshalb laufen die Testklassen jetzt nacheinander, und die Zaehlerpruefungen arbeiten mit der Differenz statt mit absoluten Werten. Kosten: 4-5 s statt 3 s Laufzeit. Ein Testlauf, dem man glauben kann, ist das allemal wert - danach sechs Laeufe in Folge gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
f4e017fe58 |
Spalten wieder vollstaendig; die Kalender-Vermutung war falsch
Zwei Nacharbeiten aus der Sichtpruefung auf der Linux-VM vom 28.08.2026. Master-Trader-Grid: Die Breitenumstellung von gestern hat mehr kaputtgemacht als geheilt. Von zwoelf Spalten blieben sieben brauchbar - hinter "Winrate %" stand eine Spalte mit abgeschnittenen Werten ohne Ueberschrift, dahinter vier leere Streifen. PnL, Copy-PnL, Profit-Faktor, Ø PnL/Trade und Copy-Trades waren weder lesbar noch als Spalte erkennbar. Das ist schlimmer als der urspruengliche Befund: dort fehlten Ueberschriften, hier die Werte. Ursache war die Sternbreite auf "Name". Zwoelf Spalten passen neben dem 460 px breiten Detailbereich nicht ins Fenster; statt waagerecht zu schieben, verteilt das DataGrid den Mangel und zerdrueckt die Auto-Spalten am Ende. Jetzt steht auch "Name" auf Auto: jede Spalte behaelt ihre Breite, das Grid bekommt einen waagerechten Rollbalken. Im Bild gegengeprueft. Kalendersymbol (Befund B-9): zurueckgenommen. Die gestrige Aenderung war eine Vermutung, und sie war falsch. Die vermeintlich sinnlose Zahl im Datumsfeld ist das heutige Datum - am 26.08. eine "26", am 28.08. eine "28". Avalonia zeichnet dort die heutige Tageszahl in ein Kalenderblatt, unter Linux fehlt der Blatt-Glyph. Zwei Gegenproben liessen das Bild unveraendert: die Formatvorlage per :not(#PART_Button) vom Knopf ferngehalten, und das Farbschema gewechselt. Eine Aenderung ohne Wirkung und ohne Begruendung gehoert nicht in den Code; an ihrer Stelle steht ein Kommentar, damit der Naechste nicht dieselbe Spur verfolgt. Rein kosmetisch, Bugtracker-Item #50. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
9b2294cb4c |
Testanleitung: eigenes X-Display je Projekt fuer Parallelbetrieb
Damit mehrere Agenten gleichzeitig Oberflaechen testen koennen, bekommt jedes Projekt eine feste Displaynummer (Vorgabe Richard): :99 PolyTrader, :98 Predictalytics, :97 ClawdDotNet, :96 IBKRTrader, :95 und absteigend fuer kuenftige Projekte. Zwei Prozesse auf demselben Display sehen die Fenster des jeweils anderen - Klicks landen im falschen Programm, Aufnahmen zeigen fremde Anwendungen. Beim Durcharbeiten fielen zwei weitere Kollisionspunkte auf, die zum Parallelbetrieb dazugehoeren und mit aufgenommen wurden: - Screenshot- und Logdateien in /tmp brauchen ein Projektpraefix. /tmp/v_1.png ueberschreiben sich parallel laufende Projekte gegenseitig. - "xvfb-run -a" darf NICHT mehr verwendet werden: Das -a sucht sich selbst ein freies Display und beginnt dabei bei :99 - ausgerechnet PolyTraders Nummer. Stattdessen "xvfb-run -n <nummer>". Die Warnung ist nicht theoretisch: Auf der VM lag ein verwaister X98-Socket, entstanden durch genau so einen "xvfb-run -a"-Aufruf beim smoke-ui-Test, als :99 belegt war. Er blockierte Predictalytics' reservierte Nummer, ohne dass ein Prozess lief. Entfernt, und die Anleitung erklaert jetzt, wie man verwaiste Sockets erkennt (ls /tmp/.X11-unix/ gegen pgrep -a Xvfb lesen) und aufraeumt. Weiter ergaenzt: - pkill nie ohne Displaynummer - "pkill Xvfb" erschlaegt die Sitzungen aller anderen Projekte. - DISPLAY in jedem Skript setzen, sonst landet man auf :0, dem echten Desktop. - Die Skriptvorlage hat jetzt einen Kopf mit PROJEKT/DISP/FENSTER; das ist alles, was sich je Projekt unterscheidet. Praktisch gegengetestet. - Aufraeumabschnitt und Belegungsliste um Displays und Verzeichnisse erweitert. Nebenbei aufgefallen: Das PolyTrader-Publish lag unter ~/pt-test statt ~/polytrader-test und verletzte damit die eigene Verzeichniskonvention. Umbenannt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
62570cfdd8 |
Sichtpruefung mit Testdaten: die Grids in Aktion, vier weitere Befunde
Testdaten in die Testdatenbank eingespielt (3 Demo-Konten, 5 Master-Trader, 3 offene Positionen, 7 Trades, 5 RF-Kandidaten), gesichert als docs/pruefplaene/testdaten-ui.sql zur Wiederverwendung. Bewusst mit 42-stelligen Wallet-Adressen und langen englischen Marktfragen - kurze Platzhalter haetten die Layoutbefunde verdeckt. Mit Daten wirkt die Anwendung vollstaendig funktionsfaehig: Grids fuellen sich, die Auswahl markiert Zeilen, das Detailformular uebernimmt den gewaehlten Datensatz, zugewiesene Konten werden korrekt angehakt, KPI-Kacheln rechnen. Vier weitere Befunde: - B-13 (wichtig): Die Spalte "Name" im Master-Trader-Grid ist auf wenige Pixel zusammengequetscht - die Anzeigenamen sind NIRGENDS zu sehen, obwohl sie die wichtigste Information der Zeile sind. Die festen Breiten der elf uebrigen Spalten lassen der Sternbreite fast nichts uebrig. - B-11 praezisiert: Nicht die Werte sind zu breit, sondern die Ueberschriften. Das RF-Grid zeigt lange Marktfragen mühelos, waehrend "Fee (bps)" zu "Fee (bp" verstuemmelt wird. Die Breiten sind auf die Datenwerte ausgelegt. - B-14: Beschreibung und Reasoning sind einzeilige Felder fuer varchar(1000). - B-15: Ein fehlerhafter Datensatz legt die gesamte Modul-Hydration lahm. Beim ersten Einspielen war AssignedAccountIds kein gueltiges JSON - daraufhin wurde kein einziger Trader geladen. Im Betrieb hiesse das: ein beschaedigter Eintrag legt das komplette Modul stumm, statt uebersprungen und gemeldet zu werden. B-7 bestaetigt: In jeder KPI-Kachel steht der Modulname doppelt. Nachgeprueft und KEIN Fehler: Copy-PnL zeigt 0,00, weil die Kennzahlen aus den tatsaechlichen Copy-Trades berechnet werden und mod_copytrading_closed_trades leer ist. Die Werte stehen auch in der Datenbank auf 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
a39ad67181 |
Modulfenster geprueft; Screenshot-Verfahren in die Testanleitung aufgenommen
Nach der Lizenzaktivierung durch Richard sind alle vier Module aktiv - die Anwendung meldet "Lizenz gueltig (online geprueft)", der Cache steht auf valid, die Statusleiste zeigt vier Module. Damit ist D-2 live abgenommen, inklusive HWID v2 auf Basis der Linux-machine-id. Ein Stueck von Roadmap A3 nebenbei. Vier weitere Befunde: - B-9: In den Datumsfeldern erscheint statt des Kalendersymbols ein Artefakt. Die Icon-Schriftart fehlt unter Linux, Fontconfig ersetzt sie stillschweigend durch eine andere. Nur im Bild zu sehen, nie im Log. - B-10 (schwerwiegend, im vorigen Commit behoben): kein einziges DataGrid wurde gerendert. - B-11: Spaltenueberschriften werden abgeschnitten, die letzten drei Spalten zeigen gar keinen Text mehr. Genau der A5-Punkt Spaltenbreiten: die festen Pixelwerte stammen aus der WinForms-Fassung mit schmalerer Schrift. Nicht behoben - Spaltenbreiten legt man sinnvoll erst mit echten Daten fest. - B-12: Der Lizenzschluessel liegt im Klartext in server_settings.xml, obwohl die Projektkonvention Verschluesselung at-rest vorsieht und der Code beides unterstuetzt. Positiv: Die acht KPI-Kacheln im Accounting brechen sinnvoll um - eine offene A5-Frage ist damit beantwortet. docs/TESTUMGEBUNG-Linux-VM.md Abschnitt 4.7 neu: wie ein Agent Oberflaechen eigenstaendig begutachtet - Xvfb dauerhaft starten, mit xdotool navigieren, mit import aufnehmen, Ausschnitte vergroessern, Kontraste nachmessen. Mit den Lehren aus diesem Durchgang: grosszuegige Wartezeiten, nur eine Instanz gleichzeitig (sonst kollidiert die zweite mit dem systemd-Dienst in der Datenbank), und auf Zeichen achten, die falsch aussehen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
f13679fadd |
DataGrid-Theme eingebunden - ohne es rendert kein einziges DataGrid
Befund B-10 aus dem Linux-Sichttest: Saemtliche Tabellen der Anwendung waren leer - keine Zeilen, keine Spaltenkoepfe, nur eine leere Flaeche. Betroffen waren alle DataGrids: Master-Trader, Offene/Geschlossene Trades, Account-Uebersicht, Ledger, Jobs. Ursache: Avalonia.Controls.DataGrid liegt in einem eigenen Paket und bringt sein Theme NICHT ueber FluentTheme mit. In App.axaml fehlte der noetige StyleInclude auf avares://Avalonia.Controls.DataGrid/Themes/Fluent.xaml. Warum das so lange unbemerkt blieb: Es gibt weder eine Fehlermeldung noch eine Bindungswarnung. Die Konstruktionspruefung bleibt gruen, weil das Fenster ja aufgebaut wird - nur gerendert wird nichts. Und die Abnahme mit echten Daten (A5) stand noch aus, ohne die eine leere Tabelle wie fehlende Daten aussieht statt wie ein Fehler. Der Fehler ist NICHT linuxspezifisch, er bestand unter Windows genauso. Die vorhandenen Anpassungen fuer DataGrid und DataGridColumnHeader in App.axaml bauen auf diesem Basis-Theme auf und liefen bisher ins Leere. Build gruen, 476 Tests gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
416a804fe3 |
Sichtpruefung der Oberflaeche unter Linux (Teil 1 von 2)
Durchgefuehrt ohne Bildschirm: Anwendung unter Xvfb, Navigation per xdotool, Aufnahmen mit import. Damit ist die Sichtpruefung reproduzierbar und ohne Anwesenheit moeglich. Positiv: Schriftrendering sauber inklusive Umlauten, typografischen Anfuehrungszeichen, Emoji und Monospace im Terminal - unter Linux mit Fontconfig nicht selbstverstaendlich. LiveCharts2/Skia rendert. Layout ohne Ueberlappungen oder abgeschnittene Texte. Die beim Fruehjahrsputz nach Assets/ verschobenen PNG-Symbole werden korrekt angezeigt. Vier neue Befunde: - B-5: Mullvad CLI Path steht unter Linux auf C:\Program Files\... - der Standardwert stammt aus der Windows-Zeit. Wer die VPN-Rotation einschaltet, bekommt einen Fehler ohne erkennbare Ursache. - B-6: Textkontrast in den KPI-Kacheln nur 2,33:1 (gemessen, RGB 46/104/68 auf 35/37/39). WCAG AA verlangt 4,5:1. - B-7: Gesamt erscheint doppelt in der KPI-Kachel. - B-8: Datumsachse der Equity-Kurve zeigt zwoelfmal 01.01. statt fortlaufender Daten. Vermutlich nicht Linux-spezifisch, nur hier aufgefallen. Offen: die vier Modulfenster. Ohne Lizenzschluessel deaktiviert BuildHost alle Module, sie bleiben in der Seitenleiste ausgegraut. Das Deploymentcenter ist von der VM erreichbar und die Lizenz-CLI meldet bereits eine HWID auf Basis der Linux-machine-id - eine Aktivierung waere zugleich die Live-Abnahme von D-2. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
83d49aa106 |
A4a vollstaendig: PolyTrader laeuft als Dienst auf Linux; Testumgebung dokumentiert
Der Pruefplan ist abgearbeitet. Die Anwendung laeuft nicht nur, sie arbeitet: Core-Hydration, MarketSyncService und 100 echte Maerkte von der Polymarket-API in die Datenbank geschrieben - HTTP, TLS, JSON und DB-Zugriff funktionieren unter Linux. Ergebnisse im Einzelnen: - MariaDB 11.8.6 auf der Test-VM, genau die in DatabaseServerVersion gepinnte Version. Alle fuenf DbContexts migriert, 21 Tabellen. - systemd: active, Shutdown in 0,08 s (Grenze 45 s) ohne SIGKILL, Restart=on-failure greift nach kill -9. - Der neue Exit-78-Schutz wirkt nachweislich: Verbindung entfernt -> Status failed, systemd meldet 78/CONFIG, KEINE Neustartschleife, verstaendliche Meldung im Journal. - D-11 (WorkingDirectory-Falle) ist KEIN Problem: server_settings.xml wird aus /opt/polytrader gelesen, eine Suche ueber das ganze Dateisystem findet keine zweite Datei. Nebenbefund: die Datei wird beim Start gar nicht angelegt, erst beim Speichern von Einstellungen. - Logrotate mit copytruncate rotiert beide Namensmuster, Dienst schreibt weiter. - Alle neun Views konstruieren fehlerfrei, beide Farbschemata vollstaendig. T2 ist belegt statt behauptet: Unter UTC meldet die Anwendung "Anzeige-Zeitzone: Europe/Berlin" und stempelt in derselben Zeile mit 20:04 statt 22:04. Auf einem UTC-Server zeigen damit alle Logs die falsche Zeit, zwischen Mitternacht und 2 Uhr sogar das falsche Datum. Neuer Befund B-4: --smoke-ui scheitert ohne X-Server (XOpenDisplay failed), obwohl es als CI-Werkzeug gedacht ist. "xvfb-run -a" loest es nachweislich - relevant, sobald A2 wieder aufgenommen wird. docs/TESTUMGEBUNG-Linux-VM.md neu: Anleitung fuer ALLE Projekte, die auf der VM testen. Zugang per eigenem SSH-Schluessel je Projekt, eigene Datenbank je Projekt (<projekt>_test samt eigenem Benutzer, nie eine fremde mitbenutzen), eigenes Dienstkonto, Verzeichnis- und Portkonventionen, Belegungsliste und Aufraeumbefehle. Kopie liegt auf der VM unter ~/TESTUMGEBUNG.md, wo jeder Agent sie beim Verbinden findet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
4e9d7259c0 |
Befundbericht zum ersten Linux-Lauf
PolyTrader laeuft auf Linux: Build 0 Fehler, 476 Tests gruen, Publish und Start funktionieren - bei Build und Tests kein einziger Unterschied zu Windows. Bestaetigt: --headless braucht keine nativen GUI-Bibliotheken (BuildAvaloniaApp wird nie aufgerufen, Skia nie geladen), master.key bekommt unter Linux korrekt 0600, Zeitzone und Lizenz-Gate verhalten sich wie dokumentiert. Drei Befunde festgehalten: B-1 (Absturz ohne Datenbank) ist behoben, B-2 (zwei Datumsformate in Logdateinamen) und B-3 (--smoke-ui verlangt jetzt eine Datenbank; war vorher genauso, nur unsichtbar) sind offen und beschrieben. Nicht geprueft und warum: systemd, Oberflaeche, SIGTERM und der T2-Nachweis brauchen eine Testdatenbank und sudo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
ad94f8c373 |
Verstaendlicher Abbruch statt Absturz, wenn die Datenbankverbindung fehlt
Erster Befund aus dem Linux-Lauf auf der Test-VM (Roadmap A4a): Ohne konfigurierte Datenbank startete die Anwendung los und starb erst tief im DI-Aufbau mit einer unbehandelten ArgumentException und rund 50 Zeilen Stacktrace - "The string argument 'connectionString' cannot be empty", geworfen aus dem EF-Kern. Exitcode 134 (SIGABRT). Fuer den Serverbetrieb ist das gleich doppelt schlecht: Der Betreiber sieht nicht, was fehlt, und systemd startet den Dienst wegen Restart=on-failure alle zehn Sekunden neu. Im Journal stehen dann endlose Startversuche statt der Ursache. Genau dieser Zustand ist bei einer Erstinstallation der wahrscheinlichste - Software liegt da, Zugangsdaten sind noch nicht gesetzt. Behoben an drei Stellen: - Program.Main prueft die Verbindung, bevor der Host gebaut wird, und gibt aus, welcher Schluessel in welcher Datei erwartet wird, samt Beispiel und dem Hinweis, dass das Schema per "dotnet ef database update" angelegt wird (die Anwendung migriert nicht selbst). - Rueckgabewert 78 (EX_CONFIG aus den BSD-sysexits) statt eines Absturzes. - deploy/polytrader.service traegt RestartPreventExitStatus=78 - ein Konfigurationsfehler repariert sich durch Neustarts nicht, er wird dadurch nur unsichtbar. - AddCorePersistence wirft als zweite Verteidigungslinie eine InvalidOperationException mit derselben Aussage, falls jemand die Methode direkt aufruft. Der Connection-String wird dabei ueber dieselben Dateien und denselben Schluessel gelesen wie spaeter im Host, damit beide Wege nicht auseinanderlaufen koennen. Build gruen, 476 Tests gruen (Windows und Linux). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
e60dffbdf6 |
Rider-Konfiguration wieder aus dem Repo nehmen
Mit dem vorigen Commit sind versehentlich vier .idea/-Dateien mitgegangen (git add -A). Sie enthalten maschinenspezifische Pfade und Index-Layouts und blockierten den git pull auf der Linux-Testmaschine, wo Rider dieselben Dateien lokal angelegt hat. Die Projektkonvention ignoriert IDE-Dateien ohnehin (.vs/, *.user) - .idea/ fehlte dort nur, weil bisher niemand mit Rider gearbeitet hat. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
e9c9967ac2 |
Pruefplan: Durchfuehrung per SSH statt auf der VM
Claude Code direkt auf der Ubuntu-VM auszufuehren scheidet aus - es blockiert die Maschine bis zum Neustart, mehrere Reparaturversuche waren erfolglos. Der Test laeuft daher ueber SSH von der Entwicklungsmaschine aus. Die Pruefschritte bleiben unveraendert; nur fuehrt sie nicht Richard von Hand aus, sondern ich per SSH. Vermerkt ist auch, wo Richard trotzdem gebraucht wird: bei allem, was Zugangsdaten oder sudo braucht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
e14dd25979 |
Pruefplan fuer den ersten Linux-Lauf (A4a)
docs/pruefplaene/PRUEFPLAN-Linux-Betrieb.md: Schritt-fuer-Schritt-Protokoll zum Abarbeiten auf einer Test-VM, jeder Schritt mit erwartetem Ergebnis und der Angabe, was zurueckzumelden ist. Zwei Fallen vorab, die beim Vorbereiten aufgefallen sind: 1. Der Linux-Publish enthaelt appsettings.Local.json mit den echten MySQL-Zugangsdaten. Ungeprueft auf die VM kopiert, laeuft der Test gegen die PRODUKTIVdatenbank - und der MarketSyncService schreibt dort als Hintergrunddienst hinein. Der Plan legt deshalb zuerst eine eigene Testdatenbank samt eigenem Benutzer an; das Umstellen der Verbindung ist ausdruecklich als wichtigster Schritt markiert. 2. Es gibt keine automatischen Migrationen beim Start (nachgeprueft: kein Migrate()/EnsureCreated() im Code). Das Schema muss vorher stehen - fuenf DbContexts, jeder mit eigenen Migrationen, ueber die Umgebungsvariable POLYTRADER_MYSQL. Inhaltliche Schwerpunkte des Plans: - Die Hypothese, dass --headless OHNE GUI-Bibliotheken auskommt, weil BuildAvaloniaApp() dort nie aufgerufen wird und Skia damit nie geladen wird. Der Plan prueft das bewusst zuerst ohne die Pakete - das Ergebnis entscheidet, was spaeter ins Server-Grundimage muss. - Die WorkingDirectory-Falle aus D-11: server_settings.xml relativ zum Arbeitsverzeichnis, master.key relativ zur Programmdatei. Bei Abweichung legt ServerSettings.Load() kommentarlos eine neue Datei an. Wird per find ueber frisch geaenderte Dateien nachgewiesen. - SIGTERM-Shutdown gegen TimeoutStopSec=45 gemessen, Restart=on-failure per pkill -9 gegengetestet. - T2 (TerminalLogger stempelt DateTime.Now statt AppTimeZone) wird auf einer UTC-VM erstmals nachweisbar statt nur behauptet. - Logrotate mit copytruncate, weil die App die Logdatei offen haelt. - Master-Key als Umgebungsvariable im Dienst: erster echter Lauf von FilePermissions unter Linux-Rechten. Am Ende eine Liste der zehn zurueckzumeldenden Ausgaben und die Befehle zum Aufraeumen der VM. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
636713b573 |
Roadmap: CI-Runner pausiert, Linux-Test von der Zielland-Abnahme getrennt
A2 (CI-Runner) auf pausiert: auf der Gitea-Maschine ist derzeit keine Leistung fuer einen weiteren Container frei (Entscheidung Richard). Der Workflow bleibt liegen und ist sofort lauffaehig, sobald ein Runner da ist. A4 aufgeteilt, weil die bisherige Blockade nicht stimmte: - A4a "Linux-Betrieb auf einer Test-VM" ist NICHT durch A3 blockiert. Am Code nachgeprueft: LicenseGate ruft bei fehlender Lizenz kein Environment.Exit auf, sondern startet die Core-Shell im eingeschraenkten Modus ohne Trading-Module. Watchdog, Error-Reporting und Update-Pruefung stehen in appsettings.json ohnehin auf false. Der Linux-Betrieb ist damit ohne Deploymentcenter testbar - und Richard hat dafuer Test-VMs. - A4b "Feldtest im Zielland" bleibt blockiert (A3 + A4a). - A5 und B3 haengen jetzt praeziser an A4b statt an "A4". Das ist mehr als Umsortieren: Die Anwendung ist noch nie auf Linux GELAUFEN - verifiziert war bisher nur, dass sie sich publishen laesst. Das ist die groesste ungetestete Flaeche im Projekt, und sie ist ab sofort adressierbar. A4a listet konkret, was zu pruefen ist: native Abhaengigkeiten von SkiaSharp/HarfBuzz, DB-Verhalten mit und ohne erreichbare MySQL, die WorkingDirectory-Falle aus D-11 (server_settings.xml relativ zum Arbeitsverzeichnis, master.key relativ zur Programmdatei - bei Abweichung legt ServerSettings.Load() kommentarlos eine neue Datei an), SIGTERM-Shutdown, Logrotate und der Master-Key als Umgebungsvariable unter Linux-Rechten. Nebenbei wird dort T2 nachweisbar: der TerminalLogger stempelt mit DateTime.Now statt AppTimeZone - auf einer UTC-VM mit Anzeigezone Europe/Berlin muessen die Logdatei-Grenzen sichtbar von der angezeigten Uhrzeit abweichen. Bisher ist das ein theoretischer Befund. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
6218a04fe4 |
Eine Roadmap statt fuenfzehn Plandokumente; Altbestand ins Archiv
Der Status des Projekts stand verstreut in elf Umsetzungsplaenen, drei Konzepten, der Linux-Analyse und dem Projektstand - teils widersprechend, teils wochenlang veraltet. Ab jetzt gibt es genau eine Statusquelle. docs/ROADMAP.md (neu): - Alle Vorhaben in vier Stufen A bis D, plus technische Schuld und Verlauf. Die Stufen sind eine Reihenfolge, keine Termine: jede schafft die Voraussetzung fuer die naechste. - Statuszeichen: erledigt / offen / blockiert (mit Ursache) / bewusst zurueckgestellt / Idee, nicht beschlossen. Damit ist das, was wir NICHT bauen wollen, sichtbar vorgehalten statt unauffindbar in einem Plan zu schlummern. - Inhaltlich getragen, nicht nur verlinkt: je Vorhaben Ziel, Phasen, Akzeptanzkriterien, offene Entscheidungen und Leitplanken aus den Quelldokumenten. - Sichtbar gemacht, was vorher zwischen den Dokumenten verborgen lag: CopyTrading Phase 1 ist der Engpass der gesamten Roadmap (MarketMaking und BundleArbitrage haben harte Voraussetzungen darauf), und die Sniper-Metriken aus Phase 3.2 sind ein Spezialfall des StrategieDrift-Fingerprints - zusammen bauen statt doppelt. Archiv (docs/archiv/): - 15 Dokumente verschoben (11 Umsetzungsplaene, 3 Konzepte, ANALYSE-Linux-Portierung). Sie bleiben die Bauanleitungen mit Code-Bezuegen, Risikotabellen und Begruendungen - eingefroren ist nur ihr Status. - archiv/README.md ordnet jedes Dokument seinem Roadmap-Punkt zu. Verweise nachgezogen - der eigentliche Aufwand: - 25 Markdown-Links repariert. 15 davon verschiebungsbedingt (eine Ebene tiefer), der Rest war schon vorher falsch: die Ideensammlung verlinkte Quellcode relativ zum Repo-Wurzelverzeichnis statt zu docs/. - 12 Dateien ausserhalb von docs/ verwiesen in Kommentaren auf die Plaene (csproj, props, setup.json, sechs Quelldateien) - alle auf archiv/ umgebogen. - Verweise auf Dateien, die der Fruehjahrsputz geloescht hat (Ui/, Program.cs, WindowMenuBar), zu Klartext entschaerft statt tote Links zu lassen. - Gegenprobe: 85 Links geprueft, 0 kaputt. Build gruen, 476 Tests gruen. PROJEKTSTAND.md entdoppelt: Abschnitt "Offen" verweist jetzt auf die Roadmap. Arbeitsteilung ist damit klar - Projektstand sagt was IST, Roadmap was KOMMT. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
5507db3e32 |
CI fuer Gitea Actions: Build und Tests auf Linux plus Waechter gegen Rueckfaelle
Die Plattformneutralitaet war nach dem WinForms-Ausbau eine Momentaufnahme: eine einzige net10.0-windows-Zeile oder ein "using System.Drawing" genuegt, und der Linux-Build ist kaputt, ohne dass es auf einer Windows-Maschine auffaellt - dort baut es weiter. Genau das faengt die CI ab, und zwar auf Linux. .gitea/workflows/ci.yml, zwei Jobs auf ubuntu-latest: - build-test: restore, build, die 476 Tests (brauchen keine DB, laufen gegen EF-InMemory), Linux-Publish. Der Publish ist kein Selbstzweck - dort faellt auf, wenn ein Paket doch windows-only ist. Anschliessend wird geprueft, dass die Executable, appsettings.json, setup.json und libSkiaSharp.so wirklich im Ergebnis liegen. - guard: keine windows-TFMs, kein UseWindowsForms/UseWPF, keine windows-only using-Direktiven, keine versionierten Secret-Dateien, keine anfaelligen Pakete. Alle Waechter sind in beide Richtungen gegengeprueft: sie schlagen bei simulierten Regressionen an (windows-TFM, UseWindowsForms, using System.Drawing, getrackte packager.config.json samt dc_sub_-Token, Newtonsoft 11.0.2) und schweigen beim Ist-Zustand. Die Namespace-Pruefung trifft bewusst nur echte using-Direktiven: im Bestand steht an vielen Stellen erklaert, WARUM System.Drawing nicht verwendet wird, und das darf keinen Fehlalarm ausloesen. Der Schwachstellen-Check ist Punkt 1 der wiederkehrenden Audit-Checkliste aus dem Sicherheitskonzept - laeuft ab jetzt bei jedem Push statt quartalsweise von Hand. Er wuerde zum Beispiel anschlagen, wenn der Newtonsoft-Pin im Core faellt. Bewusst kein -warnaserror: die 15 vorhandenen Warnungen muessten erst weg, sonst ist die CI ab dem ersten Tag rot und wird ignoriert. WICHTIG - die CI laeuft noch nicht: auf der Gitea-Instanz ist kein Actions-Runner registriert (auf Repo-, Benutzer- und Instanzebene geprueft, ueberall 0). has_actions ist true, es fehlt nur der Runner. Einrichtung Schritt fuer Schritt in docs/LEITFADEN-CI.md Abschnitt 3. .gitattributes neu: erzwingt LF fuer .yml/.sh/.service. Entwickelt wird mit autocrlf=true auf Windows, ausgefuehrt auf Linux - ein Shell-Skript mit CRLF scheitert dort mit irrefuehrenden Meldungen. Bisher gab es keine .gitattributes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
1fd3671b42 |
Projektstand dokumentiert; Modularisierungsplan auf den Iststand nachgezogen
docs/PROJEKTSTAND.md neu: Einstiegsdokument mit Gesamtueberblick - Architektur, Modul-Stand, was abgeschlossen ist und was offen. Alle Angaben am Code nachgeprueft, nicht aus den Plandokumenten uebernommen. Die offenen Punkte sind danach getrennt, ob sie am Schreibtisch erledigt werden koennen oder echtes Geld/den Zielserver brauchen - das war vorher nirgends zusammengefasst. Modularisierungsplan korrigiert: Die Phasen 3 bis 6 standen auf "IN ARBEIT" beziehungsweise offen, obwohl die Arbeit seit Wochen getan war. Nachgeprueft und abgehakt sind unter anderem: - Phase 5: alle Modul-Services liegen im Modulprojekt, frm_main ist weg, alle vier Module implementieren IPolyTraderModule - Phase 6: komplett - kein MongoDB.Driver/LiteDB mehr in irgendeiner csproj - Phase 7 teilweise: 476 Tests, keine leeren catch-Bloecke mehr, Secrets-Verschluesselung umgesetzt (AES-GCM statt DPAPI, da DPAPI Windows-only ist und die Linux-Portierung blockiert haette) Offen bleiben aus Phase 7 nur God-Methoden und die TerminalLogger-Umstellung. Beim Nachpruefen aufgefallen: Accounting A-3 (US-Steuerschicht, Form 8949) ist entgegen der bisherigen Annahme nicht gebaut - es gibt keinen UsTaxEngine. A-2 und A-4 dagegen sind da. Im Projektstand vermerkt. docs/README.md verweist jetzt auf den Projektstand und fuehrt die bisher fehlenden Ordner sicherheit/ und den Deploymentcenter-Plan auf. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
bf8048b82a |
Fruehjahrsputz: WinForms ausgebaut (P11/L5), LicenseLabrador abgeloest (D-6)
Das Repo enthaelt ab jetzt ausschliesslich plattformneutralen Code. Build gruen (0 Fehler), 476 Tests gruen, Linux-Publish der Avalonia-App verifiziert. Rueckfallebene ist der Tag winforms-final, der jetzt auch auf dem Server liegt. WinForms endgueltig ausgebaut (P11/L5): - PolyTrader.App.csproj aus PolyTraderSharp.sln genommen und geloescht - Ui/, Models/, Licensing/, services/, Properties/, Resources/icons/, Program.cs, favicon.ico entfernt - rund 4.500 LOC generierter Designer-Code - Root-appsettings.json entfernt: exaktes Duplikat der Avalonia-Kopie, die die App tatsaechlich liest. Zwei Dateien mit gleichem Inhalt laufen frueher oder spaeter auseinander. - Kein net10.0-windows mehr im Repo; Build-Warnungen von 23 auf 15 gesunken (die CS0169 aus den Designer-Resten sind weg) PNG-Symbole gerettet statt geloescht: Die Avalonia-App band sie per ..\..\Resources\*.png aus dem Repo-Root ein und haette sie mitverloren. Sie liegen jetzt in src/PolyTrader.App.Avalonia/Assets/, wo sie hingehoeren. Der avares-Pfad "Assets/<datei>.png" bleibt unveraendert - in der gebauten Assembly nachgeprueft. LicenseLabrador abgeloest (D-6): - LicenseLabrador.Client aus lib/nuget entfernt, Quellen-Mapping in NuGet.Config auf Deploymentcenter.* reduziert, lib/nuget/README.md neu - Bewusste Abweichung vom Plan: die Watchdog*-Felder in ServerSettings bleiben. D-1 hat sie auf die Deploymentcenter-API umgewidmet statt sie zu ersetzen; sie werden aktiv benutzt. Die Planzeile stammte aus der Zeit davor. Weitere Altlasten: - agentspace/ (30 Dateien: WinForms-Designer-Patcher, fix_mongo.py nach der MySQL-Migration, tmp/test/scratch-Skripte) entfernt - Ideen-fuer-Mittwoch.txt entfernt - Inhalt ist laengst umgesetzt - tote .gitignore-Regel fuer agentspace/antigravity/ entfernt - lokal entfernt (nicht versioniert): MongoDB/-Exporte, data.db, .bak-Datei Dokumentation nachgezogen: - ANALYSE-Linux-Portierung.md auf Revision 6, P11/L5 als erledigt - LEITFADEN: Abschnitt B vollstaendig aufgeloest, A5 prueft ab jetzt gegen einen Worktree des Tags statt gegen den Arbeitsbaum - UMSETZUNGSPLAN-Watchdog-LicenseLabrador-Integration.md als ABGELOEST gekennzeichnet, D-6 im Deploymentcenter-Plan auf den Iststand gezogen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
dd8da3fd3f |
Arbeitsstand gesichert: Deploymentcenter-Integration (D-0 bis D-5) und Einfenster-Shell
Sicherungscommit vor dem Aufraeumen des Repos, damit nachvollziehbar bleibt, welcher Stand vor der Bereinigung galt. Build gruen, 476 Tests gruen. Zwei Straenge, die sich ueber .csproj, Program.cs und appsettings.json ueberschneiden und darum gemeinsam abgelegt werden: Deploymentcenter-Integration (P3c, Plan D-0 bis D-5 code-seitig fertig): - Deploymentcenter.Client 2.5.0 als lokales Paket, Source-Mapping erweitert - DeploymentcenterOptions, DeploymentcenterErrorReporter, LicenseGate/LicenseCli - WatchdogHeartbeatService auf die Deploymentcenter-API umgestellt (version, os, checks, metrics, status stopped) - Security: MasterKeyResolver, SecretRedactor, FilePermissions - Directory.Build.props mit zentraler Version 0.1.0 (Packager-Versionsdisziplin) - deploy/: Packager-Vorlage und systemd-Unit; echte Zugangsdaten bleiben ueber .gitignore aussen vor - setup.json fuer die Erstinstallation - UMSETZUNGSPLAN-Deploymentcenter-Integration.md; ANALYSE-Linux-Portierung.md verweist auf den neuen Plan Einfenster-Shell (UI-Redesign): - ShellWindow + ShellNavModel als Seitenleisten-Shell - WindowMenuBar und WindowMenuModel entfallen - Modul- und Kernfenster auf die Shell-Einbettung angepasst Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |