This runbook covers the signed Tauri release pipeline. Python CLI publication remains independent in pypi-publish.yml.

• Desktop version values in desktop/package.json, desktop/src-tauri/Cargo.toml, and desktop/src-tauri/tauri.conf.json must match.
• The Git tag must be desktop-v<version>.
• Each platform builds its PyInstaller sidecar on the same operating system and CPU architecture as the Tauri host. PyInstaller output is not cross-platform.
• A release build can execute only the bundled app-server/ resource. It never falls back to source, a system Python, or an adjacent executable.
• Update packages are signed with the Tauri updater key. Automatic downgrade is disabled.
• Releases are created as drafts. They are published only after bundle, signature, notarization, install, launch, update, and uninstall checks pass.

Create a protected GitHub environment named desktop-release. Require review before jobs can access its credentials.

Repository variables:

• TAURI_UPDATER_PUBLIC_KEY: public key generated by npm run tauri signer generate. This value is compiled into release builds.
• TAURI_UPDATER_ENDPOINT (optional): absolute HTTPS endpoint. When omitted, the workflow uses https://github.com/<owner>/<repo>/releases/latest/download/latest.json.

Repository or environment secrets:

• TAURI_SIGNING_PRIVATE_KEY
• TAURI_SIGNING_PRIVATE_KEY_PASSWORD
• APPLE_CERTIFICATE (base64 PKCS#12 Developer ID Application certificate)
• APPLE_CERTIFICATE_PASSWORD
• APPLE_ID
• APPLE_PASSWORD (app-specific password)
• APPLE_TEAM_ID
• WINDOWS_CERTIFICATE (base64 PFX code-signing certificate)
• WINDOWS_CERTIFICATE_PASSWORD
• LINUX_GPG_PRIVATE_KEY
• LINUX_GPG_KEY_ID
• APPIMAGETOOL_SIGN_PASSPHRASE

The updater private key is a long-lived release root of trust. Back it up offline and never commit it. Losing it prevents existing installations from accepting future updates. Rotating it requires a deliberately staged release signed by the old trust chain.

The release action also generates latest.json for the signed updater. Asset names include platform and architecture so the two macOS builds cannot overwrite one another.

1. Run all local verification gates and ensure the worktree contains only the intended release changes.
2. Update the three Desktop version files together.
3. Create and push desktop-v<version>.
4. Approve the desktop-release environment when GitHub requests it.
5. Wait for every matrix job. Missing credentials, incomplete runtime imports, sidecar RPC startup, code-signing, notarization, updater signing, or required resources fail the release.
6. Download each workflow artifact onto a clean matching platform.
7. Verify first launch with an isolated test account:
   • no existing DeepCode Sessions are imported accidentally;
   • project selection and trust work;
   • Agent startup and shutdown leave no orphan sidecar;
   • TXT, HTML, DOCX, Markdown, and PDF inputs reach paper.md;
   • diagnostics export contains no prompts, credentials, file contents, or environment variables.
8. Publish the draft only after a previous signed version successfully updates to the candidate.
9. Test uninstall. User projects, central Session JSONL, and user configuration must remain intact.

The updater intentionally rejects lower versions. Do not enable automatic downgrades: an older application may not understand a newer SQLite schema.

For a bad unpublished draft, delete or replace the draft assets. For a bad published release:

1. stop advertising it by restoring a known-good release as the GitHub latest release or replacing the update manifest;
2. publish a higher-version hotfix whenever possible;
3. if a manual binary rollback is unavoidable, quit DeepCode, preserve the current state directory, restore the validated pre-migration SQLite backup, then install the older signed bundle;
4. never modify or roll back canonical Session JSONL as part of a Desktop database rollback.

Migration backups live under the Desktop state backups/ directory with owner-only permissions. A backup is created and validated before any existing database version transition.

• security-ci.yml scans Git history for new secrets, audits npm/Python/Rust advisories, creates Python/Node SBOMs, and audits all resolved licenses.
• A clean cargo audit blocking result is required. The current Tauri 2 Linux dependency graph also reports informational upstream maintenance/unsound warnings in the GTK3/glib chain; these are recorded in CI and must be re-evaluated on Tauri upgrades, but are not silently classified as fixed.
• Historical secret findings listed in .gitleaksignore are acknowledgements, not proof of revocation. Their credentials must be rotated before release.
• THIRD_PARTY_NOTICES.md and PRIVACY_AND_DIAGNOSTICS.md are embedded in every application bundle.
• Official reference material: Tauri updater, macOS signing, Windows signing, and Linux signing.