发布 jackin❯ 版本时，如何用硬确认流程执行…

当操作者明确要求裁剪/发布 jackin❯ 版本时，用此流程完成 readiness 门禁、changelog、版本号推荐，并在明确确认后执行 `cargo release`。

适用场景

解决思路

1. 运行 `jackin-release-check` 执行 readiness gates。若有红色 gate 立即停止，展示报告并指出需修复项；若有 warn，展示后询问是否继续。完成条件：所有 gate 绿色，或操作者接受 warn。
2. 运行 `jackin-release-notes` 生成/更新 changelog。展示 `[Unreleased]` 区段，让操作者重新分类或改措辞。完成条件：操作者批准 changelog。
3. 推荐版本号。读取已批准的 `[Unreleased]` 分桶：有 **Removed** 或 "breaking" 条目 → **major**；有 **Added** → **minor**；仅有 **Fixed** / **Changed** / **Security** / **Deprecated** → **patch**。用 `grep '^version' Cargo.toml` 读取当前版本，计算下一个版本，展示推荐并等待。完成条件：操作者确认 bump 级别。
4. 提交 changelog。如果 `CHANGELOG.md` 有未提交修改，执行 `git add CHANGELOG.md && git commit -m "docs: update changelog for vX.Y.Z"`。
5. 最终确认。展示摘要：版本号、bump 级别、changelog 形态，以及即将执行的精确命令 `cargo release <level> --execute`（它会更新 `Cargo.toml`、按 `release.toml` 将 `[Unreleased]` 重命名为 `[X.Y.Z] - <date>`、打 tag 并 push）。没有操作者明确说 “yes” 不要运行。完成条件：操作者说 “yes”。
6. 执行发布。运行 `cargo release <level> --execute`。失败时展示错误并停止。
7. 验证。运行 `git tag -l "vX.Y.Z"` 和 `git ls-remote --tags origin "refs/tags/vX.Y.Z"`。指引操作者查看现在会构建产物的 release workflow。
8. `cargo release` 前出错：可以安全修复并重跑，此技能会重新验证所有内容。
9. `cargo release` 期间出错：检查已提交或已打 tag 的内容。若 tag 已创建但未 push → `git push origin vX.Y.Z`；若 version commit 已创建但没有 tag → reset 后重试。
10. `cargo release` 之后：发布已完成；CI 失败是 workflow 问题，不是回滚问题。
11. 不要在未获得明确 “yes” 时运行 `cargo release`——这是唯一硬门禁。
12. 不要让红色 readiness gate 通过并进入发布。
13. 不要手改 `[X.Y.Z]` 版本标题——`cargo-release` 会通过 `release.toml` 的 `pre-release-replacements` 重写它；双重编辑会破坏 release commit。

适用边界 · 注意事项

• 仅检查 ready 状态时，用 `jackin-release-check`，不要用此发布流程。
• 仅更新 changelog 时，用 `jackin-release-notes`，不要用此发布流程。
• 前置条件不满足时不要用：未安装 `cargo-release`、`gh` 未认证、`release.toml` 未配置 `CHANGELOG.md` 的 `pre-release-replacements`、`CHANGELOG.md` 缺少 `<!-- next-header -->` 标记、或缺少 `.github/workflows/ci.yml`。