Files
tessera-ctl/.planning/todos/pending/2026-09-15-desktop-client-auslieferungsreif-machen.md
T
schalli 5f50c5faa0
Tessera CI/CD / Lint & Type Check (push) Successful in 44s
Tessera CI/CD / Tests (push) Successful in 52s
Tessera CI/CD / Build & Publish Images (push) Successful in 2m48s
docs: Todo — Desktop-Client auslieferungsreif machen (Versions-Check, Windows-Installer, Abnahme, CI-Bau)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018N9CD3ebPKm1b32bPpBknY
2026-09-15 21:40:15 +02:00

3.2 KiB


created: 2026-09-15T19:39:37.195Z title: Desktop-Client auslieferungsreif machen — Versions-Check, Windows-Installer, Abnahme, CI-Bau area: desktop severity: minor trigger: Sobald der User eine Bau- und Testmoeglichkeit fuer Windows organisiert hat (User 2026-09-15: "Da finden wir was. Evtl. sogar so, dass du im Browser selbst testen kannst"). Reiner Komfort — der Betrieb im Browser braucht den Client nicht. Nicht von uns aus draengen. files:

  • apps/desktop/src-tauri/src/lib.rs:82-100
  • apps/desktop/src-tauri/tauri.conf.json:4
  • apps/desktop/src-tauri/tauri.conf.json:29
  • apps/desktop/src/setup.html
  • .gitea/workflows/ci.yml
  • .planning/phases/06-desktop-client-ci-cd/06-02-SUMMARY.md

Problem

Phase 6 (Juni 2026) hat den Tauri-Rahmen um die Web-Oberflaeche gebaut (apps/desktop): Server-Adresse beim ersten Start, WebView auf die Installation, Tray mit Schliessen-in-den-Tray, Fensterzustand, Autostart, Benachrichtigungen, Versions-Check, Tessera-Symbol, Ziele AppImage + NSIS. Seit dem 2026-06-25 nicht mehr angefasst. Vier Dinge stehen zwischen dem Stand und einer Auslieferung:

  1. Versions-Check ist seit 260914-ku1 falsch. lib.rs vergleicht info.version aus GET /health/version (jetzt z. B. v1.0.0, Stempel des Server-Abbilds) mit CARGO_PKG_VERSION des Clients (0.0.1) und meldet bei Ungleichheit "Eine neue Version ist verfuegbar" — also bei JEDEM Start. Client- und Server-Version sind zwei verschiedene Dinge; der Check braucht eine eigene Quelle fuer die Client-Version (z. B. ein Feld desktopVersion in /health/version oder eine eigene Datei im Web-Abbild).
  2. Windows-Installer nie gebaut. NSIS ist in tauri.conf.json konfiguriert, gebaut wurde nur das Linux-AppImage (Tessera_0.0.1_amd64.AppImage), weil auf dem Linux-Host keine Windows-Werkzeugkette existiert (06-02-SUMMARY). Braucht einen Windows-Rechner, eine Windows-VM oder einen Windows-Runner.
  3. Keine Abnahme. Phase 6 hat keine VERIFICATION.md; der Client wurde seit Juni nicht gestartet, die Web-Oberflaeche hat sich seitdem stark veraendert (Berechtigungen, Module, Kopfzeile mit Fehler-melden-Knopf, Versionsabzeichen). Vollstaendig gegen https://tessera.ctl.de durchklicken: Erststart-Dialog, Anmeldung, Tray, Schliessen, Benachrichtigung, Fehler-melden-Knopf (funktioniert html-to-image in der Tauri-WebView?).
  4. Kein automatischer Bau. .gitea/workflows/ci.yml baut nur die Container. Desktop-Pakete muessten je Freigabe von Hand oder ueber einen zusaetzlichen Runner gebaut und irgendwo abgelegt werden (Gitea-Release?).

Solution

Eigene kleine Etappe als /gsd-quick --validate, sobald die Baumoeglichkeit steht. Reihenfolge: (1) Versions-Check richtigstellen und tauri.conf.json auf eine echte Client-Version bringen; (2) Bau auf Windows, Installer testen; (3) Abnahme gegen tessera.ctl.de mit Protokoll; (4) entscheiden, ob der Bau in die Pipeline kommt oder als dokumentierter Handgriff je Freigabe bleibt. Die eine Produktfrage an den User: Wo wird gebaut und getestet (Windows-Rechner, VM, Runner)? Wenn "im Browser testbar" eine per Browser erreichbare Windows-VM meint, kann die Abnahme von Claude ueber Playwright MCP / Bildschirm laufen.