28b3aedec7017e5cec2dde3bd2a155a093316062
10
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |
||
|
|
c5f0b1d188 |
Docs: Konzepte/Plaene in docs/ mit Typ-Unterordnern buendeln
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> |