# Phase 6: Desktop Client & CI/CD - Context

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

<domain>
## 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.

</domain>

<decisions>
## 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

</decisions>

<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>

<specifics>
## 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

</specifics>

<deferred>
## 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

</deferred>

---

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