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>

docs/ROADMAP.md

@@ -166,8 +166,23 @@ unbehandelter Ausnahme ab, statt zu sagen, was fehlt — im Dienstbetrieb hätte
 Neustartschleife im Zehn-Sekunden-Takt ergeben. Jetzt verständlicher Abbruch mit Exitcode 78
 (`EX_CONFIG`) und `RestartPreventExitStatus=78` in der systemd-Unit.
 
-🔒 **Rest blockiert:** systemd, Oberfläche, SIGTERM-Verhalten und der Zeitzonen-Nachweis (T2)
-brauchen eine **Testdatenbank** (auf der VM läuft keine MySQL) und **`sudo`**.
+✅ **Vollständig durchgearbeitet.** MariaDB 11.8.6 auf der Test-VM, alle fünf Migrationen durch
+(21 Tabellen), Betrieb mit Datenbank bestätigt — die Anwendung hat **100 echte Märkte von der
+Polymarket-API geholt und geschrieben**. Als systemd-Dienst: `active`, Shutdown in 0,08 s ohne
+`SIGKILL`, Neustart nach Absturz greift, und der neue Exit-78-Schutz verhindert nachweislich die
+Neustartschleife bei Konfigurationsfehlern. Die D-11-Falle ist **kein Problem** (gezielt geprüft:
+keine zweite `server_settings.xml`). Logrotate läuft. Alle neun Views konstruieren fehlerfrei.
+
+**T2 ist jetzt belegt statt behauptet:** Unter UTC meldet die Anwendung „Anzeige-Zeitzone:
+Europe/Berlin" und stempelt in derselben Zeile mit `20:04` statt `22:04`.
+
+⬜ **Einziger Rest: Sichtprüfung der Oberfläche** — braucht jemanden am Bildschirm der VM
+(Schriftrendering, Spaltenbreiten, Dunkelmodus unter GTK). Damit fällt dieser Rest mit **A1**
+zusammen.
+
+**Testumgebung dauerhaft nutzbar:** [TESTUMGEBUNG-Linux-VM.md](./TESTUMGEBUNG-Linux-VM.md)
+beschreibt Zugang und Konventionen für **alle** Projekte (eigene Datenbank je Projekt, eigenes
+Dienstkonto, Aufräumregeln).
 
 ### A4b 🔒 Feldtest im Zielland
 

docs/TESTUMGEBUNG-Linux-VM.md

