ClaudeDo/docs/plan.md

ToDo-App mit autonomem Agent-Worker — Design

Context

Ziel: eine persönliche ToDo-App als Desktop-Anwendung, in der mehrere Listen verwaltet werden können. Ein Teil der Tasks soll autonom von Claude abgearbeitet werden (z.B. Recherche, Code-Aufgaben, Notizen-Verarbeitung). Die Autonomie läuft in einem getrennten Hintergrund-Prozess, damit die UI davon entkoppelt bleibt.

Motivation: Aufgaben "parken" und später von einem Agenten abarbeiten lassen, ohne dafür manuell einen Chat zu öffnen. Ergebnisse landen wieder an der Task, sodass die Liste die Single-Source-of-Truth bleibt.

Listen können ein eigenes working_dir (z.B. ein Projekt-Repo) haben. Tasks solcher Listen laufen in einem dedizierten Git-Worktree, der Worker commitet die Änderungen am Ende automatisch. Die UI zeigt Branch + Diff und erlaubt Merge/Keep/Discard.

Architektur-Überblick

Monorepo (C:\Private\ClaudeDo, gehostet auf git.kuns.dev), zwei Prozesse, gekoppelt über eine gemeinsame SQLite-Datenbank:

┌─────────────────────┐        ┌──────────────────────────────┐
│  UI (Avalonia .NET) │        │  Worker (.NET 8 Console)     │
│  Listen, Tasks,     │◄──────►│  BackgroundService           │
│  Diff/Merge-Dialog  │ SQLite │  spawnt: claude -p ...       │
└─────────────────────┘  WAL   │  cwd = Worktree der Task     │
         │                     └──────────┬───────────────────┘
         │                                │ stdout (ndjson)
         └─────── todo.db ────────────────┘
                  (~/.todo-app/todo.db)

  Ziel-Repo (z.B. LagerApp):
    C:\Private\LagerApp\                              (main repo, unangetastet)
    C:\Private\.claudedo-worktrees\<list>\<task-id>\  (Worktree pro Task)

• UI (ClaudeDo.Ui, Avalonia MVVM): Listen & Tasks verwalten, Ergebnisse + Diffs anzeigen, Worktree-Aktionen.
• Worker (ClaudeDo.Worker, .NET 8 Console mit Kestrel + SignalR): hostet einen SignalR-Hub auf localhost, verwaltet die Queue intern, spawnt Claude CLI als Child-Prozess pro Task, streamt Events live an die UI, commitet, persistiert Ergebnisse.
• SQLite im WAL-Mode für persistente Daten (Listen, Tasks, Tags, Worktrees). Keine Koordinations-Felder — Live-Status läuft über SignalR.
• SignalR über localhost-HTTP (Default-Port 47821, konfigurierbar) als Push-Channel zwischen Worker und UI. UI-Connection-State ⇒ "Worker online".

Datenmodell

Schema in 3NF. Keine Mehrwert-Felder (z.B. JSON-Arrays), keine transitiven Abhängigkeiten: Worktree-Attribute wandern in eine eigene Tabelle, Tags sind über Junctions modelliert, Worker-Slots sind eigene Rows.

lists

• id TEXT PK (uuid)
• name TEXT NOT NULL
• created_at TIMESTAMP NOT NULL
• working_dir TEXT NULL — absoluter Pfad. Gesetzt + Git-Repo → Worktree-Modus.
• default_commit_type TEXT NOT NULL DEFAULT 'chore'

tasks

• id TEXT PK (uuid)
• list_id TEXT NOT NULL REFERENCES lists(id) ON DELETE CASCADE
• title TEXT NOT NULL
• description TEXT NULL
• status TEXT NOT NULL — manual | queued | running | done | failed (running bleibt persistiert für Crash-Recovery: stale running-Tasks werden beim Worker-Start auf failed gesetzt)
• scheduled_for TIMESTAMP NULL — "nicht vor"
• result TEXT NULL (Markdown)
• log_path TEXT NULL — Pfad zur ndjson-Log-Datei
• created_at TIMESTAMP NOT NULL
• started_at TIMESTAMP NULL
• finished_at TIMESTAMP NULL
• commit_type TEXT NOT NULL DEFAULT 'chore' — Conventional-Commit-Prefix (wird beim Anlegen aus list.default_commit_type befüllt, danach unabhängig).

