Milestone: Release & Updater Production Readiness

[smshagor-dev]

Goal

Make OpenMindAI releases reproducible, signed, updater-compatible, and auditable before publishing the next production tag.

Recheck status — 2026-08-29

Current source health

• Latest main CI is green: frontend version/config validation, ESLint, TypeScript/Vite build, and Rust fmt/Clippy/tests on Ubuntu, Windows, and macOS.
• Latest main Security is green: npm audit, cargo audit, and CodeQL analysis.
• Latest deterministic Rust suite reports 134 passed, 0 failed, 2 ignored real-environment/model tests.
• A separate draft PR (Add Windows Tauri application build smoke #52) is adding a Windows Tauri --no-bundle application-build smoke gate so normal CI validates the integrated desktop binary path, not only frontend and Rust independently.

Public release drift/blockers

• Public v2.0.0 is still the latest published release.
• main is 294 commits ahead of the v2.0.0 tag, so the public installer does not contain the current hardened code.
• Application metadata is still version 2.0.0; the next production release must use a new synchronized version/tag instead of moving or reusing the existing v2.0.0 tag.
• The actual v2.0.0 assets contain the Windows installer and bootstrap scripts, but do not contain latest.json, SHA256SUMS.txt, or openmindai.marker even though the old release notes claim checksum/marker files.
• The configured updater URL releases/latest/download/latest.json therefore returns 404 for the current public release.
• main is currently not branch-protected; required status checks / PR-only merge should be enabled in repository settings to prevent future merges before validation completes.

Acceptance criteria

Automated/repository gates

• Release workflow uses current GitHub Action runtimes and is aligned with Node 24 (checkout@v7, setup-node@v7, tauri-action@v1)
• Release workflow enforces that a release tag matches the synchronized app version and points at the current main commit
• Updater config is validated in normal CI: updater artifacts enabled, HTTPS endpoint configured, public key structurally valid
• Release workflow runs frontend lint/build plus Rust fmt/Clippy/tests before signing/publishing artifacts
• Release workflow contains a hard gate requiring produced Windows installer Authenticode status to be Valid
• Release workflow validates draft installer, updater signature, and latest.json version/signature/HTTPS tagged-release URL contract
• Release workflow generates SHA256SUMS.txt from the actual downloaded release assets and verifies required assets after upload
• Published release notes/assets never claim files that are not actually published — current v2.0.0 does not satisfy this
• CI/security matrix is green after release-hardening changes
• Normal CI builds the integrated Windows Tauri application binary — tracked in draft PR Add Windows Tauri application build smoke #52
• main requires PR validation/status checks before merge — repository protection is currently off

Manual trust gates

• Real TAURI_SIGNING_PRIVATE_KEY is configured and backed up securely
• Real Windows Authenticode certificate/password are configured and verified on a production release
• A signed updater round-trip is tested from an older installed version to the new release
• Clean-machine Windows install/uninstall and offline local-chat QA pass
• Public release is promoted from draft only after the manual gates above are recorded

Stable-release rule

Do not call the public distribution production-stable until a new version is cut from current green main, the signed draft pipeline succeeds, latest.json is live, the updater round-trip passes, and clean-machine/offline QA is recorded. Do not mark manual trust gates complete from code inspection, mocked secrets, or CI configuration alone.