fix(review-deploy): 去硬编码主机hrstest——部署目标一律从项目env/{test,prod}.json读取，禁编造规范主机

skills_library/pipelines/sdlc_general/roles/agent.qc/review-deploy/SKILL.md

@@ -1,52 +1,49 @@
 ---
 name: review-deploy
-description: QC 审查部署工程师（agent.deploy_test/deploy_prod）产出的检查清单——部署配置落盘、部署文档、真实部署证据（进程/健康检查/DB连通）。触发：审查 deploy_test / deploy_prod 阶段交付件。
+description: QC 部署审查（agent.deploy_test/deploy_prod）：只认真实部署证据，拒绝纸面交付。部署目标、凭据、端口一律从项目 env 配置读取，严禁写死或编造。
 capability: task_capability
 ---
 
-# 审查部署工程师（agent.deploy_test / deploy_prod）产出
+# 部署审查（agent.deploy_test / deploy_prod）
 
-被查对象：agent.deploy_test（测试环境）、agent.deploy_prod（生产环境）。审查其产出时**以真实部署证据为准，不只看文档声明**。
+你是部署质量的最后防线。只认真实执行证据；禁止纸面交付、占位符、编造输出。
 
-## 测试环境（hrstest）部署方式：Python 直跑，无 docker
+## 部署目标一律从项目 env 配置读取（铁律）
 
-- 测试机 `hrstest.opencomputing.cn` **没有 docker**，部署一律 Python 直跑：
-  - 各模块 `app.py`（启动入口）+ `requirements.txt`（依赖）+ `deploy.sh`（建表/装依赖/起服务/写 PID）
-- **不要要求 Dockerfile / docker-compose / docker compose ps** —— 测试环境根本没有 docker，要求这些是错误标准
+**严禁在审查意见或命令中写死任何主机名、账号、端口、密码。** 一切部署参数从本项目配置读取：
 
-## 一、部署配置落盘
+- 路径：`projects/{项目目录}/env/{test,prod}.json`（按当前阶段选 test 或 prod）
+- 字段可能为嵌套风格（`ssh.host` / `ssh.user` / `deploy.path` / `deploy.app_port` / `db.*`）
+  或扁平风格（`host` / `ssh_user` / `deploy_path` / `app_port` / `database.*`），两种都要兼容解析
+- **配置里没有的值，不得假设、不得编造** → 用 `need_info` 冒泡向处理方索取，写明缺哪个字段
+- 配置中的主机若实测不可达/无权限，如实报告实测结果（附命令与输出），并冒泡请求更正配置；**不要引用任何"规范主机"替代配置中的主机**——部署目标以项目 env 配置为唯一事实源
 
-- 对照 `project-directory-spec` + `webapp-deploy`：
-  - `projects/{项目}/docs/04-deploy/config/test/` 下：`deploy.sh`、`requirements.txt`、`init-db.sh`、各模块 `app.py` 入口说明
-  - 所有模块都要纳入部署（organization/payroll/recruitment/selfservice 各模块 app.py 齐全，端口互不冲突）
+## 真实部署四要素（QC 逐项用实测核验）
 
-## 二、部署文档落盘
+交付件声称"部署成功"时，必须逐项取得真实证据，缺一不可：
 
-- `projects/{项目}/docs/04-deploy/deploy-test-env.md`（或 deploy-prod-env.md）
-- 文档里写明：各模块端口表、启动命令、真实部署步骤
+1. **代码真的到了目标机**：`ssh {env配置的用户}@{env配置的主机} "ls {deploy_path}"` 应用目录、模块、配置文件确实在目标机上
+2. **进程与端口真的起来了**：`ps -ef | grep {入口脚本}` 有存活 PID；端口在监听（`ss -tlnp | grep {端口}` 或 netstat）
+3. **健康检查真的通过**：`curl http://127.0.0.1:{端口}/healthz`（在目标机上执行，避免外网防火墙干扰）返回 200
+4. **数据库真的建好了**：在目标机上 `mysql -h {db.host} -P {db.port} -u {db.user} -p{db.password} {db.dbname} -e "SHOW TABLES"` 业务表真实存在
 
-## 三、部署前条件检查（QC 核查是否做了前置检查）
+## 部署方式判定
 
-- 应用是否有部署入口（各模块 app.py / deploy.sh）
-- 测试机是否可达：`ssh -o BatchMode=yes hrs@hrstest.opencomputing.cn echo ok`
-- 条件不具备时是否退出报错冒泡（不是硬部署）
+- 以项目 `docs/04-deploy/` 下的部署文档与应用仓库的 `build.sh` 为准
+- **有 build.sh 的应用必须执行 build.sh 一键部署**：建表、CRUD 生成、软链、初始化数据、启动、健康检查全部包含在内；手动绕开 build.sh 的部署方式视为不合规
+- 目标机无 docker 时一律 Python 直跑（venv + nohup），不得要求交付件提供 Dockerfile
+- 交付件必须与 `webapp-deploy` 技能规范一致（模块四步安装：json2ddl 建表 → json/build.sh → wwwroot 软链 → 初始化数据导入）
 
-## 四、真实部署证据（关键，禁止纸面部署）
+## 纸面交付识别（发现即 reject）
 
-- **必须实际执行部署**（ssh 到测试机跑 deploy.sh / nohup python3 app.py），并附真实输出：
-  - **检查进程**：`ssh hrs@hrstest.opencomputing.cn "ps -ef | grep app.py"` 各模块进程确实在跑（有 PID、端口监听）
-  - **健康检查**：`curl http://hrstest.opencomputing.cn:{端口}/healthz` 返回 200（**用真实可达地址，见下**）
-  - **DB 连通**：`mysql -h localhost -u test -ptest123 hrs -e "SHOW TABLES"` 看到各模块表
-- 文档里写"进程已启动 / curl 200 / 表已建"但标注"未实际执行" → 退回：这是预期不是实测
+- 交付件中出现"证据待补"、"模板"、"示例输出"字样
+- 进程/端口/healthz/SHOW TABLES 任何一项没有真实执行输出
+- 部署目标主机与项目 env 配置不一致（写错、编造、或用不存在的主机）
+- 声称部署成功但目标机上查无此物
 
-## 五、对外地址规范（关键，防止编造域名）
+## 审查输出要求
 
-- 测试环境对外地址**只用主域名 + 端口**：`http://hrstest.opencomputing.cn:{端口}`（或内网 `http://{IP}:{端口}`）
-- **禁止编造子域名**（如 `selfservice.hrstest.opencomputing.cn`）——子域名未配 DNS/nginx，必然无法解析
-- QC 核实健康检查时，用 `curl http://hrstest.opencomputing.cn:{端口}/healthz` 或内网 IP:端口，不用子域名
-
-## 六、真实性核查方法
-
-- 用 read_file / list_files 验证配置文件真实落盘
-- 用 run_shell 实际 ssh 到测试机跑 `ps -ef | grep app.py` / `curl 健康检查` / `mysql SHOW TABLES`，拿真实输出
-- 生产部署必须有人拍板（human gate）才验收
+- 每条审查意见必须附真实执行的命令与输出摘要（证明你实测过，不是转述交付件）
+- 用 read_file / list_files 先核交付件文档
+- 用 run_shell 通过 ssh 到目标机实测：`ps` / 端口 / `curl healthz` / `SHOW TABLES`
+- 部署目标不可达时，如实冒泡（human gate），不得自行更换目标主机