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

发布 Factory 后端

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

严格按以下顺序执行：

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

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