# Linux-Portierung — Analyse

Stand: 2026-08-06. Reine Bestandsaufnahme und Aufwandsschätzung, **kein** Umbau.

> **Nachtrag 2026-08-23:** Der teure Teil dieser Analyse hat sich erledigt. Die rund
> 8.900 Zeilen Windows-Forms-Oberfläche samt WebView2 und den vier `PropertyGrid`-
> Instanzen gibt es nicht mehr — sie sind durch `src/ClawdDotNet.Desktop` (Avalonia,
> `net10.0`) ersetzt und beim Frühjahrsputz entfernt worden. Damit fällt der zweite
> der beiden unten vorgeschlagenen Schnitte weg: Es gibt keine Windows-gebundene
> Oberfläche mehr, die noch umzuziehen wäre. Offen bleiben die drei Kernstellen
> (DPAPI, Pfadvergleiche, Zeitzonen-IDs) und ein `linux-x64`-Release (Roadmap DC3).

Frage: Was ist nötig, damit ClawdDotNet unter Linux läuft, und was kostet das?

---

## 0. Kurzfassung

Die gute Nachricht zuerst: **Der Kern ist bereits portabel.** Alle 16 Bibliotheks-
und beide Testprojekte zielen auf `net10.0` (nicht `net10.0-windows`), es gibt im
gesamten Repository **kein einziges `DllImport`, keinen Registry-Zugriff und keine
`System.Drawing`-Nutzung** in `src/`. Windows steckt an genau drei Stellen im Kern:
DPAPI-Verschlüsselung, Groß-/Kleinschreibung bei Pfadvergleichen und die
Zeitzonen-IDs.

Die schlechte Nachricht: Die gesamte Bedienoberfläche — rund **8.900 Zeilen** in
`frm_*.cs`, `UI/`, `Models/` und `Services/` — hängt an Windows Forms, an WebView2
und, am unangenehmsten, an vier `PropertyGrid`-Instanzen, die praktisch die
komplette Einstellungsverwaltung ausmachen. Dafür gibt es in Avalonia keine
Eins-zu-eins-Entsprechung.

**Empfehlung: den Umzug in zwei Schnitte teilen.** Ein kopfloser Host (ohne GUI)
auf Linux ist in etwa **12–18 Personentagen** erreichbar und liefert den
eigentlichen Nutzen — Agenten laufen auf einem Server, nicht auf einem
Windows-Desktop. Die Avalonia-Oberfläche ist ein davon unabhängiges Vorhaben
von **32–52 Personentagen**, das man danach in Ruhe angehen kann.

Gesamt für „alles auf Linux, mit GUI": **50–80 Personentage.**

---

## 1. Bestandsaufnahme

### 1.1 Was bereits portabel ist

