Coroid models a full software lifecycle, not just the build step. Most of it runs automatically; one part is an optional checkpoint you switch on when work is consequential enough to warrant it.
The optional SDLC workflow
On the New Work form, under advanced settings, is a checkbox:
Use the SDLC workflow (optional) — review an intent and specification before planning. Leave this off to start a plan directly from your brief.
It is off by default. Left off, your brief goes straight to planning. Turned on, two artifacts 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 those are approved does planning begin.
When to turn it on
Turn it on when the cost of building the wrong thing is high, when the request came from someone who is not going to review the plan themselves, or when the brief contains an assumption you would rather see written down and agreed.
Leave it off when the brief is already unambiguous. An extra approval gate on routine work is friction without benefit — and the plan approval step still applies either way.
The five stations
The full lifecycle runs in five stages, each producing evidence the next one uses.
| Station | What happens | Status |
|---|---|---|
| Define | An ambiguous request becomes approved intent, decisions, assumptions and success measures | Beta |
| Visualize | Optional UI concepts, refined and approved as design guidance | Beta |
| Deliver | The plan is decomposed 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 the next cycle's work | Available |
Define and Visualize are the two under active development. Deliver, Prove and Improve are what runs on every task today, whether or not you switch the checkpoint on.
Why the artifacts are versioned
Approvals bind to an exact version of an artifact. Editing an approved artifact creates a new draft rather than silently changing what was agreed.
This is what makes an approval mean something. An approval that floats — attached to "the specification" rather than to a specific version of it — approves whatever the document happens to say later, which is not an approval at all.
Approval roles
Product, design, technical, security and release responsibilities can be assigned independently, so the person approving the security implications is not necessarily the person approving the scope.
Evidence lineage
The point of producing evidence at each station is that a finished pull request can be traced backwards: this change implements this task, which came from this requirement, which came from this approved intent.
That chain is what makes autonomous delivery auditable. Without it you have working code and no account of why it is the code you asked for.
How this relates to plans
The SDLC workflow and plans are different checkpoints:
- The SDLC workflow approves what should be built, before an approach exists.
- The plan approves how it will be built, before code exists.
You can use either, both, or neither. Both are cheaper than reviewing a finished pull request you disagree with.