计划树
将该技能作为持久项目方向、执行准备、进度状态和Markdown规划树的工作流权威。它跨会话和代理保留用户的意图、现有文档风格、推理轨迹以及从计划到落地的证据。
必需的操作模式
对于每个计划树任务，在编辑或实现前确定工作模式。
- 如果模式不明确，默认选择
clarify或ready-check，而不是execute-ready。 - 当存在现有计划树状态时，在改变方向之前检查相关的入口点和当前计划状态。
- 在解决方案足够成熟以实现之前，保持规划和澄清模式。将用户的意图扩展为目标、非目标、约束、选项、权衡、风险、依赖、验收标准、验证路径以及部署或回滚说明。
- 当关于范围、方法、受影响面、预期行为、验收标准、验证路径或风险的核心歧义仍然存在时，不要在主要项目表面开始正式实现。
- 仅当一个小型、隔离的原型或样本可以验证方向并且保持与生产路径明显分离时，才允许创建。
- 仅当执行不应依赖“边写代码边弄清楚”来做核心决策时，计划才算实现就绪。
- 实现落地后，更新计划树状态、落地证据、决策、未解决问题和交接说明，以便实现项目回映到持久的计划状态。
工作模式
在任务开始时选择一种主要模式，仅在状态发生变化时进行转换。
clarify：意图、范围、约束、成功标准或权衡不明确。进行讨论，必要时提出有针对性的问题，并在计划树文件中记录持久的澄清结果。不要编辑主项目实现文件。shape-plan：方向大致已知，但需要具体的解决方案映射。创建或更新路线图项、主题、假设、决策、风险、验收标准和未解决问题。ready-check：用户想要实现或继续，但准备情况不确定。评估范围、方法、受影响面、验收标准、验证和风险是否足够明确。如果不是，则返回clarify或shape-plan。resume：从先前的工作继续。读取根入口点、相关基线、目标计划README、实现状态、路线图以及仅活跃的链接文件。在编辑前总结当前阶段、活跃的TODO、阻碍项、下一个目标和最后一次验证。execute-ready：计划已足够就绪以实现。仅在约定范围内修改项目文件，然后更新计划树状态和证据。status-update：在工作或审查后更新路线图状态、实现状态、“最后落地”、“下一个目标”、“阻碍项”、“交接”或“规划注册表”。archive：将已取代的细节、旧的状态快照、已接受的证据或仅供参考的材料移出活跃文件，同时保留检索链接。normalize：重组现有的计划树或超大的混合角色源文件，使其成为更小的检索单元。首先创建或更新indexes/migration-map.md或最近的可用索引，然后按检索角色对源材料进行分类，创建简短胶囊和读者任务细节碎片，将已接受的验证移至evidence/，并将旧的状态或推理论述移至history/，除非明确批准，否则不删除源材料。audit或migrate：检查一致性、检索、漂移、遗留根目录或迁移映射。默认只读，除非用户要求修复、规范化或迁移。
在这些模式下内部进行文档操作，如 idea、promote、question 和 decision：
idea：将低承诺的想法添加到ideas/inbox.md或本地等效文件中。promote：将想法提升为路线图项、主题、未解决问题或决策，并链接原始想法。question：添加、缩小或解决一个未解决的问题。decision：创建或更新一个稳定的决策记录。
核心工作流
对于每个计划树任务：
- 选择工作模式和允许的写入范围：无、仅计划树、隔离原型或项目文件加计划树更新。
- 识别计划树根目录、目标计划根目录和用户意图。
- 读取根索引以及仅相关的路线图、状态、主题、决策、问题、想法、历史或基线文件。
- 保留现有的入口点、注册的根目录、文件夹名称、文档风格和权限顺序，除非任务明确要求重新组织它们。
- 保持活跃的路线图、交接和主题胶囊文件简短；将细节、证据和历史移出活跃状态。
- 在添加、移动、提升、归档或拆分持久文件时，更新索引、检索标题和链接。
- 在回复前进行最终检查。
- 报告更改的文件、未解决的问题、活跃模式以及在相关时建议的下一个有用的维护操作。
默认文件系统
使用 docs/plantree/ 作为计划树管理材料的跨项目默认文件系统。它是计划树系统根目录和注册表，而不是单个计划根目录；该名称避免了与提供者原生或框架原生的 plans/ 文件夹冲突。
默认结构：
docs/plantree/README.md：注册表、权限顺序、基线链接、活跃计划表以及如何阅读树。docs/plantree/baseline/：项目范围的上下文，如模块图、运行时流程、状态/存储边界、测试/发布门禁和风险热点。docs/plantree/plans/<NNN>-<plan-name>/：具有稳定数字排序、路线图/状态、主题、决策、未解决问题、证据、索引的可选历史的特定计划根目录（当项目没有既定命名约定时）。docs/plantree/ideas/inbox.md：低承诺的想法收件箱。
发现顺序：
- 当提供时，使用显式用户路径。
- 否则当
docs/plantree/README.md存在时，使用docs/plantree/。 - 否则为当前任务保留另一个明显活跃的既定树；仅当用户要求采用、规范化或迁移时才评估迁移。
- 否则在创建或更新计划之前启动
docs/plantree/。
当没有本地约定时，新的特定计划默认为 docs/plantree/plans/<NNN>-<plan-name>/，必须在 docs/plantree/README.md 中注册，并且应链接到相关的基线文件，而不是复制全局上下文。除非用户明确批准迁移，否则保留未编号或不同组织的既定树。
首次使用
当在一个没有 docs/plantree/ 的项目中调用计划树任务时，除非用户明确要求不创建文件，否则创建一个最小的根目录。
启动：
- 根目录：
docs/plantree/README.md - 基线：
baseline/README.md、module-map.md、runtime-flows.md、storage-and-state.md、test-and-release-gates.md、risk-hotspots.md - 容器：
plans/、ideas/inbox.md
保持启动内容轻量且基于证据。如果没有检查足够的代码，请编写 未知 / 需要盘点，而不是编造项目事实。对于旧的或不熟悉的项目，在创建详细计划之前先构建或刷新基线。
计划模型
在创建或维护计划根目录时使用这些角色，并根据本地约定调整名称：
README.md：范围、权限、文件映射、阅读路径以及（当它是计划树根目录时）活跃注册表。对于活跃计划表，当使用轻量级ID时，优先使用ID | 计划 | 受影响的模块 | 状态 | 当前阶段 | 最后落地 | 下一个目标。roadmap.md：按已完成、进行中、下一步和推迟分组的持久状态，除非树已经使用其他模型。implementation-status.md：仅针对进行中计划的简短操作交接。计划中或推迟的计划通常不需要此文件。open-questions.md：仅未解决的问题。topics/：持久上下文、解决方案映射、选项、约束、验收标准、实现说明、仓库卫生计划和风险分析。保持顶层主题文件为简短胶囊；将大型主题拆分为包含细节碎片的主题文件夹。decisions/：稳定的决策，当集合增长时进行索引。evidence/：当前或已接受的验证记录、审查结果、工件注释以及证据索引（当这些需要独立于历史进行检索时）。history/：已接受的检查点日志、旧审查、已淘汰的快照、仅供存档的源说明和已取代的细节。indexes/：可选的检索映射，如阶段映射、主题映射、权限映射、迁移映射和证据映射（当本地索引解决导航问题时）。ideas/：可选的低承诺想法池（当根级别的想法不够具体时）。
在创建模板、处理大型树、维护决策/状态/交接/历史/索引文件、添加仓库卫生计划或需要详细的最终检查清单时，请阅读 references/maintenance-patterns.md。
轻量级ID和模块分类
当项目没有既定的计划命名约定时，使用轻量级ID来改善文件系统扫描和持久引用，而无需创建任务数据库：
- 在项目范围内分配计划ID，如
P001、P002等。将P001映射到诸如docs/plantree/plans/001-authentication/之类的平面根目录。 - 使用固定宽度的三位十进制数字。分配最大保留计划编号加 1；绝不重复使用ID、通过重新编号来关闭间隙或编码优先级、状态、模块、所有者、工作者、阶段或日期。
- 保持语义片段稳定且为小写kebab-case。标题或受影响的模块可能会在不更改计划ID或目录的情况下发生变化。
- 当计划注册表较小时，将标识和生命周期注册保留在
docs/plantree/README.md中。仅当这改善检索时才将其拆分为索引；默认不维护并行的分配分类账。 - 路线图任务ID（如
T001）是可选的，且限于计划本地。仅当稳定的跨文件引用有帮助时才使用它们。当使用时，roadmap.md是任务标识、状态和顺序的唯一活跃权威；默认不创建单独的任务注册表或任务文件夹。 - 决策文件名可以保留
001-<decision>.md约定。当持久引用有帮助时，未解决问题可能使用Q001。想法在提升前保持未编号状态。 - 将代码或产品模块视为计划元数据，如
受影响的模块，使用在baseline/module-map.md中定义的稳定键。默认保持计划根目录平面；仅在经过演示的导航需求和记录的决策后添加模块索引或物理模块目录。 - 应用同变更一致性：在一次维护变更中更新权威文件和任何必需的入口点摘要，然后在完成前检查ID、路径、模块键、路线图唯一性、状态声明和相对链接。
- 优先选择只读漂移检测，而不是自动修复。在观察到的协调失败证明其成本合理之前，不要添加观察者、自动重新编号、分配锁定或恢复日志。
这些默认值是渐进的。保留成熟树的本地ID、问题、工单或文件夹约定，而不是在之上分层一个相互竞争的名称空间。
动态状态和证据
- 只有
进行中的计划需要implementation-status.md；计划中的计划应在roadmap.md、主题、未解决问题或决策中表达准备状态。 - 保持
implementation-status.md具有操作性和简短性。最好少于 100 行；如果增长，则归档或索引旧细节。 - 将
活跃 TODO限制为最多五个当前项目。更多项目通常意味着工作需要路线图阶段、主题或拆分。 - 当使用路线图任务ID时，在
活跃 TODO中重用这些ID，而不是在第二个注册表中重述任务标识。 - 在适用时包含具体的
当前阶段、下一个目标、最后落地、活跃 TODO、被阻塞于和最后验证或交接说明。 最后落地应指向一个提交、工件、测试结果、已接受的检查点或其他证据，并尽可能附带日期。- 对于阶段/包/门级别的证据，使用
evidence/README.md、indexes/evidence-map.md或本地等效文件。仅将history/evidence-index.md用于已取代的证据档案。不要在那里记录每一个小步骤。 - 活跃的路线图/状态文件应链接到旧证据，而不是吸收重复的日志、旧的自动化输出、审查作业细节或历史叙述。
检索模型
计划树是一个检索单元系统，而不是一个存放大型综合文档的地方。每个持久文件应有一个主要角色：
- 入口点或索引：路由、权限顺序、阅读路径和一行摘要。
- 当前状态：活跃的路线图、当前阶段、阻碍项、下一个目标和交接。
- 主题胶囊：一个领域、功能、约束集或工作流的简短摘要，并链接到细节碎片。
- 细节碎片：为一个读者任务提供的合同、备选方案、边缘情况、实现说明、部署、操作、准备或仓库卫生细节。
- 决策：具有上下文和后果的稳定选择。
- 证据：验证记录、审查结果、工件链接、已接受的测试摘要或证据索引。
- 历史/存档：已取代的状态、旧的执行日志、迁移的源材料和已淘汰的细节。
不要让一个文件同时承载摘要、活跃状态、决策、长推理、日志、证据和历史。如果一个更新会使文件跨越其角色边界，请先创建或更新一个链接的检索单元，然后在活跃文件中仅保留简洁的摘要和链接。
使用以下行数作为拆分触发点，而不是硬性正确性测试：
- 根README、计划README、路线图和实现状态：保持在 150 行或以下。
- 主题胶囊：保持在 250 行或以下。
- 普通细节碎片：在约 400 行时拆分或索引。
- 历史或证据文件：在约 500 行时索引或拆分。
拆分时...
[为翻译的目的而截断]