任务管理

<!-- @include templates/prompts/iron-law-tool.md（已内联于下方，无需另读） --> ⛔ IRON LAW · 不可违反的硬门禁（工具型命令）

本命令不是主链路上的阶段：不追加 `history`，不改 `current_stage` / `next_step` / `last_phase_result`，也不为此分配功能ID。以下规则不可协商：

1. 文件必须落盘：正文要求创建的文件必须作为实际文件写入磁盘，不可仅在对话中输出（只要求在对话里输出的，照正文办）。
2. 自检必须执行：产出后按本命令的自检项逐项核对，不得以"已经很好了"为由跳过。
3. 防循环：修复只做一次，不递归。修不了的问题记进报告，继续往下走。

违反任一条 = 立即中止当前命令，输出违规详情，等待人工介入。 <!-- @include-end templates/prompts/iron-law-tool.md -->

管理功能开发任务的拆解、分配与进度追踪。支持从 PRD 自动拆解任务、标记任务状态。

子命令解析

从本命令的参数中解析子命令和选项：

如果未提供子命令或子命令无法识别，输出以上帮助信息后停止。

任务 ID 与文件约定

任务 ID 格式

T<功能ID的日期-时分秒>-<NN>-<类型>

• <功能ID的日期-时分秒>：所属功能ID去掉 F 前缀的部分（功能 F20260718-094301 → 前缀 20260718-094301）。嵌入 feature 的唯一时分秒，使任务号全局唯一且自带归属（一眼看出属哪个 feature）
• NN：本功能内两位递增序号（每 feature 从 01 起）
• 类型：
• feat — 功能代码实现
• test — 测试编写
• doc — 文档输出
• infra — 基础设施/脚手架
• design — 设计产出

示例：功能 F20260718-094301 的任务 → T20260718-094301-01-feat、T20260718-094301-02-test

为什么 T 用「功能ID时分秒前缀 + 本地序号」而非每个任务自取时分秒：任务在拆解时成批同秒创建，若各自取独立时分秒会互相撞号。改用「所属功能的时分秒前缀 + 本功能内序号」后：既全局唯一（继承功能ID的唯一性）、又自带归属（看得出属哪个 feature）、还并行安全（不同 feature 前缀不同，同批任务靠序号区分）。任务号收敛在唯一命名的 feature 任务文件内，不跨 feature 冲突。

任务清单文件路径

docs/06_tasks/<功能ID>-<功能名>-tasks.md

示例：docs/06_tasks/F20260406-093000-user-auth-tasks.md

若功能ID未知（如独立任务），使用：docs/06_tasks/YYYYMMDD-<关键词>-tasks.md

任务清单文档格式

<!-- PDLC-TASKS -->
<!-- 功能ID: F20260406-093000 -->
<!-- 功能名称: user-auth -->
<!-- 关联PRD: docs/01_requirements/prd/F20260406-093000-user-auth-prd.md -->
<!-- 最后更新: 2026-04-06 -->

# 任务清单：user-auth（F20260406-093000）

## 总览
- 总任务数：N
- 待开始：N | 进行中：N | 已完成：N | 阻塞：N

## 任务列表

> 下例为功能 `F20260406-093000`（user-auth）的任务清单——任务ID 前缀 `20260406-093000` 即该功能ID的时分秒段，`NN` 在本功能内递增。

| 任务ID | 类型 | 描述 | 状态 | 估时 | 截止日期 | 关联文档 | 备注 |
|--------|------|------|------|------|---------|---------|------|
| T20260406-093000-01-design | design | 创建 API 设计文档 | ⬜ 待开始 | 2h | 2026-04-07 | - | - |
| T20260406-093000-02-design | design | 创建数据库设计文档 | ⬜ 待开始 | 1h | 2026-04-07 | - | - |
| T20260406-093000-03-infra | infra | 生成代码脚手架 | ⬜ 待开始 | 0.5h | 2026-04-07 | - | - |
| T20260406-093000-04-test | test | 编写单元测试 | ⬜ 待开始 | 3h | 2026-04-08 | - | - |
| T20260406-093000-05-feat | feat | 实现注册接口 | ⬜ 待开始 | 4h | 2026-04-09 | - | - |
| T20260406-093000-06-feat | feat | 实现登录接口 | ⬜ 待开始 | 2h | 2026-04-09 | - | - |
| T20260406-093000-07-test | test | 运行测试确认绿灯 | ⬜ 待开始 | 1h | 2026-04-10 | - | - |
| T20260406-093000-08-doc | doc | 创建评审记录 | ⬜ 待开始 | 1h | 2026-04-10 | - | - |

## 阻塞记录

| 任务ID | 阻塞原因 | 记录时间 | 解除时间 |
|--------|---------|---------|---------|
| （暂无） | - | - | - |

状态图标约定：

• ⬜ 待开始
• 🔄 进行中
• ✅ 已完成
• 🚫 阻塞

子命令执行流程

plan <功能名或功能ID>

前置检查：

1. 从用户输入中提取功能名称关键词或功能ID
2. 在 docs/01_requirements/prd/ 目录下搜索对应 PRD 文档
3. 未找到 PRD → 输出以下信息后立即停止，不继续执行：

   ⛔ PDLC 守卫：未找到与「<功能名>」相关的 PRD 文档。
   任务拆解必须基于已有的 PRD。请先运行：
   👉 /pdlc-prd <需求描述>

1. 找到 → 提取功能ID，读取 PRD 内容，继续执行

执行流程：