@@ -0,0 +1,245 @@
+# Linux-Testumgebung (gemeinsam genutzte VM)
+
+**Stand: 26.08.2026** · Eingerichtet beim ersten Linux-Lauf von PolyTrader (Roadmap A4a).
+
+> **Diese Anleitung gilt projektübergreifend.** Sie richtet sich an alle Agenten und Entwickler,
+> die auf der VM testen — nicht nur an PolyTrader. Die maßgebliche Fassung liegt auf der Maschine
+> selbst unter **`~/TESTUMGEBUNG.md`**; dieses Dokument im PolyTrader-Repo ist die versionierte
+> Kopie. Wer etwas an der Umgebung ändert, zieht **beide** nach.
+
+---
+
+## 1. Was diese Maschine ist
+
+Eine Ubuntu-Desktop-VM zum **Testen** — nicht für Produktivbetrieb, nicht für echte Zugangsdaten,
+nicht für Geld bewegende Läufe.
+
+| | |
+|---|---|
+| System | Ubuntu 26.04 LTS, Kernel 7.0, x86_64 |
+| Ausstattung | 31 GB RAM, 5 CPUs, ~33 GB freier Plattenplatz |
+| Erreichbar | `192.168.40.48` über einen WireGuard-Tunnel |
+| Benutzer | `richard` |
+| Besonderheit | **Desktop-Umgebung vorhanden** — grafische Anwendungen sind testbar, nicht nur Dienste |
+
+**Warum eine Desktop-VM?** Weil sich damit beides prüfen lässt: der kopflose Serverbetrieb
+(systemd) *und* die grafische Oberfläche auf der Zielplattform.
+
+---
+
+## 2. Zugang einrichten
+
+Der Zugang läuft über **SSH-Schlüssel**. Passwort-Anmeldung wird nicht verwendet — Agenten geben
+grundsätzlich keine Passwörter ein.
+
+### 2.1 Schlüssel erzeugen (auf dem eigenen Rechner)
+
+```bash
+ssh-keygen -t ed25519 -f ~/.ssh/testvm_<projekt> -N "" -C "<projekt>@testvm"
+```
+
+Ein **eigener Schlüssel je Projekt** — dann lässt sich einzelnen Projekten der Zugang entziehen,
+ohne alle anderen auszusperren.
+
+### 2.2 Öffentlichen Schlüssel hinterlegen
+
+Der Inhalt von `~/.ssh/testvm_<projekt>.pub` wird auf der VM in `~/.ssh/authorized_keys`
+eingetragen. **Das muss ein Mensch tun** (einmalig, mit Passwort). Direkt auf der VM:
+
+```bash
+mkdir -p ~/.ssh && chmod 700 ~/.ssh && echo '<INHALT DER .pub-DATEI>' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
+```
+
+### 2.3 SSH-Konfiguration (auf dem eigenen Rechner)
+
+```
+Host testvm
+    HostName 192.168.40.48
+    User richard
+    IdentityFile ~/.ssh/testvm_<projekt>
+    IdentitiesOnly yes
+    ServerAliveInterval 30
+    ServerAliveCountMax 4
+```
+
+⚠️ **Kein `ControlMaster`/`ControlPath` eintragen, wenn der Client unter Windows läuft** —
+Windows-OpenSSH unterstützt Verbindungs-Multiplexing nicht und scheitert mit
+„Failed to connect to new control master". Stattdessen mehrere Prüfschritte pro Aufruf bündeln.
+
+Test: `ssh testvm "hostname"`
+
+---
+
+## 3. Was installiert ist
+
+| Werkzeug | Version | Anmerkung |
+|---|---|---|
+| .NET SDK | 10.0.111 (Runtime 10.0.11) | SDK, nicht nur Runtime — auf der VM kann gebaut werden |
+| MariaDB | 11.8.6 | Dienst `mariadb`, lauscht auf `localhost:3306` |
+| Git | 2.53.0 | |
+| Xvfb | vorhanden | Virtueller Framebuffer für GUI-Tests ohne Bildschirm |
+| JetBrains Rider | vorhanden | |
+| Docker | **nicht** installiert | |
+| Node.js | **nicht** installiert | |
+
+**Nicht vorhandene Werkzeuge dürfen installiert werden** — aber bitte in der Belegungsliste
+(Abschnitt 6) vermerken, damit andere wissen, was sich geändert hat.
+
+---
+
+## 4. Konventionen für mehrere Projekte
+
+Die Maschine wird von mehreren Projekten geteilt. Diese Regeln verhindern, dass sich Tests
+gegenseitig zerstören:
+
+### 4.1 Datenbanken — je Projekt eine eigene
+
+**Niemals** eine fremde Datenbank mitbenutzen und **niemals** eine Produktivdatenbank verbinden.
+
+```bash
+# Passwort erzeugen und ablegen (nur für den Besitzer lesbar)
+PW=$(openssl rand -base64 18 | tr -d "/+=" | head -c 20)
+echo "$PW" > ~/.<projekt>_test_dbpw && chmod 600 ~/.<projekt>_test_dbpw
+
+sudo mariadb -e "CREATE DATABASE IF NOT EXISTS <projekt>_test CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
+                 CREATE USER IF NOT EXISTS '<projekt>_test'@'localhost' IDENTIFIED BY '$PW';
+                 GRANT ALL PRIVILEGES ON <projekt>_test.* TO '<projekt>_test'@'localhost';
+                 FLUSH PRIVILEGES;"
+```
+
+| Was | Schema | Beispiel |
+|---|---|---|
+| Datenbank | `<projekt>_test` | `polytrader_test` |
+| Benutzer | `<projekt>_test`@`localhost` | `polytrader_test` |
+| Passwortdatei | `~/.<projekt>_test_dbpw` (Rechte 600) | |
+
+Die Rechte enden **an der eigenen Datenbank** — `GRANT ALL ON <projekt>_test.*`, nie global.
+
+### 4.2 Verzeichnisse
+
+| Zweck | Ort |
+|---|---|
+| Quellcode | `~/RiderProjects/<projekt>` |
+| Publish/Testlauf im Benutzerkontext | `~/<projekt>-test` |
+| Installation als Dienst | `/opt/<projekt>` |
+
+### 4.3 systemd-Dienste
+
+Unit-Name = Projektname: `<projekt>.service`. Eigenes Dienstkonto je Projekt:
+
+```bash
+sudo useradd --system --home-dir /opt/<projekt> --shell /usr/sbin/nologin <projekt>
+```
+
+Nach dem Test **abschalten** (Abschnitt 7) — sonst laufen irgendwann fünf Dienste, die niemand
+mehr zuordnen kann, und der nächste Test misst gegen fremde Last.
+
+### 4.4 Ports
+
+Vor dem Belegen prüfen: `ss -tlnp`. Belegte Ports stehen in Abschnitt 6. Wer einen Port dauerhaft
+belegt, trägt ihn dort ein.
+
+### 4.5 Erhöhte Rechte
+
+`sudo` verlangt normalerweise ein Passwort. Für Testläufe kann es befristet freigeschaltet werden
+(**ein Mensch, einmalig**):
+
+```bash
+echo "richard ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/99-testing && sudo chmod 440 /etc/sudoers.d/99-testing
+```
+
+**Nach Abschluss wieder entfernen:**
+
+```bash
+sudo rm /etc/sudoers.d/99-testing
+```
+
+Das hebt den Schutz für das Konto vollständig auf — vertretbar auf einer Test-VM hinter VPN, aber
+nicht dauerhaft und niemals auf einer Produktivmaschine.
+
+### 4.6 GUI-Anwendungen ohne Bildschirm testen
+
+Braucht eine Anwendung X11, scheitert sie über SSH mit `XOpenDisplay failed`. Lösung:
+
+```bash
+xvfb-run -a ./MeineAnwendung --irgendein-schalter
+```
+
+Für einen Test **mit sichtbarem Fenster** muss jemand am Desktop der VM sitzen (oder RDP nutzen,
+Port 3389 ist offen) und Bildschirmfotos machen.
+
+---
+
+## 5. Was hier nicht passieren darf
+
+1. **Keine Produktivdatenbank verbinden.** Hintergrunddienste schreiben oft ungefragt — bei
+   PolyTrader etwa synchronisiert der `MarketSyncService` selbständig Marktdaten.
+2. **Keine echten Handels-/Zugangsdaten hinterlegen.** Keine privaten Schlüssel, keine
+   Live-API-Zugänge, keine Lizenzschlüssel für Produktivsysteme.
+3. **Keine fremden Projektverzeichnisse oder Datenbanken anfassen.**
+4. **Nichts Dauerhaftes hinterlassen**, was nicht in Abschnitt 6 steht.
+
+---
+
+## 6. Belegung (bei Änderungen fortschreiben)
+
+**Datenbanken**
+
+| Datenbank | Benutzer | Projekt | seit |
+|---|---|---|---|
+| `polytrader_test` | `polytrader_test`@localhost | PolyTrader | 26.08.2026 |
+
+**Dienste**
+
+| Unit | Konto | Verzeichnis | Projekt | seit |
+|---|---|---|---|---|
+| `polytrader.service` | `polytrader` | `/opt/polytrader` | PolyTrader | 26.08.2026 |
+
+**Ports** (Stand 26.08.2026)
+
+| Port | Belegt durch |
+|---|---|
+| 22 | SSH |
+| 3306 | MariaDB (nur localhost) |
+| 3389 | RDP |
+| 5000 | vorhandener Dienst (nur IPv6-localhost) |
+| 631 | CUPS |
+
+**Nachträglich installiert:** MariaDB 11.8.6, Xvfb (beide am 26.08.2026 für PolyTrader).
+
+---
+
+## 7. Aufräumen nach dem Test
+
+```bash
+# Dienst abschalten und entfernen
+sudo systemctl disable --now <projekt>
+sudo rm -f /etc/systemd/system/<projekt>.service /etc/logrotate.d/<projekt>
+sudo systemctl daemon-reload
+
+# Dateien
+sudo rm -rf /opt/<projekt> ~/<projekt>-test
+sudo userdel <projekt>
+
+# Datenbank (nur wenn nicht mehr gebraucht)
+sudo mariadb -e "DROP DATABASE <projekt>_test; DROP USER '<projekt>_test'@'localhost';"
+rm -f ~/.<projekt>_test_dbpw
+
+# sudo-Freigabe zurücknehmen
+sudo rm -f /etc/sudoers.d/99-testing
+```
+
+Danach Abschnitt 6 nachziehen.
+
+---
+
+## 8. Bekannte Einschränkungen
+
+- **Claude Code lässt sich auf dieser VM nicht betreiben.** Es blockiert die Maschine bis zum
+  Neustart; mehrere Reparaturversuche waren erfolglos, es wird auf ein Update gewartet. Agenten
+  arbeiten deshalb **über SSH von außen**. (Speichermangel ist **nicht** die Ursache — die
+  Maschine hat 31 GB, davon 25 GB frei.)
+- **Verbindungs-Multiplexing funktioniert nicht mit Windows-OpenSSH** (siehe 2.3).
+- **Die Systemzeitzone ist Testgegenstand.** Für realistische Servertests wird sie zeitweise auf
+  UTC gestellt (`sudo timedatectl set-timezone UTC`). Wer sie ändert, stellt sie danach zurück —
+  Standard hier ist `Europe/Berlin`.

