507 release

对外发布（release）

把已完成的本地提交推向外部：定版本号、打 tag、推送远端，并按项目实际探测到的发布渠道发布。它和 507-commit 的分界是可逆性——commit 停在可逆的本地提交，release 才触碰基本不可逆的对外动作（远端、公开包、公开 Release）。

安全边界

• 本 skill 只在用户明确要求发布、推送或发版时使用；
• 版本号决定权归用户：用户明确指定时直接用；未指定时显性询问用户选 patch / minor / major 或给具体号；用户给出"升一个版本号"这类半模糊指令时，按 semver（语义化版本）原则据 CHANGELOG 变更类型补全具体位；
• 明确点名即构成范围授权：用户点名的 push、tag、npm publish、GitHub Release 或其它渠道动作，在同一次连续 release run（发布流程）内持续有效；目标版本补全后，不重复确认已经点名的动作；
• 用户仅给出泛化的“发版”指令、没有说明具体对外动作时，先探测实际渠道并一次性确认完整发布范围，不把同一范围拆成逐动作确认门；
• 不自动扩到授权范围以外的 remote（远端）、branch（分支）、版本、tag、包、channel（渠道）、dist-tag（分发标签）或发布身份；这些目标变化、验证出现实质偏差、外部状态不确定或需要破坏性恢复时，必须重新确认；
• 不执行 git push --force（强制推送）到主干；
• 发布渠道的凭据、令牌和密钥不写入仓库或日志。

与 commit 的边界

507-commit 产出本地交付提交；本 skill 从“相关改动已提交、工作区干净”开始，目标版本由用户预先指定或在步骤 1 补全。工作区仍有未提交改动时，先回到 507-commit（或相应实现）完成提交，不带着脏工作区发布。

前置门禁

发布前逐项核验，任一不满足则停止并向用户报告：

1. 工作区干净（所有相关改动已 commit）；
2. CHANGELOG.md 的 Unreleased（未发布）段有内容；
3. 待发布提交与分支符合用户预期；
4. 版本号、CHANGELOG 定版段与 tag 三者一致；
5. 必要验证已通过或用户已明确知情放行。

工作流程

0. 固定范围授权

• 从用户指令中记录本次仓库、remote、branch、目标版本/tag、包与渠道；只询问尚未明确、且不能由项目事实安全补全的部分；
• “发版”默认覆盖把当前发布分支的定版提交与发布 tag 推送到已配置 upstream（上游远端）；npm、GitHub Release 等渠道仍只按用户点名或一次性确认的范围执行。用户明确“只打本地 tag”时不推送；
• 用户选择版本号后，将既有动作授权绑定到该版本，不再分别询问 push、tag 或已点名渠道；
• 范围授权持续到本次发布完成、用户明确停止，或范围失效；跨会话继续时，只有可从会话或脱敏 handoff（交接）核验原授权才沿用；
• 用户只说泛化“发版”且渠道不明时，探测后一次性展示并确认完整动作清单；确认后连续执行，不逐项重复打断。

典型判例：

• “请发版，tag 和 npm 都需要”：若版本未定，只询问版本；随后连续创建定版提交与 tag、推送当前发布分支和 tag、执行 npm publish，不再分别确认 push 与 npm；
• “只 push，不发包”：只推送用户指定或当前已核验分支，不创建发布版本、tag 或渠道产物；
• 只说“发版”：探测可用渠道后一次性确认完整范围，不按 push、npm、GitHub Release 拆成多轮；
• tag push 遇到明确的瞬时 TLS/网络错误：先核验远端 tag；未成功且无冲突时在原授权内最多重试一次。

1. 定版本号

• 读取当前最新 tag 与 CHANGELOG 顶部版本段，确认起点版本；
• 按安全边界确认目标版本号：用户明确指定则用；未指定则显性询问；半模糊指令按 semver 据 Unreleased 内容补全（仅缺陷修复/文档 → patch，向后兼容的新功能 → minor，有 Breaking（破坏性变更）→ major）；
• 把 CHANGELOG 的 Unreleased 段迁移为 ## [x.y.z] - YYYY-MM-DD，保留段内分类与条目；
• 项目存在版本号 manifest（如 package.json 的 version）时，同步更新到同一版本号。

2. 创建定版提交

将版本定版改动（CHANGELOG 迁移、manifest 版本号等）精确暂存，创建一个定版提交，遵循项目既有提交规范。

3. 打 tag

按项目惯例打 tag，默认 v<x.y.z>（如 v0.2.2），指向定版提交。

4. 推送远端（按范围授权执行）

范围授权包含远端推送、且 remote、branch、提交和 tag 未变化时，直接把定版提交与 tag 一并推送，不再追加确认：

git push origin <branch>
git push origin <x.y.z>   # 或 git push origin --tags，按项目惯例

push 被 reject（远端有新提交）、目标引用冲突或需要 --force / --rebase 时停止，报告差异，不在原授权下改变历史。

5. 发布渠道（探测 + 范围匹配，按需）

逐个探测项目实际的发布渠道，但只执行范围授权已经包含的渠道。用户未点名的渠道直接跳过，不为扩大范围而逐个追问；泛化“发版”已在步骤 0 一次性确认完整范围时，按该范围连续执行。

npm

• 探测条件：仓库根存在 package.json；
• 范围授权包含 npm publish 时执行 npm publish（预发布版本按项目惯例用 npm publish --tag 打 dist-tag）；
• 未登录、凭据缺失或实际账号与已核验发布身份不符时停止并报告，不把凭据写入任何文件。

GitHub Release

• 探测条件：git remote 指向 GitHub 且 gh（GitHub CLI）可用；
• release notes 默认从 CHANGELOG 对应版本段提取，不另行编造；
• 范围授权包含 GitHub Release 时，用 gh release create <tag> --notes "..." 创建，预发布版本加 --prerelease。

其它发布渠道（容器镜像、二进制产物等）由用户点名时按对应工具执行；本 skill 不预置全部渠道清单。

失败处理

• 命令失败后先用只读状态核验外部结果，不自动回滚已经完成的动作；外部状态已显示目标完成时，记录为成功，不重复执行；
• 若失败明确属于瞬时网络错误，目标与授权范围未变化，命令幂等或可安全重复，且外部状态能确认没有冲突，可在原授权内最多自动重试一次；
• push reject、引用冲突、外部状态不确定、凭据或发布身份变化、非幂等重试、范围变化或需要破坏性恢复时立即停止，由用户决定后续动作；
• 报告失败发生点、已成功完成的动作（如“main 已推、tag 未推、npm 未发”）、核验结果和未完成项。

完成与接力

• 完成信号：范围授权包含的全部对外动作已执行并核验成功（如 tag 已推、npm 已发、Release 已建），各渠道状态已报告。
• 产物：版本定版提交、tag、推送结果、各渠道发布链接或结果；失败时为失败点、外部状态核验和已完成动作清单。
• 候选出口：发布内容本身有问题时进入 507-fix；发布前需要交付审查时进入 507-review；发布完成后通常直接结束。
• 回退条件：前置门禁不满足、授权范围仍不明确或已经失效、push 被远端 reject、凭据缺失或需要高风险恢复时停止，不强行发布。