pipeline-service/pipeline_service
ymq ccba6f470e fix(orchestration): 环境信息只卡部署,不卡需求/设计/开发
用户 2026-08-26 定调纠正了我原方案的错误。我原本提议把「env/*.json 无占位符」做成
requirement 阶段的结束条件(把缺陷堵在最便宜的阶段)——这是错的,会把死循环制度化:

主机/SSH账号/密码/部署路径是**外部输入**,requirement agent 根本产不出来。若要求它
填全才能通过,agent 就卡在无法解决的事情上无限重试。正是 2026-08-25 hrs7 的死循环成因:
deploy_test 因 env 占位符失败 → PM 判「根因在 requirement」→ 回退整链并作废 owner 已
人工确认的三模块设计 → 重做需求后 env 依然是占位符 → 再次失败。

实际上 hrs7 的 requirement agent 做得对:填了能确定的(port 9187/dbname hrs7),未知项
标「待明确」并列入 pending 清单 —— 这是正确履职,被回退是冤枉的。

实现:
1. _check_deploy_env_ready 只对 agent.deploy_test/deploy_prod 生效,其余角色一律放行。
   检查 ssh.host/user、deploy.path、db.host/user/dbname + ssh 凭据(password 或 key_file
   二者其一) + requirement 自列的 pending 清单;domain/status 等非必需项不阻断。
2. 认领路径加此进入条件:不齐备 → 不进 running,任务置 waiting(界面可见,不在 submitted
   静默打转) + 冒泡 deploy_env_required 人工任务给 owner,写清缺哪些字段、文件在哪,
   并说明「补齐后自动继续,无需重跑上游阶段」。按 task_id 去重。
3. PM prompt 加硬约束:外部输入缺失禁止回退上游。回退前先自问「这个缺陷是上游 agent
   能做对却做错了,还是本来就产不出?」——前者才回退,后者一律冒泡等人补。

验证:11 例离线用例全过(用 hrs7 线上真实 test.json 结构),覆盖
requirement/design/develop/test 四阶段占位符必须放行、部署阶段必须阻塞并列缺失字段、
补齐后放行、密钥文件替代密码、空密码无密钥阻塞、domain 缺失不阻断。
2026-08-26 12:09:23 +08:00
..