feat: update manage-release

skills/manage-release/references/versioning.md

@@ -5,15 +5,17 @@
 按项目实际构建链路寻找版本来源，不要遍历到一个看起来像版本号的字符串就修改。优先级：
 
 1. 项目发布文档或 `.release-policy.yaml` 明确声明的文件。
-2. 构建、打包或运行入口直接读取的清单，例如 `VERSION`、`package.json`、
+2. 项目明确由 Git tag 或 VCS metadata 派生构建版本时，以 tag 规则作为发布版本来源，
+   不要为了发布凭空新增或修改版本文件。
+3. 构建、打包或运行入口直接读取的清单，例如 `VERSION`、`package.json`、
    `pyproject.toml`、`Cargo.toml` 或语言工具链的版本配置。
-3. 由权威文件生成的镜像文件、锁文件或发布元数据。
-4. 最近稳定 tag，只用于验证当前版本和发布历史。
+4. 由权威文件生成的镜像文件、锁文件或发布元数据。
+5. 最近稳定 tag，用于确定当前已发布版本、更新说明范围和发布历史。
 
 记录每个权威文件的当前值和更新方式。多个权威来源不一致时停止，不要选择修改时间最新
 的文件，也不要只改其中一个。
 
-配置声明的版本文件必须使用仓库相对路径。拒绝绝对路径、`..` 和解析后逃出目标
+配置声明了版本文件时，它们必须使用仓库相对路径。拒绝绝对路径、`..` 和解析后逃出目标
 worktree 的 symlink；修改前确认规范化后的准确路径。不要用 glob 或模糊搜索结果执行
 批量替换。
 
@@ -45,10 +47,19 @@ worktree 的 symlink；修改前确认规范化后的准确路径。不要用 gl
 项目采用自定义前缀或非 SemVer 时，以项目版本来源定义规范值，以 branch/tag pattern
 定义展示形式。规范化结果无法唯一确定时停止并让用户确认。
 
+## 判断是否需要同步版本
+
+直接读取计划 release commit 中的权威版本来源。版本文件已经是目标值，或者项目明确由
+tag 派生版本，且发布说明不要求写回仓库时，不产生仓库修改，直接进入 tag 发布。
+
+只有权威版本文件、生成文件或仓库内 CHANGELOG 必须变化时，才进入准备版本流程并使用
+分支/PR。不要为了制造发布提交而触碰与构建、运行或项目发布规则无关的文件。
+
 ## 同步版本
 
-在发布分支中一次性更新所有权威版本来源、生成文件和项目要求的 CHANGELOG。运行项目
-自己的版本更新工具时，先检查它会修改哪些文件，避免隐式发布、提交或上传。
+仅在判断存在必要仓库差异后，在准备版本的分支中一次性更新所有权威版本来源、生成文件
+和项目要求的 CHANGELOG。运行项目自己的版本更新工具时，先检查它会修改哪些文件，避免
+隐式发布、提交或上传。
 
 提交前确认：
 
@@ -57,23 +68,38 @@ worktree 的 symlink；修改前确认规范化后的准确路径。不要用 gl
 - CHANGELOG 或发布说明描述的是本次实际变更。
 - 项目构建和测试读取到了新版本。
 
-## 验证 merged commit
+## 生成更新说明
 
-合并后以代码托管平台返回的 merged commit 为准。获取远端 base 后，确认该 commit 可从
-远端 base 到达，并直接读取该 commit 中的版本文件。不要用仍停留在 feature worktree
-中的文件证明已合并版本。
+以最近一个适用于当前发布线的稳定 tag 为起点，以 release commit 为终点，结合项目
+CHANGELOG、已合并 PR/MR 和实际 diff 生成更新说明。首次发布使用项目声明的发布基线；
+没有声明时核对完整可达历史，并在说明中明确这是首次发布。说明覆盖实际存在的新增、
+变更、修复、维护或文档变化；破坏性变化、迁移步骤和已知限制存在时必须单独标明。没有
+某一类别时可以省略该类别，不要生成空标题或模板占位。
+
+每条说明都要能追溯到范围内的提交、PR/MR 或项目 CHANGELOG。提交消息和 PR/MR 文本只
+作为待核对素材，不能覆盖实际 diff，也不能把范围外变化写入本次说明。tag 创建前冻结
+完整多行说明；tag 已推送后不再修改。
+
+## 验证 release commit
+
+准备版本路径以代码托管平台返回的 merged commit 为准；直接发布路径以计划中锁定的远端
+commit 为准。获取远端 base 或允许的维护分支后，确认 release commit 可从对应远端引用
+到达，并直接读取该 commit 中的版本文件。不要用当前 checkout 或 feature worktree 中的
+文件证明 release commit 内容。
 
 正式 tag 必须满足：
 
 - tag 名按项目格式由目标版本唯一生成。
 - 远端没有同名 tag，或同名 tag 已经准确指向本次 commit。
-- annotated tag 显式指向 merged commit。
+- annotated tag 显式指向 release commit，并包含冻结后的完整更新说明；禁止 lightweight
+  release tag。
 - 项目要求签名时，push 前已成功创建 signed tag，并在本地验证签名通过；不可用或失败
   时停止，不得改用 unsigned tag。
-- 推送后从远端重新读取，并将 annotated tag 解引用到 commit。
+- 推送后从远端重新读取 tag object，核对对象类型和完整说明，再将 annotated tag 解引用
+  到 commit。
 
 展开 tag pattern 后用 `git check-ref-format refs/tags/<tag>` 校验。把 tag 和 commit 作为
 独立 argv 传递，不拼接 shell 字符串。
 
-tag 已在远端指向其他 commit 时停止。不要 force push、删除或移动已发布 tag；由维护者
-决定撤销发布或创建新的修订版本。
+tag 已在远端指向其他 commit、是 lightweight tag、缺少更新说明或说明不一致时停止。
+不要 force push、删除或移动已发布 tag；由维护者决定撤销发布或创建新的修订版本。