tags

• id INTEGER PK AUTOINCREMENT
• name TEXT NOT NULL UNIQUE — z.B. agent, manual, code, research

list_tags (Junction, Liste hat 0..n Tags)

• list_id TEXT NOT NULL REFERENCES lists(id) ON DELETE CASCADE
• tag_id INTEGER NOT NULL REFERENCES tags(id) ON DELETE CASCADE
• PK (list_id, tag_id)

task_tags (Junction, Task hat 0..n Tags; überschreibt die List-Tags nicht automatisch — die Vereinigung aus list_tags ∪ task_tags bildet die effektive Tag-Menge der Task; Ausschluss über noch zu spezifizierenden Negations-Mechanismus, bis dahin additiv)

• task_id TEXT NOT NULL REFERENCES tasks(id) ON DELETE CASCADE
• tag_id INTEGER NOT NULL REFERENCES tags(id) ON DELETE CASCADE
• PK (task_id, tag_id)

worktrees (1:1 mit Tasks, die im Worktree-Modus laufen)

• task_id TEXT PK REFERENCES tasks(id) ON DELETE CASCADE — Task hat höchstens einen Worktree.
• path TEXT NOT NULL — absoluter Pfad zum Worktree.
• branch_name TEXT NOT NULL — z.B. claudedo/<task-id-kurz>.
• base_commit TEXT NOT NULL — SHA des working_dir-HEAD beim Anlegen.
• head_commit TEXT NULL — SHA nach Auto-Commit (NULL bis Commit erfolgt).
• diff_stat TEXT NULL — Output von git diff --stat base..head.
• state TEXT NOT NULL DEFAULT 'active' — active | merged | discarded | kept.
• created_at TIMESTAMP NOT NULL

Die Abwesenheit einer worktrees-Zeile entspricht dem alten Wert 'none'. Non-Worktree-Tasks (Liste ohne working_dir) erzeugen keine Zeile.

Hinweis: Es gibt keine worker_heartbeat- oder worker_slots-Tabelle. Worker-Online-Status und aktive Slots laufen über SignalR (siehe Sektion "IPC").

Tag-Modell (Startset)

• Tags leben in tags, Zuordnung via list_tags und task_tags (Junctions).
• Effektive Tag-Menge einer Task = list_tags(task.list_id) ∪ task_tags(task.id) (additiv).
• Minimal-Startset in tags:
  • manual → Worker ignoriert, reine Notiz/Checkliste.
  • agent → Worker pickt auf, wenn Status queued.
• Weitere Profile (code, research …) später als zusätzliche Rows in tags + Handler im Worker.

IPC (SignalR)

Worker hostet Microsoft.AspNetCore.SignalR über Kestrel auf http://127.0.0.1:<port>/hub (Default 47821, in worker.config.json überschreibbar). Bindung nur an Loopback. Kein Auth-Layer.

Hub: WorkerHub

Server-Methoden (UI ruft auf):

• GetActive() → [{ slot: "queue"|"override", taskId, startedAt }] — initialer State-Sync nach Connect.
• RunNow(taskId) → triggert sofortigen Override-Run; wirft, wenn Override-Slot belegt oder Task nicht existiert.
• CancelTask(taskId) → killt laufenden CLI-Child-Prozess der Task.
• WakeQueue() → Worker prüft Queue sofort (für instant pickup nach Task-Anlage).
• Ping() → "pong" + Worker-Version (Sanity-Check).

Client-Methoden (Worker pusht an UI):

• TaskStarted(slot, taskId, startedAt)
• TaskFinished(slot, taskId, status, finishedAt) — Status done | failed.
• TaskMessage(taskId, ndjsonLine) — streamt jedes Claude-Event live (für Live-Log in TaskDetail).
• WorktreeUpdated(taskId) — Auto-Commit fertig, UI lädt worktrees-Row neu.
• TaskUpdated(taskId) — generisches Signal: UI lädt Task neu (z.B. nach Result-Persist).

Connection-State der UI ⇒ "Worker online" (kein Heartbeat in DB nötig).

UI-Verhalten bei offline Worker:

• StatusBar: "Worker offline".
• "Run Now" deaktiviert (RPC nicht möglich).
• Task-Anlage funktioniert weiter (DB-only); wird beim nächsten Worker-Start aufgenommen.

