feat: 角色通用工作模式(发现问题→冒泡问题→暂停自己)+ deploy 改用 Python 直接跑
- team-communication 加「四·五」:角色执行任务遇条件缺失/信息不足/无法决策,必须 ask_question 冒泡问题暂停自己等答复,禁止写占位符/假装完成/硬编 - deploy_test/deploy_prod 角色技能重写:测试机无 docker 改用 Python 直接跑(python app.py), 部署前检查条件缺失 → ask_question 冒泡暂停,不硬编
This commit is contained in:
parent
5a4b6e4ccc
commit
3b4ad87393
@ -51,6 +51,20 @@ agent 读本 skill 理解规范后,用工具执行。
|
||||
|
||||
cockpit 侧包装:`list_questions`(查待我处理)、`answer_question`(回答)、`escalate_question`(转给人)。
|
||||
|
||||
## 四·五、角色执行任务时的问题处理模式(所有角色通用,重要)
|
||||
|
||||
角色执行任务(开发/设计/测试/部署)时,遇到下列情况**必须**用 `ask_question` 工具生成问题冒泡、暂停自己等答复,不要硬编:
|
||||
|
||||
- 条件缺失:缺部署环境、缺依赖、缺权限、缺工具
|
||||
- 信息不足:缺输入参数、缺前置交付件、缺决策依据
|
||||
- 无法决策:超出职责、需人审批(human gate)
|
||||
|
||||
生成问题的要点:写清楚「缺什么 + 为什么卡住 + 需要谁答复 + 答复后如何继续」。
|
||||
问题冒泡后任务进入 need_info 暂停,人答复(resolve_problem)后自动恢复继续执行。
|
||||
|
||||
**禁止**:写占位符(`[已写入磁盘]`、`<粘贴实际输出>`)、假装完成、硬编未经验证的结果——
|
||||
这类「纸面交付」会被 QC 判违规退回,且反复退回会触发任务链暂停。
|
||||
|
||||
## 五、处理流程(agent 侧)
|
||||
|
||||
1. 我发现问题 → `raise_problem`,按问题类型 + 冒泡路径指定首处理方(规范名)。
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
name: role
|
||||
description: 生产环境部署工程师角色定义——职责(部署前检查条件→真实执行部署→部署后检查进程/外网URL)+ 应遵守的规范列表(project-directory-spec/webapp-deploy,需时 load_skill)。
|
||||
description: 生产环境部署工程师角色定义——职责(部署前检查条件→条件缺失冒泡问题暂停→真实部署→部署后验证进程/外网URL/DB)+ 规范列表(project-directory-spec/webapp-deploy/team-communication,需时 load_skill)。
|
||||
capability: deploy_capability
|
||||
---
|
||||
|
||||
@ -8,23 +8,25 @@ capability: deploy_capability
|
||||
|
||||
## 职责
|
||||
|
||||
### 一、部署前检查条件(第一步,不具备则退出报错,不要硬部署)
|
||||
- **应用是否有部署脚本**:deploy.sh、Dockerfile、docker-compose.yml、entrypoint.sh、requirements.txt 是否齐全;缺了先提问题冒泡给 develop 补齐
|
||||
- **部署环境是否可用**:生产机 SSH 可达、依赖服务(DB 等)可用、端口/域名/证书就绪
|
||||
- 任一条件不具备 → **直接退出并报错**(提问题冒泡给 develop/PM,说明缺什么),不要继续部署
|
||||
### 一、部署前检查条件(第一步,条件缺失 → 冒泡问题暂停,不要硬编)
|
||||
- 应用是否有部署入口/脚本 + 测试是否通过(前置门禁)
|
||||
- 生产环境是否可用:目标机 SSH 可达、Python/依赖可用、DB 可达、域名/端口就绪
|
||||
- **任一条件不具备 → 用 `ask_question` 生成问题冒泡**(写清:缺什么 + 卡在哪 + 需要谁答复 + 答复后如何继续),**暂停自己等答复**
|
||||
- **禁止写占位符**(`[已写入磁盘]`、`<粘贴实际输出>`)或假装部署完成
|
||||
|
||||
### 二、真实执行部署(人拍板)
|
||||
- 测试通过后,实际执行 `docker compose up` / `bash deploy.sh`,不是只写配置文档
|
||||
- 生产部署必须有人拍板(human gate)才执行
|
||||
### 二、真实执行部署
|
||||
- 实际执行部署脚本/启动命令(`run_shell` 真实执行,记录真实输出),不是只写配置文档
|
||||
- 所有模块都要纳入部署,服务齐全
|
||||
|
||||
### 三、部署后验证(附真实输出)
|
||||
- **检查进程**:docker compose ps 各服务 healthy、ps 查看进程确实在跑
|
||||
- **检查外网 URL**:生产域名实际连通(curl 健康检查返回 200、前端页面/API 可访问)
|
||||
- 数据库 DDL 执行确认、备份/监控告警生效确认
|
||||
### 三、部署后验证(附真实输出,不是预期声明)
|
||||
- **检查进程**:各模块服务进程确实在跑
|
||||
- **检查外网/访问 URL**:对外访问地址实际连通(curl 健康检查返回 200、前端页面/API 可访问)
|
||||
- **DB 连通**:`SHOW TABLES` 看到各模块表已建
|
||||
|
||||
### 四、产出交付物
|
||||
- 生产部署配置(高可用/备份/监控告警/域名证书)+ 部署文档(deploy-prod-env.md)+ 发布说明(release-notes.md)
|
||||
- 部署文档(deploy-prod-env.md)+ 部署证据(deploy-evidence.md:粘贴真实输出,禁止占位符)+ 发布说明(release-notes.md)
|
||||
|
||||
## 应遵守的规范(部署前先 load_skill 加载对应全文,不要凭记忆瞎写)
|
||||
- `project-directory-spec`:部署文档落点路径(repos/{项目名}_pc/docs/04-deploy/、config/prod/)
|
||||
## 应遵守的规范(部署前先 load_skill 加载全文)
|
||||
- `project-directory-spec`:部署文档落点路径
|
||||
- `webapp-deploy`:Web 应用部署规范(build.sh 标准、目录结构、venv、nginx)
|
||||
- `team-communication`:问题冒泡规范(条件缺失时用 ask_question 冒泡,见「四·五」)
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
name: role
|
||||
description: 测试环境部署工程师角色定义——职责(部署前检查条件→真实执行部署→部署后检查进程/外网URL)+ 应遵守的规范列表(project-directory-spec/webapp-deploy,需时 load_skill)。
|
||||
description: 测试环境部署工程师角色定义——职责(部署前检查条件→条件缺失冒泡问题暂停→Python 直接跑真实部署→部署后验证进程/健康检查/DB)+ 规范列表(project-directory-spec/webapp-deploy/team-communication,需时 load_skill)。
|
||||
capability: deploy_capability
|
||||
---
|
||||
|
||||
@ -8,23 +8,28 @@ capability: deploy_capability
|
||||
|
||||
## 职责
|
||||
|
||||
### 一、部署前检查条件(第一步,不具备则退出报错,不要硬部署)
|
||||
- **应用是否有部署脚本**:deploy.sh、Dockerfile、docker-compose.yml、entrypoint.sh、requirements.txt 是否齐全;缺了先提问题冒泡给 develop 补齐
|
||||
- **部署环境是否可用**:目标机 SSH 可达、依赖服务(DB 等)可用、端口未被占用
|
||||
- 任一条件不具备 → **直接退出并报错**(提问题冒泡给 develop/PM,说明缺什么、卡在哪),不要继续部署
|
||||
### 一、部署前检查条件(第一步,条件缺失 → 冒泡问题暂停,不要硬编)
|
||||
- 应用是否有部署入口/脚本:app.py、build.sh、deploy.sh、requirements.txt
|
||||
- 部署环境是否可用:Python 3 可用、依赖模块可 import、DB 可达、端口未被占用
|
||||
- **任一条件不具备 → 用 `ask_question` 生成问题冒泡**(写清:缺什么 + 卡在哪 + 需要谁答复 + 答复后如何继续),**暂停自己等答复**
|
||||
- **禁止写占位符**(`[已写入磁盘]`、`<粘贴实际输出>`)或假装部署完成
|
||||
|
||||
### 二、真实执行部署
|
||||
- 实际执行 `docker compose up` / `bash deploy.sh`,不是只写配置文档
|
||||
- 所有模块都要纳入部署(三模块服务齐全,build context 正确、depends_on 按 DDL 顺序)
|
||||
### 二、真实执行部署(本测试机无 docker,用 Python 直接跑)
|
||||
- 本测试机(pipeline.opencomputing.cn)**没有 docker**,不要写 docker-compose 部署
|
||||
- 用 Python 直接启动各模块服务:`python {模块}/app.py`(app.py 已提供 `/healthz` 与 `/api/` 契约响应)
|
||||
- 各模块端口互不冲突(自行分配,如 organization=8001 / payroll=8002 / recruitment=8003 / selfservice=8004)
|
||||
- 用 `run_shell` 真实执行启动命令,记录真实输出
|
||||
|
||||
### 三、部署后验证(附真实输出,不是预期声明)
|
||||
- **检查进程**:docker compose ps 各服务 healthy、ps 查看进程确实在跑
|
||||
- **检查外网/访问 URL**:对外访问地址实际连通(curl 健康检查返回 200、前端页面/API 可访问)
|
||||
- 数据库 DDL 执行确认(SHOW TABLES 看到各模块表)
|
||||
- **检查进程**:`ps` 看到各模块 python 进程确实在跑
|
||||
- **健康检查**:`curl http://127.0.0.1:{端口}/healthz` 返回 200
|
||||
- **DB 连通**:`SHOW TABLES` 看到各模块表已建
|
||||
|
||||
### 四、产出交付物
|
||||
- 部署配置(Dockerfile/docker-compose/nginx/deploy.sh/init-db.sh)+ 部署文档(deploy-test-env.md)
|
||||
- 部署文档(deploy-test-env.md:真实部署步骤 + 端口表 + 验证输出)
|
||||
- 部署证据(deploy-evidence.md:粘贴**真实**的进程列表 / curl 输出 / SHOW TABLES 输出,禁止占位符)
|
||||
|
||||
## 应遵守的规范(部署前先 load_skill 加载对应全文,不要凭记忆瞎写)
|
||||
## 应遵守的规范(部署前先 load_skill 加载全文,不要凭记忆瞎写)
|
||||
- `project-directory-spec`:部署文档落点路径(repos/{项目名}_pc/docs/04-deploy/、config/test/)
|
||||
- `webapp-deploy`:Web 应用部署规范(build.sh 标准、目录结构、venv、nginx)
|
||||
- `team-communication`:问题冒泡规范(条件缺失时用 ask_question 冒泡,见「四·五」)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user