plan

name	plan
description	在 ohmyflight 仓库内编写和执行单文件 plan.md。适用于中大型开发、跨模块重构、生产级验收、工具下线、测试结构整理、架构硬化、恢复演练、评测闭环，以及任何不能靠一次小补丁完成的任务；要求把 plan.md 写成需求、事实、失败测试、目标、设计、任务、验证和收口合一的执行合同。

Plan

plan.md 是本仓库中大型任务的单文件执行合同。

它不是草稿，不是聊天纪要，不是只给 agent 自己看的 todo。它同时承担需求文档、当前事实、失败测试、目标、设计、实施任务、验证计划和收口记录。

触发后先做

• 先读根目录 AGENTS.md。
• 涉及代码、测试、spec、构建时，同时读 .agents/skills/ohmyflight-dev/SKILL.md。
• 如果根目录已有 plan.md，先判断它是否属于当前任务；属于则更新，不属于则询问或明确覆盖理由。
• 如果没有 plan.md，以根目录 plan.example.md 为模板创建。
• 写完或更新 plan.md 后再做大改；执行中事实推翻计划时，先更新 plan.md 再继续。

必须保持的边界

• 一个任务只维护一个根目录 plan.md，除非 owner 明确要求多文档。
• 用户输入是线索，不直接写成结论；当前代码、spec、测试、命令输出和用户明确事实才是依据。
• 明确区分已确认事实、用户提供事实、未验证推测、计划事项、已完成并验证事项。
• 文档只写当前事实，不写历史过程、未来计划或未经验证的猜测。
• 不做旧兼容、假过渡、历史残留说明，除非当前任务明确要求。
• checklist 必须随进度更新，不能到最后一次性全勾。

plan.md 标准结构

必须按下面顺序写：

# [任务名] Plan

## 1. 需求文档

## 2. 当前事实

## 3. 失败测试

## 4. 目标

## 5. 不做范围

## 6. 设计

## 7. 实施任务

## 8. 验证计划

## 9. 收口

各章节要求

需求文档 写给 owner 看，说明要解决的实际问题、使用者、体验、范围和业务完成标准；不写实现细节。

当前事实 只写已核实内容，覆盖代码、测试、文档、配置、命令输出、已有能力、缺口和未知点。

失败测试 写清什么会失败，优先自动测试；不能自动化时写静态检查或手动验证路径。

目标 写可观察、可验证、可判定完成或失败的结果。

不做范围 服务边界清晰，不作为逃避交付的借口。

设计 写输入、判断、状态、执行、输出、记录的主链路；模块边界；文件职责；状态归属；数据或事件流；错误、恢复、中断、重试边界；测试和文档影响。

实施任务 是可执行 checklist，每项必须能判断完成或未完成。

验证计划 必须包含相关局部测试、完整验证命令、构建或安装检查、页面/工具入口检查、文档同步检查、未验证内容和剩余风险。

收口 只在任务完成时更新，写目标是否完成、失败测试是否变绿、改了什么、跑了什么验证、未验证内容、剩余风险、是否 commit/push。

完成标准

• plan.md 能让 owner 读懂需求和边界。
• 开发者能按设计和任务继续执行。
• 验证者能按验证计划判断完成。
• 收口记录真实反映已完成和已验证事项。
• plan.example.md 只作为模板，不替代当前任务的 plan.md。