Queue-Semantik

• Default: Tasks mit Tag agent und Status queued werden sequenziell abgearbeitet (FIFO, nach created_at). Worker-interner In-Memory-Slot _queueSlot.
• Schedule: scheduled_for gesetzt → Worker überspringt, bis Zeit erreicht.
• Override: UI ruft RunNow(taskId) per SignalR. Worker startet die Task in _overrideSlot parallel zur Queue. Max. 1 Queue + 1 Override = 2 gleichzeitige Runs.
• Zweiter RunNow während Override-Slot belegt → SignalR-Methode wirft, UI zeigt "Override bereits aktiv".
• Wake-up: Bei Task-Anlage ruft die UI WakeQueue(), damit der Worker nicht erst auf den nächsten Tick warten muss.

Worker-Komponenten (.NET)

Projekt: ClaudeDo.Worker — Microsoft.NET.Sdk.Web Console-App (für Kestrel + SignalR), Teil von ClaudeDo.sln, referenziert ClaudeDo.Data.

• Program.cs — WebApplication.CreateBuilder + AddSignalR() + AddHostedService<QueueService>(). app.MapHub<WorkerHub>("/hub") auf konfiguriertem Loopback-Port. Bindung: app.Urls.Add($"http://127.0.0.1:{cfg.Port}").
• Hub/WorkerHub.cs — implementiert die in der IPC-Sektion beschriebenen Methoden. Delegiert RunNow/CancelTask/WakeQueue an QueueService. GetActive() liest aus den In-Memory-Slots.
• Hub/HubBroadcaster.cs — Wrapper um IHubContext<WorkerHub> mit typisierten TaskStarted/TaskFinished/TaskMessage/WorktreeUpdated/TaskUpdated-Methoden. Wird in TaskRunner und ClaudeProcess injiziert.
• Services/QueueService.cs — BackgroundService, interner Timer (z.B. 30s als Backstop, primärer Trigger ist WakeQueue). Wählt nächste Task (Tag agent via task_tags/list_tags, scheduled_for ≤ now, _queueSlot frei). Hält In-Memory-Slots _queueSlot, _overrideSlot. Sendet TaskStarted/TaskFinished über HubBroadcaster.
• Services/StaleTaskRecovery.cs — beim Start: alle tasks.status='running' → 'failed', Begründung "worker restart".
• Runner/TaskRunner.cs — orchestriert eine Task-Ausführung (siehe Lifecycle unten).
• Runner/WorktreeManager.cs — kapselt git worktree add/remove, git rev-parse, git diff --stat, git add -A && git commit.
• Runner/ClaudeProcess.cs — kapselt System.Diagnostics.Process:
  • Cmd: claude -p --output-format stream-json --verbose --dangerously-skip-permissions
  • WorkingDirectory = worktreePath (bzw. Sandbox-Dir bei Listen ohne working_dir).
  • Prompt über stdin (vermeidet Quoting-Probleme mit Zeilenumbrüchen).
  • Async stdout-Reader, jede Zeile = 1 JSON-Event → an LogWriter, MessageParser und HubBroadcaster.TaskMessage(taskId, line).
  • stderr in Log mit [stderr]-Prefix.
  • Finales type:"result" → .result-Feld extrahieren (Markdown).
  • Exit != 0 oder fehlendes Result → Task failed, Fehler ins result-Feld.
• Runner/LogWriter.cs — streamt ndjson nach ~/.todo-app/logs/<task-id>.ndjson.
• Runner/CommitMessageBuilder.cs — baut Conventional-Commit-Message (siehe unten).
• Config/WorkerConfig.cs — lädt ~/.todo-app/worker.config.json:

  {
    "db_path": "~/.todo-app/todo.db",
    "sandbox_root": "~/.todo-app/sandbox",
    "log_root": "~/.todo-app/logs",
    "worktree_root_strategy": "sibling",
    "central_worktree_root": "~/.todo-app/worktrees",
    "queue_backstop_interval_ms": 30000,
    "signalr_port": 47821,
    "claude_bin": "claude"
  }
  

  Kein API-Key — CLI nutzt die bestehende User-Session.

Dependencies: Microsoft.AspNetCore.App (Kestrel + SignalR via Microsoft.NET.Sdk.Web), Microsoft.Extensions.Hosting, Microsoft.Data.Sqlite (via ClaudeDo.Data), System.Text.Json.

