Summary

The new dev-release workflow in #1217 works, but the release/build architecture is now split across:

• .github/workflows/dev-release.yml
• .github/workflows/build.yml
• .github/workflows/build-tauri.yml

This is functional, but harder to reason about than the unified release.yml design we ended up with in gptme/gptme.

Why this follow-up exists

In #1217, Erik asked why we didn't use the cleaner unified release.yml structure from gptme/gptme.

The answer is basically scope control: #1217 started as the smallest safe change that could add CI-gated dev prereleases on top of ActivityWatch's current workflow layout. That was the right call for landing the feature quickly, but the architectural cleanup still makes sense.

Proposed direction

Refactor the current release/build setup into a single release.yml-style workflow that:

• handles both stable and prerelease tagging paths coherently
• owns release creation logic in one place
• dispatches/reuses build steps instead of duplicating release semantics across multiple workflows
• keeps artifact naming/version derivation consistent across AW Qt / Tauri outputs
• makes the CI gate for dev releases easier to understand and audit

Constraints

• Keep the safety properties added in feat(ci): add automated dev release workflow #1217:
  • exact-SHA tagging after CI verification
  • robust self-exclusion for current workflow run
  • explicit handling of cancelled/startup_failure conclusions
• Don't regress stable release behavior
• Preserve draft prerelease behavior unless we intentionally change it

Context

• PR: feat(ci): add automated dev release workflow #1217
• Reference design: gptme/gptme/.github/workflows/release.yml

Outcome

This would reduce workflow sprawl and make future release automation changes less brittle.