feat(版本详情): 完善流程日志与需求覆盖

docs/decisions.md

@@ -96,8 +96,9 @@
 **决策**：
 - `status: todo|in_progress|testing|submitted`
 - `isBlocked: boolean` + `blockReason: string` + `blockedById: string`
+- DevTask 存在阻塞时不能转为 `submitted`，必须先解除阻塞再提测。
 
-**理由**：阻塞和状态正交。工作台筛选 `isBlocked=true` 一键拉出所有阻塞项，跨状态。
+**理由**：阻塞和状态正交。工作台筛选 `isBlocked=true` 一键拉出所有阻塞项，跨状态；但 `submitted` 代表开发交付完成，仍必须满足“当前无阻塞”的完成条件。
 
 ## 11. 加班原因可选，且去掉"其他"
 
@@ -352,7 +353,7 @@
 - 新建统一的工作日日期时间选择组件，创建任务时复用同一套交互。
 - 内置国务院办公厅发布的 2026 年中国法定节假日和调休工作日；未知年份按周末/工作日兜底。
 - 选择节假日或周末时只提示，不阻止保存；选择调休工作日时按工作日提示。
-- TestCase 增加 `plannedTestAt`，Bug 增加 `plannedFixAt`，保存为 ISO 时间戳。
+- TestCase 增加 `plannedTestAt` / `plannedEndAt`，Bug 增加 `plannedFixAt`，保存为 ISO 时间戳。
 
 **理由**：项目排期需要贴近中国工作日，但研发和线上 Bug 可能确实安排在非工作日处理，所以系统负责提醒，最终是否保存交给用户判断。
 
@@ -405,6 +406,31 @@
 
 **理由**：负责人推荐能减少项目经理初次分配成本，但分配本身是团队执行承诺，必须由人确认。把推荐和写入分开，可以复用版本成员上下文，又避免模型幻觉姓名或越权自动派单。
 
+## 34. AI 草案领取和计划必须绑定
+
+**问题**：AI 生成的 DevTask / TestCase 如果没有负责人，团队需要先领取；如果把“待领取”和“待排期”拆成两个可见状态，会让版本详情列表出现更多标签，且无法体现“领取时就应该承诺计划”的业务动作。
+
+**决策**：
+- 版本详情开发任务和测试用例不显示“待排期”标签。
+- 无负责人时显示“待领取”，领取入口必须同时填写计划起止时间。
+- 用户采纳 AI 推荐负责人后，草案已经有负责人，不再需要领取；但开始开发/测试前仍必须补齐计划起止时间。
+- DevTask 进入 `in_progress` 前必须具备 `assigneeId`、`expectedStartAt`、`expectedEndAt`。
+- TestCase 进入 `running` 前必须具备 `assigneeId`、`plannedTestAt`、`plannedEndAt`。
+
+**理由**：领取代表成员承诺执行，计划时间代表承诺边界，二者应该在同一个动作里完成。列表层只表达“谁还没接手”，状态机层负责阻止未计划任务进入执行，页面不会被额外标签干扰。
+
+## 35. 产品/UI 计划需求覆盖必须区分部分完成和完全完成
+
+**问题**：产品方案和 UI 设计经常跨天推进，同一天可能只完成某条需求的一部分。旧的勾选式“引用需求已完成”只能表达完成/未完成，日报和后续分析无法知道本次完成了什么、还剩什么，也容易把部分完成误算成可提交成果。
+
+**决策**：
+- VersionPlan 增加 `requirementCoverage[]`，每条引用需求记录 `not_started / partial / completed`、已完成内容、剩余内容、更新人和更新时间。
+- 旧的 `completedRequirementIds` 继续保留用于兼容历史数据，但当同一需求存在 `requirementCoverage` 时，以新覆盖状态为准。
+- 产品/UI 计划的成果提交门禁只认 `completed`，`partial` 只记录进度，不满足“关联需求全部覆盖”。
+- 计划增加 `logs[]`，记录需求进度更新和 AI 拆解触发/完成/失败，右侧日志时间线消费该数据。
+
+**理由**：覆盖状态是产品/UI 计划自身的业务事实，不应该用简单 checkbox 表达。显式记录“已完成/剩余”能支撑日报、复盘和需求完成质量分析，同时保留旧字段可避免历史数据迁移成本。
+
 ## 36. 小宝预警规则优先，AI 只做解释
 
 **问题**：如果直接让 AI 判断版本能否发版，模型可能忽略系统内的任务、Bug、测试、日报和权限事实，结论不可追溯；如果只按风险等级触发 AI，又会漏掉同等级内风险剧变，例如 P1 Bug 从 0 到 3、测试失败、发版日只剩 1 天。

