woostack-plan

woostack-plan

woostack-plan 是完整的规划工作流，也是唯一可直接发布 GitHub issue 的技能。若有相关源代码，则使用这些代码；如果是新项目，则使用提供的目标、约束和研究结果。它只敲定尚未解决且会产生实质影响的决策，并产出可供审查的增量。只有在用户提出要求时，才会将计划创建为 issue。规划无需检出代码、模板、先前阶段或额外审批；只读限制由 边界 规定。

命令

/woostack-plan <goal-or-partial-issue>
/woostack-plan <goal-or-partial-issue> --project <exact canonical GitHub Project URL>

--project 是唯一显式的目标选择器，用于指定用户希望在现有 Project 中跟踪的计划。未提供时，目标由请求和实际上下文决定。

工作流

1. 明确请求和相关上下文。 阅读目标或部分 issue 以及提供的约束。若存在且与请求有关，则检查代码检出内容和远程仓库，以及用户指定的任何 issue 或 Project。仅规划既不需要源代码，也不需要 GitHub 目标。发布前，必须明确唯一一个获授权的仓库和目标；绝不可根据标题、活动、惯例或未选定的默认项进行猜测。 GitHub 发布流程 负责确定目标并进行能力预检。
2. 检查相关依据。 若有源代码，则阅读范围受限的文件、测试、配置、文档和已知的相关 issue。否则，使用提供的需求和权威研究来决定有实质影响的技术选型；不要为了规划而创建代码检出。区分已观察到的架构、接口、命令和惯例与提议的内容。根据最少代码原则，检查复用或安全删除是否已能满足请求。
3. 找出尚未解决且有意义的决策。 只询问会改变结果的决策：产品行为、破坏兼容性、安全或数据边界、不可逆影响、成本和范围。对于符合请求结果的常规技术细节，直接补全，并说明补全了哪些内容。绝不凭空设置审批流程，绝不重复询问用户已做出的决定，也绝不默默推翻用户明确作出的选择。对于尚未确定的技术选型，只考虑能区分可行选项的需求：运行时、延迟和离线需求，托管和运维责任，数据一致性和恢复，隐私和身份验证，集成、预算和团队熟悉程度。通过当前权威来源研究方案适配性、兼容性，以及有实质影响的成本或锁定取舍。复用已提供且可行的技术栈；不设默认技术栈、问卷或完整设计门槛。
4. 制定连贯的计划。 将完整目标和实际依赖关系划分为小型、连贯且可验证的增量。每个增量都应产生一种可观察的行为，或解决一个影响重大的不确定性，并明确限定范围、非目标以及相关的现有依据或有具体理由的依据。只保留那些会影响决策的理由，用以说明为何更小的步骤不足以实现目标。实施检查点、任务分配、issue、PR 和发布属于不同的边界：检查点可以留在同一个 issue 或计划内，无需新增执行者或发布对象。保留不可分割的变更、受支持的兼容性义务和原子切换；不要仅为拆分交付而臆造临时过渡方案。在对话中报告计划；后续如何处理由用户决定。
5. 按请求创建 issue。“创建 issue”、“创建 GitHub issue”和“发布此计划”本身就是发布授权；无需单独审批。仅请求规划时，不写入任何内容，直接返回计划。

问题包含什么

每个问题都会说明它要实现的结果、重要约束、不在范围内的内容、定义完成标准的验收与验证预期，以及实际前置条件。这是最低要求，不是固定模板：不需要任务键、序号、标记块、父项选择策略或必需的章节顺序。尽可能注明现有文件、符号和接口，或问题结果将创建的拟议接口，方便初次阅读的人找到相关工作。对于已有负责方的约束，应链接到相关内容，而不是复制；阅读这些参考资料不会触发任何实现工作流，也不授权任何实现工作：

• 跨越应用边界的结果应遵循 应用边界适配器规则；
• 新编写的验证预期应遵循附带的 测试指南：关注可观察的契约和不同的缺口，而不是一揽子测试套件或配额。优先使用现有且充分的检查；针对已说明的要求或明确指出的重大风险，提出额外证据。区分完成标准与草案发布、使用方发布门槛，并将新的验证基础设施标明为拟议范围。不要改写现有无关问题的验收标准。

在将命令或路径写入问题之前，先核实其有效性——它必须已存在于仓库中，或由该问题或其某个前置条件创建。规划记录预期，不会运行这些预期，也不会声称它们已通过。

发布与回读

发布会将实现检查点归纳为连贯的问题结果，并复用现有问题；不会为每个检查点都创建一个问题，也不会规定每个问题对应一个 PR。仅通过主机授权的 GitHub 功能，按请求写入所要求的关系，并遵循 GitHub 配置文件； 绝不读取凭据、转发令牌或添加自定义传输方式。独立回读每个受影响的问题及其关系；仅凭变更响应无法证明任何内容。

发布流程负责确定目标、预先检查功能、复用现有问题、保留创建身份以便在响应丢失时恢复且不生成副本，以及使用可读索引代替主机无法写入的原生关系。未创建的必需原生关系仍属未完成，Plan 应如实说明，而不是声称已发布。明确选择 Project 后，会将已发布的问题加入该 Project；不会创建 Project，也不会在没有单独请求的情况下更改 Status、生命周期或验收状态。

边界

除请求授权的问题发布外，规划过程始终只读。Plan 不编辑实现源代码，不创建分支、工作树、提交或 PR，不派发实现或编排工作，也不合并任何内容。它保留人工编写的内容、现有问题身份及无关的问题、标签和历史记录：只编辑问题中承载计划的部分，其余部分保持不变。它绝不关闭、重新打开或重新分配任何内容，也绝不声称已实现、已交付、检查已通过、产品已验收或已合并。

返回内容

返回计划——增量、结果、约束、验收标准和实际前置条件——并附上已确定的仓库和目标、检查过的来源或研究、已补全的决策，以及仍未解决的问题。发布后，补充实际问题 URL、哪些内容是复用的、哪些是新建的、回读结果、写入的关系，以及任何仍未完成的事项。如果用户需要编排提示，应将其作为单独的建议：

/woostack-orchestrate --issue <verified canonical issue or tracker URL>
/woostack-orchestrate --project <verified canonical Project URL>

该提示不是派发指令。Orchestrate 会根据找到的问题自行读取并安排顺序。