docs/pruefplaene/BEFUND-Linux-Betrieb-2026-08-26.md

@@ -7,9 +7,10 @@ Roadmap: [A4a](../ROADMAP.md)
 Zeitzone `Europe/Berlin`. .NET SDK 10.0.111 mit Runtime 10.0.11 bereits vorhanden.
 Zugriff über SSH (WireGuard, Schlüssel-Authentifizierung).
 
-> **Kernaussage: PolyTrader läuft auf Linux.** Build, Tests, Publish und Start funktionieren.
-> Ein echter Fehler wurde gefunden und behoben. Der Durchgang ist **nicht vollständig** — für
-> systemd-Betrieb, Oberfläche und Zeitzonen-Nachweis fehlen eine Datenbank und `sudo`.
+> **Kernaussage: PolyTrader läuft auf Linux — als Dienst, mit Datenbank, mit echten Marktdaten.**
+> Der Prüfplan ist **vollständig abgearbeitet** (Nachtrag ab Abschnitt 5). Drei Fehler gefunden,
+> einer davon behoben. Offen bleibt nur die Sichtprüfung der Oberfläche, die einen Menschen am
+> Bildschirm braucht.
 
 ---
 
@@ -99,6 +100,11 @@ Modus überhaupt nutzen soll — deshalb hier nur vermerkt, nicht gebaut.
 
 ## 3. Nicht geprüft — und warum
 
