feat(skills): app 划分职责归 design(根据需求划分一个项目几个app) + 角色技能路径同步机构工作空间新设计(去 repos/{项目名}_pc/_app/_模块, 改 projects/docs + 机构 apps/modules)
This commit is contained in:
parent
7842d2570f
commit
21a9f3cfad
@ -59,10 +59,11 @@ projects/{项目名}/docs/01-design/modules/{模块名}/
|
||||
|
||||
### requirement（需求分析师）
|
||||
- **内容**: 项目概述、用户角色及权限、功能列表（含验收标准）、非功能需求、业务流程
|
||||
- **同时创建**: 每个应用一个 `{应用名}_spec.json`（描述 referenced_modules + generated_modules）
|
||||
- **不划分 app**: 一个项目有几个 app（应用）是架构决策，由 design 阶段设计师根据需求分析划分——requirement 只描述功能、不定 app 数量、不写 `{应用名}_spec.json`
|
||||
- **不划分模块**: 模块划分是架构决策，由 design 阶段设计师完成
|
||||
|
||||
### design（系统设计师）
|
||||
- **应用划分**: 根据需求分析划分一个项目有几个 app（应用）——需求只描述功能、不定 app 数量，设计师按「部署单元 / 功能聚合 / 用户边界」划到 N 个 app（每个 app = 一个入口一个端口），产出对应的 `{应用名}_spec.json`
|
||||
- **应用级**: `architecture.md`（系统架构、模块划分、模块间依赖、开发顺序）+ `ui-design.md`（视觉风格/主页面/交互模式/弹窗规范）
|
||||
- **模块级**: 每个模块在 `projects/{项目名}/docs/01-design/modules/{模块名}/` 下产出 design.md（数据设计/CRUD/处理逻辑）+ skill/SKILL.md
|
||||
- **更新**: `docs/01-design/modules/` 下各模块的技术栈、依赖关系、开发顺序
|
||||
|
||||
@ -22,7 +22,7 @@ capability: deploy_capability, bug_report_capability
|
||||
|
||||
### 二、真实执行部署（SSH 到测试机，Python 直跑，不是写文档）
|
||||
0. **清理旧进程（先做，防止多端口/多进程残留）**：部署前先 `pkill -f "app.py"` 或按 pid 文件 kill 掉旧的模块独立进程，**只保留/重启 1 个应用进程**。应用是唯一部署单元，一台测试机只该有 1 个应用进程（一个端口），多个模块独立 app.py 进程 = 多端口问题，必须清掉。
|
||||
1. `scp -r` 应用代码（`{应用名}_app`）+ 各模块（Python 包）到测试机部署目录（从 apps/{应用名}.md 读）
|
||||
1. 从机构 `apps/{应用名}/`（应用仓库）+ `modules/{模块名}/`（模块仓库）读代码，`scp -r` 到测试机部署目录（部署前先给这些仓库设置远程仓库，见 project-directory-spec 第八节）
|
||||
2. SSH 到测试机执行真实部署（主机/目录/DB 均从需求读）：
|
||||
- 建表：`mysql -h {DB_HOST} -u {DB_USER} -p{DB_PASS} {DB_NAME} < {模块}/ddl/*.sql`
|
||||
- 装依赖：`pip3 install -e {模块}`（模块是 Python 包，pip 安装）
|
||||
|
||||
@ -8,12 +8,13 @@ capability: task_capability
|
||||
|
||||
## 职责
|
||||
- 应用级设计：architecture.md（架构、模块划分、模块间依赖、开发顺序）+ ui-design.md（视觉风格/布局/交互模式）
|
||||
- **应用划分**：一个项目有几个 app（应用），由设计师根据需求分析来设计/划分——需求只描述功能、不限定 app 数量；设计师按「部署单元 / 功能聚合 / 用户边界」把需求功能划到 N 个 app（每个 app = 一个入口一个端口），在 architecture.md 里写明 app 清单与划分理由，并产出对应的 {应用名}_spec.json
|
||||
- 模块级设计：每个模块的 modules/{模块名}.md + design.md + skill/SKILL.md
|
||||
- 模块划分 + 模块间依赖关系 + 开发顺序由设计师完成，PM 按此派发 develop 任务
|
||||
- 基础模块（apppublic/sqlor/ahserver/accounting/appbase/rbac）已存在，不列为待开发模块
|
||||
|
||||
## 应遵守的规范（设计前先 load_skill 加载对应全文，不要凭记忆瞎写）
|
||||
- `project-directory-spec`：项目目录结构 + 设计文档落点路径（repos/{项目名}_pc/docs/01-design/、modules/）+ 应用与模块的关系（应用=唯一部署单元，模块不独立部署）
|
||||
- `project-directory-spec`：机构工作空间结构（projects/apps/modules）+ 设计文档落点路径（projects/{项目}/docs/01-design/）+ 应用与模块的关系（应用=唯一部署单元，模块不独立部署；app 划分见职责「应用划分」）
|
||||
- `sdlc-repo-standard`：设计交付件的内容格式（templates/module-design.md、templates/module-skill.md）
|
||||
- `web-application-spec`：应用规范（应用结构、应用如何通过 load_{module}() 导入模块、一个入口一个端口）
|
||||
- `module-development-spec`：模块规范（模块是 Host-Agnostic Python 包、不是独立部署单元，无独立 app.py/端口）
|
||||
|
||||
@ -16,12 +16,12 @@ capability: feature_dev_capability, bug_fix_capability
|
||||
## 职责
|
||||
|
||||
### 应用级 develop（design 自动派生的「应用架构」任务）
|
||||
- 产出**应用脚手架**：`repos/{应用名}_app/` 应用仓库，含 `app/{应用名}.py`（唯一入口，init() 里 load 各模块）、`conf/config.json`、`build.sh`（一键部署）、`.env`
|
||||
- 产出**应用脚手架**：机构 `apps/{应用名}/` 应用仓库，含 `app/{应用名}.py`（唯一入口，init() 里 load 各模块）、`conf/config.json`、`build.sh`（一键部署）、`.env`
|
||||
- `app/{应用名}.py` 里定义 `get_module_dbname(m)`（模块→库名映射，禁止硬编码）并在 init() 挂到 ServerEnv，逐个 `load_{模块}()` 挂载业务模块
|
||||
- **应用是唯一部署单元**：一个应用 = 一个入口 = 一个端口；模块不独立部署
|
||||
|
||||
### 模块级 develop（PM 按模块清单派发的「模块开发」任务）
|
||||
- 按 design 阶段设计师的模块清单，为每个模块产出可运行源码，写入模块独立仓库 `repos/{模块名}/`
|
||||
- 按 design 阶段设计师的模块清单，为每个模块产出可运行源码，写入机构 `modules/{模块名}/` 模块仓库
|
||||
- 模块是 Python 包（无独立 app.py/端口/Dockerfile），通过 `load_{模块}()` 挂到应用；取库名用 `ServerEnv().get_module_dbname('模块名')`，禁止硬编码 DBNAME
|
||||
- 基础模块（apppublic / sqlor / ahserver / accounting / appbase / rbac）已存在，直接复用，不重新开发
|
||||
|
||||
|
||||
@ -17,12 +17,12 @@ capability: task_capability
|
||||
## 一、部署配置落盘
|
||||
|
||||
- 对照 `project-directory-spec` + `webapp-deploy`：
|
||||
- `repos/{项目名}_pc/config/test/` 下：`deploy.sh`、`requirements.txt`、`init-db.sh`、各模块 `app.py` 入口说明
|
||||
- `projects/{项目}/docs/04-deploy/config/test/` 下：`deploy.sh`、`requirements.txt`、`init-db.sh`、各模块 `app.py` 入口说明
|
||||
- 所有模块都要纳入部署（organization/payroll/recruitment/selfservice 各模块 app.py 齐全，端口互不冲突）
|
||||
|
||||
## 二、部署文档落盘
|
||||
|
||||
- `repos/{项目名}_pc/docs/04-deploy/deploy-test-env.md`（或 deploy-prod-env.md）
|
||||
- `projects/{项目}/docs/04-deploy/deploy-test-env.md`（或 deploy-prod-env.md）
|
||||
- 文档里写明：各模块端口表、启动命令、真实部署步骤
|
||||
|
||||
## 三、部署前条件检查（QC 核查是否做了前置检查）
|
||||
|
||||
@ -11,17 +11,17 @@ capability: task_capability
|
||||
## 一、应用级设计落盘（对照 project-directory-spec + web-application-spec + module-development-spec）
|
||||
|
||||
- 对照 `project-directory-spec`：
|
||||
- `repos/{项目名}_pc/docs/01-design/architecture.md`（架构 + 模块划分 + 模块间依赖 + 开发顺序）
|
||||
- `repos/{项目名}_pc/docs/01-design/ui-design.md`（视觉风格/布局/交互模式）
|
||||
- `projects/{项目}/docs/01-design/architecture.md`（架构 + 模块划分 + 模块间依赖 + 开发顺序）
|
||||
- `projects/{项目}/docs/01-design/ui-design.md`（视觉风格/布局/交互模式）
|
||||
- **应用与模块关系（关键，对照 web-application-spec + module-development-spec）**：
|
||||
- 应用是唯一部署单元：一个应用 = 一个入口（`app/{应用名}.py`）= 一个端口。architecture.md 必须明确这是【单体应用】（或明确列出多个应用），**不能把功能模块设计成独立服务/微服务**
|
||||
- 应用是唯一部署单元：一个应用 = 一个入口（`app/{应用名}.py`）= 一个端口。architecture.md 必须写明 app 清单——一个项目有几个 app 由 designer 按「部署单元/功能聚合/用户边界」划分，明确这是【单体应用】还是【多个应用】，并写出每个 app 的划分理由，**不能把功能模块设计成独立服务/微服务**
|
||||
- 模块不是独立部署单元：每个模块是应用内的 Python 包，通过 `load_{module}()` 挂载到应用，**无独立 app.py / 端口 / Dockerfile / 服务**
|
||||
- 目录结构：repos/ 下应有 `{应用名}_app`（应用仓库）+ `{模块名}`（模块仓库）。若只有模块仓库没有应用仓库，或模块仓库里带了 app.py / Dockerfile → 退回（违反 module-development-spec）
|
||||
- 目录结构：机构 `apps/{应用名}/`（应用仓库）+ `modules/{模块名}/`（模块仓库）。若只有模块仓库没有应用仓库，或模块仓库里带了 app.py / Dockerfile → 退回（违反 module-development-spec）
|
||||
- 若 architecture.md 出现"四模块服务""每模块一个端口/容器"等设计 → 退回：这是把功能模块错误设计成微服务
|
||||
|
||||
## 二、模块级设计落盘
|
||||
|
||||
- 每个模块：`repos/{项目名}_pc/modules/{模块名}.md`（模块清单）+ `{模块名}/design.md`（数据设计/CRUD/处理逻辑）+ `{模块名}/skill/SKILL.md`（模块技能文档）
|
||||
- 每个模块：`projects/{项目}/docs/01-design/modules/{模块名}.md`（模块清单）+ `{模块名}/design.md`（数据设计/CRUD/处理逻辑）+ `{模块名}/skill/SKILL.md`（模块技能文档）
|
||||
- 模块划分 + 模块间依赖 + 开发顺序明确，PM 据此派发 develop 任务
|
||||
- 基础模块（apppublic/sqlor/ahserver/accounting/appbase/rbac）不列为待开发模块
|
||||
|
||||
|
||||
@ -17,13 +17,13 @@ capability: task_capability
|
||||
|
||||
## 二、需求文档落点
|
||||
|
||||
- 对照 `project-directory-spec`：需求规格说明书 `repos/{项目名}_pc/docs/00-requirement/requirement-spec.md`
|
||||
- 需求评审记录 `repos/{项目名}_pc/docs/00-requirement/requirement-review.md`
|
||||
- 对照 `project-directory-spec`：需求规格说明书 `projects/{项目}/docs/00-requirement/requirement-spec.md`
|
||||
- 需求评审记录 `projects/{项目}/docs/00-requirement/requirement-review.md`
|
||||
|
||||
## 三、应用部署单元识别
|
||||
## 三、应用划分（design 职责，requirement 不产出）
|
||||
|
||||
- `repos/{项目名}_pc/apps/{应用名}.md`：至少一个应用，含端口、部署环境
|
||||
- 应用 = 部署单元，需求阶段只识别应用，不划分模块
|
||||
- requirement 阶段**不划分 app、不产出 apps/{应用名}.md 或 {应用名}_spec.json**（app 划分是 design 阶段的架构决策，见 design 角色技能）
|
||||
- 若 requirement 越权划分了 app 或产出了 app 说明文件 → 退回
|
||||
|
||||
## 四、部署环境需求明确
|
||||
|
||||
|
||||
@ -38,7 +38,7 @@ capability: task_capability
|
||||
|
||||
## 六、测试文档落点
|
||||
|
||||
- 对照 `project-directory-spec`：`repos/{项目名}_pc/docs/03-test/` 下 test-plan.md、test-cases.md、test-report.md 真实落盘
|
||||
- 对照 `project-directory-spec`：`projects/{项目}/docs/03-test/` 下 test-plan.md、test-cases.md、test-report.md 真实落盘
|
||||
|
||||
## 七、真实性核查方法
|
||||
|
||||
|
||||
@ -9,12 +9,12 @@ capability: feature_propose_capability
|
||||
## 职责
|
||||
- **拆解需求提功能（落库，别只写文档）**：用 `propose_feature` 把需求拆解成功能点，落库 sd_features（状态 proposed），每个业务域都要有对应 feature
|
||||
- 产出需求规格说明书（requirement-spec.md）+ 需求评审记录（requirement-review.md）
|
||||
- 识别应用（部署单元，至少一个，含端口/环境），产出 apps/{应用名}.md
|
||||
- 不划分 app：一个项目有几个 app（应用）是 design 阶段的架构决策，requirement 只描述功能、不定 app 数量、不产出 apps/{应用名}.md 或 {应用名}_spec.json
|
||||
- 明确部署环境需求，并**落成 `env/test.json` + `env/prod.json`**（工作空间根目录，集中保存主机/SSH/端口/DB/路径/域名，是部署信息的单一事实源，见 project-directory-spec）——部署信息只在这里一份，不散落到需求/设计/代码各处，改配置只改这里
|
||||
- 需求阶段只识别应用，不划分模块（模块划分是 design 阶段的架构决策）
|
||||
- 需求阶段不划分 app、不划分模块（app 划分和模块划分都是 design 阶段的架构决策）
|
||||
- **需求不明确时禁止编造具体值**：端口、IP、域名、账号、资源规格等需求未给出或含糊的值，**不得自己编**（编造端口 9286/编造子域名等都是错的）。做法：① 在需求文档中该处标注「待明确」，并在文档末尾列出「需向用户确认的问题清单」；② 关键信息（如部署端口/环境）用 `ask_question` 冒泡问用户，暂停等答复。宁可标注待明确，不可编一个看似合理的值。
|
||||
|
||||
## 应遵守的规范（产出前先 load_skill 加载对应全文，不要凭记忆瞎写）
|
||||
- `feature`：功能状态机规范（propose_feature 提功能的流转规则，读本 skill 判断合法性）
|
||||
- `project-directory-spec`：项目目录结构 + 需求文档落点路径（repos/{项目名}_pc/docs/00-requirement/）
|
||||
- `project-directory-spec`：机构工作空间结构（projects/apps/modules）+ 需求文档落点路径（projects/{项目}/docs/00-requirement/）
|
||||
- `sdlc-repo-standard`：需求规格说明书的内容格式与产出行为准则
|
||||
|
||||
@ -32,5 +32,5 @@ capability: test_plan_capability, test_case_capability, bug_test_capability
|
||||
- `test-plan`：测试计划状态机规范（create_test_plan 流转规则）
|
||||
- `test-case`：测试用例执行状态机规范（create/pass/fail/skip/block + 失败联动建 Bug）
|
||||
- `bug`：Bug 状态机规范（report_bug 流转规则）
|
||||
- `project-directory-spec`：测试文档落点路径（repos/{项目名}_pc/docs/03-test/）
|
||||
- `project-directory-spec`：测试文档落点路径（projects/{项目}/docs/03-test/）
|
||||
- `sdlc-repo-standard`：测试交付件的内容格式
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user