Files
tessera-ctl/.planning/phases/06-desktop-client-ci-cd/06-CONTEXT.md
T

5.3 KiB

Phase 6: Desktop Client & CI/CD - Context

Gathered: 2026-06-25 Status: Ready for planning

## Phase Boundary

Tauri 2.x Desktop-Wrapper fuer die bestehende Tessera Web-App (Windows + Linux) mit System Tray, nativen Benachrichtigungen und konfigurierbarer Server-URL. Plus DevOps-Automatisierung: Gitea als Git-Remote einrichten, Gitea Actions CI/CD Pipeline (Lint, Tests, Docker Build, Auto-Deploy auf gleichen Server). WICHTIG: Gitea-Integration ist KEIN Feature von Tessera — es ist Tooling fuer den Entwicklungsworkflow. Claude (nicht die App) pusht manuell bei Meilensteinen/grossen Bugfixes.

## Implementation Decisions

Desktop-App Verhalten

  • D-01: Wrapper mit System Tray und nativen OS-Benachrichtigungen (z.B. Kalender-Erinnerungen). Braucht Backend-Integration fuer Notification-Events.
  • D-02: Server-URL konfigurierbar beim ersten Start. Wird lokal gespeichert. Ein Build fuer alle Umgebungen.
  • D-03: Beim Schliessen des Fensters (X-Button) wird in System Tray minimiert. Beenden nur ueber Tray-Kontextmenu.
  • D-04: Autostart-Option in Desktop-App-Einstellungen vorhanden, standardmaessig deaktiviert.

Fenster & Erscheinung

  • D-05: Fensterposition und -groesse werden beim Schliessen gespeichert, beim naechsten Start wiederhergestellt. Erster Start: 1280x800 zentriert.
  • D-06: Eigenes Tessera-App-Icon (basierend auf Design-System, OKLCH Farben).

Build & Verteilung

  • D-07: Linux: AppImage als primaeres Format (distro-uebergreifend).
  • D-08: Update-Hinweis: App prueft beim Start ob neue Version verfuegbar, zeigt Notification. Download bleibt manuell. Auto-Update kann spaeter nachgeruestet werden.
  • D-09: Code Signing kommt spaeter — erst relevant wenn Tessera an externe Kunden verkauft wird. Fuer interne Nutzung ohne Signierung OK.

Gitea-Automatisierung (DevOps, KEIN App-Feature)

  • D-10: Gitea ist reines Versionskontroll- und CI/CD-Tooling. Tessera hat keine Git/Gitea-Funktionalitaet in der App.
  • D-11: Claude pusht manuell bei Meilensteinen oder grossen Bugfixes nach Gitea. Kein automatischer Sync, kein zeitgesteuerter Push.
  • D-12: Gitea Actions CI/CD Pipeline wird bei jedem Push getriggert: Lint + TypeCheck → Tests (Vitest) → Docker Images bauen → Auto-Deploy.
  • D-13: Deploy-Ziel ist gleicher Server wie Gitea. Pipeline macht docker-compose pull + restart.

Claude's Discretion

  • Titelleiste: Nativ vs. Custom — basierend auf Aufwand und Design-System
  • App-Menueleiste: Kein Menu vs. minimales Menu — basierend auf Plattform-Konventionen
  • Windows Installer-Format: MSI vs. NSIS — basierend auf Zielgruppe (intern, spaeter extern)
  • Gitea Actions Workflow-Struktur und Stage-Konfiguration
  • Docker Image Registry: Gitea-intern vs. lokal

<canonical_refs>

Canonical References

Downstream agents MUST read these before planning or implementing.

Projekt-Kontext

  • .planning/PROJECT.md — Gesamtprojekt, Core Value, Constraints
  • .planning/REQUIREMENTS.md — Phase-6-Requirements: DESK-01, DESK-02, INFRA-04
  • .planning/ROADMAP.md — Phase-Ziel und Success Criteria

Vorherige Phasen

  • .planning/phases/01-foundation-portal-shell/01-CONTEXT.md — Design-Entscheidungen, OKLCH Tokens (relevant fuer App-Icon)
  • .planning/phases/05-dashboard-calendar/05-CONTEXT.md — Dashboard/Kalender (relevant fuer native Notifications)

Technologie

  • docker-compose.yml — Bestehende Container-Konfiguration (web, api, db). Deploy-Target fuer CI/CD
  • pnpm-workspace.yaml — Monorepo-Struktur (apps/, packages/)
  • apps/web/Dockerfile — Web-Image Build
  • apps/api/Dockerfile — API-Image Build

</canonical_refs>

<code_context>

Existing Code Insights

Reusable Assets

  • docker-compose.yml — Bestehende Service-Definitionen (web, api, db). CI/CD Deploy baut darauf auf.
  • apps/web/Dockerfile + apps/api/Dockerfile — Produktions-Dockerfiles bereits vorhanden
  • Design Tokens (OKLCH) in apps/web — Basis fuer App-Icon-Farben

Established Patterns

  • pnpm Workspace mit apps/* und packages/* — Desktop-App wird apps/desktop
  • Docker Compose mit Netzwerk-Segmentierung (frontend-net, backend-net, data-net)
  • Health Checks fuer alle Services

Integration Points

  • apps/desktop — Neues Tauri-Projekt im Monorepo
  • .gitea/workflows/ — Gitea Actions Workflow-Dateien (neu)
  • Gitea Remote muss eingerichtet werden (aktuell kein Remote konfiguriert)
  • Desktop-App laedt http://<konfigurierte-url>:3000 (Web-Frontend)
  • Notification-Backend braucht evtl. WebSocket/SSE Endpoint in apps/api

</code_context>

## Specific Ideas
  • Desktop-App ist reiner Wrapper — die gesamte Logik bleibt in der Web-App
  • Tray-Icon zeigt Tessera-Logo, Rechtsklick-Menu mit: Oeffnen, Beenden
  • Erster Start zeigt Eingabefeld fuer Server-URL, danach direkt zur Web-App
  • Gitea Actions Pipeline als Multi-Stage: erst Qualitaet pruefen, dann bauen, dann deployen
## Deferred Ideas
  • Auto-Update mit Tauri Updater: Kann spaeter nachgeruestet werden wenn Update-Server verfuegbar
  • Code Signing: Wird relevant bei externem Verkauf
  • macOS Support: Aktuell nur Windows + Linux, Mac spaeter bei Bedarf
  • Gitea Webhooks fuer externe Events: z.B. Issue-Tracking Integration

Phase: 06-Desktop Client & CI/CD Context gathered: 2026-06-25