+> **Überholt.** Dieser Abschnitt beschreibt den Zwischenstand, bevor MariaDB und `sudo`
+> verfügbar waren. Alles hier Aufgeführte wurde im **Nachtrag ab Abschnitt 5** nachgeholt —
+> bis auf die Sichtprüfung der Oberfläche. Der Abschnitt bleibt als Verlaufsspur stehen.
+
+
 | Prüfpunkt | Fehlt |
 |---|---|
 | Betrieb **mit** Datenbank, Migrationen | Auf der VM läuft **keine** MySQL; der Datenbankhost ist nicht bekannt |
@@ -128,3 +134,126 @@ Modus überhaupt nutzen soll — deshalb hier nur vermerkt, nicht gebaut.
   Prüfschritte pro Aufruf gebündelt.
 - **Speicher ist reichlich vorhanden** (31 GB, davon 25 GB frei). Die Vermutung, der
   Claude-Desktop-Absturz auf der VM könnte an Speichermangel liegen, ist damit **widerlegt**.
+
+
+---
+
+# Nachtrag: vollständiger Durchgang
+
+Nach Einrichtung von MariaDB und befristetem passwortlosem `sudo` wurde der Rest des Prüfplans
+abgearbeitet.
+
+## 5. Betrieb mit Datenbank
+
+| Prüfpunkt | Ergebnis |
+|---|---|
+| **MariaDB** | 11.8.6 installiert — **genau die Version**, die in `DatabaseServerVersion` gepinnt ist. Datenbank `polytrader_test` mit eigenem Benutzer angelegt |
+| **Migrationen** | Alle fünf DbContexts (Core, CopyTrading, ResolutionFarming, Supervisor, Accounting) melden „Done.". **21 Tabellen** mit den Präfixen `core_`, `ct_`/`mod_copytrading_`, `rf_`, `acc_` |
+| **Start mit Datenbank** | Läuft vollständig durch: Core-Hydration abgeschlossen, `MarketSyncService` gestartet |
+| **Echter Datenverkehr** | **100 Märkte von der Polymarket-API geholt und geschrieben**, beim zweiten Lauf 100 aktualisiert. HTTP, TLS, JSON-Verarbeitung und Datenbankzugriff funktionieren unter Linux |
+
+> Das ist der eigentliche Beweis: Die Anwendung *arbeitet* auf Linux, sie startet nicht nur.
+
+## 6. Dienstbetrieb (systemd)
+
+| Prüfpunkt | Ergebnis |
+|---|---|
+| **Dienst** | `active (running)`, 71,6 MB Speicher, 20 Tasks. Startet automatisch mit dem System |
+| **`WorkingDirectory`-Falle (D-11)** | ✅ **Kein Problem.** Gezielt geprüft: `server_settings.xml` in `/opt/polytrader` mit Testzeitzone `America/New_York` angelegt — die Anwendung meldete genau diese Zone. Eine `find`-Suche über das gesamte Dateisystem fand **keine zweite** Datei. Die Unit setzt `WorkingDirectory` korrekt |
+| **Nebenbefund** | `server_settings.xml` wird beim Start **nicht angelegt** — erst beim Speichern von Einstellungen. Ein frisch installierter Dienst läuft also mit Standardwerten und ohne Konfigurationsdatei |
+| **Shutdown (SIGTERM)** | ✅ **0,08 Sekunden** — weit unter `TimeoutStopSec=45`. „Deactivated successfully", **kein `SIGKILL`** im gesamten Journal |
+| **Neustart nach Absturz** | ✅ `kill -9` auf den Hauptprozess → `Restart=on-failure` greift, neue PID nach ~10 s |
+| **Neustartschutz bei Konfigurationsfehler** | ✅ Verbindung entfernt → Status `failed`, **Exit-Code 78**, systemd meldet ihn als `78/CONFIG`. **Keine Neustartschleife.** Die verständliche Meldung steht im Journal. Damit wirkt der Fix aus B-1 im Dienstbetrieb nachweislich |
+| **Dateirechte** | `master.key` `0600`, Eigentümer `polytrader` |
+
+## 7. Logrotate
+
+Regel mit **zwei Mustern** (wegen B-2) und `copytruncate` eingerichtet. Erzwungener Lauf: alle drei
+Logdateien rotiert und komprimiert, Originale auf 0 Bytes gesetzt, **Dienst schreibt ohne
+Unterbrechung weiter**.
+
+`copytruncate` ist hier zwingend: Die Anwendung hält die Logdatei offen und bekommt ein Umbenennen
+nicht mit — sie würde sonst in die rotierte Datei weiterschreiben.
+
+## 8. Zeitzonen-Befund T2 — **belegt**
+
+Bisher nur behauptet, jetzt bewiesen. Systemzeitzone auf UTC gestellt, App-Anzeigezone auf
+`Europe/Berlin`:
+
+```
+System UTC : 2026-08-26 20:04:51
+Berlin     : 2026-08-26 22:04:51
+
+Logzeile:   [20:04:39] [Info] Anzeige-Zeitzone: Europe/Berlin
+JSON-Zeile: {"ts":"2026-08-26T20:04:39.398+00:00", …}
+```
+
+**Der Widerspruch steht in derselben Zeile:** Die Anwendung meldet Berlin als Anzeigezone und
+stempelt gleichzeitig mit UTC.
+
+**Betriebliche Folge:** Auf einem UTC-Server — dem Normalfall — zeigen alle Logs UTC, während die
+Oberfläche Berliner Zeit anzeigt. Wer einen Vorfall von „22:30" sucht, findet ihn unter 20:30, und
+zwischen Mitternacht und 2 Uhr sogar in der Datei des **Vortags**. Das macht Fehlersuche im
+Ernstfall unnötig schwer.
+
+**Nicht behoben** — gehört zu T2 (Umstellung auf `Microsoft.Extensions.Logging`) und ist ein
+eigener Schnitt. Die Systemzeitzone wurde nach dem Test auf `Europe/Berlin` zurückgestellt.
+
+## 9. Oberfläche unter Linux
+
+**Alle Fenster konstruieren fehlerfrei** (`--smoke-ui` unter `xvfb-run`):
+
+```
+[OK] core.start, core.dashboard, core.settings, core.jobs, core.terminal
+[OK] copytrading.main, resolutionfarming.main, supervisor.main, accounting.main
+[OK] ShellWindow konstruiert
+[OK] ShutdownConfirmWindow konstruiert
+[OK] Einstellungs-Editor: 7 Abschnitte, 17 Felder
+[OK] Farbschema „Light": alle 27 Farben vorhanden
+[OK] Farbschema „Dark": alle 27 Farben vorhanden
+```
+
+### B-4 · `--smoke-ui` braucht einen X-Server · offen
+
+Ohne Display scheitert die Konstruktionsprüfung mit `System.Exception: XOpenDisplay failed` aus
+`AvaloniaX11Platform.Initialize`. Sie ist aber als **CI-Werkzeug** gedacht, und ein Build-Server
+hat typischerweise keinen Bildschirm.
+
+**Zwei Wege:**
+
+1. **`xvfb-run -a` vorschalten** — funktioniert nachweislich (siehe oben), erfordert nur das Paket
+   `xvfb` im Build-Image. Ein Einzeiler im CI-Workflow.
+2. `Avalonia.Headless` verwenden statt des X11-Backends. Sauberer, aber eine Codeänderung.
+
+Empfehlung: Weg 1, wenn A2 (CI-Runner) wieder aufgenommen wird — dann `xvfb` ins Image und
+`--smoke-ui` als zusätzlichen Prüfschritt aufnehmen. Der Nutzen wäre erheblich: Die
+Konstruktionsprüfung deckt neun Views und beide Farbschemata ab.
+
+### Noch offen: Sichtprüfung
+
+Die Anwendung wurde **nicht mit sichtbarem Fenster** geprüft — das braucht jemanden am Bildschirm
+der VM. Schriftrendering, Spaltenbreiten und Dunkelmodus sehen unter GTK erfahrungsgemäß anders
+aus als unter Windows. Das ist der verbleibende Rest von A1 auf der Zielplattform.
+
+---
+
+## 10. Zustand der VM nach dem Durchgang
+
+**Bewusst stehen geblieben** (damit weitergetestet werden kann):
+
+- MariaDB 11.8.6 mit Datenbank `polytrader_test`
+- Dienst `polytrader.service` unter `/opt/polytrader`, aktiv
+- Logrotate-Regel `/etc/logrotate.d/polytrader`
+- Xvfb (allgemein nützlich)
+- Anleitung `~/TESTUMGEBUNG.md`
+
+**Zurückgestellt:** Systemzeitzone wieder `Europe/Berlin`.
+
+**Noch offen:** Die befristete `sudo`-Freigabe `/etc/sudoers.d/99-testing` ist **aktiv** und sollte
+entfernt werden, sobald nicht mehr getestet wird:
+
+```bash
+sudo rm /etc/sudoers.d/99-testing
+```
+
+Vollständige Aufräumbefehle: [TESTUMGEBUNG-Linux-VM.md](../TESTUMGEBUNG-Linux-VM.md) §7.