feat(ui): complete Avalonia UI port with 7 main pages, tool settings & top MenuBar

2026-08-10 10:48:34 +02:00
parent a0e18d2a57
commit b5bf97ae74
187 changed files with 20054 additions and 882 deletions
@@ -0,0 +1,520 @@
+# Hardware-ID v2 — Implementierungsvorschlag
+
+Stand: 2026-08-06. Betrifft `LicenseLabrador` (Client + Server) und die
+Aufrufseite in ClawdDotNet ([Services/LicenseGate.cs](Services/LicenseGate.cs)).
+
+Anlass: Für den [Linux-Umzug](Linux-Portierung-Analyse.md) muss die
+Hardware-Bindung auf beiden Plattformen funktionieren. Bei der Durchsicht sind
+dabei zwei Probleme aufgefallen, die **nichts mit Linux zu tun haben**, aber
+denselben Code betreffen — die sollten in einem Zug mit erledigt werden.
+
+---
+
+## 1. Befund
+
+### 1.1 Der Rechnername steckt im Hash — das ist das eigentliche Problem
+
+[HardwareId.cs:43](../../LicenseLabrador/client-dotnet/LicenseLabrador.Client/HardwareId.cs):
+
+```csharp
+rawBuilder.Append(Environment.MachineName);   // "for system isolation"
+```
+
+Folge: **Ein umbenannter Rechner ist eine neue Maschine.** Er verbraucht einen
+weiteren Aktivierungsplatz, und der alte bleibt für immer belegt
+(`max_activations` ist standardmäßig 2 — nach zwei Umbenennungen ist die Lizenz
+dicht). Das gilt bereits heute unter Windows.
+
+Unter Linux wird daraus ein Totalausfall: In einem Container ist der Hostname
+standardmäßig die gekürzte Container-ID, also **bei jedem Start ein anderer**.
+Die Lizenz wäre nach dem zweiten `docker run` verbraucht.
+
+Die Absicht („system isolation") ist auch nicht erfüllt: Der Rechnername steht
+ohnehin im Feld `hostname`, das der Server bei jeder Prüfung mitschreibt
+([LicenseService.php:112](../../LicenseLabrador/server/src/LicenseService.php)).
+Diagnostisch verlieren wir nichts, wenn er aus dem Hash verschwindet.
+
+### 1.2 Die MAC-Ausweichlösung ist unter Linux instabil
+
+[HardwareId.cs:86](../../LicenseLabrador/client-dotnet/LicenseLabrador.Client/HardwareId.cs)
+nimmt die alphabetisch erste physische MAC. Unter Linux:
+
+- Die Stoppwortliste kennt `docker` und `veth`, aber **nicht** `br-` (Bridges),
+  `virbr` (libvirt), `cni`, `flannel`, `cali` (Kubernetes), `zt` (ZeroTier).
+- `NetworkInterfaceType` meldet unter Linux für die meisten virtuellen Geräte
+  schlicht `Ethernet` — die Typprüfung greift also nicht.
+- Bridge- und veth-MACs werden von systemd **je Boot neu zufällig** vergeben.
+
+Sortiert man solche Adressen mit, wechselt die Hardware-ID beim Neustart. Die
+Ausweichlösung ist damit unter Linux schlimmer als keine.
+
+### 1.3 Der Zustandsspeicher fällt still auf Klartext zurück
+
+[StateStore.cs:41](../../LicenseLabrador/client-dotnet/LicenseLabrador.Client/StateStore.cs)
+beim Lesen und `:90` beim Schreiben:
+
+```csharp
+try   { decryptedData = ProtectedData.Unprotect(rawData, null, ...); }
+catch { decryptedData = rawData; }        // ← Klartext wird akzeptiert
+```
+
+Unter Linux wirft DPAPI immer, also läuft alles über den Klartextzweig. Zwei
+Folgen:
+
+- `SECURITY.md` behauptet, der Cache sei „strikt an die `hardware_id` gebunden".
+  Das stimmt für die *Hülle* (die Prüfung in
+  [LicenseClient.cs:198](../../LicenseLabrador/client-dotnet/LicenseLabrador.Client/LicenseClient.cs)),
+  nicht für die Cache-Datei selbst.
+- Ernster: `max_seen_time` ist die Uhr-Rückdreh-Sperre
+  ([StateStore.cs:107](../../LicenseLabrador/client-dotnet/LicenseLabrador.Client/StateStore.cs)).
+  Wer eine `state.dat` von Hand schreiben kann, setzt den Wert auf 0 und stellt
+  die Systemuhr zurück. Der Klartext-Rückfall beim **Lesen** macht das möglich,
+  und zwar auf jeder Plattform, auf der DPAPI nicht greift.
+
+### 1.4 Ablageort bricht bei einem systemd-Dienst weg
+
+[LicenseConfig.cs:22](../../LicenseLabrador/client-dotnet/LicenseLabrador.Client/LicenseConfig.cs)
+verwendet `Environment.GetFolderPath(SpecialFolder.ApplicationData)`. Läuft der
+Dienst unter `User=clawd` ohne Heimatverzeichnis, ist `HOME` nicht gesetzt und
+`GetFolderPath` liefert einen **leeren String**. `Path.Combine("", slug,
+"license")` ergibt einen relativen Pfad — die Lizenz landet im Arbeitsverzeichnis
+oder gar nicht.
+
+### 1.5 Kein Formatkennzeichen, keine Plattformangabe
+
+Die Hardware-ID ist heute ein nackter SHA-256-Hex-String. Es gibt keine
+Möglichkeit, im Server zu erkennen, aus welcher Quelle oder von welchem
+Betriebssystem eine Aktivierung stammt — und keinen Weg, das Format je zu
+wechseln, ohne alle bestehenden Aktivierungen zu verlieren.
+
+**Randnotiz:** `OperatingSystemHelpers.IsWindows()` nutzt
+`Environment.OSVersion.Platform == PlatformID.Win32NT`. Das funktioniert
+zufällig richtig (Linux liefert `Unix`), ist aber die veraltete API.
+`RuntimeInformation.IsOSPlatform(OSPlatform.Windows)` ist in netstandard2.0
+verfügbar und der korrekte Weg.
+
+---
+
+## 2. Zielbild: das Format
+
+```
+2:<plattform>:<64 Hex-Zeichen>
+
+Beispiele:
+  2:win:9f3ab7c1…      (Windows, MachineGuid)
+  2:lin:41e0d5aa…      (Linux, /etc/machine-id)
+  2:lin:7c9182ff…      (Linux, Vorgabe per Umgebungsvariable)
+```
+
+68 Zeichen — passt in `activations.hardware_id VARCHAR(128)` ohne
+Schemaänderung. Der Doppelpunkt ist unproblematisch, die Spalte ist
+`utf8mb4_unicode_ci` und wird nur verglichen.
+
+Der Hash selbst:
+
+```
+sha256( "LicenseLabrador-HWID-v2" ‖ "\n" ‖ plattform ‖ "\n" ‖ quelle ‖ "\n" ‖ rohwert )
+```
+
+- **Kein `MachineName`.** (1.1)
+- Die Domänenzeichenkette verhindert, dass derselbe Rohwert in anderem
+  Zusammenhang wiederverwendbar ist.
+- `quelle` geht mit in den Hash: Findet der Client später eine bessere Quelle,
+  ändert sich die ID bewusst und nachvollziehbar, statt zufällig.
+
+Zusätzlich gehen drei neue Felder mit in die Anfrage — **nicht** in den Hash,
+nur zur Diagnose und für die Migration:
+
+| Feld | Beispiel | Zweck |
+|---|---|---|
+| `hwid_version` | `2` | Formaterkennung serverseitig |
+| `hwid_source` | `machine-id` | Admin sieht, wie stabil die Bindung ist |
+| `legacy_hardware_id` | `<v1-Hash>` | Migration ohne Platzverlust (Abschnitt 4) |
+
+---
+
+## 3. Quellen je Plattform
+
+Reihenfolge = Priorität. Die erste Quelle, die einen nichtleeren, plausiblen Wert
+liefert, gewinnt.
+
+### 3.1 Vorgabe (alle Plattformen, höchste Priorität)
+
+```
+LicenseConfig.HardwareIdOverride     (Code)
+LICENSELABRADOR_HWID                 (Umgebungsvariable)
+```
+
+Quelle: `override`. Der Rohwert wird trotzdem gehasht, damit das Format
+einheitlich bleibt.
+
+**Das ist der ehrliche Weg für Container und Serverbetrieb.** Heuristik kann dort
+nicht gewinnen — in einem Container gibt es keine Hardware, an die man binden
+könnte. Der Betreiber setzt einen stabilen Wert, hinterlegt ihn im
+Deployment-Geheimnis, und die Bindung ist so verlässlich wie dieser Wert. Eine
+Zeile in der systemd-Unit statt eines Ratespiels.
+
+### 3.2 Windows
+
+| # | Quelle | `hwid_source` |
+|---|---|---|
+| 1 | `HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid` (Registry64) | `machine-guid` |
+| 2 | Stabile physische MAC (Abschnitt 3.4) | `mac` |
+| 3 | Erzeugte Datei (Abschnitt 3.5) | `keyfile` |
+
+Unverändert zu heute — nur ohne `MachineName` im Hash.
+
+### 3.3 Linux
+
+| # | Quelle | `hwid_source` | Anmerkung |
+|---|---|---|---|
+| 1 | `/etc/machine-id` | `machine-id` | Von systemd bei der Installation erzeugt, überlebt Neustarts und Kernel-Updates. Die richtige Wahl auf einem echten System. |
+| 2 | `/var/lib/dbus/machine-id` | `dbus-machine-id` | Ältere Systeme ohne systemd. |
+| 3 | `/sys/class/dmi/id/product_uuid` | `dmi-uuid` | SMBIOS-UUID, echte Hardware-Bindung. **Meist nur für root lesbar** (`0400`) — Versuch in `try` einpacken, kein Fehler wenn nicht lesbar. Bei VMs vom Hypervisor gesetzt und dort stabil. |
+| 4 | Stabile physische MAC (Abschnitt 3.4) | `mac` | |
+| 5 | Erzeugte Datei (Abschnitt 3.5) | `keyfile` | |
+
+Zwei Fallen bei `/etc/machine-id`, die geprüft werden müssen:
+
+- **Leer oder nur Zeilenumbruch.** Auf Systemen mit `systemd-firstboot` oder in
+  manchen Images existiert die Datei, ist aber leer. Muss als „nicht vorhanden"
+  behandelt werden, nicht als gültiger Wert — sonst haben *alle* diese
+  Installationen dieselbe ID.
+- **Der Wert `uninitialized`.** Genau diese Zeichenkette schreibt systemd, wenn
+  die ID im laufenden Betrieb noch nicht festgelegt ist. Ebenfalls verwerfen.
+
+```csharp
+private static bool IsPlausibleMachineId(string? v)
+    => !string.IsNullOrWhiteSpace(v)
+       && v.Trim().Length >= 16
+       && !v.Trim().Equals("uninitialized", StringComparison.OrdinalIgnoreCase)
+       && v.Trim().Trim('0').Length > 0;      // nicht alles Nullen
+```
+
+### 3.4 MAC-Ausweichlösung, überarbeitet
+
+Die heutige Fassung nimmt `FirstOrDefault()` der sortierten Liste. Wenn eine
+Schnittstelle dazukommt oder wegfällt, kann sich damit die gewählte MAC ändern.
+Besser: **alle** gültigen MACs sortiert verketten — dann ändert sich der Wert
+nur, wenn sich die Netzwerkausstattung wirklich ändert, und nicht schon, weil
+eine Adresse hinzukommt, die vorher sortiert davor lag.
+
+Stoppwortliste erweitern um: `br-`, `virbr`, `cni`, `flannel`, `cali`, `weave`,
+`zt`, `tailscale`, `ipsec`, `sit`, `gre`, `dummy`, `bond`, `macvlan`, `ovs`.
+
+Zusätzlich hart ausschließen (unabhängig vom Namen):
+
+- Schnittstellen mit gesetztem **„locally administered"-Bit** (zweites Bit des
+  ersten Oktetts, `mac[0] & 0x02`). Genau das setzt systemd bei zufällig
+  erzeugten MACs für veth und Bridges. Ein sauberer, namensunabhängiger Filter —
+  und der wirksamste von allen.
+- Unter Linux zusätzlich prüfen: existiert
+  `/sys/class/net/<name>/device`? Fehlt das Verzeichnis, hat die Schnittstelle
+  kein physisches Gerät und ist virtuell. Das ist zuverlässiger als jede
+  Namensliste.
+
+```csharp
+// Namensunabhängig: zufällig erzeugte MACs tragen dieses Bit.
+private static bool IsLocallyAdministered(PhysicalAddress addr)
+{
+    var b = addr.GetAddressBytes();
+    return b.Length > 0 && (b[0] & 0x02) != 0;
+}
+```
+
+### 3.5 Erzeugte Datei als letzte Stufe
+
+`<StorageDirectory>/machine.key` — 32 Zufallsbytes, Base64, Dateirechte `0600`.
+Wird nur angelegt, wenn keine Quelle davor greift.
+
+Das ist eine **Installations-** und keine Hardware-Bindung. Für einen Container
+ohne Vorgabe ist das aber die Wahrheit, und mit einem gemounteten Datenverzeichnis
+bleibt sie über Container-Neustarts stabil. `hwid_source` = `keyfile` macht dem
+Admin sichtbar, dass diese Aktivierung schwächer gebunden ist als die anderen.
+
+Wichtig: Die Datei gehört ins **Datenverzeichnis**, nicht neben die
+Programmdatei. Sonst ist sie bei jedem Deployment weg.
+
+---
+
+## 4. Migration v1 → v2 ohne Platzverlust
+
+Der Kern: Der Client kennt **beide** IDs und schickt beide mit. Der Server zieht
+die alte Aktivierung auf die neue ID um, statt eine zweite anzulegen.
+
+**Client** — `HardwareId` bekommt neben `GetHardwareId()` (v2) ein
+`GetLegacyHardwareId()`, das die heutige v1-Berechnung *unverändert* beibehält
+(inklusive `MachineName`, damit sie zu bestehenden Aktivierungen passt). Beides
+geht in die Anfrage:
+
+```csharp
+hardware_id        = "2:lin:41e0…",
+legacy_hardware_id = "8fa2…",          // nur solange v1-Aktivierungen existieren
+hwid_version       = 2,
+hwid_source        = "machine-id",
+```
+
+**Server** — in `LicenseService::validate`, an der Stelle der heutigen Suche
+([LicenseService.php:100](../../LicenseLabrador/server/src/LicenseService.php)):
+
+```
+1. Aktivierung mit hardware_id = <v2> suchen
+   → gefunden: normaler Weg (last_seen, hostname, app_version aktualisieren)
+
+2. nicht gefunden, und legacy_hardware_id ist gesetzt:
+   Aktivierung mit hardware_id = <v1> suchen
+   → gefunden: UPDATE activations SET hardware_id = <v2>, hwid_version = 2,
+               hwid_source = <quelle> WHERE id = …
+               + audit_log-Eintrag 'hwid_migrated'
+               → weiter wie unter 1. KEIN neuer Platz verbraucht.
+
+3. weder noch: neue Aktivierung anlegen, max_activations prüfen (wie heute)
+```
+
+Damit wandern alle bestehenden Windows-Installationen beim ersten Start nach dem
+Update lautlos auf v2 — niemand merkt etwas, kein Aktivierungsplatz geht
+verloren. Das `legacy_hardware_id`-Feld kann nach einer Übergangszeit (etwa zwei
+Veröffentlichungen) aus dem Client fallen.
+
+### 4.1 Der lokale Cache muss einmal verworfen werden
+
+Nicht übersehen: Die Hardware-ID geht in zwei weitere Berechnungen ein —
+`CalculateHmac(state, licenseKey, _hardwareId)` für die Prüfsumme in
+`LicenseResult`
+([LicenseClient.cs:272](../../LicenseLabrador/client-dotnet/LicenseLabrador.Client/LicenseClient.cs))
+und den Seed des Speicherschutzes (`:287`). Nach dem Formatwechsel schlägt
+`VerifyChecksum` für jede zwischengespeicherte Hülle fehl.
+
+Das ist kein Fehler, sondern erwartet — muss aber als **Cache-Fehltreffer**
+behandelt werden (einmal online neu prüfen), nicht als
+`TamperSuspected`. Sonst sperrt sich jede bestehende Installation beim ersten
+Start nach dem Update selbst aus. Der Weg dorthin: Cache-Version im
+`LocalCacheData` mitführen (`schema_version: 2`) und einen Datensatz mit
+abweichender Version verwerfen, bevor die Prüfsumme überhaupt geprüft wird.
+
+### 4.2 Schemaerweiterung
+
+```sql
+ALTER TABLE activations
+  ADD COLUMN hwid_version TINYINT NOT NULL DEFAULT 1 AFTER hardware_id,
+  ADD COLUMN hwid_source  VARCHAR(32) NULL      AFTER hwid_version,
+  ADD COLUMN platform     VARCHAR(8)  NULL      AFTER hwid_source;
+```
+
+Alles mit Vorgabewerten, also rückwärtskompatibel — ein alter Client, der die
+Felder nicht schickt, funktioniert unverändert weiter.
+
+---
+
+## 5. Umzug Windows → Linux
+
+Das ist etwas anderes als die Formatmigration: hier wechselt die Maschine
+wirklich, die ID muss sich also ändern. Drei Wege, alle drei sinnvoll parallel:
+
+### 5.1 Der Normalfall braucht gar nichts
+
+`max_activations` ist standardmäßig **2**. Ein Windows-Entwicklungsrechner und
+ein Linux-Server passen also ohne jeden Eingriff hinein. Für den anstehenden
+Umzug ist das wahrscheinlich die ganze Antwort — die anderen beiden Punkte sind
+für den Fall danach.
+
+### 5.2 Abmelden vor dem Umzug (existiert, aber nicht erreichbar)
+
+`LicenseService::deactivate` löscht die Aktivierungszeile und gibt den Platz frei
+([LicenseService.php:153](../../LicenseLabrador/server/src/LicenseService.php)),
+und `LicenseClient.DeactivateAsync` ruft es auf. In ClawdDotNet ist die Methode
+aber nur über [LicenseGate.cs:39](Services/LicenseGate.cs) erreichbar und dort
+an die GUI gebunden.
+
+Nachzuliefern: ein Kommandozeilenschalter am Host, damit das auch ohne
+Oberfläche geht.
+
+```bash
+clawddotnet --license-deactivate
+```
+
+Das braucht der kopflose Betrieb ohnehin (siehe
+[Linux-Portierung-Analyse.md](Linux-Portierung-Analyse.md), 2.6 — der
+Lizenzdialog ist ein `MessageBox`, der einen Dienst blockieren würde).
+
+### 5.3 Umbinden aus der Verwaltung (fehlt noch)
+
+Für den Fall, dass die alte Maschine schon weg ist: In
+`public/admin/license_detail.php` je Aktivierungszeile eine Schaltfläche
+**„Aktivierung freigeben"** (löscht die Zeile, gibt den Platz frei). Ein echtes
+„Umbinden" auf eine bekannte neue ID ist unnötig — Freigeben plus Neuaktivierung
+auf dem Zielsystem ist derselbe Vorgang mit weniger Code und einer klareren
+Spur im Prüfprotokoll.
+
+Beides sollte in `audit_log` landen, mit altem und neuem Wert.
+
+---
+
+## 6. Zustandsspeicher härten
+
+Zusammen mit dem HW-ID-Umbau, weil dieselbe Datei betroffen ist und die
+Verschlüsselung den HW-ID als Schlüsselmaterial braucht.
+
+**Format** — feste Hülle statt „mal so, mal so":
+
+```
+Magic "LLS2" (4 Byte) │ Nonce (12) │ Ciphertext │ GCM-Tag (16)
+```
+
+- **AES-GCM**, Schlüssel abgeleitet aus HW-ID + `ProductSlug` per HKDF-SHA256.
+- Auf Windows das Ergebnis **zusätzlich** in DPAPI wickeln (Gürtel und
+  Hosenträger, kostet nichts).
+- Dateirechte `0600` auf Unix.
+
+**Der entscheidende Punkt: den Klartext-Rückfall beim Lesen entfernen.** Eine
+Datei, die sich nicht entschlüsseln oder nicht authentifizieren lässt, ist
+**kein Cache** — sie wird verworfen und der Client prüft online. Nicht als
+Klartext akzeptieren. Genau dieser Rückfall macht heute die
+Uhr-Rückdreh-Sperre umgehbar (1.3).
+
+Einmalig weiterhin lesbar bleiben muss das alte Format (Datei ohne `LLS2`-Magic):
+einlesen, in v2 neu schreiben, fertig. Nach einer Veröffentlichung kann der Pfad
+weg.
+
+### 6.1 netstandard2.0 hat kein AesGcm — Empfehlung: mehrfach zielen
+
+`System.Security.Cryptography.AesGcm` gibt es erst ab .NET Core 3.0, `HKDF` erst
+ab .NET 5, `File.SetUnixFileMode` erst ab .NET 7. Das Projekt zielt heute auf
+`netstandard2.0`.
+
+Zwei Wege:
+
+1. **`<TargetFrameworks>netstandard2.0;net8.0</TargetFrameworks>`** —
+   *empfohlen*. ClawdDotNet (net10.0) zieht automatisch das net8.0-Ziel und
+   bekommt `AesGcm`, `HKDF` und `File.SetUnixFileMode` ohne Umwege. Der
+   netstandard2.0-Zweig bleibt für andere Abnehmer erhalten und nutzt dort
+   BouncyCastle. Kosten: ein paar `#if NET8_0_OR_GREATER`-Blöcke an genau drei
+   Stellen.
+2. **Durchgängig BouncyCastle** (`GcmBlockCipher`, `HkdfBytesGenerator`) — die
+   Bibliothek ist mit `BouncyCastle.Cryptography` bereits als Abhängigkeit da,
+   also kein neues Paket. Kein Mehrfachziel nötig, aber die Dateirechte bleiben
+   ein Problem: `chmod` müsste per P/Invoke laufen.
+
+Weg 1 ist sauberer, weil er nebenbei das Dateirechte-Problem löst.
+
+---
+
+## 7. Ablageort (1.4)
+
+Auflösungskette in `LicenseConfig.StorageDirectory`, erste nutzbare gewinnt:
+
+1. Explizit gesetzter Wert (ClawdDotNet setzt ihn künftig — der Host hat ohnehin
+   eine eigene XDG-Auflösung).
+2. `LICENSELABRADOR_STORAGE_DIR`.
+3. Unix: `$XDG_CONFIG_HOME/<slug>/license`, sonst `$HOME/.config/<slug>/license`.
+4. Windows: `SpecialFolder.ApplicationData` wie heute.
+5. Letzter Ausweg: `<AppContext.BaseDirectory>/license`.
+
+**Und in jedem Fall: nie einen leeren Pfad durchlassen.** Der heutige Code kann
+`Path.Combine("", …)` erzeugen, ohne dass es auffällt. Ein `if
+(string.IsNullOrEmpty(...)) throw` an dieser Stelle ist besser als eine
+Lizenzdatei, die im Arbeitsverzeichnis landet und beim nächsten Start nicht mehr
+gefunden wird.
+
+---
+
+## 8. Änderungsliste
+
+### LicenseLabrador — Client
+
+| Datei | Was |
+|---|---|
+| `HardwareId.cs` | Neuschreiben: v2-Format, Quellenkette je Plattform, `GetLegacyHardwareId()`, `HwidSource`/`Platform` als Eigenschaften, MAC-Filter (locally-administered-Bit, `/sys/class/net/*/device`), Plausibilitätsprüfung für machine-id, `machine.key`-Erzeugung |
+| `LicenseConfig.cs` | `HardwareIdOverride`, Auflösungskette für `StorageDirectory`, leeren Pfad ausschließen |
+| `StateStore.cs` | `LLS2`-Hülle, AES-GCM, `schema_version`, **Klartext-Rückfall beim Lesen entfernen**, v1-Einmalmigration, `0600` |
+| `LicenseClient.cs` | Neue Felder in `validate`/`deactivate` senden; Cache mit abweichender `schema_version` als Fehltreffer behandeln, **nicht** als `TamperSuspected` |
+| `OperatingSystemHelpers` | `RuntimeInformation.IsOSPlatform`, dazu `IsLinux()`/`IsMacOs()` |
+| `LicenseLabrador.Client.csproj` | `netstandard2.0;net8.0` |
+
+### LicenseLabrador — Server
+
+| Datei | Was |
+|---|---|
+| `sql/schema.sql` + Migrationsskript | `hwid_version`, `hwid_source`, `platform` |
+| `src/LicenseService.php` | `legacy_hardware_id` entgegennehmen; Migrationssuche (Abschnitt 4); neue Felder speichern |
+| `src/Audit.php` | Ereignisart `hwid_migrated`, `activation_released` |
+| `public/admin/license_detail.php` | Quelle/Plattform je Aktivierung anzeigen, „Aktivierung freigeben" |
+| `docs/SECURITY.md` | Aussage zur Cache-Bindung korrigieren (1.3) |
+
+### ClawdDotNet
+
+| Datei | Was |
+|---|---|
+| [Services/LicenseGate.cs](Services/LicenseGate.cs) | `StorageDirectory` explizit setzen; `MessageBox`/`frm_License` hinter eine Schnittstelle (`ILicensePrompt`) legen, damit der kopflose Host eine Konsolenfassung einsetzen kann |
+| Host (neu) | `--license-deactivate`, `--license-set-key`, `--license-status` |
+| `docs/Integrationsplan-WatchDog-LicenseLabrador.md` | Format v2 und Migrationsweg nachtragen |
+
+---
+
+## 9. Testplan
+
+Das Wichtigste zuerst — die Fälle, die heute schiefgehen würden:
+
+| Fall | Erwartung |
+|---|---|
+| Rechner umbenennen | **ID unverändert** (Kern von 1.1) |
+| Container zweimal starten, `/etc/machine-id` im Abbild | beide Male dieselbe ID |
+| Container ohne `machine-id`, Datenverzeichnis gemountet | ID über Neustarts stabil, `hwid_source = keyfile` |
+| Container ohne `machine-id`, **ohne** Mount | ID wechselt — muss so sein, und im Protokoll erkennbar |
+| `LICENSELABRADOR_HWID` gesetzt | gewinnt gegen alles, `hwid_source = override` |
+| `/etc/machine-id` leer bzw. `uninitialized` | wird verworfen, nächste Quelle greift |
+| Docker-Bridge und veth vorhanden, keine machine-id | MAC-Wahl ignoriert sie, ID über Neustart stabil |
+| Bestehende v1-Windows-Aktivierung, Client aktualisiert | Zeile wird auf v2 umgeschrieben, `max_activations` unverändert, Prüfprotokolleintrag |
+| v1-Cache-Datei nach dem Update | einmal online geprüft, dann v2-Cache — **kein** `TamperSuspected` |
+| `state.dat` von Hand mit `max_seen_time = 0` | Datei wird verworfen, Uhr-Rückdreh-Sperre bleibt wirksam |
+| systemd-Dienst ohne `HOME` | Ablageort auflösbar, keine Datei im Arbeitsverzeichnis |
+| Alter Client gegen neuen Server | funktioniert unverändert (Felder haben Vorgabewerte) |
+| Neuer Client gegen alten Server | funktioniert, Zusatzfelder werden ignoriert |
+
+Die letzten beiden Zeilen sind nicht optional: Client und Server werden nicht
+gleichzeitig ausgerollt.
+
+---
+
+## 10. Aufwand
+
+| Block | PT |
+|---|---:|
+| `HardwareId` v2 samt Quellenkette, MAC-Filter, `machine.key` | 2–3 |
+| Client mehrfach zielen + `StateStore`-Härtung | 2–3 |
+| Server: Migrationssuche, Schema, Prüfprotokoll, Verwaltungsansicht | 2–3 |
+| ClawdDotNet: `ILicensePrompt`, Lizenz-Kommandozeile | 1–2 |
+| Tests (Container-Fälle brauchen echtes Docker) und Abnahme | 1–2 |
+| **Summe** | **8–13** |
+
+Das ist mehr als die 3–5 PT, die in der Linux-Analyse für „Lizenz" standen —
+weil dort nur die Plattformverträglichkeit gerechnet war. Die Punkte 1.1 und 1.3
+sind bestehende Fehler, die unabhängig vom Umzug behoben werden sollten; sie
+machen den Unterschied aus.
+
+Der Block ist **unabhängig vom übrigen Linux-Umzug** und kann sofort beginnen —
+er hängt an keiner der offenen GUI-Entscheidungen.
+
+---
+
+## 11. Was ich anders machen würde als heute — kurz begründet
+
+Drei Entscheidungen im Vorschlag verdienen eine Begründung, weil sie vom
+bisherigen Ansatz abweichen:
+
+**Rechnername raus.** Er ist der Grund, warum die heutige Bindung fragiler ist
+als nötig, und er trägt nichts bei, was `activations.hostname` nicht schon
+festhält. Eine Bindung, die bei einer Umbenennung bricht, bindet nicht an
+Hardware, sondern an eine Konfiguration.
+
+**Vorgabe per Umgebungsvariable statt besserer Heuristik für Container.** Man
+kann eine Container-Umgebung nicht sinnvoll erraten — es gibt dort keine
+Hardware. Jede zusätzliche Heuristik verschiebt nur, wo es falsch wird. Eine
+explizite Vorgabe ist ein bewusster Betreiberentscheid, in der Unit-Datei
+sichtbar, im Prüfprotokoll nachvollziehbar.
+
+**Kein Klartext-Rückfall, auch nicht „zur Sicherheit".** Der heutige Rückfall
+sollte Robustheit bringen, kostet aber genau die Eigenschaft, für die der Cache
+existiert. Ein verworfener Cache bedeutet: einmal online prüfen. Das ist der
+mildere Schaden — und wer keine Verbindung hat, hat immer noch die
+Offline-Gnadenfrist aus der signierten Hülle, die von dieser Datei nicht abhängt.