PolyTraderSharp/docs/umsetzungsplaene/UMSETZUNGSPLAN-Watchdog-LicenseLabrador-Integration.md

# Umsetzungsplan: Watchdog & LicenseLabrador in PolyTrader einbinden

> Stand: 2026-07-28 · Grundlage: Review von `J:\Softwareprojekte\WatchDog` und
> `J:\Softwareprojekte\LicenseLabrador`.
> **Reihenfolge ist bindend:** Teil A (Blocker in den Fremdprojekten) vor Teil B (Einbindung).
> Wer B ohne A baut, bindet bekannte Lücken fest in den Produktivbetrieb ein.

---

## 0. Kurzfassung der Bewertung

**LicenseLabrador (Server)** ist handwerklich gut: keine Secrets im Repo, Argon2id, CSRF in allen
Admin-Formularen, durchgängig Prepared Statements, Ed25519 über den Base64-Payload (umgeht das
Kanonikalisierungsproblem elegant), Nonce-Reflexion, Rate-Limit plus Failed-Key-Sperre, Audit-Log.
Der Server kann so bleiben. Die Schwächen liegen im **C#-Client**.

**Watchdog** ist funktional weit, hat aber Produktiv-Secrets im Git, ein hartkodiertes
Admin-Passwort und eine Autorisierung, die jeden Agent-Token wie einen Admin behandelt. Vor der
Anbindung von PolyTrader muss dort aufgeräumt werden.

Kritischster Einzelbefund für **unseren** Betrieb: die Hardware-ID von LicenseLabrador ist auf
einem Rechner mit Mullvad-VPN nicht stabil (siehe L-1). Ohne Fix sperrt PolyTrader sich selbst aus.

---

## 0a. Nachprüfung vom 29.07.2026

Beide Projekte wurden nach dem ersten Review nachgebessert. Stand jetzt:

**LicenseLabrador — integrationsbereit.** Die vier Blocker sind behoben (Änderungen liegen noch
uncommitted im Arbeitsverzeichnis, sollten also committet werden):

- **L-1 erledigt.** `HardwareId` nutzt jetzt `MachineGuid` (bzw. `/etc/machine-id`) als
  Primärquelle, `ProcessorCount` ist raus, der MAC-Fallback filtert virtuelle Adapter
  (Mullvad, WireGuard, Docker, Hyper-V, WSL) und sortiert deterministisch. Damit ändert ein
  VPN-Wechsel die Hardware-ID nicht mehr — die Selbst-Aussperrung ist vom Tisch.
- **L-2 erledigt.** Der gecachte Envelope wird gegen die lokale `hardware_id` geprüft; kopierte
  `state.dat`-Dateien werden verworfen.
- **L-3 erledigt.** `signatureTampered` liefert jetzt `TamperSuspected` statt still in die
  Offline-Kulanz zu fallen.
- **L-5 erledigt.** Das HMAC-Secret wird aus der Hardware-ID abgeleitet, und `docs/SECURITY.md`
  führt es korrekt als Laufzeit-Schutz gegen Property-Patching, nicht als kryptografische
  Sicherheit.
- Das SDK baut fehlerfrei (eine `CS8604`-Warnung in `LicenseClient.cs:47`).
- **Offen:** L-4 (gecachte Endpoints haben weiter Vorrang vor der Konfiguration, `http://` wird
  weiter akzeptiert) sowie L-6 bis L-13. L-4 entschärfen wir auf unserer Seite, indem wir
  ausschließlich `https://`-Endpoints konfigurieren — da die Antwort signaturgeprüft ist, kann ein
  untergeschobener Endpoint keine gültige Lizenz erfinden, sondern uns höchstens in die Offline-
  Kulanz drängen. Kein Blocker mehr, aber Nachtrag wert.

**Watchdog — integrationsbereit mit zwei Auflagen.** Commits `1e453f8` und `404e184` haben die
Blocker abgearbeitet; nachgeprüft am 29.07.2026:

- **Erledigt in `1e453f8`:** W-2 (Backdoor entfernt, nur noch `password_verify`), W-3 (CSRF in
  `admin.php` und `index.php`), W-4 (alle XSS-Vektoren escaped, inklusive `e.message`), **W-5**
  (Token-Scoping greift: `validateToken()` wird benutzt, `$requireAdmin()` schützt `monitor/edit`,
  `monitor/delete`, `icon/upload`), W-6 (Status-API nicht mehr offen), **W-13** (Alarm nur noch
  bei Zustandswechsel, zusätzlich 120 s Dämpfung pro Quelle und Art).
- **W-14 erledigt in `404e184`.** `Evaluator.php` setzt einen Monitor nur noch auf `up`, wenn
  `last_status === 'ok'` **und** die Metriken unauffällig sind. Zustandsmaschine
  durchgespielt: dauerhaftes `status=error` bleibt auf `error` (ein Alarm, danach Ruhe);
  Rückkehr auf `ok` erzeugt genau eine Entwarnung; Absturz → genau ein Down-Alarm;
  `down` + Rückkehr mit `status=error` → ein `hard_error`. Die Flapping-Schleife ist weg.