docs/workflow.md

@@ -35,6 +35,22 @@
 
 开发任务从“待开发”切换到“开发中”时，只有当前时间已经超过 `expectedEndAt`（预计截止）才要求填写延后原因。超过预计开始时间但仍未超过预计截止时间，不视为延后。
 
+## AI 草案领取与计划流程
+
+开发任务和测试用例由 AI 生成后，版本详情里不再显示独立的“待排期”状态：
+
+1. DevTask / TestCase 没有负责人时显示“待领取”。
+2. 点击“领取并填写计划”时同时写入当前用户为负责人，并填写计划起止时间。
+3. 已采纳推荐负责人的 AI 草案已经有负责人，不需要领取，但开始开发/测试前仍必须点击“填写计划”补齐计划起止时间。
+4. DevTask 开始开发前必须同时具备 `assigneeId`、`expectedStartAt`、`expectedEndAt`；TestCase 开始测试前必须同时具备 `assigneeId`、`plannedTestAt`、`plannedEndAt`。
+5. 计划起止时间自动按工作日历计算 `estimateHours`。AI 预估仍保留在 `aiEstimateHours`，不代表负责人已确认排期。
+
+## 开发任务提测流程
+
+1. DevTask 从“自测”转为“已提测”前，任务不能处于阻塞中。
+2. 如果 `isBlocked=true`，必须先解除阻塞并清空阻塞原因，再允许提测。
+3. “已提测”仍然是 DevTask 终态；后续测试通过或失败不回写 DevTask 状态。
+
 ## 测试轮次流程
 
 测试用例支持按版本开启多轮测试：
@@ -207,6 +223,8 @@ AI 估时约束：
 - `version-plan-workflow.ts` 是调研/产品方案/UI 设计完成条件的唯一入口。
 - `requirement-selector.ts` 是版本内关联需求候选的唯一入口。
 - `TaskCategory.code` 是 AI 和系统任务类型的稳定映射锚点，`id` 只作为存储主键。
+- 产品方案和 UI 设计的引用需求不再用 checkbox 直接标记完成，必须通过 `requirementCoverage[]` 记录 `not_started / partial / completed`、本次已完成内容和剩余内容；只有 `completed` 计入成果提交门禁。
+- 产品/UI 计划右侧展示计划日志，需求进度更新和 AI 拆解触发/完成/失败都写入 `VersionPlan.logs[]`，页面只消费日志数据，不临时拼历史。
 ## Work Activity Daily Report Flow (2026-06-26)
 
 The daily report flow uses mixed evidence:
@@ -244,8 +262,8 @@ AI 解读不由人工按钮触发。`at_risk`、`likely_delayed`、`blocked` 自
 - 调研、产品方案、UI 设计、开发任务、测试用例、Bug 创建时使用统一工作日日期时间选择器。
 - 日期选择器接入中国节假日日历。当前内置 2026 年国务院办公厅放假调休安排；其他年份先按周末/工作日兜底。
 - 非工作日只提示，不阻止保存；调休工作日按工作日提示。
-- 测试用例计划测试时间字段为 `plannedTestAt`；Bug 计划修复时间字段为 `plannedFixAt`。
-- 测试轮次复制用例时保留计划测试时间、AI 预估和执行预估，清空实际执行记录。
+- 测试用例计划测试时间字段为 `plannedTestAt` / `plannedEndAt`；Bug 计划修复时间字段为 `plannedFixAt`。
+- 测试轮次复制用例时保留计划测试起止时间、AI 预估和执行预估，清空实际执行记录。
 
 ## 工时统计口径