Building software has a fixed order of steps, and vibe names them: check the tree, produce generated sources, build, test, let an agent create what only an agent can, verify, assemble, deploy. Each step runs only when something it depends on changed.
vibe has two [lifecycles](../glossary/index.xml#lifecycle). `clean` has one [phase](../glossary/index.xml#phase) and removes derived state. `default` has nine phases in a fixed order: `validate`, `install`, `generate`, `build`, `test`, `create`, `verify`, `package`, `deploy`. Naming a phase runs every phase before it as well: `vibe test` validates, installs, generates, builds and tests.
| Phase | What it does |
| `validate` | the cheap preflight: the manifest parses, the declared extensions and profiles are well formed; no network |
| `install` | the package install described elsewhere in this manual: resolve, fetch, copy, generate the boot files |
| `generate` | derived sources from specifications and prompts, written where the project's stack says |
| `build` | the deterministic build of the project's stack |
| `test` | deterministic checks: the stack's test runner and the discipline gates the installed packages contribute |
| `create` | the optional agentic step: work that only an agent can do, long and non-deterministic, off unless the project switches it on |
| `verify` | the late quality gate over what was built and created |
| `package` | assemble distributables without touching any destination |
| `deploy` | apply the packaged artifacts to explicit destinations through a named profile |
Every phase run records a [fingerprint](../glossary/index.xml#fingerprint) of the inputs it declared; the next run skips a phase whose inputs did not change. Freshness is judged per [contribution](../glossary/index.xml#contribution), so one stale step re-runs alone and its neighbours stay skipped. This is what makes `vibe deploy` cheap to type twice: the second time it mostly reports that everything is fresh.
`--plan` reports what a phase run would do and changes nothing; every real run prints, before executing, the contributions it will run: their id, the point they bind to, the kind of handler, and where they came from. Nothing in the lifecycle runs invisibly.
`vibe clean <phase>` chains the clean lifecycle in front of any default phase: `vibe clean build` removes the derived state and then validates, installs, generates and builds.
The phases are fixed; what runs inside them is contributed by packages. A stack package binds the language's build and test runners, a discipline package binds its gates, a project may bind its own scripts. Installing a package is the consent for its contributions to run, and the [manifest](../glossary/index.xml#manifest) of the project can switch a contribution off or replace it by its id.
The lifecycle is a framework, not a universal coding agent: it runs deterministic mechanics and hands agentic work to whatever agent hosts it.
A failing step stops the chain; the phases before it keep their results, and the failure names the contribution that failed.
The older verbs keep their meaning beside the lifecycle: `vibe check`, `vibe bin build`, `vibe skill` and `vibe cache` are not phases.
Fingerprints and last-run records live in `.vibe/lifecycle.toml`, machine state that is not committed; deleting it costs one full run.