AI 的 plan 功能只管"下一步做什么"，不管"为什么这么做"
哪些方案被排除了、为什么选了这条路——全靠记忆
没有记录，同样的决策反复推翻，项目越推进越模糊
新 session 开始时，没人知道上次停在哪里、下一步该做什么
Plan Tree 是一个通用的 AI planning skill，把短期 plans 变成结构化的 Markdown 规划树，让项目跨会话、跨 agent 推进时不漂移。
过去和现在的工作重心发生了根本性变化：
这个比例不是精确工时，而是工作重心变化：质量越来越取决于前置方案是否充分、边界是否稳定、验收是否清楚、状态源是否统一。
项目状态分为 Done / In Progress / Next / Deferred 四个区域，一眼看清当前阶段。
当前交接、活跃 TODO、blockers——新 session 从这里恢复上下文。
为什么这么选、后果是什么——决策一旦记录就不再凭空蒸发。
只放真正没解决的问题，已决问题移到 Decisions，绝不混用。
约束、选项、验收标准——围绕一个主题的完整上下文。
旧验证、检查点、过期材料——归档但不删除，保留推理轨迹。
低承诺的想法，不被当作需求——成熟后才 promote 到正式节点。
从灵感到归档，信息在规划树中的完整流动路径：
一个新想法被放入 ideas/inbox.md，此时它没有任何承诺。
想法成熟后，从 ideas 移到 roadmap.md 的 Next 列，标记为已 promote。
开始实施时，更新 roadmap 状态，创建 implementation-status.md。
代码提交、测试通过、验证完成——这些都是"证据"。
只有当 artifact 存在时，才在 roadmap 标记为 Done。
归档而非删除——保留推理轨迹，保持活跃文件短小。
用户的每一个请求都会被分类到对应的意图路由：
| 意图 | 含义 |
|---|---|
| idea | 添加低承诺想法到 ideas/inbox.md |
| promote | 把想法提升为 roadmap 项、topic 或 decision |
| status | 更新 roadmap 或实施/交接状态 |
| question | 添加、缩小或解决一个未决问题 |
| decision | 创建或更新稳定决策记录 |
| archive | 把过期证据移出活跃文件 |
| audit | 一致性、检索和漂移检查 |
| resume | 恢复上下文：当前阶段、TODO、blockers |
| migrate | 评估或迁移旧规划树 |
看看各组件如何"对话"：
plan-tree 的默认文件布局——每个文件都有明确的角色：
plan-tree 按以下优先级寻找规划树入口：
用那个路径，最高优先级。
使用它作为入口——这是默认位置。
保留它，评估是否需要迁移——不要强行替换。
引导创建 docs/plantree/，从零开始建立规划树。
plan-tree 是代码演化的意图空间和控制平面。代码库是实现空间；规划树是意图、约束、评价和投影空间。
大部分实现变化都应该能投影回 plan：Done、Blocked、Risk reduced、Decision changed 或 Question opened。长期没有投影回 plan 的变化，就会变成不可见的漂移。
不靠感觉，靠证据。代码提交了？测试通过了？验证完成了？没有证据就不能标 Done。
保留推理轨迹——把旧证据移到 history/，而不是删掉。未来的你可能需要知道"当初为什么这么做"。
bridge before move——不要一步到位。先注册、桥接旧规划树，再逐步迁移。
只放未解决问题。已决问题移到 Decisions，待办事项放在 Status——不要混用。
Plan 的漂移更容易看见——这正是 plan-tree 的价值：让不可见的东西变得可见。程序还能跑、测试还能过，但模块职责变宽、抽象不再贴合——代码漂移更隐蔽。
新 session 开始时，按以下顺序恢复上下文：
找到规划树入口和注册的 plan roots。
了解项目级上下文：模块地图、运行时流程、风险热点。
明确当前 plan 的范围和阅读路径。
获取活跃 TODO、blockers、上次验证。
当前处于哪个阶段、下一步是什么。
不要全读，只读与当前任务相关的。
当前阶段、活跃 TODO、blockers、下一步、上次验证。
每次编辑或审计后，确认以下各项：