docs: codify release workflow

AGENTS.md

@@ -36,6 +36,30 @@ Release 以上一个实际发布的正式 Release 为基线，审计完整提交
 
 每个正式 Release 必须附带可安装的 Android APK。APK 文件名统一使用 `edgeever-android-vX.Y.Z-<ABI>.apk`，例如 `edgeever-android-v0.4.14-arm64-v8a.apk`。GitHub APK 默认仅构建 `arm64-v8a`；只有出现明确兼容需求时才额外提供其他 ABI，Play AAB 仍保留全部架构。若完整变更区间影响移动端代码、其共享依赖、原生配置或 APK 构建，则从本次发布提交重新构建生产签名 APK；否则可复用最近的兼容 APK，并在正文中注明来源 Release。发布前验证 APK 版本、签名、SHA-256 及下载可用性。
 
+### Release 固化流程
+
+执行“提交、推送并发布”时，必须按以下顺序操作：
+
+1. 在 `main` 上检查 `git status --short --branch` 和完整 diff。无关的未提交修改不得混入发布；需要继续保留的工作区修改应使用可恢复的 `git stash` 暂存，发布完成后恢复。
+2. 查询远端最新正式 Release 与标签，使用上一个实际 Release 作为变更审计基线；不得以孤立标签或仅存在于本地的标签作为基线。
+3. 确定下一个 SemVer 版本。同步更新根目录 `package.json`；若发布包含移动端代码或 APK，则同步更新 `apps/mobile/app.json` 的 `expo.version`，并递增 `android.versionCode`。
+4. 为功能或修复关联的 Issue 添加合适 Label（通常为 `enhancement` 或 `bug`），然后提交全部本次发布改动。提交后先推送 `main`，确认远端提交可见。
+5. 从即将发布的提交执行验证。至少完成相关类型检查、测试和 Web 构建；移动端变更必须执行 `bun run build:android:apk:local`，不得用工作区其他未提交改动构建 APK。
+6. 验证 APK 的 `versionName`、`versionCode`、包名、生产签名、目标 ABI、SHA-256 和文件大小。将产物重命名为 `edgeever-android-vX.Y.Z-arm64-v8a.apk`，并确保只上传该版本产物。
+7. 创建标签并推送标签，标签必须指向已验证的 `main` 提交；随后创建非 Draft、非 Prerelease 的 GitHub Release，上传 APK，并在发布后确认 Release、标签、附件状态和下载链接均可用。
+8. Release 正文使用英文，必须包含用户可感知的变化、关联 Issue 和实际验证结果；发布完成后将已完成的 Issue 回链到 Release 并关闭。
+
+推荐的移动端发布验证命令：
+
+```sh
+bun run typecheck
+bun run typecheck:mobile
+bun run build:web
+bun run build:android:apk:local
+```
+
+生产签名环境文件和密钥必须位于仓库外（默认使用 `~/.config/edgeever/android/signing.env`），不得写入仓库、Release 正文或日志。
+
 ## Cloudflare 自动部署约束
 
 当用户要求根据 GitHub 项目链接将本项目安装部署到 Cloudflare 时，必须先完整阅读并严格按照 `docs/agent-deploy-cloudflare.md` 执行。该文档是此部署流程的唯一操作规范；不要在本文件重复维护部署命令、密码配置或 Workers Builds 步骤。