Coroid 模拟完整的软件生命周期，而非仅涵盖构建环节。其中大部分流程可自动执行；仅有一个可选节点会在工作重要性足够高时启用。
可选的SDLC工作流程
在新任务表单的高级设置中，有一个对应的复选框：
使用SDLC工作流程（可选）——在规划前先审核需求与规格说明。若关闭此选项，可直接根据需求概要启动规划。
该选项默认处于关闭状态。关闭后，需求概要通过审核即可直接启动规划。资格审核启用后，会先生成并审批两份文档：
- 需求——明确工作的具体用途，同时记录背后的决策与假设。
- 规格说明——界定工作范围、排除项及验收标准。
只有这两份文档获批后，才会开始规划流程。
何时启用此功能
若打造错误产品的成本较高、需求提出者不会自行审核规划，或需求概要中包含你希望书面确认并达成共识的假设时，可启用此功能。
若需求概要已经清晰明确，则无需启用。对常规工作增设额外审批节点只会徒增阻碍却无实际益处——且无论是否启用该功能，规划审批步骤仍会执行。
五个阶段
完整生命周期分为五个阶段，每个阶段都会生成供下一阶段使用的凭证。
| 阶段 | 执行内容 | 状态 |
|---|---|---|
| 定义 | 模糊的需求将转化为获批的需求、决策、假设及成功衡量标准。 | 测试版 |
| 可视化 | 可选的用户界面概念，经优化后作为设计指导获批。 | 测试版 |
| 交付 | 规划被拆解后由智能体执行。 | 可用 |
| 验证 | 需求对应到具体任务、检查项、评审结果及拉取请求变更。 | 可用 |
| 优化 | 监控、修复及评估会将回归问题转化为下一周期的工作。 | 可用 |
- 定义经批准的意图、决策、假设及成功衡量标准测试版
- 可视化可选的用户界面构思，经认可后可作为设计指引测试版
- 交付计划被拆解后由智能体执行可用
- 验证需求对应到任务、检查项、发现的问题及变更可用
- 优化回归问题会成为下一轮工作的内容可用
可选开启SDLC工作流程，可在规划开始前确认意图和规范的正确性。
优化环节会为下一轮工作提供输入：监控、修复和评估会将回归问题转化为新任务。
定义与可视化阶段仍在积极开发中。交付、验证及优化阶段目前已应用于所有任务，无论是否启用该审批节点。
为何要对文档进行版本管理
审批操作会绑定到文档的特定版本。编辑已获批的文档会生成新草稿，而非悄悄更改已达成共识的内容。
这正是审批具备实际意义的原因。若审批绑定的是“规格说明”而非其特定版本，那么审批对象就会变成文档后续的内容，这根本算不上真正的审批。
审批角色
产品、设计、技术、安全及发布相关职责可独立分配，因此审批安全影响的人员未必是审批范围的人员。
凭证溯源
在每个阶段生成凭证的目的是便于追溯完整的pull request：某项变更实现了特定任务，该任务源自特定需求，而需求又来自已获批的需求。
正是这一链条让自主交付过程可被审计。缺少它，虽有可运行的代码，却无法解释为何这是你要求开发的代码。
从审核通过的代码到版本发布
pull request 是工作周期的产出物。当仓库规则允许合并后，版本发布会锁定完整的提交SHA值，并记录该提交包含的所有变更。其就绪门会针对指定环境评估该特定提交。审批操作会绑定到门控快照；若修改候选版本或策略，此前的决策便会失效。
发起部署请求后会触发连接管道中的部署尝试。提供商回调或手动证明会记录部署到环境的内容，部署后的金丝雀测试会单独记录运行状况。因此任务、pull request 和版本发布具有不同的含义：已完成的工作并不等同于代码已部署到生产环境。
其与规划的关系
SDLC工作流程与规划是不同的审批节点：
- SDLC工作流程用于审批应构建什么在尚无实施方案时确定开发内容。规划
- 用于审批规划用于审批构建方式在代码存在前确定实现路径。
你可以任选其一、同时使用或都不用。相比审核最终生成的不符要求的pull request，这两种方式成本更低。