tech-plan

name	tech-plan
description	根据需求和问答记录生成技术方案文档。在 dev-flow 流程的第 4 步自动加载。
version	2.1.0

技术方案 · 输出格式

你的任务

为每个任务生成 计划.md 技术方案文档，写入输出目录。方案要行为化：描述系统应该做什么，而不是怎么做。

输出格式

参考以下模板生成每个任务的 计划.md：

# <任务名称>（IDxxxxxxx）· 计划

> 父需求：<所属大需求> ｜ 负责人：<人名>
> 依赖：<关键依赖说明>

## 目标
<1-3 句话说清楚这个任务要做什么，用行为化描述>

## 验收标准
- [ ] <具体、可测试的条目 1>
- [ ] <具体、可测试的条目 2>
- [ ] <具体、可测试的条目 3>
<!-- 若需求含视觉规格（PRD 截图/原型已定死位置或文案），逐条列为可勾选项，照图写死。以下为示例，按本需求替换或删除： -->
<!-- - [ ] <字段>折进已有列<列名>作为第 N 行，不新建独立列 -->
<!-- - [ ] <按钮>文案精确为<原文>，位于<页签>工具栏、紧挨<相邻按钮> -->
<!-- - [ ] <筛选A><筛选B>与现有筛选并列 -->

## 任务拆解
1. **<子任务 1 名称>**（`<涉及的模块/接口>`）：<行为描述>
   - 实现要点：<关键逻辑，用接口/类型描述，不写文件路径>
2. **<子任务 2 名称>**（`<涉及的模块/接口>`）：<行为描述>
   - 实现要点：<关键逻辑>

## 边界 / 依赖
- **不做的事（作用域外）**：
  - <明确列出不实现的功能>
- **外部依赖**：
  - <依赖的接口/表/配置>
- **需要配合的事项**：
  - <需要其他人做的事>

## 待确认
- <仅列 PRD 图与正文都未给出的开放项>

> 判定（图已定 vs 真待确认）：位置/文案凡 PRD 图或正文已给出，一律按图写进验收标准，不进本节；只有两处都没写才算真待确认。

## 状态：进行中

格式要求

1. 行为化描述：目标和验收标准描述系统应该做什么，不描述实现过程

   • ✅ 好例子："运行 npm test 时，所有关于用户偏好的测试通过"
   • ❌ 坏例子："代码要写好"
   • ✅ 好例子："接口返回 { preferences: Preference[] }，空数组表示无偏好"
   • ❌ 坏例子："在 src/api/user.ts 第 42 行加一个函数"

2. 避免写死文件路径和行号：任务拆解用模块名/接口名描述，不用具体路径

   • 文件路径会随重构过时，接口描述更稳定
   • 如果某段代码精确到无法用文字描述（如状态机、Schema），可以内联代码片段并注明"来自原型"

3. 视觉规格按图写死：需求含 PRD 截图/原型时，把其中已定死的元素（视觉规格五要素：列归属/合并、按钮精确文案、所在页签、筛选位置、字段顺序）逐条写进验收标准，文案与页签名照抄 PRD 图，不自拟

   • 这与「避免写死文件路径」不冲突：路径是会过时的实现细节，UI 位置/文案是需求本身

4. 验收标准要具体可测：每条标准独立可验证

   • ✅ 好例子："空输入时，接口返回 400 并包含 message: '不能为空'"
   • ❌ 坏例子："错误处理要正确"

5. 作用域外要明确：防止执行时越界

   • 列出"不做什么"和"不在本次范围"的事项

6. 头部署名：头部「负责人」取第 0 步解析出的个人标识（person）

7. 状态：初始为「进行中」，完成后改为「已完成（详见 ../总结.md）」

写入规则

• 文件路径：<session_dir>/<任务简称_ID>/计划.md
• 任务简称从 PRD 中提取，不超过 10 个字
• 目录不存在时自动创建
• 编码：UTF-8

注意事项

• 方案要基于 QA 记录中的结论，不要和 QA 矛盾
• 涉及数据库变更的，Schema 描述可以用代码片段内联（这是允许的例外）
• 涉及接口变更的，接口形状用代码片段描述（也是允许的例外）
• 如果发现方案有困难，主动和用户沟通调整
• 写完后用 AskUserQuestion 向用户确认方案