- **W-22 erledigt.** `escapeHtml` liegt jetzt auf Dateiebene (`index.php:630`) vor allen
  Verwendungen. Monitore ohne Metriken — unser Fall — brechen im Detail-Fenster nicht mehr ab.
- **W-23 erledigt.** `session_start()` steht am Anfang von `api.php`; der Admin-Session-Zweig
  funktioniert.
- **W-24 erledigt.** `display_errors` und Stack-Traces hängen an `WATCHDOG_DEBUG=1`; API-Fehler
  liefern sauberes JSON ohne interne Details.
- **W-1 teilweise erledigt — Auflage 1.** Aus dem getrackten `config/config.php` sind die echten
  Werte raus (Platzhalter), `config.example.php` ist ergänzt, `config.local.php` war schon
  gitignoriert und die Merge-Logik ist intakt. **Aber die Secrets stehen weiter in der
  Git-History:** `git show 1e453f8:config/config.php` liefert DB-Passwort, `shared_key` und
  `setup_token` im Klartext. Das lässt sich durch Bearbeiten von HEAD nicht heilen — **alle drei
  müssen rotiert werden** (das FTP-Passwort aus `deploy_config.json` gleich mit, es ist dasselbe).
- **Auflage 2 — W-16 (UTC vs. `NOW()`).** Unverändert: `cli/tick.php:39,44,106`,
  `ProxmoxPoller.php:56,117` und `admin.php:115,157` mischen UTC-Strings aus PHP mit dem
  `NOW()` der DB-Session. Steht die MySQL-Zeitzone nicht auf UTC, verschieben sich
  Job-Fälligkeit, Lock-Leases und der Log-Cleanup um den Offset. Entweder in der DB-Session
  `SET time_zone = '+00:00'` setzen oder `NOW()` durchgängig durch UTC-Parameter ersetzen.
  Nicht integrationsblockend, aber vor dem Produktivbetrieb zu klären.
- **Weiterhin offen, ohne Einfluss auf unsere Anbindung:** W-11 (`api.php:157` gibt im eigenen
  `catch` weiter `$t->getMessage()` heraus — der neue Handler in `Autoload.php` macht es richtig,
  wird hier aber umgangen), W-15 (`intervalSeconds` der PS-/Bash-Agents wird weiter ignoriert;
  unser C#-Client sendet `interval` und ist korrekt), **W-17** (`self_ping` ist weiter ein
  `echo`-Stub — es gibt also keinen Alarm, wenn der Watchdog selbst stirbt), W-7 bis W-10, W-12,
  W-18 bis W-21.

**Konsequenz für die Reihenfolge:** Schritt 1 und 2 sind erledigt. **Teil B kann vollständig
beginnen** — B.1 bis B.3 (Heartbeat) und B.4/B.5 (Lizenz) sind nicht mehr blockiert. Parallel
abzuarbeiten: Secrets rotieren, W-16, W-17.

---

## Teil A — Blocker in den Fremdprojekten

### A.1 Watchdog — Sicherheit

| # | Befund | Datei | Maßnahme |
|---|---|---|---|
| W-1 | DB-Passwort, `shared_key`, `setup_token` als Defaults im **getrackten** `config/config.php` (auch in der Git-History) | `config/config.php:15,19,20` | Datei nach `config.php.example` umbenennen (Muster von LicenseLabrador), aus dem Index nehmen, **alle drei Secrets rotieren** |
| W-2 | Hartkodiertes Admin-Passwort, vor der DB-Prüfung ausgewertet | `public/admin.php:31` | Ersatzlos entfernen; nur noch `users`-Tabelle + `password_verify` |
| W-3 | Kein CSRF-Schutz im Admin — Monitor löschen, Proxmox-Target anlegen, Token widerrufen sind cross-site auslösbar | `public/admin.php` (alle POST-Zweige) | `Csrf`-Klasse aus LicenseLabrador übernehmen (1:1 portierbar) |
| W-4 | Stored XSS: Heartbeat-`message` und Disk-Namen landen ungefiltert per `innerHTML` im Dashboard | `public/index.php:707,731,744,770` | `textContent` statt `innerHTML`, oder clientseitig escapen |
| W-5 | Jeder gültige Agent-Token autorisiert **jeden** Endpunkt — auch `/api/monitor/delete`, `/api/monitor/edit`, `/api/link`, `/api/icon/upload` | `public/api.php:66-77` | Zwei Berechtigungsstufen trennen: Agent-Token nur für `heartbeat`/`event`; verwaltende Routen nur mit Admin-Session oder `shared_key`. `TokenManager::validateToken()` (prüft die Source-Bindung) wird derzeit **nirgends** aufgerufen — einbinden |
| W-6 | `/api/status`, `/api/events`, `/api/lineage` sind bewusst unauthentifiziert und zusätzlich von der Basic-Auth ausgenommen | `public/api.php:60`, `.htaccess:6` | Für uns nicht akzeptabel: „polytrader ist seit 14:03 down" ist eine verwertbare Information. Lesezugriff hinter Session **oder** eigenen Read-Token legen |
| W-7 | Installer-Download läuft **vor** dem Login-Check; `{{TOKEN}}`/`{{SOURCE}}` werden ungefiltert in ein PowerShell-Skript interpoliert, das als SYSTEM ausgeführt wird | `public/admin.php:58-84` | Hinter `$isLoggedIn` verschieben, Platzhalter strikt validieren (`[A-Za-z0-9_-]`), Host nicht aus `HTTP_HOST` ableiten |
| W-8 | Agent-Token als **maschinenweite** Umgebungsvariable, Default-URL `http://` | `agents/windows/install.ps1.tmpl:104`, `agents/*/watchdog-agent.*:9,4` | Token in eine ACL-geschützte Datei unter `C:\ProgramData\Watchdog`; HTTPS erzwingen |
| W-9 | SVG-Upload in denselben Origin, `mkdir(0777)` | `public/api.php:284-296`, `admin.php:240` | SVG entfernen oder als `Content-Disposition: attachment` ausliefern; `0755` |
| W-10 | Proxmox: `allowSelfSigned = true` als Default, `cert_fingerprint` nie benutzt, Token-Secret im Klartext in der DB | `src/ProxmoxClient.php:18,76`, `schema:87` | Fingerprint-Pinning umsetzen (steht so in HANDOFF §8), Secret verschlüsseln |
| W-11 | `500`-Antwort gibt `$t->getMessage()` an den Client (DB-Fehlerdetails) | `public/api.php:141-144` | Generische Meldung, Details ins `event_log` |
| W-12 | FTP-Deploy-Passwort im Klartext, identisch mit DB- und Admin-Passwort | `scripts/deploy_config.json` | Eigenes Passwort, rotieren |

