writing-plans

编写计划

计划请求仅授权创建或修订计划文档，不授权实施。 仅当用户提出要求或当前工作流已授权相关工作时，才执行计划。

以计划为依据

提问前，先检查相关的代码库证据。 如果继续执行需要冒险猜测，最多提一个问题；否则只说明会影响执行或验证的假设和未知事项。

除非用户要求仅在聊天中输出，否则将草拟的计划保存到代码库。 默认使用 docs/plans/YYYY-MM-DD_<topic>-plan.md，主题采用简洁的小写 kebab-case 格式；执行期间在原有计划文件中更新。

规划结构

始终包含 Goal、Plan 和 Completion Checklist。 仅添加以下列表中有用的可选部分：

## Context
## Architecture
## Tech Stack
## Non-Goals
## Assumptions
## Unknowns
## Risks
## Rollback / Recovery

对于系统边界、所有权、数据流、API、状态、权限、存储或部署，使用 Architecture。 对于工具、运行时和包的选择，使用 Tech Stack。 对于生产数据、迁移、基础设施、发布或公共 API，包含 Rollback / Recovery。

编写可执行任务

使用 Markdown 复选框，每项任务都明确说明一个操作、操作对象、预期结果和验收依据。

- [ ] Update `src/auth.ts` to reject expired tokens; verify with `npm test -- auth`.

按依赖关系排列任务，并将重要未知事项转化为前期探索任务。 避免使用含糊、捆绑多个事项或无明确终点的任务，例如“提升质量”“处理边缘情况”或“永久监控”。 以有限的完成检查收尾，并将其与文件、命令、测试、审查或部署状态，或明确的用户验收挂钩。

执行并跟踪

• 仅在验收方法通过后勾选任务。
• 如果完成情况无法从代码库状态中明确看出，请添加简洁的证据。
• 未通过或无法执行的检查保持未勾选；将不适用的任务标记为 - [x] Not applicable: <reason>。
• 如果后续工作使证据失效，请重新打开任务。
• 仅跟踪当前已保存的计划，不要检查或修改无关计划。
• 如果计划仅在聊天中提供，请在聊天中展示更新后的复选框和证据。

仅当所有任务和完成检查均已勾选、重要未知事项已解决或获认可、风险已有明确处置方案，且所需的交接或发布工作已完成时，才声明完成。 不得仅凭实施已完成就推断整体完成。

删除已完成的计划

完全执行已保存的计划后，将其删除，然后报告已删除的路径。 不得删除仅在聊天中提供的计划，也不得删除缺少完成证据的计划。