feat(skills): feature-granularity-and-testing——功能点必须单次操作级小功能+正反用例设计；requirement/test角色技能引用

skills_library/all/feature-granularity-and-testing/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: feature-granularity-and-testing
+description: 功能点粒度规范与正反用例设计。设计功能点、编写/评审测试用例前必读——功能点必须是单次操作级小功能（一个按钮/一个接口/一个后台逻辑单元），禁止大模块级功能清单；用例按小功能点逐条设计正反用例并留真实执行证据。
+---
+
+# 功能点粒度规范与正反用例设计
+
+> 适用角色：agent.requirement（拆功能点）、agent.design（功能→接口）、agent.develop（实现对照）、agent.test（用例设计与执行）、agent.qc（验收对照）。
+
+## 1. 什么是「小功能点」（唯一正确口径）
+
+功能点 = **客户的一次操作，或系统后台的一次逻辑单元操作**。判定标准——同时满足：
+
+1. **一次触发**：一个按钮点击 / 一个表单提交 / 一个接口调用 / 一次后台调度触发。
+2. **一个明确的输入→输出契约**：输入字段、输出结果、失败原因都能逐字段列出来。
+3. **可独立验收**：能单独构造正例和反例，不依赖"跑通整个模块"。
+
+### 正例（合格的小功能点）
+- `W-01a 设置世界模式为 independent 并保存`（一次设置+保存动作）
+- `W-01b 世界模式设为非法值时拒绝保存并提示`（同一操作的校验分支）
+- `W-04a 保存当前世界快照`（一次保存动作）
+- `W-04b 恢复指定世界快照`（一次恢复动作）
+
+### 反例（禁止的大功能点）
+- ❌ `独立世界`（= 模块级，含多个操作，无法单独验收）
+- ❌ `世界管理`（= 页面级，不是操作）
+- ❌ `共享世界同步`（= 机制级，应拆成：加入世界/上报操作/接收状态/断线重连恢复 等逐条）
+
+### 命名与编号
+- 编号格式：`{模块前缀}-{序号}{后缀字母}`，后缀字母区分同一操作的正常/校验分支（a=主流程，b/c…=校验与异常分支）。
+- 每条功能点必须带：触发方式、输入字段清单、正常输出、失败输出（错误码/提示）、量化验收指标（如响应时间、条数、大小上限）。
+
+## 2. 功能点拆分流程（requirement 角色）
+
+1. 先按页面/模块列出"操作面"（有哪些按钮、表单、接口、后台作业）。
+2. 每个操作面拆到单次操作级：一个按钮=1 个功能点；一个接口的每个校验分支=1 个功能点。
+3. 后台逻辑单元同理：一次调度/一次状态流转/一次持久化=1 个功能点。
+4. 拆完自检：任取一条功能点，问"反例（错误输入/越权/不存在/并发）怎么设计"——答不出来就是粒度太粗，继续拆。
+5. 全部落库 `sd_features`（propose_feature），每条独立编号，禁止把多个操作合并进一条记录。
+
+## 3. 正反用例设计（test 角色）
+
+**每个小功能点至少 1 条正例 + 1 条反例**，反例不是可选项。
+
+### 正例（正向用例）
+- 合法输入 → 期望输出，逐字段断言（接口返回结构/字段值/落库记录/界面变化）。
+- 断言写具体：「返回 status=200 且 body.data.id 非空且数据库表 xxx 新增 1 行」，禁止「功能正常」式描述。
+
+### 反例（反向用例，至少覆盖适用项）
+- **非法值**：类型错误、超长度、枚举外取值、空值/缺必填 → 期望拒绝+明确提示。
+- **越权**：未登录、无权限角色访问 → 期望 401/403，不得 200。
+- **不存在**：操作不存在的对象 → 期望 404/明确错误，不得 500。
+- **边界**：0 条、1 条、上限条数、上限大小（快照 10MB 类约束）。
+- **重复/并发**：重复提交、并发写 → 期望幂等或明确报错，不得脏数据。
+
+### 用例字段要求（落库 sd_test_cases 时）
+- `case_name`：`{功能点编号}-{方向}-{一句话}`，如 `W-01a-pos-设置 independent 保存成功`、`W-01b-neg-非法值拒绝保存`。
+- `steps`：可直接执行的步骤（含入口路径、请求方法、参数），不得写"进入系统操作一下"。
+- `expected_result`：可判定的期望（具体字段/状态码/界面元素），不得写"正常显示"。
+
+## 4. 执行与证据（test 角色）
+
+1. 入口一律从项目 `env/test.json` 读（base_url/登录凭据/DB 通道），禁止硬编码主机端口。
+2. 每条用例执行后更新 `sd_test_cases.status`（pass/fail/blocked），`actual_result` 写**原始输出**（响应体片段/报错原文/截图路径），不写"符合预期"。
+3. `blocked` 必须注明具体原因（哪个接口、什么错误），禁止以"环境不可用"笼统带过；环境不可用本身要落 `sd_bugs`。
+4. fail 用例落 `sd_bugs`（含 task_id 关联本任务），标题写功能点编号。
+
+## 5. 验收口径（qc/pm）
+
+- 测试通过标准 = **全部小功能点的正反用例真实执行且无 fail**，而非"主流程能走通"。
+- 报告必须给出：功能点总数、用例总数（正例/反例）、pass/fail/blocked 计数、每条证据路径。
+- 出现"用例 blocked 但任务报通过"= 验收造假，一律退回。
+
+## 6. 自检清单（交付前逐条过）
+
+- [ ] 每条功能点都是单次操作级（能用一句话说出"谁，点哪里/调哪个接口，期望什么"）
+- [ ] 每个功能点都有正例，且至少 1 条反例
+- [ ] 反例覆盖：非法值/越权/不存在 三类中适用项
+- [ ] 期望结果全部可判定（无"正常/合理"模糊词）
+- [ ] 执行证据是原始输出而非转述结论