| Bereich | Zeilen | Zielframework | Windows-Abhängigkeit |
|---|---:|---|---|
| `src/ClawdDotNet.Core` | 8.959 | `net10.0` | nur DPAPI (1 Datei) |
| 15 Tool-Projekte | 6.415 | `net10.0` | nur `.exe`-Pfade im SocialMediaManager |
| `tests/` (348 Tests, 39 Dateien) | 6.888 | `net10.0` | 3 Testfälle mit `C:\`-Pfaden |

Alle NuGet-Pakete laufen unter Linux: `Microsoft.Data.Sqlite` (bringt
`e_sqlite3` nativ für linux-x64/arm64 mit), `MySqlConnector`, `Npgsql`,
`Microsoft.Data.SqlClient`, `MongoDB.Driver`, `MailKit`, `FluentFTP`,
`Telegram.Bot`, `WTelegramClient`, `SharpCompress`, `Snappier`,
`Microsoft.Extensions.Logging`. Kein Paket muss ersetzt werden — mit zwei
Ausnahmen (siehe 2.1 und 2.3).

Auch die Dinge, bei denen man Ärger erwarten würde, sind sauber gelöst:

- [AtomicFile.cs:167](src/ClawdDotNet.Core/Storage/AtomicFile.cs:167) — `Commit`
  prüft `File.Exists` und weicht auf `File.Move` aus. `File.Replace` verlangt
  unter Unix ebenfalls eine vorhandene Zieldatei; der Fall ist also schon
  abgedeckt. Die Wiederholschleife ist unter Linux überflüssig, aber harmlos.
- [TaskFrontmatter.cs:27](src/ClawdDotNet.Core/Tasks/TaskFrontmatter.cs:27) —
  normalisiert `\r\n` und `\r` vor dem Zerlegen. Task-Dateien von einem
  Windows-Rechner werden unter Linux korrekt gelesen.
- Textdateien werden durchgängig als **UTF-8 ohne BOM** geschrieben
  (`AtomicFile`, `FileLogWriter`, `AgentEditorTool`). Kein `Encoding.Default`,
  keine Codepage-Fallen.
- Zeitstempel gehen als `DateTime.UtcNow` in die Datenbank und werden mit
  `DateTimeStyles.RoundtripKind` gelesen.

### 1.2 Was am Windows-Teil hängt

| Bereich | Zeilen | davon Designer |
|---|---:|---:|
| `frm_*.cs` (6 Formulare + Dialoge) | 4.946 | 1.865 |
| `UI/` (BackupPanel, WebViewBridge, EmbeddedUiManager) | 1.087 | 428 |
| `Models/` (PropertyGrid-ViewModels) | 1.257 | — |
| `Services/` (4 Dienste, an WinForms-Timer gekoppelt) | 1.501 | — |
| `Properties/` | 123 | — |
| **Summe** | **8.914** | **2.293** |

Dazu drei `.resx`-Dateien à ~272 KB (eingebettete Symbole/Bilder) und eine
`frm_main.en.resx` für die englische Lokalisierung über den
WinForms-Resx-Mechanismus.

Steuerelement-Inventar aus den Designer-Dateien: 24 `Label`, 19
`ToolStripButton`, 12 `TabPage`, 12 `Button`, 9 `TextBox`, 6 `DataGridView`, 6
`ToolStrip`, 5 `ComboBox`, **4 `PropertyGrid`**, 4 `TableLayoutPanel`, 4
`FlowLayoutPanel`, 3 `TabControl`, 3 `SplitContainer`, 1 `RichTextBox`, 1
`ListView`, 1 `NotifyIcon`, 1 `DateTimePicker`, 1 `NumericUpDown`.

Tabs in `frm_main`: Chat, Logs, Settings (mit Unter-Tabs App-Settings,
Instance-Settings), Agent Settings, Jobs/Services (mit Unter-Tabs Jobs,
Services, Job History), Info, Backup.

---

## 2. Die harten Brocken

### 2.1 WebView2 → kein Linux (Chat- und Übersichts-Ansicht)

`Microsoft.Web.WebView2` ist die einzige Windows-only-Paketabhängigkeit des
Hauptprojekts und trägt die zwei sichtbarsten Ansichten:
[frm_main.cs:235](frm_main.cs:235) und [frm_chat.cs:44](frm_chat.cs:44) laden
`overview.html` bzw. `chat.html` aus `EmbeddedUI/` über
`SetVirtualHostNameToFolderMapping` unter `https://ui.clwd.internal/`. Die
Kommunikation läuft über [WebViewBridge.cs](UI/WebViewBridge.cs) —
`WebMessageReceived` in die eine, `ExecuteScriptAsync` in die andere Richtung.

Drei Wege, jeder mit einem eigenen Preis:

| Variante | Was passiert | Aufwand | Risiko |
|---|---|---:|---|
| **A — Avalonia.WebView** | HTML/JS bleiben. Unter Linux rendert WebKitGTK, unter Windows weiterhin WebView2. Die Bridge wird auf die Abstraktion der Bibliothek umgeschrieben. | 4–6 PT | Bibliothek ist deutlich weniger reif als WebView2; WebKitGTK-Abhängigkeit muss auf dem Zielserver vorhanden sein; Verhalten unterscheidet sich je Plattform. |
| **B — nativ neu in Avalonia** | Chat als echte Avalonia-Ansicht mit `ItemsControl` und einem Markdown-Renderer. `EmbeddedUI/` entfällt. | 8–12 PT | Kein Fremdrisiko, aber Neuentwicklung. Am Ende deutlich wartbarer als HTML-in-Container. |
| **C — lokaler HTTP-Server + Systembrowser** | Die App liefert `EmbeddedUI/` über `http://localhost:port` aus, der Nutzer öffnet den Browser. | 3–4 PT | Bricht die Ein-Fenster-Anmutung. Passt aber ausgezeichnet zum kopflosen Betrieb — dort **ist** der Browser die Oberfläche. |

**Empfehlung:** C für den kopflosen Host (fällt dort ohnehin an), B für die
Desktop-Oberfläche. Variante A koppelt uns an eine Bibliothek, die weniger stabil
ist als alles andere im Projekt.

### 2.2 PropertyGrid → es gibt keinen Ersatz von der Stange

Vier `PropertyGrid`-Instanzen in [frm_main.Designer.cs](frm_main.Designer.cs)
bilden App-Settings, Instance-Settings, Agent-Settings und Tool-Settings ab. Sie
werden vollständig durch Attribute gesteuert — **246 `[Category]`,
`[DisplayName]`, `[Description]`-Angaben** verteilt auf vier Dateien:

- [Models/ToolSettingsViewModels.cs](Models/ToolSettingsViewModels.cs) — 108
- [Models/AgentSettingsViewModel.cs](Models/AgentSettingsViewModel.cs) — 54
- [Models/AppSettings.cs](Models/AppSettings.cs) — 51
- [Models/InstanceSettingsViewModel.cs](Models/InstanceSettingsViewModel.cs) — 33