Task-Lifecycle (Worktree-Modus)

Nur wenn list.working_dir gesetzt und ein Git-Repo ist:

1. Worktree anlegen (WorktreeManager.CreateAsync):
   • base = git -C <working_dir> rev-parse HEAD
   • branch = claudedo/<task-id-kurz>
   • worktreePath = <working_dir>/../.claudedo-worktrees/<list-slug>/<task-id>/
   • git -C <working_dir> worktree add -b <branch> <worktreePath> <base>
   • Insert in worktrees: task_id, path, branch_name, base_commit, state='active', created_at=now.
2. Claude-Run via ClaudeProcess.RunAsync(prompt, worktreePath, ...).
3. Auto-Commit (WorktreeManager.CommitAsync), nur wenn Run erfolgreich UND Änderungen vorhanden:
   • git -C <worktreePath> add -A
   • Nichts staged → skippen (head = base).
   • Sonst: git commit -m <conventional-message> (Author aus User-Git-Config).
   • head = rev-parse HEAD, diff_stat = git diff --stat base..head.
   • Update worktrees: head_commit, diff_stat.
4. Status finalisieren: tasks.status='done', tasks.result = Claude-Result-Markdown, tasks.finished_at=now.
5. Kein Auto-Cleanup. worktrees.state bleibt 'active', bis der User über die UI eine Aktion wählt.

Fehlerpfade:

• Run failed / Exit != 0 → tasks.status='failed', kein Auto-Commit, worktrees-Row bleibt mit state='active' zur Inspektion.
• working_dir ist kein Git-Repo → Task failed mit klarer Meldung; keine worktrees-Row, keine Fallback-Sandbox.
• Worktree-Anlegen failed (Branch/Dir existiert) → Task failed; keine worktrees-Row geschrieben; Runner räumt nicht auf.

Non-Worktree-Modus (list.working_dir NULL): cwd = ~/.todo-app/sandbox/<task-id>/, kein Git, Standard-Toolset wie bisher.

Conventional Commit Message

Format: {type}({list-slug}): {title}

• type = task.commit_type (Default chore).
• {list-slug} = list.name lowercased, whitespace→-, nicht-alphanumerisch entfernt.
• {title} = task.title, truncated auf 60 Zeichen.
• Body (optional, zweizeilig nach Leerzeile):

  {task.description, max 400 chars}
  
  ClaudeDo-Task: <task-id>
  

Beispiel: feat(lager-app): add barcode scan retry logic

UI-Komponenten (Avalonia)

• MainWindow mit 2-Pane-Layout: links Listen, rechts Tasks der gewählten Liste.
• ListEditor — Feld Working Directory (Ordner-Picker), Default Commit Type Dropdown.
• TaskItemView zeigt Titel, Tags, Status (Badge), "Run Now"-Button (→ ruft WorkerHub.RunNow(taskId); deaktiviert wenn Worker offline).
• TaskDetailPane — Description, Result-Markdown (AvaloniaEdit oder Markdown.Avalonia), Link zum ndjson-Log.
  • Bei vorhandener worktrees-Row mit state='active': Branch, diff_stat, Buttons Open Worktree, Show Diff, Merge into main, Keep as branch, Discard.
  • Merge into main: git -C <working_dir> merge --ff-only <branch> (UI warnt bei non-ff) → worktrees.state='merged', Worktree + Branch entfernen.
  • Keep as branch: Worktree entfernen, Branch behalten → worktrees.state='kept'.
  • Discard: git worktree remove --force + git branch -D → worktrees.state='discarded'.
• TaskEditor — Dropdown Commit Type (Default aus Liste).
• StatusBar — Worker-Status aus SignalR-Connection-State (Connected ⇒ online), aktive Tasks aus In-Memory-State (initial via GetActive(), danach via TaskStarted/TaskFinished-Events).
• TaskDetailPane zeigt bei laufender Task den Live-Stream der TaskMessage-Events (rolling Log).
• WorkerClient (ClaudeDo.Ui/Services/WorkerClient.cs) — kapselt HubConnection, Auto-Reconnect, exponiert IObservable<…>-Events bzw. INotifyPropertyChanged-Properties für die ViewModels.
• SettingsDialog — Default-Tags, Pfad zur todo.db, SignalR-Port (muss zum Worker passen).

