dootask-update

name	dootask-update
description	更新已部署的 DooTask：前置检查后执行 `sudo ./cmd update`（拉代码 + composer + 迁移 + 重启），本地有改动时停下交用户决定，不自动强制、失败即停。

DooTask 更新流程

刚性技能——前置检查 → 向用户确认一次 → 执行 → 报告结果。任何一步失败立即停止。

核心原则

违反字面规则 = 违反流程精神。 不要擅自加步骤、绕过 sudo/确认，尤其不要替用户决定强制更新（会丢本地改动）。

./cmd update 已封装整套更新（检测本地改动→git fetch→必要时备份库→git pull/reset→composer install→migrate→重启 php+nginx→写 UPDATE_TIME）。本技能职责是更新前把关、选对参数、处理本地改动这一关键岔路、执行前确认。

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

1. 已安装：必须存在 vendor/autoload.php（脚本会查，没装则报"请先执行安装命令"——此时引导用户走 dootask-install）
2. 工作目录：在项目根
3. 当前分支 / 目标分支：默认更新当前分支；用户要切分支用 --branch <分支>。若用户没说，确认是否就更新当前分支
4. 本地改动（关键）：git status 看是否有未提交改动
5. sudo：sudo ./cmd update 需 root

检查通过后汇报结果，向用户确认一次再执行。

关键岔路：本地有改动

脚本检测到本地改动时会询问是否强制更新。强制更新 = git reset --hard origin/<分支>，会丢弃所有本地改动。

• 发现本地有改动 → 停下，把改动清单报告用户，让用户决定：先提交/暂存改动，还是确认强制更新
• 不要替用户选 --force
• 只有用户明确说"丢掉改动强制更新"时，才带 --force

参数选择

参数	作用	何时用
--branch <分支>	切到指定分支再更新	用户要换分支（如切 dev/pro）
--force	强制更新：git checkout -f + git reset --hard	危险：仅用户明确接受"丢弃本地改动"后
--local	本地更新模式：只备份库 + migrate + 重启，不拉远程代码	代码已就位（如手动改过/CI 拉过），只需迁移+重启

数据库

• 远程模式下，脚本检测到 database/ 目录有迁移变动会自动备份数据库再继续——这是脚本内置的，无需手动。
• 但若是大版本升级或用户在意数据，执行前提醒用户：本次可能含库迁移，已有自动备份兜底；如需可先 ./cmd mysql backup 额外备份。

执行

确认（含本地改动决策）后执行：

sudo ./cmd update
# 切分支： sudo ./cmd update --branch pro
# 强制（丢改动，用户确认后）： sudo ./cmd update --force
# 本地模式： sudo ./cmd update --local

成功后报告：更新到的分支、是否做了库备份/迁移、服务是否重启完成。

失败处理

• 任何步骤失败立即停止，原样报告错误
• 不要自动重试、不要自动跳过、不要因为 git pull 失败就自己改成 --force
• 常见失败：
  • 请先执行安装命令 → 走 dootask-install
  • 代码拉取失败，可能存在冲突 → 报告，让用户决定是否 --force（丢改动）或先处理冲突
  • 重启服务失败 → 脚本会尝试 down 后重起；若仍失败，报告交用户

禁止项

错误做法	正确做法
检测到本地改动就自动 --force	停下，报告改动，交用户决定
git pull 失败就自动改用 --force	报告冲突，交用户
不加 sudo	sudo ./cmd update
未装就更新	先走 dootask-install
失败后自动重试/跳过	立即停止

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

• "有点本地改动，强制更新一下就好了" → 不，--force 会丢改动，必须用户拍板
• "拉取冲突了，我 reset 一下" → 不，交用户决定
• "已经装过了吧，直接更新" → 先确认 vendor/autoload.php 在