Dazu kommen `[TypeConverter(typeof(ExpandableObjectConverter))]` für
verschachtelte Objekte, `[PasswordPropertyText(true)]` für Geheimnisse und ein
eigener [ModelTypeConverter](Models/ModelTypeConverter.cs), der das
Modell-Auswahlfeld dynamisch aus der OpenRouter-Modellliste füllt.

Avalonia hat kein `PropertyGrid`. Zwei Möglichkeiten:

1. **`Avalonia.PropertyGrid`** (Community, MIT). Versteht `Category`,
   `DisplayName`, `Description`, `Browsable`, `ReadOnly` und
   `ExpandableObjectConverter`. Die ViewModels und ihre Attribute könnten
   weitgehend unverändert bleiben — das spart am meisten. Zu prüfen ist, ob der
   dynamische `ModelTypeConverter` mit `GetStandardValues` unterstützt wird; das
   ist der Punkt, an dem so etwas erfahrungsgemäß hakt. **Aufwand 6–8 PT**, plus
   dauerhafte Abhängigkeit an ein Ein-Personen-Projekt.
2. **Von Hand gebaute Einstellungsformulare.** Mehr Arbeit, aber wir bekommen
   eine Oberfläche, die man Nutzern zumuten kann — das `PropertyGrid` ist
   ehrlicherweise eine Entwickleransicht. Passwörter, Verzeichnisauswahl,
   Validierung und die Modell-Auswahl werden dabei richtig statt behelfsmäßig.
   **Aufwand 10–14 PT.**

Das ist der größte Einzelposten der GUI-Portierung. Die Entscheidung kann und
sollte man verschieben, bis das Grundgerüst steht.

### 2.3 DPAPI → Geheimnisse liegen unter Linux im Klartext

[SecretProtector.cs:42](src/ClawdDotNet.Core/Security/SecretProtector.cs:42):

```csharp
if (!OperatingSystem.IsWindows())
    return plainText;
```

Unter Linux verschlüsselt `Protect` **stillschweigend nicht**. OpenRouter-Key,
Datenbank-Verbindungszeichenfolgen mit Passwort, Mail-Zugangsdaten und das
Telegram-2FA-Passwort lägen im Klartext in `InstanceConfig.json` und
`AgentSettings.json` — genau der Zustand, den S7 behoben hat. Auf einem Server,
der per SSH erreichbar ist und gesichert wird, ist das schlechter als auf einem
Einzelplatz-Windows.

Dasselbe gilt für den Lizenz-Zustandsspeicher:
`LicenseLabrador/client-dotnet/.../StateStore.cs:92` schützt seine Datei ebenfalls
nur unter Windows per DPAPI.

Zu klären ist also ein plattformübergreifendes Verfahren. Realistisch:

- **AES-GCM mit Schlüssel aus einer Datei mit `0600`** neben der Konfiguration
  (Linux) bzw. weiterhin DPAPI (Windows). Einfach, wirkt gegen versehentliche
  Weitergabe und Backups, nicht gegen einen Angreifer mit demselben Benutzer —
  dieselbe Schutzstufe wie DPAPI heute.
- Optional zusätzlich `libsecret`/Schlüsselbund, wenn eine Desktop-Sitzung da
  ist. Auf einem Server gibt es die nicht, also braucht es den Dateiweg ohnehin.

Nebenwirkung, die man einplanen muss: **Konfigurationen sind nicht mehr zwischen
Betriebssystemen austauschbar.** Ein `enc:v1:`-Wert von Windows ist unter Linux
nicht lesbar und umgekehrt. `Unprotect` wirft dann korrekterweise eine
`SecretProtectionException` ([SecretProtector.cs:81](src/ClawdDotNet.Core/Security/SecretProtector.cs:81)) —
für den Umzug einer Instanz braucht es einen Migrationsweg (Präfix `enc:v2:`,
Werte neu eintragen oder ein Export/Import-Kommando).

**Aufwand 3–5 PT** inklusive Tests und Migration.

### 2.4 Zeitzonen → das ist die stillste Fehlerquelle

[TaskSchedule.cs:161](src/ClawdDotNet.Core/Tasks/TaskSchedule.cs:161):

```csharp
try { return TimeZoneInfo.FindSystemTimeZoneById(id); }
catch { return TimeZoneInfo.Utc; }
```

Und [SchedulerTaskMigration.cs:32](src/ClawdDotNet.Core/Tasks/SchedulerTaskMigration.cs:32)
schreibt `TimeZoneInfo.Local.Id` in die Task-Frontmatter. Auf dem
Entwicklungsrechner ergibt das `"W. Europe Standard Time"`, unter Linux
`"Europe/Berlin"`.

Task-Dateien sind Markdown im `SharedWorkspace` und wandern zwischen Rechnern.
Trifft eine Windows-ID auf ein System ohne die Umsetzungsdaten, greift das
`catch` — und der Task läuft ab sofort nach **UTC statt Ortszeit**, also im
Sommer zwei Stunden zu früh. Ohne Fehlermeldung, ohne Logeintrag. Ein Task, der
um 08:00 die Marktübersicht holen soll, läuft um 06:00.

