# Journal-Eintrag: 06.05.2026 - Windows Cross-Packaging mit Conveyor

## Kontext

Der Windows-Build (.msi) war bisher blockiert, da unser Gitea-Runner ("Zora") auf ARM64-Linux läuft und das
Standard-Compose-Plugin zwingend eine Windows-Umgebung mit WiX Toolset für MSI-Pakete benötigt. Dies führte zu
ständigen "Roten Kreuzen" in der CI.

## Durchgeführte Arbeiten

### 1. 🏗️ Strategiewechsel: Hydraulic Conveyor

Anstatt auf einen Windows-Runner zu warten, wurde **Hydraulic Conveyor** als Packaging-Lösung eingeführt. Conveyor
erlaubt den Bau von Windows-MSI-Paketen direkt auf Linux, indem es eigene Toolchains mitbringt.

- **`conveyor.conf` erstellt:** Zentrale Konfiguration für die Desktop-App (Icons, JVM-Argumente, Windows-spezifische
  GUIDs).
- **Eingangsquelle:** Nutzt das JVM-JAR des Desktop-Shell-Moduls als Input.

### 2. 🐧 Gitea-Workflow Update

Der Workflow `.gitea/workflows/feature-build.yml` wurde radikal umgebaut:

- **Runner-Wechsel:** Von `windows-latest` (der nie existierte) auf `ubuntu-latest`.
- **Build-Schritte:**
  1. Gradle `jvmJar` erstellt die Plattform-unabhängige JAR.
  2. Installation von Conveyor via CLI.
  3. `conveyor make windows-msi` erzeugt das Paket.
- **Artefakte:** Die resultierende `.msi`-Datei wird nun korrekt in der Gitea-UI hochgeladen.

## Status: In Arbeit (Verifikation ausstehend)

- **CI-Update:** Die Blockade durch die Variable `DESKTOP_CI_ENABLED` wurde entfernt. Der Workflow läuft nun bei jedem
  Push auf einen Feature-Branch.
- **Input-Fix:** Die `conveyor.conf` wurde auf das spezifische JAR-Namensmuster (`meldestelle-desktop-jvm-*.jar`)
  angepasst.
- **Workflow-Stabilisierung:** Das Installations-Skript wurde um eine HTML-Validierung und einen **npm-Fallback**
  erweitert, da die offizielle Download-URL im Runner instabil war (Log #481).
- **Nächster Schritt:** Beobachtung des nächsten CI-Laufs in Gitea (Task #482+). Sobald das MSI bereitsteht, erfolgt der
  Hardware-Test.

**🏗️ [Lead Architect]**
**🐧 [DevOps Engineer]**