feat(ai): 优化拆解重跑与结果展示

docs/decisions.md

@@ -12,7 +12,7 @@
 - `testing` → 80%
 - `submitted` → 100%
 
-**理由**：客观、不允许造假。需求级/版本级进度 = `Σ(estimateHours × 状态推导%) / Σ(estimateHours)`。
+**理由**：客观、不允许造假。需求级/版本级进度 = `Σ(估算耗时 × 状态推导%) / Σ(估算耗时)`。估算耗时优先取执行人填写的 `estimateHours`，没有时才用 AI 草案的 `aiEstimateHours` 兜底。
 
 ## 2. 实际工时 — 由开始/完成时间戳计算
 
@@ -269,3 +269,34 @@
 - 需求候选来源属于领域边界；统一 selector 能避免从需求池、项目需求、版本需求之间误取数据。
 - AI 不应该猜数据库 id；稳定语义码能兼容管理员调整展示名称，也方便后续扩展更多模型。
 - 测试用例带任务类型后，才能知道测试覆盖范围，AI 拆解和人工创建的数据形状也一致。
+
+## 24. AI 预估和执行人预估分离
+
+**问题**：AI 拆解写入 `estimateHours` 会让系统误以为负责人已经确认了工时和排期；同时 AI 会根据原型自动反推预计开始/截止，造成“计划已填”的错觉。
+
+**决策**：
+- AI 输出字段统一改为 `aiEstimateHours`，不再输出/写入 `estimateHours`。
+- `estimateHours` 只表示执行人或负责人确认后的执行预估。
+- 进度和统计口径优先使用 `estimateHours`；缺失时使用 `aiEstimateHours` 兜底；两者都没有时才从计划时间推导或按无估时处理。
+- AI 采纳开发任务时不写预计开始/截止时间，由负责人后续填写计划排期。
+- AI 重新拆解入口拆成“重新拆解开发任务”和“重新拆解测试用例”，请求通过 `target` 控制本次只生成哪类草案。
+- AI 估时允许小于 0.5h，汇总时保留小数精度；实际耗时仍按状态时间戳计算并保持 0.5h 口径。
+
+**理由**：
+- AI 给的是建议，不是负责人承诺。
+- 排期属于执行人计划，不能由拆解 Agent 代填。
+- 独立重拆能避免修改开发任务时顺手覆盖测试用例，降低误采纳风险。
+
+## 25. AI 重新拆解先过滤已采纳重复草案
+
+**问题**：第一次 AI 拆解的 DevTask/TestCase 已经被采纳后，用户再次重新拆解时，模型可能再次输出同一批草案。若直接展示给用户采纳，会造成开发任务和测试用例重复。
+
+**决策**：
+- AI 返回结果后，前端在打开采纳弹窗前先做确定性去重。
+- 开发任务比对范围是当前版本已关联需求下的现有 DevTask；测试用例比对范围是当前版本下的现有 TestCase。
+- 重复判定使用：任务类型 code + 标题规范化 + 引用来源（需求 / 原型批注）一致。
+- 重复草案不进入采纳列表，只在弹窗提示已过滤数量。
+
+**理由**：
+- 去重不能只依赖模型提示，必须有系统规则兜底。
+- 标题也参与签名，避免同一需求/QY 下不同真实工作项被误过滤。