一个计划是一组按顺序排列、被归入不同阶段的任务集合。在编写代码前，您需要先对其进行审批。
当工作涉及多个需按特定顺序执行的变更，或者您希望在确定任何内容前先了解整体方案时，可使用计划功能。
生命周期
规划本身是一个独立阶段，并非瞬间完成的转换过程。
- **规划启动。**架构师会梳理代码库并起草各阶段及任务。
- **您会对草稿进行评审。**这是整个系统中成本最低的干预节点。
- **审批、修改或重置。**审批后计划即可执行；修改会将计划退回给您反馈；重置则会重新开始规划流程。
- **执行。**任务会按照顺序执行，同时遵循阶段边界要求。
您可以一步完成审批和执行，也可以先审批再稍后启动执行。
优先选择修改而非重置
当计划接近符合要求时，修改操作能保留架构师对代码库的认知成果，并融入您的反馈。重置则会丢弃已有成果并重新起步。
若整体方案有误才需重置；若方案正确但细节有待完善则应选择修改。修改的成本更低，且被驳回的计划内容不会丢失——它会成为下一次尝试的输入依据。
控制正在运行的计划
正在执行的计划可以暂停、恢复或取消，您还能查看各阶段的进度。计划也可被克隆，这是复用已验证结构的高效方式——比如将某迁移方案应用到第二个服务中。
已完成的计划可被归档，以保持主视图的清晰性。
一个 pull request，而非每个任务对应一个
计划的各任务不会各自生成独立的 pull request。它们会在各自的分支上工作，最终合并到共享的分支车道；当相关工作满足条件时，该分支会被合并为针对基准分支的单个拉取请求。
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘这样一来，你只需审核一次整合后的功能，即可看到全部变更内容，无需逐个审批未完成的阶段。
跨项目计划属于特殊情况：若某个任务所属的项目与分支车道对应的项目不同，该任务会单独被合并，因此每个代码仓库会对应一个pull request。一个pull request无法跨越两个代码仓库。
阶段与并行处理
阶段体现的是顺序要求，而非并发执行。若资源允许，同一阶段内的任务可并行运行；下一阶段需等待当前阶段完成。
即便一个计划包含十个可并行执行的任务，且只有一个代理插槽，这些任务仍会依次运行。结构本身并不会创造处理能力——详见处理能力与代理插槽.
选择计划还是任务？
你可以自行决定，只需在路由步骤中选择分阶段工作计划或单个可执行任务即可。没有任何组件会分析你的需求并替你做决定。
判断标准是可读性：同事能一次性读完的pull request属于任务；需要多个有序变更的则属于计划。
针对规模较大的工作误判为任务的风险更高——任务在执行中途可能会超出范围，导致资源浪费；而误判为计划只会让你多走一道不必要的审批流程。
交付关卡
计划可设置交付关卡，用以规定其输出成果推进前必须满足的条件。详见质量关卡.