---
name: factory-release
description: Use when the user explicitly asks to release the factory backend, run its release workflow, or bump its deployed version.
---

# 发布 Factory 后端

仅在用户明确要求后端发版、release 或提升部署版本时执行本流程。普通代码修改、提交或推送不触发发版。

严格按以下顺序执行：

1. 确认目标是当前 `factory` 后端。若用户要求发布 `ehs_web` 前端，改读 `.codex/memory/reference_ehs_web_release.md`。
2. 执行 `git status --short`，确认工作区状态。发布提交只能包含 `changelog.md` 和 `server/settings.py`；不得混入其他已修改或未跟踪文件。
3. 执行 `bash update_changelog.sh`，从脚本输出读取形如 `3.1.YYYYMMDDHH` 的版本号，记为 `<VER>`。不得自行编造或改写版本号。
4. 把 `server/settings.py` 中唯一权威版本字段 `SYS_VERSION` 更新为 `<VER>`。
5. 读取 `changelog.md` 顶部约 20 行，确认标题是 `## <VER>`，且自上一个 tag 起的提交分类合理。出现重复段、明显漏项或无关内容时，先向用户确认，不得继续打 tag。
6. 再次检查 diff，只暂存 `changelog.md` 和 `server/settings.py`。
7. 提交信息使用 `release: <VER>`，不添加工具或模型专属署名。
8. 创建无 `v` 前缀的 tag：`git tag <VER>`。
9. 推送当前分支到 `origin`，成功后再执行 `git push origin <VER>`。逐步检查结果，不用命令链掩盖中间失败。
10. 汇报 `<VER>`、changelog 包含的提交类别、commit hash、tag 名，以及分支和 tag 的推送结果。

若提交、tag 或推送中途失败，先检查实际 Git 状态。任何会重写历史或删除远端 tag 的回退操作，都必须先取得用户明确授权。