skills_library/pipelines/sdlc_general/roles/agent.requirement/role/SKILL.md

@@ -7,7 +7,7 @@ capability: feature_propose_capability
 # 需求分析师（requirement）角色定义
 
 ## 职责
-- **拆解需求提功能（落库，别只写文档）**：用 `propose_feature` 把需求拆解成功能点，落库 sd_features（状态 proposed），每个业务域都要有对应 feature
+- **拆解需求提功能（落库，别只写文档）**：用 `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）——部署信息只在这里一份，不散落到需求/设计/代码各处，改配置只改这里

skills_library/pipelines/sdlc_general/roles/agent.test/role/SKILL.md

@@ -17,7 +17,7 @@ capability: test_plan_capability, test_case_capability, bug_test_capability
 - 冒烟失败是部署问题，报 Bug 时 description 明确写「部署/环境根因，非功能缺陷」，PM 会据此指派给 deploy_test 而非 develop
 
 ### 二、用例测试（验证系统功能是否正常）
-- 测什么：design 的每个功能点——CRUD、业务接口、RBAC、数据契约、i18n
+- 测什么：design 的每个功能点——CRUD、业务接口、RBAC、数据契约、i18n。**按 `feature-granularity-and-testing` 技能设计正反用例**——每个小功能点至少 1 条正例 + 1 条反例（非法值/越权/不存在/边界），反例不是可选项；先 load_skill 加载该技能再设计
 - 用 `create_test_plan` 落库 sd_test_plans，`create_case` 落库 sd_test_cases（每个功能点都要有用例覆盖）
 - 用 `pass_case` / `fail_case` / `skip_case` / `block_case` 真实执行；selftest.py 必须是真实断言（非占位符），附真实执行输出
 - **功能 fail → 问题交给开发工程师（agent.develop）**：`report_bug` 建 Bug 落库 sd_bugs，走 Bug 闭环（develop 修复 → test 复测关闭）