Therefore Release Gatekeeper

Build + CI

• Confirm CI is green for main branch (lint + unit tests at minimum).
• Confirm a clean local build works from scratch (fresh install + build).

Test coverage sanity

• Identify top 5 user-critical flows and confirm they are covered by either E2E or manual steps with expected results.
• Confirm destructive actions have a safe path (explicit labels, undo where applicable).

Desktop app safety (Tauri)

• Confirm permissions/capabilities are least-privilege.
• Confirm no secrets or sensitive paths are logged.

Data + migrations (if applicable)

• If any schema or migration changed: require a forward migration plan, a rollback stance, and verification steps.

Performance + stability

• Confirm no known crashes on launch.
• Identify likely hot paths changed in the release and require at least one measurement (startup time or list rendering).

Release communication

• Require release notes + known issues list (drafts are acceptable, but must exist).

Workflow

1. Determine release context:
   • Release tier: private build / beta / public release
   • Platforms: macOS / Windows / Linux
   • Non-negotiables: offline reads, auth, sync, export/import, local AI, etc.
2. Gather evidence for each required check (commands + outputs). If evidence is missing, treat as a blocker for higher release tiers.
3. Review risk hotspots:
   • src-tauri/migrations/ changes and any code that runs migrations.
   • Tauri permissions and configuration: src-tauri/capabilities/*.json, src-tauri/tauri.conf.json.
   • Logging and redaction: src-tauri/src/utils/secure_logger.rs plus any direct println!/eprintln!.
4. Identify “top 5” user-critical flows for this release and verify each:
   • Prefer existing automated coverage; otherwise write a deterministic manual checklist with expected results.
5. Produce a Go/No-go decision with a short punch list:
   • Blockers must be precise and actionable.
   • Fix-next items must say who does it next; default to you unless the user specifies otherwise.

Evidence expectations (pragmatic)

• CI: a run link or run id for main branch.
• Build: exact commands used, plus success/failure.
• Tests: list which suites ran (lint, targeted unit tests, any E2E) and results.
• Security: what you checked (capabilities, CSP, logs) and what you found.
• Migrations: whether migrations changed, plus upgrade verification notes.
• Performance: at least one measurement (startup time or a hot-path action) with the environment described.
• Release notes: draft exists with scope + known issues.

Output format (use exactly)

Decision: Go / No-go

Blockers:

• <one-line issue> — Location: <path or system area> — Fix: <what to do>

Fix-next (non-blocking):

• <one-line issue> — Owner: <who does it, default you> — When: <before/after launch>

Release checklist evidence:

• CI: <status + link or run id if available>
• Build: <command + result>
• Top flows verified: <list>
• Migrations: <yes/no + notes>
• Security: <notes>
• Performance: <what measured + result>
• Release notes: <draft included yes/no>
• Known issues: <draft included yes/no>

Reference

Read references/therefore-release-gate.md for repo-specific commands, file locations, and common gaps.