.NET 6+ kann Windows-IDs unter Linux über ICU auflösen, aber nur wenn ICU
vorhanden ist. In einem schlanken Container (Alpine ohne `icu-libs`, distroless)
oder bei `InvariantGlobalization=true` ist es das nicht — dann schlägt jede
Auflösung fehl und alles fällt auf UTC.

Was zu tun ist:

- Beim Schreiben auf **IANA normalisieren**
  (`TimeZoneInfo.TryConvertWindowsIdToIanaId`), beim Lesen beide Formen
  akzeptieren.
- Das `catch` **nicht mehr still schlucken** — eine unbekannte Zeitzone muss
  protokolliert werden, besser noch den Task als fehlerhaft markieren.
- Das Zielsystem muss `tzdata` haben. Für Container explizit installieren.

Verwandt: **82 Vorkommen von `DateTime.Now`/`UtcNow`**. Die meisten sind
unkritisch, zwei fallen auf:
[TaskboardService.cs:80](src/ClawdDotNet.Core/Tasks/TaskboardService.cs:80)
schreibt `DateTime.Now`-Zeitstempel in Task-Dateien, und
[LiveLogViewerService.cs:98](Services/LiveLogViewerService.cs:98) sucht die
Logdatei des Tages über `DateTime.Now`. Server laufen üblicherweise mit `TZ=UTC`
— dort wechselt die Logdatei dann um 02:00 Ortszeit statt um Mitternacht, und
Task-Zeitstempel bekommen eine andere Bedeutung als bisher. Kein Fehler, aber
eine Verhaltensänderung, die man kennen sollte.

**Aufwand 2–3 PT.**

### 2.5 Groß-/Kleinschreibung bei Pfaden → sicherheitsrelevant

Linux-Dateisysteme unterscheiden Groß- und Kleinschreibung, Windows nicht. An
vier Stellen wird das Gegenteil angenommen — und drei davon bewachen eine
Sandbox-Grenze:

- [WorkspacePath.cs:72](src/ClawdDotNet.Tools.FileRW/WorkspacePath.cs:72) —
  `normalizedCandidate.StartsWith(normalizedRoot, OrdinalIgnoreCase)`. Das ist
  die Prüfung, die Agenten daran hindert, aus ihrem Arbeitsverzeichnis
  auszubrechen.
- [FileRWTool.cs:174](src/ClawdDotNet.Tools.FileRW/FileRWTool.cs:174) —
  Abgleich gegen die Liste geschützter Pfade.
- [FtpTool.cs:155](src/ClawdDotNet.Tools.FTP/FtpTool.cs:155) — dieselbe
  Einschließungsprüfung.
- [BackupService.cs:384](src/ClawdDotNet.Core/Backup/BackupService.cs:384).

Unter Linux sind `/home/x/Workspace` und `/home/x/workspace` **zwei
verschiedene Verzeichnisse**. Der Vergleich mit `OrdinalIgnoreCase` würde einen
Pfad im zweiten als „innerhalb" des ersten durchwinken. Genauso liefe die
Sperrliste in `FileRWTool` ins Leere, sobald jemand die Schreibweise ändert.

Nötig ist ein Vergleichsverfahren, das die Plattform berücksichtigt — ein
`PathComparer`, der unter Windows `OrdinalIgnoreCase` und unter Unix `Ordinal`
verwendet, konsequent an allen vier Stellen.

Ebenfalls betroffen, aber harmlos:
[AtomicFile.cs:35](src/ClawdDotNet.Core/Storage/AtomicFile.cs:35) schlüsselt
seine Sperren mit `fullPath.ToLowerInvariant()`. Unter Linux teilen sich damit
zwei verschiedene Dateien eine Sperre — das serialisiert zu viel, gefährdet aber
nichts.

**Aufwand 2–3 PT**, davon der größere Teil Tests.

### 2.6 Prozessaufrufe und `.exe`-Annahmen

- **`Process.Start("explorer.exe", …)`** — 4 Stellen
  ([frm_main.cs:1552](frm_main.cs:1552), [frm_main.cs:1557](frm_main.cs:1557),
  [frm_main.cs:1562](frm_main.cs:1562), [BackupPanel.cs:338](UI/BackupPanel.cs:338)).
  Ersatz: `Process.Start(new ProcessStartInfo(path) { UseShellExecute = true })`
  bzw. `xdg-open`. Die Variante `explorer.exe /select,"…"` hat unter Linux kein
  Gegenstück — dort öffnet man nur den Ordner.
- **`Microsoft.VisualBasic.Interaction.InputBox`** — 3 Stellen
  ([Program.cs:280](Program.cs:280), [Program.cs:291](Program.cs:291),
  [frm_main.cs:658](frm_main.cs:658)), zwei davon für den interaktiven
  Telegram-Login (Code und 2FA-Passwort). Braucht einen eigenen Dialog. Für den
  kopflosen Betrieb ohnehin problematisch: **ein Login, der ein Eingabefenster
  öffnet, blockiert einen Dienst.** Dort muss der Telegram-Login anders gelöst
  werden (vorab per CLI, oder über die Weboberfläche).
