fix(ai): 强化拆解切片和测试粒度

docs/agent-spec.md

@@ -65,7 +65,7 @@
 
 **输出**：
 - 对账报告（结构化文本，含"完美对应/需求未见原型/无需求ID分组/含糊"）
-- DevTask 草案数组（每条带 `aiDraft: true` + `references[]` + `aiEstimateHours`，可选 `recommendedAssigneeName` / `recommendedAssigneeReason`）
+- DevTask 草案数组（每条带结构化 `description` + `aiDraft: true` + `references[]` + `aiEstimateHours`，可选 `recommendedAssigneeName` / `recommendedAssigneeReason`）
 - TestCase 草案数组（每条带 `aiDraft: true` + `references[]` + `aiEstimateHours`，可选 `recommendedAssigneeName` / `recommendedAssigneeReason`）
 - `target = dev_tasks` 时 `testCaseDrafts` 必须为空数组；`target = test_cases` 时 `devTaskDrafts` 必须为空数组
 
@@ -76,11 +76,19 @@
 - 没有 QY 编号但原型文本已命中需求编号或需求概述时，不应丢弃；可只引用 `requirement`，并在 `matched.noteIds` 返回空数组。
 - 既匹配不到需求编号，也匹配不到需求概述语义，但能形成明确功能名称和任务范围的原型批注，进入 `prototypeOnly`，对应草案带 `requirementName` 且不带 `requirement` 引用。
 - 只有无法形成稳定任务/用例的含糊批注才进入 `ambiguous`。
+- 原型批注只要包含标题、详细说明、字段、异常或验收标准之一，且能判断用户动作或系统行为，就不能进入 `ambiguous`；这类内容必须进入 `matched` 或 `prototypeOnly` 并继续拆解。
+
+**开发任务与测试用例拆解粒度**：
+- Agent 先在内部把每条 QY 或命中的需求拆成交付切片，再生成 DevTask/TestCase；交付切片维度按 UI、交互、接口、数据、异常、边界、状态流转、兼容和回归扫描。
+- 每条业务规则、字段规则、交互规则、异常规则和验收标准都必须至少映射到 1 条开发任务或 1 条测试用例；本次 target 不包含的一侧可以不输出，但另一侧必须覆盖。
+- DevTask 必须是一个可交付工程动作。前端、后端、接口、数据库、数据处理和集成支持要按职责拆开。
+- DevTask `description` 必填，至少包含实现范围和验收点；如存在非目标范围或依赖，也必须写明。
 
 **测试用例拆解粒度**：
 - TestCase 要按功能点、UI 交互、表单校验、接口、数据一致性、权限、异常、边界、状态流转、兼容性和回归点拆细。
 - 不允许用一条“验证 XX 完整流程”覆盖多个交互、多个接口或多个规则。
 - 一条 QY 若同时涉及 UI、接口、数据、异常和状态变化，通常应拆出 3-8 条 TestCase。
+- TestCase `description` 必填，至少包含前置条件、操作步骤和预期结果；涉及边界、异常或数据一致性时，必须写明测试数据或状态。
 - 测试用例 `categoryCode` 可使用：`test_functional`、`test_ui_interaction`、`test_form_validation`、`test_api`、`test_data_consistency`、`test_permission`、`test_exception`、`test_boundary`、`test_state_flow`、`test_compatibility`、`test_regression`。
 
 **写入**：
@@ -250,7 +258,7 @@ interface DecomposeOutput {
     prototypeOnly: Array<{ requirementName: string; noteIds: string[]; taskCount: number }>;
     ambiguous: Array<{ noteId: string; reason: string }>;
   };
-  devTaskDrafts: Array<{ title: string; description?: string; categoryCode: string; priority: Priority; aiEstimateHours: number; requirementName?: string; recommendedAssigneeName?: string; recommendedAssigneeReason?: string; references: Reference[] }>;
+  devTaskDrafts: Array<{ title: string; description: string; categoryCode: string; priority: Priority; aiEstimateHours: number; requirementName?: string; recommendedAssigneeName?: string; recommendedAssigneeReason?: string; references: Reference[] }>;
   testCaseDrafts: Array<{ title: string; description: string; categoryCode: string; priority: Priority; aiEstimateHours: number; requirementName?: string; recommendedAssigneeName?: string; recommendedAssigneeReason?: string; references: Reference[] }>;
 }
 ```

docs/decisions.md

@@ -490,3 +490,16 @@
 - 冲突响应返回 `currentVersion` 和 `currentValue`，但当前前端不自动合并、不自动重试，避免把旧本地副本用新版本号再次覆盖服务端数据。
 
 **理由**：这是 AppData 阶段成本最低、收益最高的一致性补强。它不能提供字段级协同编辑，但能阻止最危险的“静默最后写入覆盖”。后续拆成关系表和领域 API 后，再在具体实体上做更细粒度的事务、唯一约束、审计日志和冲突合并 UI。
+
+## 40. AI 拆解借鉴 Superpowers 的交付切片和测试倒逼粒度
+
+**问题**：AI 原型拆解虽然已经要求细颗粒任务和测试用例，但模型仍可能把清晰 QY 批注压成一条大任务、一条“完整流程验证”，或者把带详细说明、字段和验收标准的批注误判为含糊。
+
+**决策**：
+- Prototype Decompose Agent 在生成 DevTask/TestCase 前，必须先按 UI、交互、接口、数据、异常、边界、状态流转、兼容和回归做内部交付切片。
+- 每条业务规则、字段规则、交互规则、异常规则和验收标准，必须至少映射到 1 条开发任务或 1 条测试用例；本次 target 不包含的一侧可以不输出，但另一侧必须覆盖。
+- DevTask `description` 从可选变为必填，至少包含实现范围和验收点。
+- TestCase `description` 必须包含前置条件、操作步骤和预期结果；涉及边界、异常或数据一致性时写明测试数据或状态。
+- 原型批注只要包含标题、详细说明、字段、异常或验收标准之一，且能判断用户动作或系统行为，就不得进入 `ambiguous`；必须进入 `matched` 或 `prototypeOnly` 继续拆解。
+
+**理由**：Superpowers 的任务计划和 TDD 流程本质上是“先把工作拆成可验证切片，再用测试约束倒逼粒度”。把这套方法沉淀到 Agent 契约里，能减少粗拆、漏拆和误判含糊，同时不改变现有数据模型，只提高 AI 草案的结构质量。