[CI/CD] Implement Git tagging and ensure release atomicity between CLI and GUI

[ZhanZiyuan]

Description:

Currently, the release-cli.yml workflow publishes the package to npm if the version in package.json is updated, but it does not create a Git tag. The release-gui.yml is then triggered by workflow_run, which builds the binaries and creates the GitHub Release.

This flow has several risks:

• Broken Atomicity: If release-cli succeeds (NPM updated) but release-gui fails (e.g., a Windows build error), the NPM package will point to a version that has no corresponding GitHub Release or Git tag.
• Missing Source of Truth: There is no Git tag (e.g., v1.0.0) created in the repository history to mark the exact state of the code for a specific release.
• Inconsistent Release State: If a user downloads the CLI from NPM, they might expect a corresponding GitHub Release to exist immediately.

Suggested Solution:

• Modify release-cli.yml to create and push a Git tag after a successful NPM publish.
• Consider merging the release logic or using the creation of a Git tag (v*) as the primary trigger for both CLI and GUI releases to ensure they are tied to the same commit.

[TrueNine]

Hi @ZhanZiyuan, thanks for the detailed analysis!

This has been addressed in #4. Here's a summary of the changes:

release-cli.yml — Added a step to create and push a v${version} Git tag after successful npm publish.

release-gui.yml — Replaced workflow_run trigger with push: tags: ['v*'], so the GUI release is now driven by the tag itself.

New flow: main push → CLI build & npm publish → Git tag → tag triggers GUI build → GitHub Release

This ensures:

• A Git tag always marks the exact release commit
• If npm publish fails, no tag is created, so GUI build won't trigger
• CLI and GUI releases are tied to the same commit via the tag

[ZhanZiyuan]

LGTM!