- **`yt-dlp.exe` / `ffmpeg.exe`** —
  [SocialMediaManagerTool.cs:782](src/ClawdDotNet.Tools.SocialMediaManager/SocialMediaManagerTool.cs:782)
  und `:825`. Die PATH-Suche davor funktioniert unter Linux bereits; nur die
  Ausweichpfade sind fest auf `.exe` verdrahtet und laufen dort ins Leere.
  Kleine Änderung, aber sie fällt sonst erst zur Laufzeit auf.

**Aufwand zusammen 1–2 PT.**

### 2.7 WinForms-Timer in der Dienstschicht

`Services/` ist logisch kein UI-Code, hängt aber an
`System.Windows.Forms.Timer`:

- [BackupScheduler.cs:41](Services/BackupScheduler.cs:41)
- [LiveLogViewerService.cs:38](Services/LiveLogViewerService.cs:38) — schreibt
  zusätzlich direkt in eine `RichTextBox`
- [OpenRouterStatusService.cs:43](Services/OpenRouterStatusService.cs:43)
- [frm_main.License.cs:41](frm_main.License.cs:41)

Der Backup-Zeitplan und die Lizenzprüfung gehören in den kopflosen Host und
müssen dafür auf `System.Threading.PeriodicTimer` umgestellt werden. Der
Log-Betrachter ist echte Oberfläche und wird ohnehin neu gebaut.

**Aufwand 2–3 PT.**

### 2.8 Lizenzierung — erledigt (Stand 2026-08-06)

> **Nachtrag.** LicenseLabrador und WatchDog sind im **Deploymentcenter**
> zusammengefasst, Hardware-ID v2 ist dort umgesetzt. Der Client
> (`Deploymentcenter.Client`, `netstandard2.0;net8.0`) läuft auf beiden
> Plattformen, die HW-ID ist container- und umbenennungsfest, der Ablageort
> löst sich auch ohne `HOME` auf, und der Zustandsspeicher ist mit AES-GCM
> plattformübergreifend verschlüsselt.
>
> **Damit ist die einzige potenziell blockierende Frage dieser Analyse
> beantwortet.** Details und offene Punkte der Anbindung:
> [Deploymentcenter-Anbindung-Review.md](Deploymentcenter-Anbindung-Review.md).

Es bleibt reine Anschlussarbeit in ClawdDotNet: Projektverweis umhängen,
[LicenseGate](Services/LicenseGate.cs) gegen die neue Ergebnisklasse schreiben
(`LicenseState` ist entfallen, `Status` ist jetzt eine Zeichenkette), `MessageBox`
durch das mitgelieferte `ILicensePrompt` ersetzen und die Lizenzprüfung aus
[Program.cs:112](Program.cs:112) fensterfrei machen.

**Aufwand 2–3 PT** (vorher 3–5).

---

## 3. Kleinere Punkte, die trotzdem beißen

### 3.1 Kultur- und Zahlenformatierung

Nur 16 Stellen im gesamten Projekt nennen eine Kultur explizit. Das heißt
umgekehrt: fast alles formatiert mit `CurrentCulture`. Auf dem
Entwicklungsrechner ist das `de-DE`, auf einem Server mit unbesetztem `LANG`
ist es `InvariantCulture`. Aus `1,25` wird `1.25`.

Wo das folgenlos bleibt:
- **JSON** — `System.Text.Json` schreibt Zahlen immer invariant. Alle
  Konfigurationen, Zustandsdateien und API-Aufrufe sind sicher.
- **SQLite** — Werte gehen typisiert über Parameter, nicht als Text.

Wo hinzuschauen ist:
- Zeichenkettenverkettung in Logeinträgen und Prompts (`$"{cost:F4}"`). Wenn
  eine Zahl mit deutschem Dezimalkomma in einen Prompt gerät, muss das Modell
  raten.
- Anzeigewerte in der Oberfläche — dort ist Ortsformat gewünscht, aber es sollte
  bewusst gesetzt sein, nicht zufällig.

**Empfehlung:** einmal alle Formatierungen durchgehen und trennen — invariant
für alles Maschinenlesbare, `CurrentCulture` nur für die Anzeige. Am besten mit
einem Analyzer (`CA1305`, `CA1304`, `CA1310`) als Warnung im Build, damit es so
bleibt.

**Aufwand 2–3 PT.**

### 3.2 Globalisierungsmodus festlegen

`InvariantGlobalization=true` macht das Publikat kleiner und ICU überflüssig —
kostet aber `TimeZoneInfo.FindSystemTimeZoneById` (siehe 2.4), kulturabhängige
Vergleiche und korrektes `ToLower()` für Umlaute. Für dieses Projekt mit
zeitzonenabhängiger Planung ist das **keine Option**; die Entscheidung sollte im
Projekt dokumentiert und ICU/tzdata als Voraussetzung festgehalten werden.

