[Bug]: CLI release becomes public before npm/PyPI succeed, with no same-version recovery checks

由 TrailSnap 需求管理平台同步。

需求描述

Description / observed behavior

CLI release run 30285974899 for v0.8.1 built all three platform binaries and completed create-release, then both registry jobs failed:

• npm job: HTTP 403, cannot publish over trailsnap-cli@0.8.0.
• PyPI job: HTTP 400, trailsnap_cli-0.8.0-py3-none-any.whl already exists.

This was a tag/package-version mismatch plus a release advertised before registry publication completed. The incident was subsequently repaired: registry timestamps show 0.8.1 on npm at 16:45:51 UTC and PyPI at 16:46:04 on July 27. The current version files also agree at 0.14.2.

Remaining workflow behavior

Checked September 13 at cebe34a8826e: build-publish-cli.yml still makes a non-draft GitHub release in create-release, with both publish-pypi and publish-npm depending on that job. Their uploads are unconditional, and the workflow has no tag-to-package-version check before public release creation or per-registry checkpoint for a partial publish.

This release path does not follow the publish-then-record saga pattern: the public completion record is written before both registry operations are verified. Another duplicate-version, authentication, or registry failure can leave GitHub ahead of one or both registries.

Expected behavior / possible fixes

Validate the tag against both package versions before any publication. Build and retain the registry packages alongside the binaries. Stage the GitHub release as draft, publish/verify each registry version, then make the release public. If one registry succeeds and the other fails, recovery should verify the existing artifact and publish only what is missing; a version conflict should require explicit resolution rather than being ignored.

Verification scenario and environment

The reproduction evidence is the linked GitHub-hosted run on v0.8.1, not a local app/browser problem. In an isolated workflow test, fail the second registry upload after the first succeeds, then resume: the same release should finish without retagging or trying to overwrite the first registry's immutable files. Current package version files: npm and PyPI.

Prepared with AI assistance (Codex); evidence comes from the linked public workflow, run history, and release metadata. No production release was triggered for this report.

当前行为

未提供

期望行为

未提供

验收与审核

暂无

Requirement: REQ-111

Read .github/workflows/build-publish-cli.yml and compare its release, publish-pypi, and publish-npm jobs with package/trailsnap-cli/package.json and pyproject.toml. Reproduce the isolated second-registry failure described in the issue, then verify that tag and package versions are checked, the GitHub release remains staged until both registries succeed, and recovery does not overwrite an existing artifact.