Windows releases were shipping both NSIS exe and MSI bundles, which made the
release page harder to understand and increased the chance that users would
pick the wrong asset. Restricting Windows output to MSI narrows the installer
surface while the release asset naming now spells out platform, architecture,
and bundle type directly in every published filename.
Constraint: Remote desktop packaging is triggered by GitHub Actions releases, not local uploads
Constraint: Updater metadata must keep latest.json stable for existing clients
Rejected: Keep publishing both NSIS and MSI with better docs | still leaves the higher-risk installer on the release page
Rejected: Rename assets manually after upload | easy to drift from workflow output and updater metadata
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: If Windows exe bundles are reintroduced later, reassess SmartScreen and AV impact before publishing them again
Tested: YAML parse for both desktop workflows; git diff --check on modified files; manual review of PowerShell changes
Not-tested: End-to-end GitHub Actions release run; PowerShell parser validation on a Windows host
GitHub Actions showed that Linux compilation and .deb packaging succeed on both x64 and ARM64, but AppImage consistently fails inside linuxdeploy. The workflows now ship Linux as .deb only so CI and releases stay reliable while the AppImage path is investigated separately.
Constraint: Current GitHub-hosted Linux packaging fails specifically in linuxdeploy after successful .deb output
Rejected: Keep AppImage enabled and accept red workflows | blocks release confidence for an optional format
Rejected: Drop Linux builds entirely | would remove a working .deb delivery path
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Re-enable AppImage only after capturing linuxdeploy stderr and validating both Linux architectures on GitHub Actions
Tested: git diff --check; YAML parse of both workflow files; inspection of failed GitHub Actions logs showing .deb success before AppImage linuxdeploy failure
Not-tested: Re-run of updated workflows on GitHub Actions
The local desktop build path already proved that AppImage packaging needs libfuse2 and that macOS artifacts may be directories rather than plain files. This commit aligns the GitHub workflows with those realities so remote validation matches the local release path more closely.
Constraint: GitHub-hosted Linux runners do not guarantee AppImage runtime deps unless we install them explicitly
Rejected: Leave release workflow unchanged and trust local macOS build only | would not validate Linux packaging path at all
Rejected: Upload only DMG/installer files in dev workflow | hides the macOS .app artifact users expect for local testing
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep dev and release desktop dependency lists in sync when packaging requirements change
Tested: git diff --check; YAML parse of both workflow files; manual inspection of artifact collection and Linux dependency steps
Not-tested: Live GitHub Actions execution on repository runners
