Three workflows take the system phase 5 composed and put it somewhere real. They are separate on purpose: a local environment is for looking at the thing, provisioning is for creating what it will run on, and a release is a versioned, reversible promotion.
All three read the composed app under <devDir>/app and the binding solution architecture, and all three refuse to guess at credentials — every one of them stops at a gate and asks for what it needs by name, so no secret is ever written into a workflow definition or an instance's state.
A local environment to click through
ccw_start SDLC 7 Local Deployment
| Input | Required | Default | Meaning |
|---|---|---|---|
projectName, workspaceDir, devDir |
yes | ||
externalServices |
no | stubbed |
stubbed, live, or per service: geocoding=live,mail=stubbed |
keepRunning |
no | true |
Leave the environment up after you approve |
It checks the system is actually built, defines the local environment from the architecture — services, migrations, seed data, and every external dependency either stubbed offline or wired to the real thing — provisions it, starts it, and checks health deterministically before claiming anything works.
The per-service form of externalServices is what makes this usable in practice: run against the real geocoding provider because the stub cannot tell you whether the addresses in your seed data resolve, while mail stays stubbed because nobody wants a test run sending it. When a service is set to live, the workflow stops at a credentials gate first and asks you for that service's credentials, which land in deploy-local/.env.local and never in the run.
Then it hands over: a manual test gate, where you click through the running system and write down what is wrong. Your findings drive SDLC Fix Subsystem rounds, a re-compose and a redeploy, and it asks again — until you are satisfied. With keepRunning: true the environment is still up when the run ends.
Out: deploy-local/ with the deploy manifest, stubs, seeds, reports and your findings.
Provisioning the environments
ccw_start SDLC 9 Provision Infrastructure
| Input | Required | Default | Meaning |
|---|---|---|---|
projectName, workspaceDir, devDir |
yes | ||
environment |
no | staging |
staging, production or all |
The architecture decides what gets provisioned; this workflow refuses to invent it. If solution-architecture.md has not named a hosting provider, the run aborts and tells you to go back to phase 2 — an infrastructure decision made by an agent halfway through a provisioning run is exactly the kind of decision that should be recorded first. Provider-specific notes ship as instruction files (Scaleway, for instance) so the generated terraform matches how that provider actually names things.
It authors terraform per environment under <devDir>/infra/, asks for credentials by name at a gate, runs plan, and stops at a cost gate with the monthly cost before anything is applied. After apply it verifies connectivity and re-runs to prove idempotency, hands the non-secret outputs to phase 8's deploy manifests, and generates the CI/CD pipeline configuration when the architecture names a platform.
Releasing
ccw_start SDLC 8 Release and Deploy
| Input | Required | Default | Meaning |
|---|---|---|---|
projectName, workspaceDir, devDir |
yes | ||
promoteTo |
no | production |
production for a full promotion, staging to stop after staging verification |
The sequence:
- Prepare the release — a semver version and release notes derived from the change log in
06-changes/, so the notes describe theCH-###andBUG-###records that actually went in. - Define the environments and collect deployment secrets at a gate.
- Build a version-stamped, immutable artifact. The same artifact is what reaches production; nothing is rebuilt between environments.
- Deploy to staging, then prove it: a deterministic health check and a smoke run, not a log line saying it started.
- A bounded release review, then a human production gate. This is the decision the package will never make for you.
- Deploy to production, check health, verify, and on success record
REL-###in07-releases/releases.jsonland git-tag the release. - Rollback is a first-class path behind its own gate, not an improvisation: when verification fails, the workflow offers it with the previous release already identified.
Out: 07-releases/ with the release log and notes, and deploy-remote/staging/ and deploy-remote/production/ with the manifests each deploy used.
A workable order
For a new system: build with phase 5 → click through it with phase 7 → provision staging with phase 9 → release to staging with phase 8 and promoteTo: "staging" → provision production → release for real.
After that, changes go through phase 6 or Bug Fix, and each one ends in another phase 8 run. A hotfix can start its release directly from the bug workflow.