Commit Graph
8 Commits
Author SHA1 Message Date
Richard 10f928eb4e Paralleles WebGUI mit Kestrel, Token-Sicherung und SSE-Logs implementiert 2026-09-07 21:55:51 +02:00
RichardandClaude Opus 5 53231d62bc Testen laeuft jetzt ueber das Deploymentcenter; Befunde in den Bugtracker
CI / Build & Tests (Linux) (push) Canceled after 0s
CI / Plattformneutralität & Hygiene (push) Canceled after 0s
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>
2026-08-28 21:06:34 +02:00
RichardandClaude Opus 5 9b2294cb4c Testanleitung: eigenes X-Display je Projekt fuer Parallelbetrieb
CI / Build & Tests (Linux) (push) Canceled after 0s
CI / Plattformneutralität & Hygiene (push) Canceled after 0s
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>
2026-08-27 20:49:28 +02:00
RichardandClaude Opus 5 83d49aa106 A4a vollstaendig: PolyTrader laeuft als Dienst auf Linux; Testumgebung dokumentiert
CI / Build & Tests (Linux) (push) Canceled after 0s
CI / Plattformneutralität & Hygiene (push) Canceled after 0s
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>
2026-08-26 22:09:09 +02:00
RichardandClaude Opus 5 4e9d7259c0 Befundbericht zum ersten Linux-Lauf
CI / Build & Tests (Linux) (push) Canceled after 0s
CI / Plattformneutralität & Hygiene (push) Canceled after 0s
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>
2026-08-26 21:48:59 +02:00
RichardandClaude Opus 5 e14dd25979 Pruefplan fuer den ersten Linux-Lauf (A4a)
CI / Build & Tests (Linux) (push) Canceled after 0s
CI / Plattformneutralität & Hygiene (push) Canceled after 0s
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>
2026-08-23 22:33:00 +02:00
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>
2026-08-23 21:07:08 +02:00
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>
2026-08-23 18:56:50 +02:00