fix(ai): 自动追加AI任务类型

docs/decisions.md

@@ -264,7 +264,7 @@
 - 调研/产品方案/UI 设计都使用子任务清单；完成时必须满足规则引擎要求并提交链接或文件成果。
 - 新增 `requirement-selector.ts`，所有关联需求候选都从当前版本所属项目下的已采纳需求中取，不从全量需求池取。
 - DevTask 和 TestCase 共用 `TaskCategory` 字典，`TestCase` 增加 `categoryId`。
-- `TaskCategory` 增加稳定 `code`，AI 输出 `categoryCode`，前端再映射为当前系统的 `categoryId`。
+- `TaskCategory` 增加稳定 `code`，早期用于 AI `categoryCode` 到系统 `categoryId` 的映射；后续 AI 任务类型改为以 `taskTypeName` 为主，见决策 #41。
 
 **理由**：
 - 完成条件属于业务规则，不属于按钮组件；集中到工作流引擎后，列表和抽屉能保持一致。
@@ -389,7 +389,7 @@
 
 **决策**：
 - 在测试分组增加细分类：UI 交互、表单校验、数据一致性、权限、边界值、状态流转、回归测试。
-- AI tool schema、shared 类型和前端任务类型字典同步允许这些 `categoryCode`。
+- 早期 AI tool schema、shared 类型和前端任务类型字典同步允许这些 `categoryCode`；后续这些类型只作为建议映射，AI 可通过 `taskTypeName` 输出字典外类型，见决策 #41。
 - Prompt 明确要求 TestCase 按功能点、交互、接口、数据、权限、异常、边界、状态流转和回归点拆细。
 - 一条 QY 如果同时涉及 UI、接口、数据、异常和状态变化，通常应拆出 3-8 条 TestCase，不允许用单条“完整流程验证”兜住。
 
@@ -503,3 +503,16 @@
 - 原型批注只要包含标题、详细说明、字段、异常或验收标准之一，且能判断用户动作或系统行为，就不得进入 `ambiguous`；必须进入 `matched` 或 `prototypeOnly` 继续拆解。
 
 **理由**：Superpowers 的任务计划和 TDD 流程本质上是“先把工作拆成可验证切片，再用测试约束倒逼粒度”。把这套方法沉淀到 Agent 契约里，能减少粗拆、漏拆和误判含糊，同时不改变现有数据模型，只提高 AI 草案的结构质量。
+
+## 41. AI 拆解任务类型不受人工字典限制，采纳时自动入库
+
+**问题**：任务类型字典最初服务于人工新建任务表单，覆盖的是常见开发和测试类型。AI 从原型里识别出的真实交付切片可能更细，例如“人员名片交互”“预入职数据源”“姓名展示兼容测试”。如果继续要求 AI 只能输出既有 `categoryCode` 枚举，就会把拆解能力绑死在人工表单选项上，字典没覆盖时容易漏拆或被迫归到错误类型。
+
+**决策**：
+- AI DevTask / TestCase 草案必须输出 `taskTypeName`，这是展示给用户的任务类型名称。
+- `categoryCode` 改为可选兼容映射；只有能明确对应已有稳定语义码时才输出，不再作为 schema 必填项，也不再限制为固定枚举。
+- 前端采纳 AI 结果时，按 `taskTypeName` 在当前 `TaskCategory` 同分组内查找；不存在则自动追加一条 `isSystem=false` 的任务类型，并用该类型的 `id` 写入 DevTask/TestCase。
+- 去重逻辑按任务类型名称、标题和引用来源判断；已采纳过的自定义 AI 类型再次生成时也能过滤重复草案。
+- 人工新建任务表单继续使用任务类型字典作为可选项，但这个字典会随着 AI 草案采纳自动扩展。
+
+**理由**：人工表单的任务类型是录入辅助，不应该成为 AI 拆解边界。`taskTypeName` 让模型按真实工作切片命名，采纳时自动补字典让后续筛选、统计和人工创建都能复用新类型，同时避免 AI 直接写数据库 `categoryId`。