Nebenbemerkung: `COLLATE NOCASE` in
[SqliteMemoryRepository.cs:143](src/ClawdDotNet.Core/Memory/SqliteMemoryRepository.cs:143)
und [SqliteTaskRepository.cs:105](src/ClawdDotNet.Core/Tasks/SqliteTaskRepository.cs:105)
ist ASCII-beschränkt — `Ä` und `ä` gelten SQLite als verschieden. Das ist heute
schon so und ändert sich beim Umzug nicht, ist also kein Portierungsthema,
sondern eine bestehende Eigenheit.

### 3.3 Zeilenenden

1.230 Stellen verwenden `Environment.NewLine` oder `\r\n`. Für Logdateien ist
das egal. Bei **Task-Dateien** und Agenten-erzeugten Dateien im geteilten
Arbeitsverzeichnis führt es zu Rauschen: Eine Datei, die unter Windows
geschrieben und unter Linux angefasst wird, ändert komplett ihre Zeilenenden.
Wenn der Arbeitsbereich unter Git liegt oder synchronisiert wird, sieht jede
Änderung wie eine Vollumschreibung aus. Der Parser kommt damit klar (siehe 1.1)
— es ist eine Frage der Ordnung, kein Fehler. Empfehlung: für Task- und
Konfigurationsdateien fest `\n` schreiben.

### 3.4 Dateinamen

`Path.GetInvalidFileNameChars()` liefert unter Windows 41 Zeichen, unter Linux
genau zwei (`\0` und `/`). [FileLogWriter.cs:95](src/ClawdDotNet.Core/Logging/FileLogWriter.cs:95)
säubert Modulnamen damit — unter Linux entstehen also Dateinamen, die auf
Windows nicht mehr lesbar sind. Betrifft Sicherungen, die zwischen Systemen
wandern. Ebenso die Windows-Sonderfälle `CON`, `PRN`, `AUX` und Namen mit
abschließendem Punkt: unter Linux erlaubt, beim Rückspielen auf Windows nicht.
Für den Sicherungs-/Wiederherstellungsweg über Systemgrenzen hinweg relevant.

### 3.5 Ablageorte

[SettingsManager.cs:24](Services/SettingsManager.cs:24) legt `AppSettings.json`
neben die Programmdatei (`AppDomain.CurrentDomain.BaseDirectory`). Unter Windows
in einem Benutzerverzeichnis geht das; unter Linux liegt die Anwendung typisch
in `/opt/…` oder `/usr/lib/…` und ist für den Dienstbenutzer **nicht
schreibbar**. Dasselbe gilt für die Zielordner `tools/`, `Logs/` und
`Instances/`, die die Build-Ziele in `ClawdDotNet.csproj` neben der
Programmdatei anlegen.

Nötig ist eine Trennung von Programm und Daten nach XDG-Konvention:
`$XDG_CONFIG_HOME` bzw. `/etc/clawddotnet` für die Konfiguration,
`$XDG_DATA_HOME` bzw. `/var/lib/clawddotnet` für Instanzen und Datenbanken,
`/var/log/clawddotnet` für Logs. Dazu Dateirechte: Instanzverzeichnisse mit
Geheimnissen gehören auf `0700`, Konfigurationsdateien auf `0600` — unter
Windows regelt das die ACL des Benutzerprofils, unter Linux muss man es setzen.

**Aufwand 2–3 PT.**

### 3.6 Tests

Von 348 Tests sind fast alle portabel. Auffällig ist
[WorkspacePathTests.cs:49](tests/ClawdDotNet.Tools.Tests/FileRW/WorkspacePathTests.cs:49):

```csharp
[InlineData(@"C:\Windows\System32\config\SAM")]
[InlineData(@"\\server\share\evil.txt")]
[InlineData(@"C:\temp\datei.txt")]
```

Unter Linux liefert `Path.IsPathRooted(@"C:\temp\datei.txt")` **`false`** — das
ist ein gewöhnlicher relativer Dateiname mit Doppelpunkt und Backslashes darin.
Der Test prüft dort also etwas anderes als beabsichtigt. Und da er die
Sandbox-Grenze absichert, ist das keine Kleinigkeit: Er muss
betriebssystemabhängig aufgeteilt werden, mit einer eigenen Linux-Fassung
(`/etc/passwd`, `../../etc/passwd`, Symlinks). Symlinks sind überhaupt ein
Prüfpunkt, den es unter Windows so nicht gab — `Path.GetFullPath` löst sie
**nicht** auf, `File.ResolveLinkTarget` schon. Ein Agent könnte im
Arbeitsverzeichnis einen Symlink nach `/etc` anlegen und die Prüfung ginge
durch.

Ebenso in [YouTubeUrlTests.cs:118](tests/ClawdDotNet.Tools.Tests/SocialMedia/YouTubeUrlTests.cs:118)
(harmlos, nur Beispieldaten).

