release

name	release
description	Use when releasing a new DooTask frontend version from the `pro` branch. Rigid sequential workflow (translate → version → build → commit → push) with strict pre-checks (branch, clean worktree, Node 20+) and per-step user confirmation. Use when user says "发布新版本", "release", "出新版本", "打版本". Stop on any failure; do NOT auto-fix dirty worktree, do NOT add tag step, do NOT use `git add -A`.

DooTask 发布流程

刚性技能——严格按顺序执行，每步向用户确认，任何一步失败立即停止。

核心原则

违反字面规则 = 违反流程精神。 不要擅自增加、省略、合并或重排步骤。

前置检查（全部通过才能继续）

执行任何发布步骤前，依次检查：

1. 分支：必须是 pro，否则停止，提示用户切换
2. 工作区：git status 必须干净（无未提交变更、无未跟踪文件），否则停止并交由用户处理
3. Node.js：必须 ≥ 20，否则停止

检查通过后汇报结果，用户确认后再开始执行。

发布步骤

每步执行前向用户确认；每步执行后报告结果。

Step 1: 翻译

npm run translate

更新多语言翻译文件。

Step 2: 版本号

npm run version

更新版本号。

Step 3: 构建前端

npm run build

构建前端生产版本。

最终：提交并推送

所有步骤完成后：

1. 通过 git diff + git status 汇总所有变更，向用户报告摘要
2. 询问用户是否提交并推送
3. 用户明确确认后才执行 git add、git commit、git push
4. 未确认一律不执行

提交规范：

• 提交信息使用 release: v<新版本号>（与历史提交风格一致，参见 git log --oneline | grep '^release:'）
• 只 add 本次发布相关改动，按文件名显式添加（例如 git add package.json public/js/...），不要用 git add -A 或 git add .，以免卷入未跟踪的本地实验文件

失败处理

• 任何步骤失败立即停止，报告错误信息
• 不要自动重试
• 不要自动跳过失败步骤
• 由用户决定如何处理

禁止项（基线测试暴露的反模式）

错误做法	正确做法
遇到脏工作区主动提出修复方案（加 .gitignore、先 push 等）	停下，报告脏工作区事实，交用户决定
增加 git tag v1.7.xx 步骤	DooTask 现行发布流程不打 tag，不要擅自添加
git add -A / git add .	按文件名显式添加发布相关改动
一次性 add + commit + push，不给确认机会	摘要 → 问确认 → 再 add/commit/push 三步分离
把 translate/version/build 顺序自作主张调整	顺序固定为 translate → version → build
失败后"我再试一次"或"跳过这步"	立即停止，交还给用户

Red Flags —— 出现这些念头立即停下

• "这个脏工作区我来帮 TA 搞定一下" → 停下，交用户
• "顺便打个 tag 吧" → 不，没有这一步
• "git add -A 省事" → 不，显式 add
• "翻译这步没改动可以跳" → 不，按顺序执行、执行后报告结果即可
• "一起 commit + push 一气呵成" → 必须先让用户确认