Coroid 包含四种工作单元。它们可以相互嵌套，选择恰当的单元主要取决于工作的规模以及需要同时执行的工作量。
| 单元 | 规模 | 结束时间 |
|---|---|---|
| 任务 | 一项变更 | 一个 pull request |
| 计划 | 分阶段实现的功能 | 整个计划对应一个 pull request |
| 迭代 | 一段时间内的工作块 | 无论这些任务产出什么内容 |
| 通道 | 并行工作流程 | 计划工作所集成到的分支 |
迭代 · 两周
阶段 1
任务支付表单任务卡片验证阶段 2
任务订单摘要独立任务
任务修复日期解析问题任务
最基本的单元。一个任务是一个可产出单个 pull request 的工作单元，也是实际被执行的内容——计划、迭代和通道都是组织任务的方式。
如果你能用一段话描述出结果，且审核人员能一次性读完相关内容，那它就是一个任务。
计划
当工作需要按特定顺序进行多次变更时，就会形成计划：即按阶段分组的有序任务集合，在编写任何代码前需先获得审批。
以下情况可使用计划：
- 后续步骤依赖前期步骤的输出
- 你想在确定实施方案前先了解整体思路
- 该项工作是功能开发而非简单变更
审批计划是系统中成本最低的干预节点。在此阶段否决方案仅需花费一分钟；若三个任务执行完毕后再否决，则需重复三次操作。
计划如何进入你的代码库
计划的各任务不会分别生成单独的 pull request。它们会在各自的分支上工作，然后合并到共享的通道分支，该分支会被提升为针对你的基准分支的单个拉取请求。
分支通道
计划工作的整合位置
一个 pull request
整合后的功能，经一次审核
main
您的基础分支
若任务所属项目与分支通道所在项目不同，则该任务会独立推送，此时跨项目计划会在每个代码库中生成一个 pull request。
因此你只需审核一次整合后的完整功能，无需逐个审核未完成的阶段。
例外情况是跨多个项目的工作：属于不同项目的任务会在各自的通道中推进，因此跨项目计划会为每个代码库生成单独的 pull request。这是不可避免的——一个 pull request 无法跨越两个代码库。
迭代
迭代是限定时间的工作容器，拥有独立的指标和时间线。迭代用于回答“本周期内我们要做什么、进展如何”，而非“该功能如何构建”。
当你需要协调团队在一定周期内的工作时可使用迭代；分解单个功能时使用计划。二者并非互斥选项——一个迭代可包含属于多个计划的任务。
通道
通道是计划并行工作的集成位置。任务以通道的分支为目标，而非你的基准分支，因此多个智能体可同时推进而不会发生冲突，一旦符合条件，整合后的结果就会被提升为单个 pull request。
计划关注的是顺序，通道关注的是并发和集成。如果你有充足的智能体资源且工作无需严格串行执行，通道就能让它们协同运行，最终仍输出为可审核的单一变更。
如何选择
关键不在于你想要多少个拉取请求——任务和计划最终都会生成一个拉取请求。关键在于结果值得审核前需要完成多少工作量。
- 这项变更是否能让审核人员一次性读完？是 → 任务。
- 它是否需要按顺序进行多次变更才能形成完整的功能？是 → 计划。其通道会在允许的情况下并行处理各部分工作。
迭代作为规划和报告层，与上述机制并行运作。
版本发布的定位
一个版本发布是集成后的交付记录，并非另一项任务、计划、迭代或工作流。它会锁定代码库的提交记录，确认计划内的工作已包含在该提交中，并跟踪各环境下的部署尝试情况。一个版本发布可能包含多个迭代的工作；一个迭代也可能生成多个版本发布。工作流升级会触发一个 pull request，但本身并不会生成经过验证的交付成果。
同时运行数量的限制因素
并非结构问题，而是容量限制。一个包含十个可并行执行的任务且仅有单个代理槽位的计划，会依次执行这些任务。详见容量与代理槽位。