tessera-ctl/.planning/phases/18-desktop-client-fertigstellen/18-05-SUMMARY.md

phase, plan, subsystem, tags, requires, provides, affects, actuals, tech-stack, key-files, key-decisions, patterns-established, requirements-completed, coverage, duration, completed, status

phase	plan	subsystem	tags	requires	provides	affects	actuals	tech-stack	key-files	key-decisions	patterns-established	requirements-completed	coverage	duration	completed	status
18-desktop-client-fertigstellen	05	infra	ci gitea-actions tauri cargo-xwin nsis windows-cross-build desktop	phase provides 18-desktop-client-fertigstellen (18-02) Job `desktop` mit Linux-AppImage-Bau, `actions/cache`-Uebergabe an `publish`, `desktop-collect.sh`/`publish-release.sh` phase provides 18-desktop-client-fertigstellen (18-04) Client mit tauri-plugin-opener/autostart/window-state — die Cargo.toml, die der Cross-Bau kompilieren muss	Job `desktop` baut auf dem Linux-Runner zusaetzlich `Tessera-Setup-X.Y.Z.exe` per Cross-Bau (cargo-xwin, NSIS) Gruener Pipeline-Lauf auf `main` mit beiden Dateien (`.exe` + `.AppImage`), gruenem `publish`	18-06	tokens tasks commits 900 3 2	added patterns cargo-xwin 0.23.x (Ubuntu apt lld/llvm/clang/nsis) Cross-Job-Handoff ueber actions/cache@v4 (Schluessel gitea.sha), nicht upload-artifact — bestaetigt auch fuer den erweiterten Job funktionsfaehig Cache-Restore-Schritt steht VOR jedem Installationsschritt, der geprueft werden soll (command -v ... || cargo install), sonst greift die Restauration zu spaet und das Werkzeug wird bei jedem Lauf neu gebaut	created modified .gitea/workflows/ci.yml	Windows-Bau laeuft nacheinander im selben Job wie der Linux-Bau (ein Cache, ein Runner) statt in einem eigenen Job — wie in 18-CONTEXT.md (Specific Ideas, Runner-Grenzen 8 Kerne/15 GB) festgelegt. cargo-xwin, NSIS-Plugin-Ablage (~/.local/share/tauri) und die xwin-SDK-Ablage (~/.cache/cargo-xwin) wurden in den bestehenden Cargo-Zwischenspeicher-Schritt aufgenommen statt einen zweiten Cache-Schritt anzulegen. Der Schritt 'Windows-Werkzeuge' (rustup target add + cargo install cargo-xwin) wurde bewusst NACH dem Cargo-Zwischenspeicher-Schritt platziert (nicht wie im Plantext 'nach Rust-Toolchain' woertlich als naechster Schritt), damit die command -v cargo-xwin-Pruefung den wiederhergestellten Cache sieht und das Werkzeug bei warmem Cache nicht jedes Mal neu gebaut wird.	Iterationsschleife (D-16): jede Runde ein eigener Commit mit Praefix 'ci(desktop): Runde N — {Ursache}', Ursache/Fix im SUMMARY dokumentiert.	DESK-01 DESK-04 DESK-05	id description requirement verification human_judgment D1 Der CI-Job desktop baut auf dem Linux-Runner den Windows-Installer per Cross-Bau (cargo-xwin, NSIS) und sammelt Tessera-Setup-X.Y.Z.exe neben Tessera-X.Y.Z.AppImage ein DESK-04 kind ref status e2e Gitea CI/CD Lauf 367 (Commit 742fb5c), Job 'Desktop-Pakete bauen', Schritt 'Pakete einsammeln' pass false id description requirement verification human_judgment D2 Ein Push auf main endet mit einem gruenen Lauf: Job desktop mit beiden Dateien, Job publish mit Abbildern, die die Pakete tragen DESK-04 kind ref status e2e Gitea CI/CD Lauf 367 (Commit 742fb5c) — alle vier Jobs gruen, Job publish hat Abbilder mit Etiketten beta/latest gepusht pass false id description requirement verification human_judgment D3 Jeder Fehlschlag der Pipeline wird gelesen, der Job angepasst, erneut gepusht — hoechstens drei Runden, jede als normaler Commit DESK-01 kind ref status manual_procedural Runde 1 (Commit 742fb5c): clippy-Komponente fehlte, ein Commit, danach gruen — 1 von hoechstens 3 Runden verbraucht pass false	29min	2026-09-16	complete