DB-Zugriff via Microsoft.Data.Sqlite + Repository-Layer (TaskRepository, ListRepository). Git-Operationen (UI + Worker) über gemeinsamen GitService in ClaudeDo.Data. MVVM via CommunityToolkit.Mvvm.

Worker als Windows-Service (Ziel-Deployment)

Initial läuft der Worker als Console-Prozess (lokales Dev-Setup). Im Endzustand soll er als Windows-Service automatisch starten.

Code-seitig:

• Paket Microsoft.Extensions.Hosting.WindowsServices referenzieren.
• In Program.cs: builder.Host.UseWindowsService(o => o.ServiceName = "ClaudeDoWorker").
• Logging zusätzlich über EventLog (builder.Logging.AddEventLog(...)), damit Service-Fehler im Windows Event Viewer landen.
• Alle Pfade in worker.config.json absolut auflösen (%USERPROFILE% / ~ expandieren) — der Service-Working-Directory ist standardmäßig C:\Windows\System32.
• StaleTaskRecovery (siehe oben) sorgt nach Service-Restart automatisch für das Aufräumen hängender running-Tasks.
• Restart-Verhalten via sc.exe failure-Konfig oder beim Install.

Install:

• Veröffentlichen mit dotnet publish -c Release -r win-x64 --self-contained false.
• Service registrieren:

  sc.exe create ClaudeDoWorker binPath= "C:\Path\To\ClaudeDo.Worker.exe" start= auto
  sc.exe failure ClaudeDoWorker reset= 60 actions= restart/5000/restart/10000/restart/30000
  

• Später optional: kleines ClaudeDo.Installer-Projekt (WiX oder MSIX), das das auch macht.

Auth-Konflikt mit "User-CLI-Session" beachten: Der Worker-Service läuft per Default unter LocalSystem — der hat keinen Zugriff auf die ~/.claude/-Session des interaktiven Users, in der der CLI-Login liegt. Optionen:

1. Empfohlen: Service unter dem User-Account laufen lassen (sc.exe config ClaudeDoWorker obj= ".\<username>" password= "..." oder via services.msc → "Log On As"). Dann greift die bestehende claude login-Session des Users. Voraussetzung: User-Account hat das Recht "Log on as a service".
2. Fallback: Wieder auf API-Key wechseln (ANTHROPIC_API_KEY als Umgebungsvariable des Service oder im worker.config.json). Dann ist der Service unabhängig vom User-Profil — verliert aber den Vorteil "kein Key-Handling".

Entscheidung wird beim Service-Deployment getroffen, bleibt für die initiale Console-Variante irrelevant. Service-Modus erfordert keine Schema- oder API-Änderungen am Worker.

SignalR im Service-Modus: Bindung bleibt 127.0.0.1:47821. Da die UI auf demselben Rechner läuft, ist Loopback-Erreichbarkeit gegeben — Windows-Firewall greift bei Loopback nicht.

Project-Layout (Monorepo)

Repo: ClaudeDo auf git.kuns.dev, lokal C:\Private\ClaudeDo

/ClaudeDo
  ClaudeDo.sln
  /src
    /ClaudeDo.App              Avalonia Entry (App.axaml, Program.cs)
    /ClaudeDo.Ui               Views, ViewModels, Worktree-Dialoge
    /ClaudeDo.Data             Repositories, Models, SqliteConnectionFactory, GitService
    /ClaudeDo.Worker           Console/BackgroundService
  /tests
    /ClaudeDo.Worker.Tests     xUnit, In-Memory-SQLite + temp-Repo für Worktree-Tests
  /schema
    schema.sql                 Single source of truth für DB-Schema
    migrations/                (später, falls nötig)
  /docs
    plan.md, architecture.md
  .gitignore                   bin/, obj/, *.db, worker.config.json, logs/

Vorteil Monorepo: gemeinsames schema.sql, atomische Änderungen über UI+Worker, ein Clone reicht, einheitlicher .NET-Stack.

Verification

