feat(skills): 需求分析阶段接管功能清单+IFPUG功能点计算+模块初步划分,设计阶段复核细化+功能细化,所有角色交付必附复杂度评估
- 新增 all/module-partitioning 技能:模块划分八原则(A业务能力/B业务边界/C高内聚低耦合/D业务闭环/E生命周期独立/F唯一责任/G基础设施非业务模块/H稳定后再抽象/I四张图判边界)+四张图绘制指南(业务对象/生命周期/数据所有权/业务依赖)+复用已有模块铁律+反模式速查,附工单系统迷你推导示例 - agent.requirement role:①功能清单+IFPUG功能点(function-point-counting+fp_calc.py规则引擎,禁LLM心算,产出fp-report.md四件套)②模块初步划分(module-partitioning,产出module-partition.md)③小功能点落库sd_features(测试锚点,两套口径都产出)⑤复杂度评估必附 - agent.design role:①模块划分复核+细化(以requirement的module-partition.md为上游,调整须写明依据,禁无证据推翻)②功能细化(功能点→模块→接口三级追溯)③app划分保留④模块级详细设计⑤复杂度评估 - sdlc-repo-standard:requirement/design产出规格更新+通用交付约定新增复杂度评估段(所有角色必附:判定/简单声明/复杂拆分建议/过大上报,编排决策权在PM) - qc review-requirement:B组新增IFPUG报告核对(证据链/规则引擎/待确认)+模块划分核对(四张图齐全/粒度铁律/复用判定/基础设施误判/依赖无环)+复杂度评估核对 - qc review-design:B组改为模块划分复核(上游衔接/八原则抽查)+功能细化覆盖(三级追溯/镀金理由)+C组复杂度评估 - common/task:模块化拆分原则职责归属改为requirement初划+design定稿+PM派发
This commit is contained in:
parent
f362d1f82a
commit
bedb183aff
146
skills_library/all/module-partitioning/SKILL.md
Normal file
146
skills_library/all/module-partitioning/SKILL.md
Normal file
@ -0,0 +1,146 @@
|
||||
---
|
||||
name: module-partitioning
|
||||
description: Use when 划分软件模块/确定模块边界/复核模块拆分/把功能清单归并成模块。八原则(A业务能力/B业务边界/C高内聚低耦合/D业务闭环/E生命周期独立/F唯一责任/G基础设施非业务模块/H稳定后再抽象)+四张图(业务对象/生命周期/数据所有权/业务依赖)判定边界，优先复用已有模块。
|
||||
category: software-development
|
||||
tags: [module, architecture, boundary, partitioning, design, requirement]
|
||||
trigger_conditions:
|
||||
- 需求分析/设计阶段要把功能清单划分成模块
|
||||
- 复核或重做已有模块划分，判断模块边界是否合理
|
||||
- 判断某个功能该归入哪个模块、是否该独立成模块
|
||||
- 模块拆分过细(1~2表一模块)或过粗(巨型模块)需要重新归并
|
||||
related_skills: [function-point-counting, feature-granularity-and-testing, module-development-spec, web-application-spec]
|
||||
---
|
||||
|
||||
# 模块划分（八原则 + 四张图）
|
||||
|
||||
把「功能清单」归并成「模块清单」的判定方法。模块 = 一个可独立开发/复用/部署挂载的业务能力单元
|
||||
（Host-Agnostic Python 包，见 module-development-spec；不独立部署，挂在应用伞下）。
|
||||
|
||||
**铁律（用户强调）**：
|
||||
1. **模块划分面向概念聚合，禁止 1~2 张表就切一个模块**——按业务能力聚合，不按表/页面/CRUD 机械切。
|
||||
2. **能用已有模块实现的功能，必须用已有模块**，不重复造（基础模块 apppublic/sqlor/ahserver/
|
||||
accounting/appbase/rbac，以及平台已有业务模块）。先查已有模块清单再划分。
|
||||
3. 模块划分是**架构决策**：requirement 阶段出初步划分（八原则+四张图），design 阶段复核+细化。
|
||||
4. 产出必须含：模块清单 + 每模块的业务能力/边界/唯一责任 + 模块间依赖 + 开发顺序（拓扑序）。
|
||||
|
||||
## 输入与输出
|
||||
|
||||
- **输入**：功能清单（来自 function-point-counting 的功能明细表，或 propose_feature 落库的 sd_features）。
|
||||
- **输出**：`modules/{模块名}.md` 清单（功能/仓库/依赖/开发顺序/关联应用）+ architecture.md 的模块划分章节
|
||||
（落点见 sdlc-repo-standard / project-directory-spec）。
|
||||
|
||||
## 工作流（六步，先画图后切块）
|
||||
|
||||
### 第 1 步：列功能清单并标注业务对象
|
||||
逐条功能问「它操作/产生哪个核心业务对象」（如 订单、工单、发票、人员、世界快照）。
|
||||
一个功能可能涉及多个对象，全列出。这是四张图的原料。
|
||||
|
||||
### 第 2 步：画四张图（判边界的唯一客观依据，详见 references/diagrams-guide.md）
|
||||
|
||||
| 图 | 画什么 | 读出什么边界信号 |
|
||||
|---|---|---|
|
||||
| ① 业务对象图 | 核心业务对象 + 对象间关系(1:1/1:N/聚合/引用) | 强聚合(组合/父子)的对象**同模块**；仅引用(外键/ID)的对象**可分属不同模块** |
|
||||
| ② 业务生命周期图 | 每个核心对象的状态机(状态+迁移+触发者) | 共享同一状态机/状态流转紧密耦合的功能**同模块**；生命周期各自独立的**可拆** |
|
||||
| ③ 数据所有权图 | 每张表/数据「谁创建、谁写、谁读、谁是权威源」 | **所有权一致**(同一主体全权 CRUD)的数据归**同模块**；跨主体读写=耦合点，需接口而非共表 |
|
||||
| ④ 业务依赖图 | 功能/对象间的调用与数据依赖(有向) | 依赖**单向且稀疏**=好边界；**双向/环状**依赖=切错了，需重新归并或抽接口 |
|
||||
|
||||
### 第 3 步：按四张图聚出候选模块
|
||||
- 把「业务对象图里强聚合 + 生命周期共享 + 数据所有权一致」的功能聚成一个候选模块。
|
||||
- 在「业务依赖图」上检查：候选模块之间应尽量单向依赖、无环。有环 → 合并环上模块或抽出共享接口。
|
||||
|
||||
### 第 4 步：八原则逐条校验每个候选模块（机械判定，见下）
|
||||
|
||||
### 第 5 步：复用判定——能用已有模块的，删掉候选、改为「引用已有模块」
|
||||
对照平台已有模块清单（基础模块 + 已上线业务模块）。候选模块的能力若已有模块覆盖 →
|
||||
不新建，在 architecture.md 写明「复用 {已有模块}，通过 load_{module}() 挂载 / API 调用」。
|
||||
|
||||
### 第 6 步：定依赖与开发顺序
|
||||
- 模块间依赖画成有向图，求拓扑序：被依赖的先开发。
|
||||
- 基础模块/已复用模块不列为待开发。
|
||||
- 一个模块 = 一个 develop 任务（PM 据此派发，见 task 技能）。
|
||||
|
||||
## 八原则（逐条机械判定，命中反例即重划）
|
||||
|
||||
**A. 一个模块代表一个「业务能力」**
|
||||
- 判定：能否用一句「动词+业务宾语」概括模块职责（如「管理工单全生命周期」「计算并落账消费」）？
|
||||
- 反例：职责描述需要「和/以及/还有」连接多个不相关能力 → 拆分。
|
||||
- 反例：模块名是技术词（utils/common/base/helper）而非业务词 → 多半违反 G。
|
||||
|
||||
**B. 明确的业务边界**
|
||||
- 判定：模块的输入/输出/触发场景能否清晰列举？边界外的事它一概不管？
|
||||
- 反例：说不清「什么不属于这个模块」→ 边界模糊，重划。
|
||||
|
||||
**C. 高内聚，低耦合**
|
||||
- 内聚判定：模块内功能是否都围绕同一业务能力/同一组核心对象（看业务对象图+数据所有权图）？
|
||||
- 耦合判定：模块间依赖是否少而单向（看业务依赖图）？是否靠共享数据库表直接读写对方数据（强耦合，禁止）？
|
||||
- 反例：模块内功能各干各的（低内聚）；两模块互相直接读写对方的表（高耦合）→ 重划或抽接口。
|
||||
|
||||
**D. 能独立完成一个业务闭环**
|
||||
- 判定：模块单独存在能否完成一个完整业务动作（输入→处理→产出/落库），不依赖另一个模块才能跑通主流程？
|
||||
- 反例：A 模块的每个功能都必须先调 B 模块才能产生任何业务结果 → A、B 应合并。
|
||||
- 注意：闭环≠孤立。允许通过**接口**依赖其他模块（如调记账模块落账），但主业务逻辑自洽。
|
||||
|
||||
**E. 生命周期相对独立**
|
||||
- 判定：模块能否独立地新增/修改/废弃，而不强制牵动其他模块同步改？版本/演进节奏是否独立？
|
||||
- 反例：改 A 必须同时改 B、C 才能编译/运行（非接口耦合）→ 生命周期绑死，应合并或解耦。
|
||||
|
||||
**F. 明确的「唯一责任」**
|
||||
- 判定：每类业务数据/每个核心能力，是否**有且仅有一个**模块对其负责（创建+维护+权威源）？
|
||||
- 反例：两个模块都能写同一张核心表 / 都声称负责「用户管理」→ 责任重叠，合并或明确分工。
|
||||
- 与数据所有权图交叉验证：一份数据只有一个 owner 模块。
|
||||
|
||||
**G. 不要把「基础设施」误认为业务模块**
|
||||
- 基础设施 = 与具体业务无关、被各业务模块共用的技术能力：数据库访问、HTTP 框架、认证鉴权、
|
||||
日志、缓存、文件存储、ID 生成、加解密、消息队列。
|
||||
- 判定：去掉具体业务场景，这个能力是否依然成立且被多方复用？是 → 基础设施，**不是业务模块**。
|
||||
- 处置：基础设施用平台已有基础模块（apppublic/sqlor/ahserver/appbase/rbac/accounting），
|
||||
**不要为它新建业务模块**，更不要把它和业务功能混进同一个业务模块。
|
||||
- 反例：建一个「数据库模块」「工具模块」「公共模块」当业务模块开发 → 违反 G。
|
||||
|
||||
**H. 共享能力要「稳定后」再抽象**
|
||||
- 判定：两个以上模块出现的相似逻辑，是否已**稳定**（接口/语义不再频繁变）？
|
||||
- 稳定 → 抽象成共享能力（基础模块或独立共享模块）。
|
||||
- 未稳定（还在快速变、各处需求不一致）→ **先各自实现，不要过早抽象**（过早抽象=错误抽象，
|
||||
日后改不动）。记录为「候选共享能力，待稳定后抽取」，不在本期强行合并。
|
||||
- 反例：第一期就把两个还在变的功能抽成「通用 XX 服务」，结果两边需求一分叉就得加一堆参数 → 违反 H。
|
||||
|
||||
**I. 用「四张图」判断模块边界**
|
||||
- 见第 2 步。四张图是 A~H 的客观证据来源：边界争议回到图上找答案，不靠主观感觉。
|
||||
- 任何模块划分结论，都要能指出「依据哪张图的哪个信号」。
|
||||
|
||||
## 模块粒度（防过细/过粗）
|
||||
|
||||
- **过细信号**：一个模块只有 1~2 张表、只有一个 CRUD、职责一句话说不满 → 合并进相邻同业务能力模块。
|
||||
- **过粗信号**：一个模块覆盖多个不相关业务对象、职责要「和/以及」连接、内部能拆出多个独立闭环 → 拆分。
|
||||
- **合适粒度**：一个模块 = 一个业务能力 = 一组强聚合业务对象 + 其完整生命周期 + 一致的数据所有权。
|
||||
|
||||
## 复用已有模块（铁律 2 的落地）
|
||||
|
||||
划分前必须先拿到「已有模块清单」：
|
||||
- 基础模块（不重复开发）：apppublic、sqlor、ahserver、accounting、appbase、rbac。
|
||||
- 平台已有业务模块：查目标应用 pkgs/ 下已挂载模块 + 平台模块文档。
|
||||
- 判定：候选模块能力 ⊆ 已有模块能力 → 复用（load_{module}() 挂载 / HTTP API 调用），不新建。
|
||||
- 部分重叠 → 复用已有 + 新模块只做增量，通过接口对接，禁止 fork 已有模块代码。
|
||||
|
||||
## 输出模板（architecture.md 模块划分章节 + modules/{模块名}.md）
|
||||
|
||||
architecture.md 写：
|
||||
1. 四张图（业务对象/生命周期/数据所有权/业务依赖，文字或 mermaid）。
|
||||
2. 模块清单表：模块名 | 业务能力(A) | 唯一责任(F) | 核心对象 | 依赖模块 | 开发顺序 | 复用/新建。
|
||||
3. 复用判定：哪些能力复用已有模块、如何挂载。
|
||||
4. 模块依赖图 + 拓扑开发顺序。
|
||||
|
||||
modules/{模块名}.md 写（格式见 sdlc-repo-standard）：功能/仓库/技术栈/状态/依赖模块/开发顺序/关联应用。
|
||||
|
||||
## 反模式速查（命中即重划）
|
||||
|
||||
| 反模式 | 违反原则 | 修法 |
|
||||
|---|---|---|
|
||||
| 1~2 张表切一个模块 | A/D/粒度 | 按业务能力聚合 |
|
||||
| 建「数据库/工具/公共」业务模块 | G | 用基础模块，不新建 |
|
||||
| 两模块共写一张核心表 | C/F | 定唯一 owner，另一方走接口 |
|
||||
| A、B 互相直接读写对方数据 | C/E | 抽接口，单向依赖 |
|
||||
| 模块间依赖成环 | C/I(依赖图) | 合并环上模块或抽共享接口 |
|
||||
| 第一期就抽「通用XX服务」 | H | 待稳定再抽，先各自实现 |
|
||||
| 已有模块能实现却新建 | 铁律2 | 复用 load_{module}()/API |
|
||||
| 巨型模块覆盖多业务 | A/B/粒度 | 按业务对象拆 |
|
||||
@ -0,0 +1,99 @@
|
||||
# 四张图绘制指南（模块边界判定的客观依据）
|
||||
|
||||
四张图是模块划分的**证据层**：任何「这两个功能该不该同模块」的争议，回到图上找信号，
|
||||
不靠主观感觉。文字描述即可（必要时 mermaid），关键是**信号读法**。
|
||||
|
||||
## ① 业务对象图
|
||||
|
||||
**画什么**：系统全部核心业务对象（名词：订单/工单/客户/发票/人员/快照…），对象间关系及类型。
|
||||
|
||||
**关系类型（决定聚合强度）**：
|
||||
- 组合/父子（强聚合）：A 由 B 组成，B 离开 A 无意义。如 工单—工单消息、订单—订单行。
|
||||
- 关联（中）：A 引用 B，两者各有生命周期。如 工单→受理人、订单→客户。
|
||||
- 仅引用（弱）：A 只存 B 的 ID 做查询过滤。如 业务流水→机构ID。
|
||||
|
||||
**怎么画（文字模板）**：
|
||||
```
|
||||
对象: 工单
|
||||
├─组合─ 工单消息(离开工单无意义)
|
||||
├─组合─ 转派流水(append-only,工单专属)
|
||||
├─关联─ 客户(提单人,独立生命周期)
|
||||
└─引用─ 机构ID(仅过滤)
|
||||
```
|
||||
|
||||
**边界信号**：组合关系的对象**必须同模块**（拆开=一个业务闭环被劈两半）；
|
||||
仅引用的对象**分属不同模块没问题**。
|
||||
|
||||
## ② 业务生命周期图
|
||||
|
||||
**画什么**：每个核心对象的状态机——状态清单、迁移事件、触发者（角色/系统）。
|
||||
|
||||
**怎么画（文字模板）**：
|
||||
```
|
||||
工单: new →(agent认领) agent_processing →(回复) agent_replied
|
||||
→(客户确认) closed / →(追问超限) human_pending →(认领) human_processing
|
||||
→(客服回复) staff_replied →(客户确认) closed
|
||||
触发者: 客户(建单/确认/追问)、agent(自动答复)、运维(认领/回复/转派)
|
||||
```
|
||||
|
||||
**边界信号**：
|
||||
- 操作**同一状态机**的功能（建单/追问/确认/认领/转派）→ 同模块（状态机是模块的内聚核）。
|
||||
- 两个对象的状态机**互相触发迁移**（A 到某态必须改 B 的态）→ 强耦合，优先考虑同模块；
|
||||
确实要拆则必须走接口/事件，禁止跨模块直改对方状态列。
|
||||
- 生命周期完全独立、互不触发 → 可分属不同模块（原则 E 的证据）。
|
||||
|
||||
## ③ 数据所有权图
|
||||
|
||||
**画什么**：每张表（或每组逻辑数据）的 CRUD 归属——谁创建(C)、谁更新(U)、谁读(R)、谁是权威源。
|
||||
|
||||
**怎么画（表格模板）**：
|
||||
| 表/数据 | 创建者 | 更新者 | 读取者 | 权威源(owner) |
|
||||
|---|---|---|---|---|
|
||||
| tk_tickets | ticket模块 | ticket模块 | ticket/报表 | ticket模块 |
|
||||
| users | rbac | rbac | 全部模块(只读) | rbac |
|
||||
| 余额流水 | accounting | accounting | 业务模块(只读) | accounting |
|
||||
|
||||
**边界信号**：
|
||||
- 一张表有且仅有一个 owner 模块（原则 F 唯一责任的直接证据）。
|
||||
- **两个模块都写同一张表 = 边界切错**：要么合并模块，要么把写权收归 owner、另一方走接口。
|
||||
- 「读取者=全部模块」的表是基础设施数据（users/权限/参数），owner 是基础模块，业务模块只读——
|
||||
这也验证原则 G（别为它建业务模块）。
|
||||
|
||||
## ④ 业务依赖图
|
||||
|
||||
**画什么**：模块/候选模块间的调用与数据依赖，有向边 A→B 表示「A 的业务过程需要 B 的能力/数据」。
|
||||
|
||||
**怎么画（文字模板）**：
|
||||
```
|
||||
工单模块 → rag模块(检索知识库) [单向,接口调用]
|
||||
工单模块 → pipeline-service(待办注册) [单向,provider机制]
|
||||
记账模块 → 产品模块(取定价) [单向]
|
||||
产品模块 → 记账模块(?) [若存在=环,必须消除]
|
||||
```
|
||||
|
||||
**边界信号**：
|
||||
- **无环 + 稀疏**（每个模块出边≤3 条左右）= 边界健康。
|
||||
- **环状依赖（A→B 且 B→A）= 边界切错**：合并环上模块，或抽出共享接口/事件把环打断。
|
||||
- 依赖边标注**实现方式**（接口调用/事件/只读数据）——凡是「直接读写对方数据库表」的边都是
|
||||
坏味道（原则 C 高耦合证据），改为接口。
|
||||
- 依赖图直接给出**开发顺序拓扑序**：无入边的先开发（基础/被依赖模块），依赖别人的后开发。
|
||||
|
||||
## 四张图 → 模块划分的推导顺序
|
||||
|
||||
1. ①②定「聚合核」：强聚合对象+共享状态机 = 候选模块的内核。
|
||||
2. ③定「唯一责任」：每个候选模块核对数据所有权，冲突即调整边界。
|
||||
3. ④定「模块间关系」：依赖成环→回调 1/2 重新聚合；无环→拓扑序=开发顺序。
|
||||
4. 最后过八原则 A~H 逐条校验（I 就是本指南）。
|
||||
|
||||
## 迷你示例（工单系统的正确推导）
|
||||
|
||||
功能清单：建单/agent自动答复/追问/转人工/认领/客服回复/转派/客户确认关闭/附件上传下载/
|
||||
工单知识库沉淀/用户登录/权限校验/文件存储。
|
||||
|
||||
- ①：工单—消息—转派流水 组合；附件挂在消息上（组合）。
|
||||
- ②：全部工单功能操作同一状态机（new→…→closed）。
|
||||
- ③：tk_* 三表 owner 唯一；users/permission 是 rbac 的；files 是文件存储的。
|
||||
- ④：工单→rag(检索/沉淀,接口)、工单→待办中枢(provider)、工单→文件存储(webpath)。
|
||||
- 结论：**一个 ticket 业务模块**（建单~关闭全生命周期+附件+知识库沉淀）；
|
||||
登录/权限/文件存储是基础设施→复用 rbac/filemgr 基础能力（原则 G），**不建模块**；
|
||||
rag 检索是已有模块→接口复用（铁律2）。
|
||||
@ -54,17 +54,31 @@ projects/{项目名}/docs/01-design/modules/{模块名}/
|
||||
|
||||
- 完成后用 `deliver` 交付，`files` 列出所有产出文件路径——这是 QC/PM 核验「实际产出」的依据，别只写文档不列文件
|
||||
- git 提交由 PM 审核通过后系统统一执行，角色无需自己提交（develop 例外：模块/应用仓库本地 commit 是 QC 核验的硬证据，见下）
|
||||
- **复杂度评估（所有角色必附，2026-09-14 起）**：每个任务开工先自评复杂度，deliver 时必须在
|
||||
summary 或交付文档末尾附「复杂度评估」段——
|
||||
1. **判定**：本任务及后续派生工作是否复杂。复杂信号：涉及多个模块/应用、多个独立交付单元、
|
||||
工作量超单 agent 一次产出（预估 >1 个聚焦交付件）、存在可并行的独立子工作。
|
||||
2. **简单** → 写明「复杂度评估：简单，单交付单元，无需拆分」。
|
||||
3. **复杂** → 给出**建议拆分方案**：子任务清单（每条 title/role/description/依赖关系，
|
||||
能并行的标并行、有依赖的标 depends_on 前序），供 PM 编排派发。
|
||||
4. **执行中发现任务过大** → 立即用 ask_question/raise_problem 上报 PM 请求拆分，
|
||||
禁止硬撑巨型任务导致探索死循环（30 轮耗尽无产出）。
|
||||
- 编排决策权在 PM（create_tasks/create_sub_tasks），角色只提供评估+建议，不越权派发。
|
||||
|
||||
## 各角色产出内容（落点路径见 project-directory-spec）
|
||||
|
||||
### requirement（需求分析师）
|
||||
- **内容**: 项目概述、用户角色及权限、功能列表（含验收标准）、非功能需求、业务流程
|
||||
- **功能清单 + IFPUG 功能点计算**: 按 `function-point-counting` 技能产出 `docs/00-requirement/fp-report.md`（功能明细/汇总 UFP/待确认/假设 四件套，fp_calc.py 规则引擎计算，禁 LLM 心算）
|
||||
- **模块初步划分**: 按 `module-partitioning` 技能（八原则+四张图）产出 `docs/00-requirement/module-partition.md`（四张图 + 模块清单 + 复用判定 + 开发顺序拓扑）；能用已有模块的必须复用已有模块，禁止 1~2 表一模块
|
||||
- **不划分 app**: 一个项目有几个 app（应用）是架构决策，由 design 阶段设计师根据需求分析划分——requirement 只描述功能、不定 app 数量、不写 `{应用名}_spec.json`
|
||||
- **不划分模块**: 模块划分是架构决策，由 design 阶段设计师完成
|
||||
- **小功能点落库**: 按 `feature-granularity-and-testing` 粒度用 propose_feature 落库 sd_features（测试/验收锚点，与 IFPUG 规模度量是两套口径都要产出）
|
||||
|
||||
### design（系统设计师）
|
||||
- **模块划分复核+细化**: 以 requirement 的 module-partition.md 为上游，按 `module-partitioning` 八原则+四张图复核细化（调整必须写明依据，禁止无证据推翻），落定模块间接口契约 + 依赖图 + 开发顺序
|
||||
- **功能细化**: 把需求功能点细化到模块内可开发规格（页面交互/数据表归属/CRUD/接口契约），产出功能点→模块→接口三级追溯表，覆盖核对无遗漏
|
||||
- **应用划分**: 根据需求分析划分一个项目有几个 app（应用）——需求只描述功能、不定 app 数量，设计师按「部署单元 / 功能聚合 / 用户边界」划到 N 个 app（每个 app = 一个入口一个端口），产出对应的 `{应用名}_spec.json`
|
||||
- **应用级**: `architecture.md`（系统架构、模块划分、模块间依赖、开发顺序）+ `ui-design.md`（视觉风格/主页面/交互模式/弹窗规范）
|
||||
- **应用级**: `architecture.md`（系统架构、模块划分复核结论、模块间依赖、开发顺序）+ `ui-design.md`（视觉风格/主页面/交互模式/弹窗规范）
|
||||
- **模块级**: 每个模块在 `projects/{项目名}/docs/01-design/modules/{模块名}/` 下产出 design.md（数据设计/CRUD/处理逻辑）+ skill/SKILL.md
|
||||
- **更新**: `docs/01-design/modules/` 下各模块的技术栈、依赖关系、开发顺序
|
||||
|
||||
|
||||
@ -88,7 +88,7 @@ submitted ──claim──▶ running ──submit──▶ review ──approv
|
||||
PM 派发任务时先评估复杂度，复杂任务自动分解并编排执行顺序（能并行并行、不能并行串行），同时记录父子关系。
|
||||
|
||||
1. **先评估**：判断当前任务是否「过于复杂」（涉及多个模块/应用、多个独立交付单元、工作量超单 agent 一次产出）。简单任务直接派发单个任务，不强行拆分。
|
||||
2. **模块化拆分原则（design 阶段定模块，PM 按模块派发）**：模块划分由 design 阶段的设计师完成（架构能力更强）——概念相近的功能组合成一个独立模块，每个模块独立设置仓库，归入应用伞仓库（pkgs/<模块>），并在模块定义里写明模块间依赖关系 + 开发顺序。PM 派发 develop 任务时按设计师划分好的模块清单：一个模块 = 一个 develop 任务；按模块间依赖编排（无依赖并行、有依赖串行）。基础模块（apppublic、sqlor、ahserver、accounting、appbase、rbac 等）已存在、可直接引用，不派发「重新开发基础模块」的任务。
|
||||
2. **模块化拆分原则（requirement 初划，design 定稿，PM 按模块派发）**：模块划分在 requirement 阶段按 `module-partitioning` 技能（八原则+四张图）初步完成（产出 module-partition.md），design 阶段复核+细化+定稿（模块清单/依赖/开发顺序，调整须写明依据）——概念相近的功能组合成一个独立模块，每个模块独立设置仓库，归入应用伞仓库（pkgs/<模块>），并在模块定义里写明模块间依赖关系 + 开发顺序。PM 派发 develop 任务时按设计定稿的模块清单：一个模块 = 一个 develop 任务；按模块间依赖编排（无依赖并行、有依赖串行）。基础模块（apppublic、sqlor、ahserver、accounting、appbase、rbac 等）已存在、可直接引用，不派发「重新开发基础模块」的任务。
|
||||
3. **任务粒度控制（巨型任务拆小）**：单个任务必须聚焦单一交付单元，禁止派发「一次性实现全部 N 个模块 / 全部表契约 / 脚手架 + DDL 全套」这种巨型任务——任务过大时 agent 会因工作量大、方向迷失而陷入探索死循环（反复 read_file/run_shell 却不 write_file/deliver，30 轮耗尽无产出）。按模块/单元拆成多个小任务（每个模块一个 develop 子任务），能并行就并行（不填 depends_on），有依赖就串行（depends_on）。
|
||||
4. **自动分解**：复杂任务 → 拆成多个子任务，每个子任务含 title、role、description；用 `create_tasks` 一次批量派发。子任务默认挂当前里程碑任务名下（`parent_id` 由系统自动记录），任务树（/task）据此分层显示。
|
||||
5. **自动编排**：
|
||||
|
||||
@ -1,22 +1,50 @@
|
||||
---
|
||||
name: role
|
||||
description: 系统设计师角色定义。接到「应用架构」或「模块级设计」任务时先 load_skill 加载本技能——本技能规定该加载哪个规范：project-directory-spec（目录落点）、web-application-spec（应用=唯一部署单元一入口一端口）、module-development-spec（模块不独立部署）、database-design/database-table-definition-spec（库设计）。不先加载会把单体设计成多服务、把模块设计成带 app.py 的应用。
|
||||
description: 系统设计师角色定义。接到「应用架构」或「模块级设计」任务时先 load_skill 加载本技能——本技能规定：复核+细化 requirement 阶段的模块划分（module-partitioning 八原则+四张图）、功能细化（功能点→模块内接口/数据/交互细化）、应用(app部署单元)划分、模块级详细设计。该加载哪个规范：project-directory-spec（目录落点）、web-application-spec（应用=唯一部署单元一入口一端口）、module-development-spec（模块不独立部署）、database-design/database-table-definition-spec（库设计）。不先加载会把单体设计成多服务、把模块设计成带 app.py 的应用、推翻需求阶段的模块划分重造。
|
||||
capability: task_capability
|
||||
---
|
||||
|
||||
# 系统设计师（design）角色定义
|
||||
|
||||
## 职责
|
||||
- 应用级设计：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）已存在，不列为待开发模块
|
||||
|
||||
### 1. 模块划分复核 + 细化（上游是 requirement 的 module-partition.md，不推翻重造）
|
||||
- **先 load_skill 加载 `module-partitioning` 全文**，用它复核需求阶段的初步模块划分：
|
||||
- 读 `projects/{项目名}/docs/00-requirement/module-partition.md`（四张图+模块清单+复用判定）。
|
||||
- 八原则 A~I 逐条复核 + 四张图补全细化（需求阶段画不全的依赖边/所有权在设计期落定）。
|
||||
- **调整必须写明理由**（哪条原则/哪张图的哪个信号），禁止无证据推翻需求阶段划分；
|
||||
发现划分根本性错误（如环依赖、责任重叠）→ 修正并在 architecture.md 记录变更对照。
|
||||
- 细化产出：模块间依赖图（有向无环）+ 开发顺序拓扑序 + 每模块的接口契约草案
|
||||
（模块对外暴露什么、依赖谁的什么）。PM 按此派发 develop 任务（一个模块=一个任务）。
|
||||
- 复用判定复核：requirement 标注的「复用已有模块」逐个核实真实存在且能力覆盖；
|
||||
基础模块（apppublic/sqlor/ahserver/accounting/appbase/rbac）已存在，不列为待开发模块。
|
||||
|
||||
### 2. 功能细化（需求功能点 → 模块内可开发规格）
|
||||
- 输入：requirement 的功能清单（fp-report.md 功能明细 + list_features 落库的小功能点）。
|
||||
- 把每个功能点细化到模块内实现规格：页面/交互（ui-design.md）、数据表归属、CRUD 定义、
|
||||
处理逻辑（接口契约：入参/出参/错误分支）、功能点→模块→接口三级追溯表。
|
||||
- **覆盖核对**：每个需求功能点必须落到某个模块的某个接口/页面，无遗漏；
|
||||
新增的镀金功能（需求没有的）必须写明理由，否则删除。
|
||||
- 功能细化不改需求口径：发现需求矛盾/缺口 → 冒泡 ask_question，不自行改需求。
|
||||
|
||||
### 3. 应用划分（app 部署单元，design 专属职责）
|
||||
- 一个项目有几个 app（应用），由设计师划分——按「部署单元 / 功能聚合 / 用户边界」把模块
|
||||
归到 N 个 app（每个 app = 一个入口一个端口），architecture.md 写明 app 清单与划分理由，
|
||||
产出对应的 {应用名}_spec.json（referenced_modules / generated_modules）。
|
||||
|
||||
### 4. 模块级详细设计
|
||||
- 每个模块产出 modules/{模块名}.md + modules/{模块名}/design.md + skill/SKILL.md
|
||||
（数据设计 DDL/CRUD/处理逻辑，格式见 sdlc-repo-standard 的 templates）。
|
||||
|
||||
### 5. 交付必附复杂度评估（所有角色统一约定，见 sdlc-repo-standard）
|
||||
- deliver 时附「复杂度评估」段：后续 develop 工作是否需拆分 + 建议的任务编排
|
||||
（每模块一个任务、依赖串并行关系）。编排决策权在 PM。
|
||||
|
||||
## 应遵守的规范（设计前先 load_skill 加载对应全文，不要凭记忆瞎写）
|
||||
- `project-directory-spec`：机构工作空间结构（projects/apps/modules）+ 设计文档落点路径（projects/{项目}/docs/01-design/）+ 应用与模块的关系（应用=唯一部署单元，模块不独立部署；app 划分见职责「应用划分」）
|
||||
- `module-partitioning`：模块划分八原则+四张图（复核/细化 requirement 划分的判定依据）
|
||||
- `project-directory-spec`：工作空间结构 + 设计文档落点路径 + 应用与模块的关系（应用=唯一部署单元，模块不独立部署）
|
||||
- `sdlc-repo-standard`：设计交付件的内容格式（templates/module-design.md、templates/module-skill.md）
|
||||
- `web-application-spec`：应用规范（应用结构、应用如何通过 load_{module}() 导入模块、一个入口一个端口）
|
||||
- `module-development-spec`：模块规范（模块是 Host-Agnostic Python 包、不是独立部署单元，无独立 app.py/端口）
|
||||
- `database-design`：数据库设计规范（字段语义→类型映射、系统不加外键、编码字典设计，设计阶段产出时遵守）
|
||||
- `database-design`：数据库设计规范（字段语义→类型映射、系统不加外键、编码字典设计）
|
||||
- `database-table-definition-spec`：表定义四段式格式
|
||||
|
||||
@ -34,24 +34,31 @@ capability: task_capability
|
||||
|
||||
## B 组：设计专家维度
|
||||
|
||||
6. **应用/模块划分**（对照技能映射表加载）：
|
||||
6. **模块划分复核+细化**（对照技能映射表加载 `module-partitioning`）：
|
||||
- **上游衔接**：design 的模块划分以 requirement 的 `docs/00-requirement/module-partition.md` 为上游。核对 architecture.md 有「复核结论」——沿用或调整；**每处调整必须写明依据**（八原则哪条/四张图哪个信号）。无证据推翻需求阶段划分 = 不过；完全没提 module-partition.md（凭空重划）= 不过。
|
||||
- 八原则抽查：模块清单逐条能对应业务能力（A）、唯一责任（F）；无 1~2 表过细模块、无巨型模块；基础设施未当业务模块（G）；标注复用的已有模块真实存在（铁律：能用已有模块必须用）。
|
||||
- 模块间依赖图无环 + 开发顺序拓扑可行（依赖在前）。
|
||||
7. **功能细化覆盖**：
|
||||
- 有「功能点→模块→接口」三级追溯表（或等价映射），每个需求功能点（list_features + fp-report 明细）落到某模块某接口/页面，无遗漏。
|
||||
- 新增镀金功能（需求没有的）有书面理由，无理由 = 不过。
|
||||
8. **应用/模块划分**（对照技能映射表加载）：
|
||||
- 应用是唯一部署单元：一个应用 = 一个入口（app/{应用名}.py）= 一个端口；architecture.md 写明 app 清单 + 单体/多应用划分理由。把功能模块设计成独立服务/微服务/独立端口 → 不过。
|
||||
- 模块是应用内 Python 包，无独立 app.py / 端口 / Dockerfile。
|
||||
7. **数据库设计**（对照技能映射表加载）：
|
||||
9. **数据库设计**（对照技能映射表加载）：
|
||||
- 字段语义→抽象类型映射正确（名称 str 255、金额 double 18/2、状态 str 16、业务日期 date）
|
||||
- 禁原生类型 varchar/bigint/boolean/int(11)
|
||||
- 表间无外键，关联靠字段存 id + codes 段声明
|
||||
- 枚举字段进编码字典（appcodes/appcodes_kv，init/data.json 定义）
|
||||
- 表定义四段式（summary/fields/indexes/codes）
|
||||
8. **架构合理性逐项**（把主观判断转成「有无论证」的机械核对）：
|
||||
- 模块间依赖方向无环、开发顺序可行（依赖在前、被依赖在后）
|
||||
10. **架构合理性逐项**（把主观判断转成「有无论证」的机械核对）：
|
||||
- 设计说明写明**预期数据量/并发量及对应选型理由**——写不出规模假设 = 不过（无论证的架构选型不采信）
|
||||
- 无微服务化倾向（「每模块一个端口/容器」类设计 = 不过）
|
||||
|
||||
## C 组：合规项
|
||||
|
||||
9. **文档落点**：architecture.md / ui-design.md / modules/{模块}.md + {模块}/design.md 齐全（对照 project-directory-spec）。
|
||||
10. **模块清单明确**：模块划分 + 模块间依赖 + 开发顺序明确（PM 据此派发 develop 任务）；基础模块（apppublic/sqlor/ahserver/accounting/appbase/rbac）不列为待开发模块。
|
||||
11. **文档落点**：architecture.md / ui-design.md / modules/{模块}.md + {模块}/design.md 齐全（对照 project-directory-spec）。
|
||||
12. **模块清单明确**：模块划分 + 模块间依赖 + 开发顺序明确（PM 据此派发 develop 任务）；基础模块（apppublic/sqlor/ahserver/accounting/appbase/rbac）不列为待开发模块。
|
||||
13. **复杂度评估已附**：交付件有「复杂度评估」段（简单写明无需拆分 / 复杂给出建议拆分方案：每模块一个 develop 任务+依赖编排）。缺失 = 不过。
|
||||
|
||||
## 技能映射表（按核对内容必载，不凭记忆）
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@ capability: task_capability
|
||||
## 必读文件
|
||||
|
||||
- 原始需求：`projects/{项目}/docs/00-requirement/requirement-spec.md`（需求规格说明书）+ 需求采集任务的原始输入（任务描述/用户上传材料）
|
||||
- 需求分析交付件：`projects/{项目}/docs/00-requirement/` 下分析产出（需求细化/功能化描述）
|
||||
- 需求分析交付件：`projects/{项目}/docs/00-requirement/` 下分析产出（fp-report.md 功能点报告、module-partition.md 模块初步划分、需求细化/功能化描述）
|
||||
- 路径权威来源：先 load_skill 加载 `project-directory-spec`，不要凭记忆找路径
|
||||
|
||||
## A 组：原始需求逐条契合（主体核对项）
|
||||
@ -35,9 +35,23 @@ capability: task_capability
|
||||
## B 组：合规项
|
||||
|
||||
4. **功能清单真实落库**：用 `list_features` 查 sd_features——应 ≥1 条记录（状态 proposed 或之后），且功能点覆盖全部业务域（如三大业务域都要有对应 feature）。只在文档里写了、库里 0 条 → 不过。
|
||||
5. **文档落点**：需求文档在 `project-directory-spec` 规定的路径（对照技能，不凭记忆）。
|
||||
6. **部署环境需求明确**：测试/生产环境的资源规格、依赖服务、端口、环境变量、高可用、备份、监控告警是否写清。空泛写「按标准配置」= 不过。
|
||||
7. **无越权划分**：requirement 阶段不划分 app、不产出 apps/{应用名}.md（app 划分是 design 职责）。越权 → 不过。
|
||||
5. **IFPUG 功能点计算真实产出**：`docs/00-requirement/fp-report.md` 存在，且含四件套（功能明细表带 DET/RET/FTR/复杂度/FP/证据、UFP 汇总、待确认清单、计算假设）。核对项：
|
||||
- 明细表每行有 evidence（需求章节/原文摘要）与 calc_basis（档位→复杂度→权重）——无证据行 = 不过。
|
||||
- **必须过规则引擎**：报告里的复杂度/FP 应与 `function-point-counting` 的权重矩阵一致（抽查 2~3 行按矩阵复核）。明显是 LLM 心算（复杂度与 DET/FTR 档位对不上、UFP 加总不等于各行 FP 之和）→ 不过。
|
||||
- 需求含糊处已进待确认清单而非猜数（抽查有无「低置信度却给了数」）。
|
||||
6. **模块初步划分真实产出**：`docs/00-requirement/module-partition.md` 存在，且：
|
||||
- **四张图齐全**（业务对象/业务生命周期/数据所有权/业务依赖）——缺任一张 = 不过。
|
||||
- 模块清单表每模块写明业务能力（一句话动词+宾语）、唯一责任、核心对象、依赖、开发顺序、复用or新建。
|
||||
- **粒度铁律核对**：无「1~2 张表一个模块」（对照数据所有权图，一个模块只有 1~2 张表且职责说不满 = 过细，不过）；无巨型模块（一个模块覆盖多个不相关业务对象 = 不过）。
|
||||
- **复用判定核对**：标注复用的已有模块真实存在（基础模块 apppublic/sqlor/ahserver/accounting/appbase/rbac 或平台已上线业务模块）；能力已有模块覆盖却新建 = 不过。
|
||||
- **基础设施误判核对**：无「数据库模块/工具模块/公共模块」当业务模块（违反原则 G）= 不过。
|
||||
- 依赖图无环（有环且未说明如何消除 = 不过）。
|
||||
- 判定依据先 load_skill 加载 `module-partitioning` 全文，逐条对照八原则，不凭记忆。
|
||||
7. **文档落点**：需求文档在 `project-directory-spec` 规定的路径（对照技能，不凭记忆）。
|
||||
8. **部署环境需求明确**：测试/生产环境的资源规格、依赖服务、端口、环境变量、高可用、备份、监控告警是否写清。空泛写「按标准配置」= 不过。
|
||||
9. **复杂度评估已附**：交付件（deliver summary 或文档末尾）有「复杂度评估」段——简单需写明「无需拆分」，复杂需给出建议拆分方案（子任务清单+依赖）。缺失 = 不过。
|
||||
10. **无越权划分**：requirement 阶段不划分 app、不产出 apps/{应用名}.md 或 {应用名}_spec.json（app 划分是 design 职责）。越权 → 不过。
|
||||
⚠️ 模块**初步**划分是 requirement 的合法职责（module-partition.md），不算越权；design 阶段复核细化。
|
||||
|
||||
## 真实性核查（所有核对项通用）
|
||||
|
||||
|
||||
@ -1,20 +1,64 @@
|
||||
---
|
||||
name: role
|
||||
description: 需求分析师角色定义。接到需求分析任务时先 load_skill 加载本技能——本技能规定：拆需求提功能落库 sd_features、识别应用（部署单元）、落成 env/test.json+env/prod.json（部署信息单一事实源）、需求不明确的端口/主机/账号禁止编造（标注待明确或 ask_question 冒泡问）。不先加载会编造端口/子域名等具体值。
|
||||
description: 需求分析师角色定义。接到需求分析任务时先 load_skill 加载本技能——本技能规定：①功能清单编制+IFPUG功能点计算(function-point-counting技能+fp_calc.py规则引擎,禁LLM心算) ②模块初步划分(module-partitioning技能,八原则+四张图,优先复用已有模块) ③拆小功能点落库sd_features ④部署环境信息落env/*.json(禁止编造) ⑤交付必附复杂度评估。不先加载对应技能会凭记忆瞎写、编造端口、模块划分无依据。
|
||||
capability: feature_propose_capability
|
||||
---
|
||||
|
||||
# 需求分析师（requirement）角色定义
|
||||
|
||||
## 职责
|
||||
- **拆解需求提功能（落库，别只写文档）**：用 `propose_feature` 把需求拆解成功能点，落库 sd_features（状态 proposed），每个业务域都要有对应 feature。**功能点粒度按 `feature-granularity-and-testing` 技能**——必须是单次操作级小功能点（一个按钮/一个接口/一个后台逻辑单元），禁止模块级大功能清单；先 load_skill 加载该技能再拆
|
||||
- 产出需求规格说明书（requirement-spec.md）+ 需求评审记录（requirement-review.md）
|
||||
- 不划分 app：一个项目有几个 app（应用）是 design 阶段的架构决策，requirement 只描述功能、不定 app 数量、不产出 apps/{应用名}.md 或 {应用名}_spec.json
|
||||
- 明确部署环境需求，并**落成 `env/test.json` + `env/prod.json`**（工作空间根目录，集中保存主机/SSH/端口/DB/路径/域名，是部署信息的单一事实源，见 project-directory-spec）——部署信息只在这里一份，不散落到需求/设计/代码各处，改配置只改这里
|
||||
- 需求阶段不划分 app、不划分模块（app 划分和模块划分都是 design 阶段的架构决策）
|
||||
- **需求不明确时禁止编造具体值**：端口、IP、域名、账号、资源规格等需求未给出或含糊的值，**不得自己编**（编造端口 9286/编造子域名等都是错的）。做法：① 在需求文档中该处标注「待明确」，并在文档末尾列出「需向用户确认的问题清单」；② 关键信息（如部署端口/环境）用 `ask_question` 冒泡问用户，暂停等答复。宁可标注待明确，不可编一个看似合理的值。
|
||||
## 职责（按序完成，产出落点见 project-directory-spec）
|
||||
|
||||
### 1. 功能清单编制 + IFPUG 功能点计算（规模度量）
|
||||
- **先 load_skill 加载 `function-point-counting` 全文**，按它的十步工作流做：
|
||||
读需求全文 → 定应用边界 → 列角色与外部系统 → 识别业务过程 → 判 ILF/EIF/EI/EO/EQ →
|
||||
去重 → 逐功能提 DET/RET/FTR + 证据 → 写 input.json → **跑 fp_calc.py 规则引擎算 FP**。
|
||||
- **铁律：LLM 只做语义识别，复杂度判定与 FP 加权必须跑规则引擎**，禁止心算 FP、禁止直接报总数。
|
||||
- 规则引擎用法（fp_calc.py 是纯 stdlib 脚本，环境无关）：
|
||||
1. `load_skill(name='function-point-counting', file_path='scripts/fp_calc.py')` 取脚本全文；
|
||||
2. `write_file` 存到 `projects/{项目名}/docs/00-requirement/tools/fp_calc.py`；
|
||||
3. input.json 按技能里的 schema 写好，`run_shell` 执行
|
||||
`python3 .../tools/fp_calc.py input.json --json` 得复杂度与 FP。
|
||||
- 输出四件套（功能明细/汇总/待确认/假设）存
|
||||
`projects/{项目名}/docs/00-requirement/fp-report.md`。
|
||||
- 信息不足的功能**进待确认清单，不猜**（状态/原因/需要确认 三要素）。
|
||||
- 证据链：每个功能点带需求原文章节引用，无证据不入账。
|
||||
|
||||
### 2. 模块初步划分（八原则 + 四张图）
|
||||
- **先 load_skill 加载 `module-partitioning` 全文**（含 references/diagrams-guide.md 四张图画法）。
|
||||
- 按六步工作流：功能标注业务对象 → 画四张图（业务对象/生命周期/数据所有权/业务依赖）→
|
||||
聚候选模块 → **八原则 A~I 逐条机械校验** → **复用判定（能用已有模块必须用已有模块）** →
|
||||
定依赖与开发顺序（拓扑序）。
|
||||
- **粒度铁律：面向概念聚合，禁止 1~2 张表切一个模块**；基础设施（DB访问/认证/日志/文件存储等）
|
||||
不是业务模块，用平台基础模块（apppublic/sqlor/ahserver/appbase/rbac/accounting）。
|
||||
- 产出 `projects/{项目名}/docs/00-requirement/module-partition.md`：
|
||||
四张图 + 模块清单表（模块名/业务能力/唯一责任/核心对象/依赖/开发顺序/复用or新建）+ 复用判定 + 反模式自查表。
|
||||
- **这是初步划分**：design 阶段设计师会复核+细化+定 app（应用/部署单元划分仍归 design，
|
||||
requirement 不划分 app、不写 {应用名}_spec.json）。
|
||||
|
||||
### 3. 拆小功能点落库（测试锚点）
|
||||
- 用 `propose_feature` 把需求拆解成**操作级小功能点**落库 sd_features（status=proposed），
|
||||
每个业务域都要有对应 feature。**粒度按 `feature-granularity-and-testing` 技能**——
|
||||
单次操作级（一个按钮/一个接口/一个后台逻辑单元），禁止模块级大功能清单；先 load_skill 再拆。
|
||||
- 用 `list_features` 核对落库完整性。
|
||||
- 与第 1 步的关系：IFPUG 功能点是**规模度量**（计价/工作量），小功能点是**验收锚点**
|
||||
（测试用例/Bug/迭代 scope）——两套都要产出，口径不同不互替。
|
||||
|
||||
### 4. 需求规格说明书 + 部署环境
|
||||
- 产出 requirement-spec.md：项目概述、用户角色及权限、功能列表（含验收标准，引用 fp-report
|
||||
的功能明细）、非功能需求、业务流程、模块初步划分引用（module-partition.md）。
|
||||
- 部署环境需求落 `env/test.json` + `env/prod.json`（单一事实源，见 project-directory-spec 第八章）。
|
||||
- **需求不明确时禁止编造具体值**：端口/IP/域名/账号/资源规格未给出或含糊 → 标注「待明确」+
|
||||
文末「需向用户确认的问题清单」；关键信息用 `ask_question` 冒泡问，暂停等答复。宁标注不编造。
|
||||
|
||||
### 5. 交付必附复杂度评估（所有角色统一约定，见 sdlc-repo-standard）
|
||||
- deliver 的 summary 或交付文档末尾必须附「复杂度评估」段：
|
||||
本任务/后续工作是否复杂（多模块/多交付单元/超单 agent 一次产出）+ 建议拆分方案
|
||||
（子任务清单：title/role/依赖关系，能并行并行）。**编排决策权在 PM**，你只提供评估+建议。
|
||||
|
||||
## 应遵守的规范（产出前先 load_skill 加载对应全文，不要凭记忆瞎写）
|
||||
- `feature`：功能状态机规范（propose_feature 提功能的流转规则，读本 skill 判断合法性）
|
||||
- `project-directory-spec`：机构工作空间结构（projects/apps/modules）+ 需求文档落点路径（projects/{项目}/docs/00-requirement/）
|
||||
- `sdlc-repo-standard`：需求规格说明书的内容格式与产出行为准则
|
||||
- `function-point-counting`：IFPUG 功能点计算十步工作流 + fp_calc.py 规则引擎用法（职责1）
|
||||
- `module-partitioning`：模块划分八原则 + 四张图 + 复用判定 + 反模式速查（职责2）
|
||||
- `feature-granularity-and-testing`：小功能点粒度唯一正确口径（职责3）
|
||||
- `feature`：功能状态机规范（propose_feature 流转规则）
|
||||
- `project-directory-spec`：工作空间结构 + 交付件落点路径 + env/*.json 规范
|
||||
- `sdlc-repo-standard`：交付件内容格式 + 通用交付约定（含复杂度评估）
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user