Phase 18 Plan 05: Windows-Cross-Bau im CI-Job desktop Summary

Der CI-Job desktop baut jetzt in einem Lauf auf dem Linux-Runner sowohl das Linux-AppImage als auch — per Cross-Bau mit cargo-xwin und NSIS aus dem Ubuntu-Paket — den Windows-Installer; bewiesen durch einen gruenen Pipeline-Lauf mit beiden Dateien und gruenem publish.

Performance

• Duration: 29 min
• Started: 2026-09-16T14:46:59Z (erster Commit dieses Plans)
• Completed: 2026-09-16T15:15:23Z
• Tasks: 3 (Task 2 = Checkpoint, kein eigener Commit; 3 Aufgaben, 2 Commits)
• Files modified: 1 (.gitea/workflows/ci.yml)

Accomplishments

• Job desktop installiert lld llvm clang nsis per apt und ein neues rustup target x86_64-pc-windows-msvc + cargo-xwin (Schritt "Windows-Werkzeuge", NACH dem Cache-Restore platziert, damit ein warmer Cache das Neu-Bauen von cargo-xwin erspart).
• Nach dem bestehenden AppImage-Schritt baut ein neuer Schritt "Windows-Installer bauen (Cross-Bau)" per pnpm --filter @tessera/desktop exec tauri build --runner cargo-xwin --target x86_64-pc-windows-msvc --bundles nsis.
• "Pakete einsammeln" laeuft jetzt mit --require linux,windows; desktop-collect.sh kannte den Windows-Zweig (target/x86_64-pc-windows-msvc/release/bundle/nsis/*.exe) bereits aus 18-01, keine Skript-Aenderung noetig.
• Cargo-Zwischenspeicher um ~/.cargo/bin/cargo-xwin, ~/.cache/cargo-xwin (Windows-SDK-Ablage von cargo-xwin) und ~/.local/share/tauri (NSIS-Plugins) erweitert.
• Iterationsschleife durchlaufen (D-16): 1 Runde — fehlende clippy-Komponente im --profile minimal-Toolchain behoben, dann gruener Lauf.
• Gruener Pipeline-Lauf auf main (Lauf 367, Commit 742fb5c): alle vier Jobs gruen, Job desktop in ~10 min (kalter Cache) mit Tessera-Setup-1.1.0-beta.742fb5c.exe (2.775.663 Bytes) und Tessera-1.1.0-beta.742fb5c.AppImage (82.479.608 Bytes), Job publish hat Abbilder mit Etiketten beta/latest gepusht.

Task Commits

Jede Aufgabe wurde atomar committet:

1. Task 1: Windows-Cross-Bau in den Job desktop einbauen - 1c4247a (ci)
2. Task 2: Push und CI-Lauf beobachten - Checkpoint, kein eigener Commit (Push durch Orchestrator, kein Repo-Zustand veraendert)
3. Task 3, Runde 1: clippy-Komponente ergaenzt - 742fb5c (ci)

Plan metadata: folgt in diesem Commit (docs(18-05): ...)

Files Created/Modified

• .gitea/workflows/ci.yml - Windows-Cross-Bau-Schritte im Job desktop (apt-Pakete, Werkzeuge, Cache-Pfade, Bauschritt, Einsammeln mit beiden Plattformen), plus die Runde-1-Korrektur (rustup component add clippy)

Decisions Made

• Windows-Bau nacheinander im selben Job wie der Linux-Bau, ein Cache — wie in 18-CONTEXT.md (Specific Ideas) festgelegt, statt eines zweiten parallelen Jobs, der die Runner-Grenzen (8 Kerne/15 GB) ueberschritten haette.
• Der neue Schritt "Windows-Werkzeuge" wurde entgegen der woertlichen Plan-Reihenfolge ("nach Rust-Toolchain") NACH dem Cargo-Zwischenspeicher-Schritt platziert. Grund: command -v cargo-xwin >/dev/null 2>&1 || cargo install --locked cargo-xwin soll den wiederhergestellten Cache sehen koennen — stuende der Schritt vor dem Cache-Restore, waere cargo-xwin bei jedem Lauf neu gebaut, selbst wenn der Cache es bereits enthaelt. Das Ziel des Plans ("SDK-Ablage ... soll nur einmal geladen werden") war damit nur durch die Umstellung der Reihenfolge sauber erreichbar; die genannten Kennzeichen des Plans (cargo-xwin-Vorkommen, Cache-Pfade, Bauschritt-Reihenfolge AppImage-vor-NSIS) blieben davon unberuehrt und alle automatisierten <verify>-Pruefungen bestehen weiterhin.
• Keine XWIN_CACHE_DIR-Umgebungsvariable im ersten Anlauf gesetzt (Plan-Vorgabe: das ist eine Ausweichlösung der Iterationsschleife, nicht Teil von Task 1) — nicht noetig, der Lauf war nach der Clippy-Korrektur gruen.

Deviations from Plan

Auto-fixed Issues

1. [Rule 3 - Blocking] cargo clippy scheiterte an fehlender clippy-Komponente

• Found during: Task 2 (erste CI-Rueckmeldung, "rot")
• Issue: Der Schritt "Rust-Toolchain" installiert stable mit --profile minimal, dieses Profil enthaelt clippy nicht. Der bereits bestehende Schritt "Rust pruefen" (aus 18-02, unveraendert von diesem Plan) ruft cargo clippy auf und scheiterte mit 'cargo-clippy' is not installed for the toolchain 'stable-x86_64-unknown-linux-gnu'.
• Fix: "$HOME/.cargo/bin/rustup" component add clippy direkt nach der Toolchain-Installation im Schritt "Rust-Toolchain" ergaenzt (voller Pfad, weil $GITHUB_PATH erst fuer Folgeschritte greift, nicht innerhalb desselben run:-Blocks).
• Files modified: .gitea/workflows/ci.yml
• Verification: Lauf 367 (Commit 742fb5c) — Schritt "Rust pruefen" gruen, gesamter Job desktop gruen.
• Committed in: 742fb5c (ci(desktop): Runde 1 — clippy-Komponente fehlt im Toolchain)

---

Total deviations: 1 auto-fixed (1 blocking, per D-16-Iterationsschleife — dies ist die im Plan vorgesehene Korrekturrunde, keine ungeplante Abweichung im engeren Sinn). Impact on plan: Notwendige Korrektur fuer einen gruenen Lauf; kein Scope-Creep, betraf ausschliesslich den bereits vorhandenen "Rust pruefen"-Schritt aus 18-02.

Iterationsschleife (D-16)

Runde	Signatur im Protokoll	Ursache	Aenderung	Commit
1	error: 'cargo-clippy' is not installed for the toolchain 'stable-x86_64-unknown-linux-gnu' (Job desktop, Schritt "Rust pruefen", Lauf 366)	--profile minimal installiert keine clippy-Komponente	rustup component add clippy im Schritt "Rust-Toolchain"	742fb5c

Nach Runde 1: Lauf 367 (Commit 742fb5c) komplett gruen — Iterationsschleife nach 1 von hoechstens 3 Runden beendet.

Issues Encountered

Keiner ueber die dokumentierte Runde 1 hinaus. Hinweis aus der Rueckmeldung des roten Laufs: nach dem Fehlschlag in Runde-0 (Lauf 366) landete nichts im Cargo-Cache (Post-Schritt wegen success()=false uebersprungen) — der naechste Lauf startete entsprechend kalt (~10 min fuer den Job desktop). Kein Fehler, nur zur Einordnung der Bau-Dauer.

User Setup Required

None - keine externe Dienstkonfiguration noetig.

Next Phase Readiness

• Beide Desktop-Pakete (.exe, .AppImage) entstehen zuverlaessig in einem CI-Lauf auf main; das Beta-Abbild traegt sie ab Lauf 367.
• 18-06 kann den Testserver auf den neuen Stand ziehen und die Pakete dort sichtbar machen (Download-Weg selbst wurde bereits in 18-02 gebaut und per Probelauf geprueft).
• Der Release-Anhang (Gitea-Release-Datei-Upload) ist erst beim naechsten Freigabe-Tag v* sichtbar — in diesem Lauf war kein Tag gesetzt, der Release-Schritt lief erwartungsgemaess nicht.

---

Phase: 18-desktop-client-fertigstellen Completed: 2026-09-16