gouki
e6bbfdfdc7
FAILED_STATE 语义原为「永久拒绝该远端提交」，但闸门失败可能源于环境问题 而非代码问题（venv 缺 pytest、systemd PATH 缺 nvm）。此时修复手段是修环境， 远端 hash 并未变化，于是形成自锁： 旧脚本写入标记 → 修好环境后的新脚本因 hash 未变被跳过 → 标记永不失效 cc1 实测已因此冻结：dd192bac 被拦（纯文档提交），随后e9cc95c修 update.sh 的提交本身也被同一个错误判定写入标记，每分钟只打印「跳过重复部署」， 只能人工 ssh 删除标记才能恢复。 改为带时间戳的冷却窗口（DEPLOY_COOLDOWN，默认 6h）： - 标记内容由裸 hash 变为 "<commit> <epoch> <单行原因>" - 到期自动重试，兼得防抖（不反复抖动/告警轰炸）与自愈（修完环境自动恢复） - 识别旧格式（无时间戳）即清理并放行，不让旧死锁残留 - 日志输出真实失败原因与「立即重试」命令，不再一律宣称「健康检查失败」 此前同批修复的另外两处（随e9cc95c一并上线）： - 测试闸门区分「pytest 未安装」与「测试失败」，前者跳过而非拦截 - JS 闸门 node 探测增加 ~/.nvm/versions/node/*/bin 回退 验证：bash -n 通过；冷却逻辑 10 项分支测试全通过；pytest 334 passed