**Aufwand 2–4 PT**, inklusive Symlink-Absicherung in `WorkspacePath` selbst.

### 3.7 Bau und Auslieferung

[Deploy-Build.ps1](Deploy-Build.ps1) setzt PowerShell 5.1 voraus, verwendet
Backslash-Pfade und den festen Ausgabepfad `bin\Release\net10.0-windows`. Für
Linux braucht es entweder eine `pwsh`-taugliche Fassung oder — besser — einen
schlichten `dotnet publish -r linux-x64 --self-contained` mit einer
systemd-Unit-Datei. Dazu:

- systemd-Unit mit eigenem Dienstbenutzer, `Restart=on-failure`
- Prüfen, ob der bestehende Watchdog-Heartbeat
  ([Program.cs:367](Program.cs:367)) mit `systemd-notify` zusammenspielen soll
- optional `.deb` oder AppImage für den Desktop-Fall

**Aufwand 3–5 PT.**

---

## 4. Der empfohlene Schnitt

Der entscheidende Befund dieser Analyse: **Die Oberfläche ist nicht der Grund,
warum wir Linux wollen.** Der Grund ist, dass Agenten auf einem Server laufen
sollen. [Program.cs](Program.cs) baut bereits alles — Speicher, Engine,
Taskboard-Scanner, Watchdog, Lizenzprüfung — vollständig auf, **bevor**
`frm_main` überhaupt entsteht (Zeilen 36–385 gegen 388–401). Diese Trennung
existiert faktisch schon; sie muss nur formalisiert werden.

### Stufe 1 — Kern Linux-fest und kopfloser Host (12–18 PT)

| Schritt | PT |
|---|---:|
| Geheimnisse plattformübergreifend (2.3) | 3–5 |
| Zeitzonen normalisieren, Fehler nicht mehr schlucken (2.4) | 2–3 |
| Pfadvergleiche plattformabhängig + Symlink-Prüfung (2.5, 3.6) | 3–5 |
| Prozessaufrufe, `.exe`-Pfade (2.6) | 1–2 |
| Ablageorte und Dateirechte nach XDG (3.5) | 2–3 |
| `ClawdDotNet.Host` — Startlogik aus `Program.cs` herauslösen, `PeriodicTimer` statt WinForms-Timer, Telegram-Login ohne Dialog | 4–6 |
| Tests auf Linux grün, CI-Lauf für linux-x64 | 2–3 |

**Ergebnis:** Die Anwendung läuft als systemd-Dienst auf einem Linux-Server. Die
Windows-GUI bleibt unverändert bestehen und wird weiter benutzt. Das ist der
Punkt, an dem der Nutzen anfällt.

### Stufe 2 — Avalonia-Oberfläche (32–52 PT)

| Schritt | PT |
|---|---:|
| Grundgerüst: Avalonia-Projekt, DI, Dispatcher, Shell mit Tabs, MVVM-Schicht | 5–7 |
| Logs-Tab (`RichTextBox` → `SelectingItemsControl` mit Filterung) | 2–3 |
| Agent-Settings: Liste, Werkzeugauswahl, Aktionsschaltflächen | 5–8 |
| Einstellungs-Tabs — PropertyGrid-Ersatz (2.2) | 6–10 |
| Jobs / Services / Job History (4 `DataGridView`) | 4–6 |
| Backup-Panel | 3–4 |
| Instance-Manager und die fünf Dialoge | 4–6 |
| Chat-Ansicht (Variante B, siehe 2.1) | 8–12 |
| Info, Statusleiste, Werkzeugleisten, Menü, Lokalisierung de/en | 3–4 |

Die Spanne ist breit, weil zwei Entscheidungen noch offen sind (PropertyGrid-Ersatz
und Chat-Variante). Sind die getroffen, lässt sich das auf etwa ±15 % genau
angeben.

### Stufe 3 — Auslieferung und Härtung (6–10 PT)

Publish-Pipeline, systemd-Unit, Paketierung, Abnahme auf echter Hardware,
Dokumentation, Umzugsweg für bestehende Instanzen.

### Gesamt

| | PT | bei Vollzeit |
|---|---:|---|
| Stufe 1 | 12–18 | 2,5–3,5 Wochen |
| Stufe 2 | 32–52 | 6,5–10,5 Wochen |
| Stufe 3 | 6–10 | 1,5–2 Wochen |
| **Summe** | **50–80** | **10–16 Wochen** |

---

## 5. LiveCharts2

Zur Einordnung: **Das Projekt enthält heute keine einzige Diagrammdarstellung.**
Die Suche nach `Chart`, `Series` oder `Plot` findet nur JSON-Feldnamen der
Yahoo-Finance-Abfrage in
[DirectAPITool.cs:126](src/ClawdDotNet.Tools.DirectAPI/DirectAPITool.cs:126).

