feat: 部署信息集中到工作空间根目录 env/ 文件夹（单一事实源）
- project-directory-spec：顶层目录加 env/（test.json + prod.json），
集中保存主机/SSH/端口/DB/路径/域名，改配置只改一处
- requirement：明确部署环境需求落成 env/test.json + env/prod.json
- deploy_test/deploy_prod：从 env/{test,prod}.json 读环境信息（不再写死、不再从 apps 散读）
部署信息不写死在技能里，也不散落项目各处，集中在 env/ 一处。
This commit is contained in:
parent
0dacb96388
commit
b1b255b95f
@ -30,13 +30,16 @@ global（全局基础）→ org（客户）→ pipeline（产线）→ project
|
||||
```
|
||||
{workspace}/
|
||||
├── README.md # 项目说明
|
||||
├── env/ # 部署环境信息（集中保存，部署时读，改配置只改这里）
|
||||
│ ├── test.json # 测试环境（主机/SSH/端口/DB/路径）
|
||||
│ └── prod.json # 生产环境
|
||||
└── repos/ # 项目仓库目录，每个子目录都是一个独立 git 仓库
|
||||
├── {项目名}_pc/ # 项目工程文档仓库（一个项目一个）
|
||||
├── {应用名}_app/ # 应用仓库（一个应用一个，可多个）
|
||||
└── {模块名}/ # 独立模块仓库（一个模块一个，可多个）
|
||||
```
|
||||
|
||||
工作空间根下只有 `README.md` 和 `repos/` 两个顶层项，其余所有内容都进 `repos/` 下的对应仓库。
|
||||
工作空间根下只有 `README.md`、`env/`、`repos/` 三个顶层项，其余所有内容都进 `repos/` 下的对应仓库。**部署环境信息统一放 `env/`，不散落到需求/设计/代码各处**。
|
||||
|
||||
## 三、目录作用
|
||||
|
||||
@ -44,6 +47,27 @@ global（全局基础）→ org（客户）→ pipeline（产线）→ project
|
||||
- 每个项目一个，放在工作空间根。
|
||||
- 内容：项目定位、功能概述、技术栈、目录导航、快速上手。
|
||||
|
||||
### env/ —— 部署环境信息（集中管理，部署时读）
|
||||
- 每个项目一个，放在工作空间根，与 repos/ 平级。
|
||||
- 集中保存项目所有部署环境信息（测试/生产的主机、SSH 账号、部署目录、端口、数据库连接、域名）。
|
||||
- **单一事实源**：改端口等配置只改这里一个文件，不散落到需求/设计/代码各处。
|
||||
- requirement 阶段生成（用户给了环境信息就填，没给标注待明确 + 冒泡问）；design/develop 读端口；deploy_test/deploy_prod 读对应环境执行部署。
|
||||
|
||||
文件格式（JSON）：
|
||||
```json
|
||||
// env/test.json
|
||||
{
|
||||
"environment": "test",
|
||||
"host": "hrstest.opencomputing.cn",
|
||||
"ssh": { "user": "hrs", "port": 22 },
|
||||
"deploy_dir": "~/hrs_app",
|
||||
"app_port": 9280,
|
||||
"access_url": "http://hrstest.opencomputing.cn:9280",
|
||||
"database": { "host": "localhost", "port": 3306, "user": "test", "password": "test123", "name": "hrs" },
|
||||
"runtime": { "python": "3.10", "docker": false }
|
||||
}
|
||||
```
|
||||
|
||||
### repos/ —— 项目仓库目录
|
||||
- 项目的仓库根目录，**每个子目录都是一个独立 git 仓库**（独立 `.git`、独立提交、独立版本管理）。
|
||||
- 临时文件、非仓库文件**不进 repos/**。
|
||||
@ -101,6 +125,7 @@ global（全局基础）→ org（客户）→ pipeline（产线）→ project
|
||||
|------|------|------|
|
||||
| requirement | 需求规格说明书 | `repos/{项目名}_pc/docs/00-requirement/requirement-spec.md` |
|
||||
| requirement | 应用部署单元定义 | `repos/{项目名}_pc/apps/{应用名}.md` |
|
||||
| requirement | 部署环境信息 | `env/test.json` + `env/prod.json`（集中保存，改配置只改这里） |
|
||||
| design | 系统架构 / UI 设计 | `repos/{项目名}_pc/docs/01-design/architecture.md`、`ui-design.md` |
|
||||
| design | 模块清单 + 模块级设计 | `repos/{项目名}_pc/modules/{模块名}.md` + `repos/{项目名}_pc/modules/{模块名}/design.md` + `repos/{项目名}_pc/modules/{模块名}/skill/SKILL.md`（模块技能文档，develop 参考） |
|
||||
| develop | 模块源码 | `repos/{模块名}/`（内部结构以 module-development-spec 为准） |
|
||||
@ -123,4 +148,4 @@ QC/PM 检查交付件时，用 `read_file` / `list_files` 的路径是相对工
|
||||
| 测试文档 | `repos/{项目名}_pc/docs/03-test/` |
|
||||
| 部署文档 | `repos/{项目名}_pc/docs/04-deploy/` |
|
||||
|
||||
⚠️ 工作空间根下只有 `README.md` 和 `repos/` 两个顶层项，**所有交付文件都在 `repos/` 下**。检查时路径必须从 `repos/` 写起，不要在工作空间根下找 `docs/`、`apps/` 等目录——它们不存在。
|
||||
⚠️ 工作空间根下只有 `README.md`、`env/`、`repos/` 三个顶层项，**所有交付文件都在 `repos/` 下**（部署环境信息在 `env/`）。检查时路径必须从 `repos/` 写起，不要在工作空间根下找 `docs/`、`apps/` 等目录——它们不存在。
|
||||
|
||||
@ -6,14 +6,14 @@ capability: deploy_capability
|
||||
|
||||
# 生产环境部署工程师（deploy_prod）角色定义
|
||||
|
||||
## 部署环境来源（禁止写死环境信息）
|
||||
## 部署环境来源（读 env/prod.json，禁止写死）
|
||||
|
||||
生产环境信息（主机 / SSH 账号 / 部署目录 / 端口 / 数据库连接 / 域名证书）**从项目需求 `apps/{应用名}.md` 的「部署环境」章节读取**，不得写死默认值。需求未明确的环境信息用 `ask_question` 冒泡问用户，别自己编。
|
||||
生产环境信息（主机 / SSH 账号 / 部署目录 / 端口 / 数据库连接 / 域名证书）**从项目工作空间根目录 `env/prod.json` 读取**（单一事实源，见 project-directory-spec），不得写死默认值。需求未明确的环境信息用 `ask_question` 冒泡问用户，别自己编。
|
||||
|
||||
## 职责
|
||||
|
||||
### 一、部署前检查条件（第一步，条件缺失 → 冒泡问题暂停，不要硬编）
|
||||
- 先 read_file 读 `apps/{应用名}.md` 的「部署环境」章节，拿到主机/账号/目录/端口/DB/域名
|
||||
- 先 read_file 读工作空间根目录 `env/prod.json`，拿到主机/账号/目录/端口/DB/域名
|
||||
- 应用是否有部署入口（`app/{应用名}.py` 唯一入口）+ 测试是否通过（前置门禁）
|
||||
- 生产环境是否可用：目标机 SSH 可达、Python/依赖可用、DB 可达、域名/端口就绪
|
||||
- **任一条件不具备 → 用 `ask_question` 生成问题冒泡**（写清：缺什么 + 卡在哪 + 需要谁答复 + 答复后如何继续），**暂停自己等答复**
|
||||
|
||||
@ -6,14 +6,14 @@ capability: deploy_capability
|
||||
|
||||
# 测试环境部署工程师（deploy_test）角色定义
|
||||
|
||||
## 部署环境来源（禁止写死环境信息）
|
||||
## 部署环境来源（读 env/test.json，禁止写死）
|
||||
|
||||
部署环境信息（主机 / SSH 账号 / 部署目录 / 应用端口 / 数据库连接）**从项目需求 `apps/{应用名}.md` 的「部署环境」章节读取**，不得用写死的默认值（写死 `hrstest.opencomputing.cn` / `~/hrs_app` / `test/test123` 之类都是错的——不同项目测试环境不同）。需求里未明确的环境信息，用 `ask_question` 冒泡问用户，别自己编。
|
||||
部署环境信息（主机 / SSH 账号 / 部署目录 / 应用端口 / 数据库连接）**从项目工作空间根目录 `env/test.json` 读取**（这是集中保存部署信息的单一事实源，见 project-directory-spec），不得写死默认值。需求里未明确的环境信息（env/test.json 缺失或字段为空），用 `ask_question` 冒泡问用户，别自己编。
|
||||
|
||||
## 职责
|
||||
|
||||
### 一、部署前检查条件（第一步，条件缺失 → 冒泡问题暂停，不要硬编）
|
||||
- 先 read_file 读 `apps/{应用名}.md` 的「部署环境」章节，拿到主机/SSH账号/部署目录/端口/DB 连接
|
||||
- 先 read_file 读工作空间根目录 `env/test.json`，拿到主机/SSH账号/部署目录/端口/DB 连接
|
||||
- 应用是否有部署入口（`app/{应用名}.py` 唯一入口 + `load_{模块}()` 挂载各模块）
|
||||
- 目标机是否可达：`ssh -o BatchMode=yes {SSH账号}@{主机} echo ok`
|
||||
- 依赖是否可用：目标机 python3、能否 import 模块依赖
|
||||
|
||||
@ -10,7 +10,7 @@ capability: feature_propose_capability
|
||||
- **拆解需求提功能（落库，别只写文档）**：用 `propose_feature` 把需求拆解成功能点，落库 sd_features（状态 proposed），每个业务域都要有对应 feature
|
||||
- 产出需求规格说明书（requirement-spec.md）+ 需求评审记录（requirement-review.md）
|
||||
- 识别应用（部署单元，至少一个，含端口/环境），产出 apps/{应用名}.md
|
||||
- 明确部署环境需求（测试/生产的资源规格、依赖服务、端口、环境变量、高可用、备份、域名证书、监控告警）
|
||||
- 明确部署环境需求，并**落成 `env/test.json` + `env/prod.json`**（工作空间根目录，集中保存主机/SSH/端口/DB/路径/域名，是部署信息的单一事实源，见 project-directory-spec）——部署信息只在这里一份，不散落到需求/设计/代码各处，改配置只改这里
|
||||
- 需求阶段只识别应用，不划分模块（模块划分是 design 阶段的架构决策）
|
||||
- **需求不明确时禁止编造具体值**：端口、IP、域名、账号、资源规格等需求未给出或含糊的值，**不得自己编**（编造端口 9286/编造子域名等都是错的）。做法：① 在需求文档中该处标注「待明确」，并在文档末尾列出「需向用户确认的问题清单」；② 关键信息（如部署端口/环境）用 `ask_question` 冒泡问用户，暂停等答复。宁可标注待明确，不可编一个看似合理的值。
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user