1. Schema-Init: Worker erstellt todo.db bei erstem Start mit WAL, legt alle Tabellen an (lists, tasks, tags, list_tags, task_tags, worktrees). Initial werden in tags die Rows 'agent' und 'manual' eingefügt. → sqlite3 todo.db ".schema" zeigt die erwartete Struktur in 3NF. 1a. SignalR-Endpoint: Worker startet, curl -i http://127.0.0.1:47821/hub antwortet (HTTP 400 Negotiate-Fehler ohne SignalR-Handshake ist OK — Hauptsache Port lauscht und nur auf Loopback). 1b. Hub-Roundtrip (UI- oder Test-Client): connection.InvokeAsync<string>("Ping") liefert "pong".
2. CLI-Preflight: claude --version läuft, User eingeloggt. Worker-Startup-Check failed laut, wenn nicht erfüllt.
3. Smoke-Spawn (Unit-Test): claude -p --output-format stream-json --dangerously-skip-permissions, Prompt "ping" via stdin → result-Message erhalten + geparst.
4. End-to-End Happy Path (Non-Worktree):
   • UI: Liste "Test" (kein working_dir), Task mit Tag agent + Status queued, Description "Schreibe eine Haiku über Intralogistik".
   • Worker erkennt Task binnen 5s (Log: picked up task <id>), startet CLI-Run, schreibt Result zurück.
   • UI zeigt Status done + Result-Markdown.
5. Worktree-Happy-Path (Integrations-Test mit temp-Repo):
   • Liste mit working_dir=<temp-repo>, Task "add hello.txt with content hi".
   • Nach Run: Worktree unter <temp-repo>/../.claudedo-worktrees/<slug>/<id>/, hello.txt drin, 1 Commit chore(<slug>): add hello.txt auf Branch claudedo/<id-kurz>. worktrees-Row für die Task: head_commit != base_commit, diff_stat gesetzt, state='active'.
6. No-Changes-Run: Prompt, der nichts ändert → tasks.status='done', kein Commit, worktrees.head_commit IS NULL (oder = base_commit).
7. Kein Git-Repo: working_dir auf normalen Ordner → Task failed mit klarer Meldung, keine worktrees-Row.
8. Merge-UI: nach erfolgreichem Run Button "Merge into main" → <working_dir> HEAD enthält den Commit, Branch + Worktree weg, worktrees.state='merged'.
9. Override-Parallelität: Zwei queued Tasks → nur eine läuft. Bei zweiter "Run Now" klicken → WorkerHub.RunNow succeeded, beide laufen parallel, UI bekommt zwei TaskStarted-Events (slots queue + override), in Worktree-Listen zwei getrennte Worktrees. Dritter RunNow → SignalR-Exception "override slot busy".
10. Schedule: Task mit scheduled_for = now + 2min → Worker wartet; nach Ablauf startet sie.
11. Worker-Offline-Erkennung: Worker-Prozess killen → SignalR-Connection bricht ab, UI-StatusBar wechselt sofort auf "offline" (kein Polling-Lag). "Run Now"-Buttons werden disabled. Laufende Task bleibt running → beim nächsten Worker-Start setzt StaleTaskRecovery sie auf failed, worktrees-Row bleibt zur Inspektion. UI reconnected automatisch und ruft erneut GetActive() für den State-Sync.
12. Live-Stream: Während eine Task läuft, UI öffnet TaskDetailPane → ndjson-Events erscheinen in Echtzeit (jedes TaskMessage-Event wird angehängt).
13. Wake-up: Task in UI anlegen mit Tag agent, Status queued → UI ruft WakeQueue() → Worker startet die Task in < 1s (nicht erst nach Backstop-Intervall).
14. Unit-Tests (Worker): QueueService-Selection-Logik (Override-Slot-Belegung, Schedule-Filter, Sequenzialität) mit In-Memory-SQLite. Hub-Methoden mit TestServer + HubConnectionBuilder.

Offene Punkte für später (nicht Scope dieses Plans)

• Zusätzliche Tag-Profile mit spezialisierten Toolsets (code → engere Permissions, research → Netzwerk).
• MCP-Server-Integration für externe Dienste.
• Notification bei Task-fertig (Windows Toast).
• Non-ff Merges (Rebase-/Squash-Option im UI).
• Bulk-Discard alter Worktrees.
• Anzeige der ndjson-Message-Chronik im UI.
• Windows Job Objects für garantierten Child-Cleanup beim Worker-Crash.
• Installer-Projekt (ClaudeDo.Installer, WiX/MSIX), das den Service registriert + UI shortcut anlegt.