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

docs/agent-spec.md

@@ -65,8 +65,8 @@
 
 **输出**：
 - 对账报告（结构化文本，含"完美对应/需求未见原型/无需求ID分组/含糊"）
-- DevTask 草案数组（每条带结构化 `description` + `aiDraft: true` + `references[]` + `aiEstimateHours`，可选 `recommendedAssigneeName` / `recommendedAssigneeReason`）
-- TestCase 草案数组（每条带 `aiDraft: true` + `references[]` + `aiEstimateHours`，可选 `recommendedAssigneeName` / `recommendedAssigneeReason`）
+- DevTask 草案数组（每条带结构化 `description` + `taskTypeName` + `aiDraft: true` + `references[]` + `aiEstimateHours`，可选 `categoryCode` / `recommendedAssigneeName` / `recommendedAssigneeReason`）
+- TestCase 草案数组（每条带 `taskTypeName` + `aiDraft: true` + `references[]` + `aiEstimateHours`，可选 `categoryCode` / `recommendedAssigneeName` / `recommendedAssigneeReason`）
 - `target = dev_tasks` 时 `testCaseDrafts` 必须为空数组；`target = test_cases` 时 `devTaskDrafts` 必须为空数组
 
 **原型与需求匹配规则**：
@@ -89,11 +89,12 @@
 - 不允许用一条“验证 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`。
+- DevTask / TestCase 必须输出 `taskTypeName`，用于展示和任务类型字典写入。`categoryCode` 只作为可选的兼容映射字段；没有合适稳定码时可以省略，不能因此停止拆解。
 
 **写入**：
 - 用户确认后，调用 `useDevTaskStore.createTask` 和 `useTestCaseStore.createTestCase`
 - 打开采纳弹窗前，前端先过滤当前版本已采纳过的重复 DevTask/TestCase 草案
+- 写入前，前端按 `taskTypeName` 检查 `TaskCategory` 字典；不存在时自动追加非系统任务类型，再用新 `categoryId` 写入 DevTask/TestCase
 - 写入字段中 `aiDraft: true`、`aiDraftAt: ISO时间戳`
 - 写入 `aiEstimateHours`，不写入执行人预估 `estimateHours`
 - DevTask / TestCase 必须写入 `versionId` 作为执行归属；`requirementId` 可选
@@ -258,12 +259,12 @@ 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[] }>;
-  testCaseDrafts: 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; taskTypeName: string; categoryCode?: string; priority: Priority; aiEstimateHours: number; requirementName?: string; recommendedAssigneeName?: string; recommendedAssigneeReason?: string; references: Reference[] }>;
+  testCaseDrafts: Array<{ title: string; description: string; taskTypeName: string; categoryCode?: string; priority: Priority; aiEstimateHours: number; requirementName?: string; recommendedAssigneeName?: string; recommendedAssigneeReason?: string; references: Reference[] }>;
 }
 ```
 
-要求：AI 不输出数据库 `categoryId`，只输出稳定 `categoryCode`。前端确认写入时按 `TaskCategory.code` 映射成 `categoryId`；映射失败时使用对应分组的默认类型兜底。AI 不输出 `estimateHours`、预计开始或预计截止。草案没有 `requirement` 引用时，必须有 `requirementName` 和至少一个 `prototype_note` 引用。
+要求：AI 不输出数据库 `categoryId`。`taskTypeName` 是必填的展示和字典类型名；`categoryCode` 只是可选映射提示，不限制 AI 拆解。前端确认写入时按 `taskTypeName` 自动确保 `TaskCategory` 存在，缺失则追加到任务类型字典，再写入对应 `categoryId`。AI 不输出 `estimateHours`、预计开始或预计截止。草案没有 `requirement` 引用时，必须有 `requirementName` 和至少一个 `prototype_note` 引用。
 
 ### 任务/用例分组契约
 

docs/architecture.md

@@ -188,7 +188,7 @@ V2 接入后端后改为基于 `ProjectMember` 表的 RBAC（Owner/Admin/Member/
 
 - `version-plan-workflow.ts`：调研/产品方案/UI 设计的子任务、需求覆盖、成果提交和完成条件。
 - `requirement-selector.ts`：当前版本所属项目下可关联需求的候选筛选，默认只返回 `status === 'adopted'` 的项目需求。
-- `task-category.ts`：DevTask/TestCase 共用任务类型字典，`id` 用于存储，`code` 用于 AI 语义映射。
+- `task-category.ts`：DevTask/TestCase 共用任务类型字典，`id` 用于存储，AI 输出的 `taskTypeName` 可在采纳时自动追加到字典，`code` 仅作可选语义映射。
 
 页面组件只消费规则层输出，不直接拼完成条件或候选筛选条件。
 ## Work Activity Daily Report Layer (2026-06-26)

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`。

docs/workflow.md

@@ -235,7 +235,7 @@ AI 估时约束：
 
 - `version-plan-workflow.ts` 是调研/产品方案/UI 设计完成条件的唯一入口。
 - `requirement-selector.ts` 是版本内关联需求候选的唯一入口。
-- `TaskCategory.code` 是 AI 和系统任务类型的稳定映射锚点，`id` 只作为存储主键。
+- `TaskCategory.name` 是 AI 草案的任务类型展示和自动入库锚点；`TaskCategory.code` 仅作为可选兼容映射，`id` 只作为存储主键。
 - DevTask 新数据必须有 `versionId`；`requirementId` 作为正式需求语义标签可选。版本级聚合走 `versionId`，需求级进度只统计带 `requirementId` 的任务。
 - 产品方案和 UI 设计的引用需求不再用 checkbox 直接标记完成，必须通过 `requirementCoverage[]` 记录 `not_started / partial / completed`、本次已完成内容和剩余内容；只有 `completed` 计入成果提交门禁。
 - 产品/UI 计划右侧展示计划日志，需求进度更新和 AI 拆解触发/完成/失败都写入 `VersionPlan.logs[]`，页面只消费日志数据，不临时拼历史。