Coroid models a full software lifecycle, not merely the build phase. Most of it runs automatically; one part is an optional checkpoint you enable when the work is significant enough to warrant it.
The optional SDLC workflow
On the New Work form, under advanced settings, features a checkbox:
Use the SDLC workflow (optional) — review an intent and specification prior to planning. Disable this to start a plan directly from your brief.
It is off by default. When disabled, your brief goes straight to planning. When enabled, two artefacts are produced and approved first:
- Intent — what the work is actually for, with the decisions and assumptions behind it recorded.
- Specification — scope, exclusions and acceptance criteria.
Only once these are approved does planning commence.
When to enable it
Enable it when the cost of building the wrong thing is high, when the request came from someone who won’t review the plan themselves, or when the brief contains an assumption you’d prefer to see documented and agreed upon.
Disable it when the brief is already unambiguous. An extra approval gate on routine work creates unnecessary friction with no real benefit — and the plan approval step still applies regardless.
The five stages
The full lifecycle comprises five stages, each producing evidence used by the next stage.
| Stage | What happens | Status |
|---|---|---|
| Define | An ambiguous request becomes an approved intent, along with decisions, assumptions and success measures. | Beta |
| Visualize | Optional UI concepts, refined and approved as design guidance. | Beta |
| Deliver | The plan is broken down and agents execute it. | Available |
| Prove | Requirements map to tasks, checks, review findings and pull-request changes. | Available |
| Improve | Monitors, remediation and evaluations turn regressions into work for the next cycle. | Available |
Define and Visualize are the two stages under active development. Deliver, Prove and Improve run on every task today, whether or not you enable the checkpoint.
Why the artefacts are versioned
Approvals are tied to an exact version of an artefact. Editing an approved artefact creates a new draft rather than silently altering what was previously agreed upon.
This is what gives an approval real meaning. An approval that is loosely attached to "the specification" rather than to a specific version of it approves whatever the document says at that moment, which is not a genuine approval at all.
Approval roles
Product, design, technical, security and release responsibilities can be assigned independently, so the person approving the security implications isn’t necessarily the same person approving the scope.
Evidence lineage
The purpose of generating evidence at each stage is to allow a finished pull request to be traced back: this change implements this task, which stems from this requirement, which originates from this approved intent.
That chain is what makes autonomous delivery auditable. Without it, you have working code but no record of why it matches what you requested.
How this relates to plans
The SDLC workflow and plans are distinct checkpoints:
- The SDLC workflow approves what should be built, prior to any approach being defined.
- The plan approves how it will be built, prior to any code being written.
You can use either option, both, or neither. Using both options works out cheaper than having to review a completed pull request that you disagree with.