1. 读取 PRD 文档，分析功能范围、用户故事和验收标准
2. 同时检查 docs/02_design/ 下是否存在相关设计文档，有则一并读取
3. 扫描本功能的任务文件（docs/06_tasks/<功能ID>-*-tasks.md），取其中已有任务的最大序号 +1（不跨 feature 扫描）——每 feature 独立编号，并行开发不同 feature 时任务号互不干扰、合并零冲突
4. 按 PDLC 阶段顺序拆解任务：

• 设计任务（design）：需要产出的每份设计文档各一个任务
• 基础设施任务（infra）：目录初始化、脚手架生成
• 测试任务（test）：测试计划编写、测试代码编写
• 功能实现任务（feat）：每个独立接口/页面/模块各一个任务，粒度不超过半天工作量
• 文档任务（doc）：评审记录、CHANGELOG 更新

1. 为每个任务估算工时（0.5h 为最小单位）
2. 根据估时和 PDLC 阶段依赖关系，自动推算每个任务的截止日期：

• 从今日日期开始，按阶段顺序排列（设计 → 基础设施 → 测试 → 功能实现 → 文档）
• 同阶段内的任务可并行，截止日期相同
• 下一阶段的开始日期 = 上一阶段截止日期的下一个工作日
• 每日按 8h 工作量计算，超出的顺延到下一工作日

1. 在 docs/06_tasks/ 下创建任务清单文档
2. 输出任务总览表格（含预计完成时间线）

list [功能名或功能ID]

1. 有参数：在 docs/06_tasks/ 下查找对应功能的任务文件，输出该功能任务详情
2. 无参数：扫描 docs/06_tasks/ 下所有任务文件，汇总非已完成任务，按状态分组输出：

• ⏰ 已逾期（截止日期早于今日且未完成的任务，最先展示）
• 🔄 进行中
• 🚫 阻塞（含阻塞原因）
• ⬜ 待开始（按功能ID分组，仅展示最近 3 个功能）

1. 输出末尾追加整体完成率统计：完成率: X/N (XX%)
2. 若存在逾期任务，额外输出警告：⚠️ 有 N 个任务已逾期，请及时处理

start <任务ID>

1. 在 docs/06_tasks/ 下扫描所有任务文件，找到包含该任务ID的文件
2. 未找到 → 提示任务ID不存在后停止
3. 找到 → 将该任务状态从 ⬜ 待开始 / 🚫 阻塞 更新为 🔄 进行中
4. 更新文件顶部的总览计数
5. 更新文件顶部的 最后更新 时间
6. 输出确认消息：✓ 任务 <任务ID> 已标记为进行中

done <任务ID>

1. 在 docs/06_tasks/ 下扫描所有任务文件，找到包含该任务ID的文件
2. 未找到 → 提示任务ID不存在后停止
3. 找到 → 将该任务状态更新为 ✅ 已完成，在备注列填入完成时间
4. 更新文件顶部的总览计数和 最后更新 时间
5. 输出确认消息：✓ 任务 <任务ID> 已完成
6. 若该功能所有任务均已完成，额外输出：🎉 功能 <功能ID> 全部任务已完成！

blocked <任务ID> <原因>

1. 在 docs/06_tasks/ 下找到包含该任务ID的文件
2. 未找到 → 提示任务ID不存在后停止
3. 找到 → 将该任务状态更新为 🚫 阻塞，在备注列填入原因摘要
4. 在文档末尾的"阻塞记录"表格追加一行（任务ID、原因、当前时间）
5. 更新文件顶部的总览计数和 最后更新 时间
6. 输出确认消息：⚠️ 任务 <任务ID> 已标记为阻塞：<原因>

reopen <任务ID>

1. 找到包含该任务ID的文件
2. 未找到 → 提示任务ID不存在后停止
3. 找到 → 将该任务状态更新为 ⬜ 待开始，清空备注列
4. 若阻塞记录表格中有该任务，填入当前时间作为解除时间
5. 更新总览计数和 最后更新 时间
6. 输出确认消息：✓ 任务 <任务ID> 已重新打开

查看进度

/pdlc-status 不汇总任务进度；用 list 子命令查看，或直接打开 docs/06_tasks/ 下的清单。

$ARGUMENTS

状态机：本命令不写

本命令不写状态机（不碰 docs/.pdlc-state/<feature-id>.json）。任务看板不是主链路上的阶段： 一旦写入，就会把已评审、等待发布的功能改成 current_stage=task / next_step=null—— /pdlc-ship 不再把它列为可发布，循环驱动把它判成阻塞。任务进度只记在 docs/06_tasks/ 的清单里。 交接时省略「📦 状态快照」一行——本命令没有写状态机，写出来就是虚报。

<!-- @include templates/prompts/handoff.md（已内联于下方，无需另读） -->

段四：交接（Handoff）

命令完成后必须输出以下格式的最终消息：

✅ <阶段名> 完成：<主要产出物路径>
📊 自检：<通过数>/<总数> 通过（若有未通过，附要点）
📦 状态快照：docs/.pdlc-state/<feature-id>.json
👉 下一步：/pdlc-<next_step>
   （如果有分叉）或 /pdlc-<alt>（条件：<选择依据>）

规则：

• 主流程命令（写状态机的命令；下一跳见正文里「本命令的状态机取值」）必须显式输出"下一步"，不可省略
• 工具型命令（Layer 3）可以没有 next_step，此时输出 👉 下一步：（本次流程结束，无后续）
• 分叉场景必须说明选择条件，例如"若需补充测试用例 → /pdlc-tdd；若测试已齐 → /pdlc-review"

<!-- @include-end templates/prompts/handoff.md -->