### A.2 Watchdog — funktionale Fehler

| # | Befund | Wirkung |
|---|---|---|
| W-13 | `api.php:120` alarmiert bei **jedem** Heartbeat mit `status=error`/`warning` sofort | Ein dauerhaft fehlerhafter Dienst im 30-s-Takt erzeugt 120 Telegram-Nachrichten pro Stunde. Widerspricht §6 des Umsetzungsplans („nur bei Zustandswechsel") |
| W-14 | `upsertHeartbeat` erzwingt `state = IF(state="down","up",…)`, der Evaluator setzt bei frischem Heartbeat zusätzlich `error → up` („recovered") | Ein Dienst, der dauerhaft `status=error` meldet, pendelt im Minutentakt zwischen „recovered" und „hard_error" — mit Alarm bei jedem Wechsel |
| W-15 | Agents senden `intervalSeconds`, die API liest nur `interval`/`expected_interval_sec` | Der gemeldete Takt wird still verworfen, es bleibt bei 60 s. Der C#-Client sendet `interval` und ist zufällig korrekt |
| W-16 | PHP schreibt UTC-Strings, MySQL vergleicht mit `NOW()` (Session-Zeitzone) | Job-Fälligkeit, Lock-Leases und Log-Cleanup verschieben sich um den UTC-Offset, sofern die DB nicht auf UTC steht. Betrifft `cli/tick.php:39,44,106` und `admin.php:108` |
| W-17 | `self_ping` ist ein `echo`-Stub, `proxmox_smart` hat keinen Handler, `first_contact_deadline_utc` / `expect_running` / `ack_until_utc` werden nie ausgewertet | Der „Wer wacht über den Wächter"-Mechanismus fehlt komplett; der Nie-Start-Alarm ebenfalls. Beides sind Abnahmekriterien aus dem Plan |
| W-18 | `warning_digest` schickt HTML durch `notifyImmediate`, das per `htmlspecialchars` escaped | Im Telegram erscheinen `<b>`-Tags als Text |
| W-19 | Nur der Heartbeat-Zweig liegt im `try/catch`, danach läuft der Code ohne Fehlerbehandlung weiter | Uneinheitliche Fehlerbilder |
| W-20 | Kein Rate-Limit auf `/api/heartbeat` (Plan §14 fordert es) | Ein durchdrehender Client flutet die DB |
| W-21 | Keine Tests im gesamten Projekt (Plan §13 fordert Unit-Tests der Zustandsmaschine) | W-13/W-14 wären mit einem Test aufgefallen |

**Mindestumfang vor der Einbindung:** W-1, W-2, W-5, W-13, W-14, W-16. Ohne W-13/W-14 ist der
Watchdog für einen produktiven Trading-Bot unbrauchbar, weil jeder echte Fehler in einer
Nachrichtenflut untergeht.

### A.3 LicenseLabrador — Client

| # | Befund | Datei | Maßnahme |
|---|---|---|---|
| **L-1** | **Hardware-ID ist instabil.** Die „erste" aktive Netzwerkkarte wird per `FirstOrDefault` ohne stabile Sortierung gewählt, dazu `ProcessorCount` | `HardwareId.cs:47`, `:40` | **Blocker für uns.** Mullvad, Hyper-V und Docker legen virtuelle Adapter an und wieder ab — jede Änderung erzeugt eine neue HWID, damit eine neue Aktivierung, damit `max_activations` (Default 2) erschöpft: PolyTrader sperrt sich selbst aus. Fix: nur `MachineGuid` als Primärquelle; MAC nur als Fallback, wenn die Registry nichts liefert, und dann sortiert und auf physische Adapter gefiltert; `ProcessorCount` entfernen |
| L-2 | Offline-Cache ist maschinen-portabel: geprüft wird nur `payload.license_key == licenseKey`, **nicht** `hardware_id` und nicht `product` | `LicenseClient.cs:195` | Wer `state.dat` von einer aktivierten Maschine kopiert und das Netz blockiert, läuft bis zu 168 h auf beliebig vielen Rechnern. Der wirksamste Angriff auf das gesamte System — und mit zwei Vergleichen behoben |
| L-3 | Erkannte Signaturmanipulation (`signatureTampered`) wird verworfen und fällt still in die Offline-Kulanz | `LicenseClient.cs:132-135` | `LicenseState.TamperSuspected` zurückgeben und protokollieren |
| L-4 | Kein TLS-Zwang; Endpoints aus dem **Cache** haben Vorrang vor der Konfiguration | `LicenseClient.cs:276-292`, `:342` | `http://`-Endpoints ablehnen; konfigurierte Endpoints zuerst versuchen, gecachte nur als Ergänzung |
| L-5 | HMAC-„Härtung" mit Klartext-Konstante im Assembly, geprüft mit demselben Prozess-Secret | `LicenseClient.cs:23,172` | Schützt gegen nichts, was ein Angreifer nicht in derselben Sitzung mitpatcht. Als Obfuskation behalten, aber in `docs/SECURITY.md` nicht mehr als Schutzmaßnahme führen |
| L-6 | Offline-`.lic` ohne Hardware-Bindung bzw. ohne Key gilt für **jede** Maschine bzw. **jeden** Key | `LicenseClient.cs:232,242`, `offline_license.php:62` | Im Admin-Dialog `hardware_id` verpflichtend machen (Ausnahme nur mit expliziter Warnung); ein geleaktes Notfall-File ist sonst ein Universal-Crack bis `valid_until` |
| L-7 | Session-Cookie ohne `secure`-Flag | `server/src/Auth.php:11` | `'secure' => true` + HTTPS erzwingen |
| L-8 | `key_id` wird signiert und übertragen, vom Client aber ignoriert | `Signature.cs` | Ohne Auswertung ist keine Schlüsselrotation möglich, ohne alle Clients gleichzeitig zu tauschen. Für uns momentan verschmerzbar, aber notieren |
| L-9 | `LicenseClient` erzeugt einen `HttpClient` pro Instanz und ist nicht `IDisposable` | `LicenseClient.cs:28` | Socket-Leak bei wiederholter Instanziierung; `HttpClient` injizierbar machen |
| L-10 | `app_version` hartkodiert `"1.0.0"` | `LicenseClient.cs:325` | Aus `LicenseConfig` befüllen — der Server pflegt die Spalte bereits |
| L-11 | `strtotime()` liefert bei ungültigem Datum `false` → `valid_until: false` im JSON → Deserialisierung wirft → stilles „keine Lizenz" | `offline_license.php:55` | Datum validieren |
| L-12 | Nur 5 Unit-Tests; `EvaluateOfflineFallback`, Statusabbildung und Grace-Ablauf sind ungetestet | `ClientTests.cs` | Tests für L-1/L-2 mitliefern |
| L-13 | `create_admin.php`: Minimum 6 Zeichen, Passwort wird im Klartext angezeigt | `server/tools/create_admin.php` | Minimum 12, Eingabe verdecken |

**Mindestumfang vor der Einbindung:** L-1, L-2, L-3, L-4.

---

## Teil B — Einbindung in PolyTrader

### B.0 Leitentscheidungen

1. **Eigene Client-Implementierung für den Watchdog.** Der mitgelieferte `WatchdogTestClient`
   deaktiviert die Zertifikatsprüfung vollständig (`WatchdogClient.cs:42`). Wir schreiben einen
   schlanken `WatchdogHeartbeatService` in `PolyTrader.Core` — der HTTP-Vertrag ist trivial
   (ein POST mit JSON und einem Header) und wir behalten die Kontrolle über TLS, Timeouts und
   Fehlerverhalten.
2. **LicenseLabrador.Client als Projektreferenz**, nicht als kopierter Code — dann fließen
   Fixes aus Teil A.3 automatisch ein. Voraussetzung: L-1 bis L-4 sind dort behoben.
3. **Kein `Environment.Exit` bei ungültiger Lizenz.** `docs/INTEGRATION.md` schlägt das vor; für
   einen Trading-Bot mit offenen Positionen ist ein harter Abbruch gefährlich. Stattdessen:
   Trading-Module gar nicht erst starten (Startfall) bzw. geordnet stoppen (Laufzeitfall).
4. **Secrets über `SecretProtection`.** Watchdog-Token und Lizenzschlüssel werden mit dem
   bestehenden AES-GCM-Master-Key (`POLYTRADER_MASTER_KEY`) verschlüsselt abgelegt — dieselbe
   Mechanik wie für Wallet-Keys.
5. **Heartbeat-Metriken bleiben schlank.** Version, aktive Module, Uptime. **Keine** Kontostände,
   Positionen, Wallet-Adressen oder Trader-Namen — der Watchdog-Server liegt beim Hoster und
   seine Status-API war bis W-6 öffentlich lesbar.

### B.1 Slice W-A — Heartbeat-Grundgerüst ✅ ERLEDIGT (29.07.2026)

Umgesetzt in [WatchdogHeartbeatService.cs](../../src/PolyTrader.Core/Services/WatchdogHeartbeatService.cs)
mit 21 Tests in [WatchdogHeartbeatTests.cs](../../tests/PolyTrader.Tests/WatchdogHeartbeatTests.cs).
Abweichungen und Ergänzungen gegenüber der Planung unten:

- **TLS-Zwang implementiert:** `TryBuildEndpoint` akzeptiert nur `https://`; `http://` ausschließlich
  für Loopback-Adressen (lokales Testen). Damit kann der Agent-Token nicht versehentlich im
  Klartext übertragen werden — der Grund, warum der mitgelieferte Testclient nicht verwendet wird.
- **Intervall wird nach unten begrenzt** (10 s), damit ein Fehlkonfigurierter Client den Watchdog
  nicht flutet (W-20 ist serverseitig weiter offen).
- **Log-Entprellung:** nur der erste Fehlversuch und die Erholung werden protokolliert, nicht
  jeder Tick. Sonst hätte ein längerer Watchdog-Ausfall das Terminal geflutet.
- **Settings-Quelle injizierbar** (`Func<ServerSettings>`), damit der Dienst ohne Datei testbar ist.
- **Token darf verschlüsselt sein:** `SecretProtection.Unprotect` reicht Klartext unverändert
  durch und entschlüsselt `enc:v1:…`, wenn ein Master-Key gesetzt ist. Kein neuer Fehlerpfad,
  wenn kein Master-Key existiert.
- **UI — vollständig über das Settings-Fenster bedienbar:** Enabled, URL, Source, Instance und
  Intervall erscheinen automatisch im bestehenden `PropertyGrid` (Kategorie „Watchdog Monitoring").
  Der **Agent-Token** ist bewusst `[Browsable(false)]` und wird über den Designer-Button
  „Watchdog-Token setzen …" mit **maskierter Eingabe** gepflegt — kein Secret offen im Fenster und
  kein Handanlegen an der `server_settings.xml`. Bei gesetztem Master-Key wird er über
  `SecretProtection.Protect` verschlüsselt abgelegt, sonst mit deutlichem Hinweis im Klartext.
  Die schreibgeschützte Anzeige `WatchdogTokenStatus` zeigt „nicht gesetzt" /
  „gesetzt (verschlüsselt)" / „gesetzt (Klartext)". Zweiter Button: „Test-Heartbeat senden" —
  nutzt die **gespeicherten** Werte, damit ein Erfolg keine Konfiguration bestätigt, die nicht
  auf der Platte liegt.
- **Änderungen greifen ohne Neustart.** `ExecuteAsync` wertet die Konfiguration in jedem Durchlauf
  neu aus (1-s-Poll, Sendezeitpunkt über eine Fälligkeit, der Takt bleibt also exakt) statt einen
  `PeriodicTimer` mit fest verdrahtetem Intervall zu benutzen. Ein-/Ausschalten, Takt-, URL- und
  Token-Änderungen wirken sofort nach dem Speichern; Zustandswechsel werden je Ursache genau
  einmal geloggt. Zwei Tests fixieren das Live-Ein- und -Ausschalten.

Ursprüngliche Planung:

**Neu:** `src/PolyTrader.Core/Services/WatchdogHeartbeatService.cs` (`BackgroundService`)

- `ExecuteAsync`: `PeriodicTimer` im konfigurierten Takt (Default 60 s). **Jeder** Sendeversuch in
  `try/catch` — ein nicht erreichbarer Watchdog darf PolyTrader niemals beeinträchtigen.
- Payload: `source`, `instance`, `type: "heartbeat"`, `status`, `message`, `interval`
  (**nicht** `intervalSeconds`, siehe W-15), `group`, `metadata`.
- Header `X-Watchdog-Key` mit dem entschlüsselten Agent-Token.
- `HttpClient` aus `SocketsHttpHandler` wie die übrigen Clients in `Program.cs`, mit
  Standard-Zertifikatsprüfung und 10 s Timeout.
- Registrierung in `Program.cs` neben `MarketSyncService`:
  `services.AddHostedService<WatchdogHeartbeatService>();`

**Konfiguration** in `ServerSettings` (`src/PolyTrader.Core/Models/ServerSettings.cs`), analog zu
den Threema-/Mullvad-Feldern:

```
WatchdogEnabled          bool    = false
WatchdogUrl              string  = ""          // https:// erzwungen
WatchdogSource           string  = "polytrader"
WatchdogInstance         string  = "prod-1"
WatchdogIntervalSeconds  int     = 60
WatchdogToken            string  = ""          // via SecretProtection verschlüsselt
```

Bedienung über die bestehende `SettingsView` (Designer-fähig, partial + `.Designer.cs` — siehe
UI-Regel), mit einem „Test-Heartbeat senden"-Button.

**Abnahme:** Monitor erscheint im Watchdog-Dashboard, `last_seen_utc` läuft mit. PolyTrader startet
und arbeitet unverändert, wenn `WatchdogUrl` falsch oder der Server aus ist.

### B.2 Slice W-B — Status aus dem Log ableiten ✅ ERLEDIGT (31.07.2026)

Umgesetzt im `WatchdogHeartbeatService`. Abweichungen gegenüber der Planung:

- **Nur `Error` eskaliert**, keine Warnungs-Eskalation: App-Warnungen (VPN-Reconnect, „kein
  Master-Key" …) sind zu häufig, um daraus einen Monitor-Alarm zu rechtfertigen. `Warning`/`Info`
  lassen den Status auf `ok`. Das vermeidet auch eine Rückkopplung, wenn der Dienst selbst warnt.
- **Entprellung über ein Nachwirkfenster** (`ErrorStickyWindow = 5 min`): Nach einem `Error` meldet
  der Heartbeat so lange `status=error`, bis 5 Minuten ohne neuen Fehler vergangen sind — dann
  wieder `ok`. Kein Flackern error→ok→error, Erholung wird genau einmal gemeldet. (Der 30-Minuten-
  Notbehelf aus der Planung entfällt, weil W-13 im Watchdog behoben ist und ohnehin nur bei
  Zustandswechsel alarmiert wird.)
- **`Sanitize()`** entfernt Wallet-Adressen/Keys (`0x…`-Hex) und verschlüsselte Secrets
  (`enc:v1:…`) und kürzt auf 200 Zeichen, bevor eine Fehlermeldung an den (extern gehosteten)
  Watchdog geht. Beträge werden bewusst nicht gestrippt (würde die Meldung entwerten; der Kanal ist
  nur für den Betreiber).
- Angedockt über `TerminalLogger.OnLogMessage` (synchron), Abmeldung in `Dispose`.

Ursprüngliche Planung: Der Heartbeat soll `status=error` melden, wenn PolyTrader in Not ist.

- `TerminalLogger.OnLogMessage` abonnieren, Fehler der letzten `n` Intervalle zählen.
- Ableitung: `Error` im Fenster → `status=error` mit der letzten Fehlermeldung als `message`;
  `Warning` → `status=warning`; sonst `ok`.
- **Entprellen ist Pflicht**, solange W-13 im Watchdog nicht behoben ist: sonst löst jeder
  Heartbeat eine eigene Telegram-Nachricht aus. Bis dahin `status=error` frühestens alle 30 Minuten
  erneut senden.
- Meldungstexte kürzen (≤ 200 Zeichen) und **keine** Wallet-Adressen, Keys oder Beträge
  durchreichen. Ein Filter über die bekannten Secret-Präfixe gehört dazu.

### B.3 Slice W-C — Lifecycle-Events ✅ ERLEDIGT (31.07.2026)

Umgesetzt im `WatchdogHeartbeatService` (`SendEventAsync` → `POST /api/event`):

- **Start:** `kind: "started"` mit App-Version, genau einmal, sobald der Dienst aktiv wird
  (in der Sendeschleife, nach `AppHost.Start()`), vor dem ersten Heartbeat.
- **Geplantes Beenden:** `StopAsync` sendet `kind: "stopped_graceful"` (best effort, 3-s-Timeout,
  blockiert das Herunterfahren nie). Läuft über den bestehenden Pfad `AppHost.StopAsync()` nach
  `Application.Run` + den 10-Sekunden-Bestätigungsdialog.
- Damit unterscheidet der Watchdog „sauber beendet" (Monitor → `stopped`, kein Alarm) von
  „abgestürzt" (Staleness → genau ein Down-Alarm) — der eigentliche Mehrwert.
- Tests decken „started"→„stopped_graceful" über den Dienst-Lebenszyklus sowie den
  `/api/event`-Vertrag ab.

**Abnahme (manuell, live):** PolyTrader über die Menüleiste beenden → Monitor geht auf `stopped`,
**kein** Alarm. PolyTrader per Task-Manager abschießen → nach `Interval × Faktor + Grace` genau
**ein** Down-Alarm.

---

**Stand 31.07.2026:** Watchdog-Seite (B.1/B.2/B.3) und Lizenz-Seite (B.4, B.5 vereinfacht)
umgesetzt; 438 Tests grün, `--smoke-ui` ok. Offen nur noch die **live**-Abnahme (echter Server)
und die Fremdprojekt-Auflagen (Watchdog-Secrets rotieren, UTC/NOW(), `self_ping`-Stub).

### B.4 Slice L-A — Lizenzprüfung beim Start ✅ ERLEDIGT (31.07.2026)

Umgesetzt in [Licensing/LicenseGate.cs](../../Licensing/LicenseGate.cs), Startdialog in
[Ui/LicenseDialog.cs](../../Ui/LicenseDialog.cs) (+`.Designer.cs`), Verdrahtung in
[Program.cs](../../Program.cs), Schlüssel-/Statusfeld in
[ServerSettings.cs](../../src/PolyTrader.Core/Models/ServerSettings.cs). Abweichungen und
Ergänzungen gegenüber der ursprünglichen Planung unten:

- **Ort:** `LicenseGate` liegt im **App-Projekt** (`PolyTraderSharp.Licensing`), nicht in Core.
  Grund: `Program.Main` (App) ist der einzige Aufrufer, und so bleibt die (cross-repo)
  SDK-Referenz auf `PolyTrader.App` beschränkt statt in Core alle Module zu belasten.
- **SDK-Einbindung:** `LicenseLabrador.Client` als **Cross-Repo-Projektreferenz** von
  `PolyTrader.App` auf `..\..\LicenseLabrador\...` (Fixes am SDK fließen ohne Kopie ein). Baut
  sauber, kein BouncyCastle-Konflikt mit Nethereum.
- **Slug `pt`** (nicht `polytrader`), Endpoint **`https://license.mhdf.de`**, eingebetteter
  Public-Key. **End-to-End verifiziert** (ohne Aktivierung zu verbrauchen): `validate` mit
  bewusst ungültigem Schlüssel liefert signiertes `not_found`/„Invalid license key" (⇒ Slug `pt`
  bestätigt, Produkt existiert), Nonce wird reflektiert, und die Server-**Signatur verifiziert
  gegen den eingebetteten Public-Key** (openssl Ed25519 „Verified Successfully"). Der Client wird
  echte Antworten also akzeptieren.
- **Startablauf:** Master-Key wird jetzt **vor** dem Host-Build geladen (`ConfigureSecretProtection(bootLog)`),
  dann der Gate. Bei `IsUsable == false` → modaler Dialog (Schlüssel eingeben, **Hardware-ID
  anzeigen + kopieren**, „eingeschränkt starten"); bleibt es ungültig, wird die Modulliste
  **leer** gebaut → nur die Core-Shell (Terminal/Settings) startet. **Kein `Environment.Exit`.**
  `TamperSuspected` wird als nicht nutzbar behandelt und im Dialog benannt.
- **Konfiguration wie beim Watchdog-Token:** `ServerSettings.LicenseKey` (`[Browsable(false)]`,
  bei Master-Key verschlüsselt) + Statusanzeige. Der Schlüssel `9KHEZ-…` ist bereits in
  `server_settings.xml` hinterlegt → beim ersten echten Start validiert der Gate automatisch und
  aktiviert auf **dieser** Maschine (kein Dialog nötig, falls gültig).
- **Ein Dialog für beide Wege (31.07.2026):** Der Settings-Toolstrip-Button „Lizenz prüfen /
  setzen …" öffnet **denselben** `LicenseDialog` wie der Start, nur im Verwalten-Modus
  (`startupContext:false`, Button „Schließen" statt „eingeschränkt starten"). Damit validiert man
  auch aus den laufenden Einstellungen gegen den Server (Hardware-ID sichtbar/kopierbar); der
  frühere einfache Text-Prompt entfällt. Ein gültig validierter Schlüssel wird verschlüsselt
  gespeichert und gilt ab dem nächsten Start.
- **Verifikation:** Solution baut fehlerfrei, 430 Tests grün, `--smoke-ui` konstruiert zusätzlich
  `license.dialog`. Eigene Unit-Tests für den Gate wurden bewusst **nicht** angelegt: er ist
  dünner Leim über dem SDK (das seine eigenen Krypto-Tests mitbringt), und ein Test bräuchte eine
  Referenz vom Testprojekt auf die WinExe. Stattdessen deckt der Smoke-Test Konstruktion/Compile ab.
- **Offen (bewusst):** L-4 bleibt serverseitige Hygiene — sicherstellen, dass die `endpoints`-
  Einstellung im Lizenz-Admin **https oder leer** ist (gecachte Endpoints hätten sonst im SDK
  Vorrang). Und die eigentliche **erfolgreiche** Aktivierung mit dem echten Schlüssel passiert
  erst beim realen Start aus PolyTrader (mit dessen Hardware-ID) — von hier aus bewusst nicht
  getestet, um keinen Aktivierungs-Slot auf der falschen Maschine zu verbrennen.

Ursprüngliche Planung:

**Neu:** `src/PolyTrader.Core/Security/LicenseGate.cs`

- Wird in `Program.Main` **nach** `ConfigureSecretProtection` und **vor** `AppHost.Start()`
  aufgerufen — der Lizenzschlüssel liegt verschlüsselt und braucht den Master-Key.
- `LicenseConfig`: `ProductSlug = "polytrader"`, eingebetteter `PublicKeyBase64`,
  Endpoints ausschließlich `https://`.
- Ergebnis:
  - `IsUsable == true` → normaler Start. Bei `ValidOffline` zusätzlich eine sichtbare
    Restlaufzeit im Launcher.
  - `IsUsable == false` → Lizenzdialog (Schlüssel eingeben, Hardware-ID anzeigen und kopierbar
    machen), Trading-Module werden **nicht** registriert. Der Rest der Shell darf starten, damit
    Terminal und Settings erreichbar bleiben.
- `TamperSuspected` (nach L-3) wird deutlich angezeigt und wie „nicht nutzbar" behandelt.

**Wichtig:** Der Schlüssel gehört in die verschlüsselte Ablage, nicht in `appsettings.json`.

### B.5 Slice L-B — ~~Revalidierung im Betrieb~~ VERWORFEN (Entscheidung 31.07.2026)

**Es gibt bewusst KEINE Laufzeit-Revalidierung.** Richards Vorgabe: im laufenden Betrieb darf
lizenzseitig **gar nichts** passieren — die Software darf niemals mitten in einer Sitzung aufhören
zu arbeiten (offene Positionen, laufende API-Aufrufe). Die einzige Durchsetzung ist der
**Startup-Gate (B.4)**: beim nächsten Start einer ungültigen/widerrufenen/kopierten Lizenz startet
die Software nicht mehr voll, sondern zeigt die Aufforderung, eine (neue) gültige Lizenz anzugeben.
Kein `BackgroundService`, kein 12-h-Timer, kein Netzwerkaufruf während der Sitzung.

**Warum das reicht (Bedrohungsmodell = Schutz vor einfachem Kopieren auf ein fremdes System):**
Die Software läuft überwiegend auf eigenen Systemen. Geschützt werden soll nur gegen „jemand
kopiert die Software auf ein eigenes System und macht dort weiter". Das leistet der Startup-Gate
durch drei Mechanismen des SDK, **alle beim Start**:

1. **Hardware-gebundene Aktivierung** — ein fremdes System hat eine andere `MachineGuid` ⇒ andere
   Hardware-ID ⇒ braucht einen eigenen Aktivierungs-Slot.
2. **`max_activations`** — sind alle Slots belegt, liefert der Server `activation_limit` ⇒ die
   Kopie startet nicht (nur die Aufforderung erscheint).
3. **Hardware-gebundener Offline-Cache (L-2-Fix)** — ein mitkopierter `state.dat` gehört zu einer
   fremden Hardware-ID und wird offline verworfen ⇒ die Kopie kann sich auch ohne Netz nicht
   „durchmogeln".

**Zwei Stellschrauben im Lizenz-Admin (Produkt `pt`):**
- **`max_activations`** großzügig auf die Zahl der eigenen Maschinen + Reserve setzen (ein
  Windows-Neuinstall erzeugt eine neue `MachineGuid` = neuer Slot; alte Aktivierungen im Admin
  freigeben). Sonst sperrt man sich bei einem Reinstall selbst aus.
- **`default_cache_ttl_hours`** (Offline-Kulanz, Default 168 h/7 Tage) = wie lange eine **eigene**,
  bereits aktivierte Maschine ohne Serverkontakt neu starten darf. Für rein eigene Systeme darf
  das gern länger sein. Die Kopie profitiert davon nicht (Punkt 3).

**Verhalten bei fehlender/ungültiger Lizenz beim Start (aktuell umgesetzt):** modaler Dialog
(Schlüssel eingeben / Hardware-ID kopieren / „eingeschränkt starten"). Ohne gültige Lizenz startet
nur die Core-Shell (Terminal + Einstellungen), **keine Module** — die Software „arbeitet" also
nicht, bleibt aber bedienbar genug, um eine Lizenz einzutragen. Wer stattdessen ein hartes
Beenden statt des eingeschränkten Modus will, ist eine Ein-Zeilen-Änderung im Dialog (offen).

### B.6 Slice L-C — Predictalytics

Beide Dienste sind mandantenfähig ausgelegt: ein zweites Produkt `predictalytics` im
LicenseLabrador-Admin, ein zweiter Monitor im Watchdog. Der Heartbeat-Service ist bewusst
projektunabhängig geschrieben und lässt sich unverändert übernehmen. Fällt an, sobald
Predictalytics produktiv geht.

---

## Reihenfolge und Aufwand

| Schritt | Inhalt | Abhängigkeit |
|---|---|---|
| 1 | Watchdog A.1 (W-1, W-2, W-5) + A.2 (W-13, W-14, W-16) | — |
| 2 | LicenseLabrador A.3 (L-1 bis L-4) + Tests | — |
| 3 | B.1 Heartbeat-Grundgerüst + Settings-UI | 1 |
| 4 | B.2 Status aus dem Log | 3 |
| 5 | B.3 Lifecycle-Events | 3 |
| 6 | B.4 Lizenzprüfung beim Start | 2 |
| 7 | B.5 Revalidierung | 6 |
| 8 | Restliche Befunde aus A.1/A.2/A.3 | — |
| 9 | B.6 Predictalytics | 3, 6 |

Schritte 1 und 2 sind unabhängig voneinander und können parallel laufen.

---

## Offene Entscheidungen für Richard

1. **Wo läuft der Watchdog?** Aktuell ein Shared-Webserver bei derselben Hosting-Firma. Für den
   Zweck („Außensicht auf einen Server-Crash") reicht das, solange es nicht dieselbe Maschine ist.
   Der `self_ping` an healthchecks.io (W-17) fehlt aber noch komplett — bis dahin gibt es keinen
   Alarm, wenn der Watchdog selbst stirbt.
2. **Lizenzierung für uns selbst oder für Kunden?** Wenn PolyTrader vorerst nur auf unseren
   eigenen Maschinen läuft, ist die Offline-Kulanz von 168 h großzügig und L-2 entsprechend
   entspannter. Sobald Dritte die Software bekommen, sind L-1, L-2 und L-6 harte Blocker.
3. **`max_activations`** sollte für unsere eigene Lizenz großzügig gesetzt werden (5+), solange
   L-1 nicht behoben ist — sonst reicht ein VPN-Wechsel für eine Aussperrung.