LiveCharts2 ist damit **keine Portierung, sondern neue Funktionalität** — sie
gehört zum Trading-Teil, nicht zum Linux-Umzug, und ist in den 50–80 PT oben
nicht enthalten. Wenn die Kursansichten kommen, sind dafür grob 5–10 PT
zusätzlich zu rechnen. Das passt zu dem, was in
[docs/Roadmap.md](../Roadmap.md) und der Notiz „Basis vor Trading härten"
festgehalten ist: Erst die Basis, dann die Handelsansichten.

Ein Punkt, der jetzt schon zählt: LiveCharts2 setzt auf SkiaSharp, genau wie
Avalonia. Das spricht zusätzlich dafür, die Diagramme erst **nach** der
Avalonia-Portierung zu bauen — sonst entstehen sie zweimal.

---

## 6. Was vor dem ersten Handgriff zu entscheiden ist

1. **Ist das Ziel Server oder Desktop?** Bei „Server" reicht Stufe 1, und Stufe 2
   kann entfallen oder durch eine Weboberfläche ersetzt werden. Das ändert die
   Schätzung um den Faktor drei.
2. **Chat-Ansicht: HTML behalten oder nativ neu bauen?** (2.1)
3. **PropertyGrid: Fremdbibliothek oder eigene Formulare?** (2.2)
4. ~~**Erlaubt LicenseLabrador den Wechsel der Hardware-ID?**~~ — **geklärt**,
   siehe 2.8 und
   [Deploymentcenter-Anbindung-Review.md](Deploymentcenter-Anbindung-Review.md).
5. **Bleibt Windows als Zielplattform bestehen?** Wenn ja, muss alles doppelt
   getestet werden, und die Geheimnis-Verschlüsselung braucht beide Wege plus
   Umzugspfad. Wenn nein, wird 2.3 deutlich einfacher.

Frage 1 und 5 beantworten sich vermutlich schnell; 2 und 3 kann man bis zum
Beginn von Stufe 2 offenlassen, ohne Stufe 1 zu blockieren. Damit liegt nichts
mehr außerhalb unserer Hand — **Stufe 1 kann beginnen.**

---

## Anhang — Vollständige Fundstellenliste

| Thema | Datei:Zeile |
|---|---|
| DPAPI | [SecretProtector.cs:42](src/ClawdDotNet.Core/Security/SecretProtector.cs:42), `:66`, `:90`, `:94` |
| DPAPI (Lizenz) | `LicenseLabrador/client-dotnet/.../StateStore.cs:43`, `:92` |
| Zeitzone | [TaskSchedule.cs:161](src/ClawdDotNet.Core/Tasks/TaskSchedule.cs:161), [SchedulerTaskMigration.cs:32](src/ClawdDotNet.Core/Tasks/SchedulerTaskMigration.cs:32) |
| Pfad-Groß-/Kleinschreibung | [WorkspacePath.cs:72](src/ClawdDotNet.Tools.FileRW/WorkspacePath.cs:72), [FileRWTool.cs:174](src/ClawdDotNet.Tools.FileRW/FileRWTool.cs:174), [FtpTool.cs:155](src/ClawdDotNet.Tools.FTP/FtpTool.cs:155), [BackupService.cs:384](src/ClawdDotNet.Core/Backup/BackupService.cs:384), [AtomicFile.cs:35](src/ClawdDotNet.Core/Storage/AtomicFile.cs:35) |
| `explorer.exe` | [frm_main.cs:1552](frm_main.cs:1552), `:1557`, `:1562`, [BackupPanel.cs:338](UI/BackupPanel.cs:338) |
| `VisualBasic.InputBox` | [Program.cs:280](Program.cs:280), `:291`, [frm_main.cs:658](frm_main.cs:658) |
| `.exe`-Werkzeugpfade | [SocialMediaManagerTool.cs:782](src/ClawdDotNet.Tools.SocialMediaManager/SocialMediaManagerTool.cs:782), `:825` |
| WinForms-Timer | [BackupScheduler.cs:41](Services/BackupScheduler.cs:41), [LiveLogViewerService.cs:38](Services/LiveLogViewerService.cs:38), [OpenRouterStatusService.cs:43](Services/OpenRouterStatusService.cs:43), [frm_main.License.cs:41](frm_main.License.cs:41) |
| WebView2 | [frm_main.cs:235](frm_main.cs:235), [frm_chat.cs:44](frm_chat.cs:44), [WebViewBridge.cs](UI/WebViewBridge.cs), [ClawdDotNet.csproj](ClawdDotNet.csproj) |
| PropertyGrid | [frm_main.Designer.cs](frm_main.Designer.cs) (4×), [Models/](Models/) (246 Attribute) |
| Datenablage | [SettingsManager.cs:24](Services/SettingsManager.cs:24), [ClawdDotNet.csproj](ClawdDotNet.csproj) (Build-Ziele) |
| Testdaten mit Windows-Pfaden | [WorkspacePathTests.cs:49](tests/ClawdDotNet.Tools.Tests/FileRW/WorkspacePathTests.cs:49) |
| Build-Skript | [Deploy-Build.ps1](Deploy-Build.ps1) |