version-bump

更新日志范围

• 每次从空白内容生成，只保留上一版本到本次版本的实际变化；覆写既约束文件写入，也约束条目内容。
• 旧更新日志仅用于核对边界和排除重复，不作为新日志的模板。历史条目、致谢和 PR 引用不沿用；本次致谢仅在用户明确要求时加入。
• 合并或补入历史提交不代表新增功能。每条日志必须对应版本基线与最终代码之间的有效差异，子模块变更须检查对应提交范围。
• 发布页的固定说明由发布工作流维护，不带入本次更新日志。

流程

1. 检查未提交改动：先使用 commit 技能，按独立目的逐项审查、验证并原子提交已获授权的业务改动；不得把多个业务目的合并，也不得夹带版本号与 changelog。格式整理遵守提交技能的独立提交顺序
2. 读取 android/gradle.properties 中的 appVersionName 和 appVersionCode
3. 确定新版本号：
   • 默认：patch +1（如 1.1.33 → 1.1.34），appVersionCode +1
   • 用户指定了具体版本号时，使用用户指定的版本
4. 沿 git log --first-parent -- android/gradle.properties 确定上一版本基线，核对版本号提升提交及已有的对应发布标签；阅读该基线的更新日志，确认上一版已包含的内容
5. 以 git diff <基线> HEAD 的最终差异为依据，结合提交记录归纳用户可感知的变化；不能仅凭提交日期、合并顺序或提交标题判断版本归属，忽略纯重构、CI 修复与代码风格改动
6. 合并同一功能的多次改动：如果某功能在两个版本之间经历了多次修改，以最终状态为准。例如功能 A 先加入后被移除，则更新日志中不应有任何关于功能 A 的描述
7. 识别本次版本涉及的 GitHub issue：用 gh 读取 issue 原文，逐条核对本次改动是否完整满足 issue 要求；只有完整满足时，提交信息才允许追加 close #xxxx，否则不要追加
8. 修改 android/gradle.properties 的 appVersionName 和 appVersionCode
9. 修改 srx_core/Cargo.toml 的 version 字段，保持与 app 版本号同步
10. 覆盖写入 .github/CHANGELOG.md，不保留旧日志，仅保留本次新版本条目
11. 提交前逐条核对：能否对应基线后的有效代码变化，是否重复上一版内容或沿用旧致谢，中英文是否一一对应；有不符项先修正，再提交
12. 使用 commit 技能创建仅包含版本号、必要锁文件与本次 changelog 的原子提交，提交信息格式：chore: bump version to {version}；仅当第 7 步确认完整满足某个 issue 时，才在提交信息末尾追加 close #xxxx

推送规则

• 完成版本号提升后，禁止主动询问用户是否 git push，也禁止擅自 git push
• 用户明确要求推送后，核对本次仓库、远端、分支或标签及待推送提交；授权只覆盖当前这一次推送尝试，不能沿用先前会话的许可
• 尝试执行后授权立即失效；重试、变更提交范围、子模块或后续推送都必须重新取得明确允许。没有新的推送请求时，禁止主动询问是否推送或擅自推送

更新日志格式

使用中英文双语，英文在前、中文在后，中间用单独一行 --- 分隔。正文不写版本号或分类标题；GitHub Release 标题负责展示版本。

固定结构如下：

- English change 1
- English change 2

---

- 中文改动描述 1
- 中文改动描述 2

规则：

• 英文列表在前，中文列表在后，中间只有一条分隔线，中英文条目一一对应
• 不写任何 markdown 标题行，包括 #、##、###
• 每条以动词或清晰动作开头，简洁描述用户可感知的变化
• 条目平铺，不折叠，不使用 emoji，条目末尾不加标点
• 文件末尾无空行