The lifecycle: from validate to deploy

The nine phases

03vibe has two lifecycles. clean has one 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.

04 vibe <phase> executes every default-lifecycle phase up to and including the named one, in order — the Maven ritual verbatim. vibe clean <phase> runs the clean lifecycle first, then the default lifecycle up to <phase> (§4.4). A phase with no contributions and no built-in binding completes as a no-op — Maven's empty-phase law, which is what makes nine slots cost nothing for a prompt-only project (its deploy chain degenerates to validate+install).

06 vibe has two lifecycles. clean — one phase, exactly PROP-053. default — nine phases, in this fixed order:

07 build — the deterministic algorithmic build. The engine prepares selected native groups, replays pending compiler lanes, executes dependency-ordered artifact targets through exact mechanisms, then phase rows. Builtin Cargo, compatibility [[binary]] lowering and package-supplied native Build replacement are commissioned; the foreign adapter consumes exact prepared carriage, owns staged output proof/A2 records and preserves provider freshness through rollback.

08 package — assemble distributables without mutating destinations. Verified artifact records feed builtin static-skill, Agent Plugin/client projection and deterministic Windows-zip providers, plus package-supplied native Package replacement. The foreign adapter resolves and revalidates the real Build A2 record before invocation and retains engine-owned fingerprints, proof and records.

09 deploy — apply selected package artifacts to explicit destinations through profiles, exact providers, plan/lock/intent/receipt/recovery/inverse ownership. Builtin local/client providers and a real package-supplied native replacement are commissioned; live remote publication remains subject to ordinary red lines.

Nothing runs twice for nothing

10Every phase run records a fingerprint of the inputs it declared; the next run skips a phase whose inputs did not change. Freshness is judged per 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.

11 Every phase execution owns a fingerprint — a hash over its declared inputs (for install: manifest+sources, already built; for build: the slot sources + project sources the preset names; for create: the prompt documents + their spec closure). A phase whose fingerprint matches the recorded one skips, reporting fresh per contribution — the Gradle up-to-date property grafted onto the Maven ritual. This is the design answer to «если vibe.toml не поменялся, инсталлировать пакеты не нужно», generalised to all nine phases because create (tokens) and build (native compile time) are even more expensive than install.

12 Freshness is judged per contribution, not only per phase: one stale execution re-runs alone; its peers stay skipped. A handler MAY declare extra inputs in its manifest entry (inputs = ["spec/prompts/**"]); a handler that declares none is conservatively re-run whenever the phase's own inputs move.

Seeing before doing

13--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.

14 Nothing runs invisibly. Every phase run prints the contributions it will execute (id, point, handler kind, providing package) before running them — the narrator genre the tooling already speaks ([k/n] lines). A ritual whose steps are secret is not a ritual. The full instrument rack is §3.5.

15vibe 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.

16 vibe [clean] <phase> [<pkgref>…] [flags]. Any default-lifecycle phase may be named; clean before it runs the clean lifecycle first. vibe clean install org.x/y --offline keeps its exact PROP-053 semantics (wipe → world from lock → refresh the named) as the special case it already was. This section IS the «own semantics ruling» PROP-053 ##CHAIN-ONLY-INSTALL required before any wider grammar — that anchor is superseded by this one at build time, by a status move and a successor note beside it, never by deleting or renaming it. Pkgrefs remain meaningful only to the install phase (they scope what refreshes); other phases take flags, not pkgrefs, until a ruling says otherwise.

Where the steps come from

17The 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 of the project can switch a contribution off or replace it by its id.

18 Installing a package IS the consent to run its extensions (owner ruling 2026-08-25, ##LIFE-MANDATE-NO-CONSENT). No allow-lists, no first-run prompts, no --allow-… flags — the Gradle/Webpack/Clang posture: an ecosystem of native extensions where the trust decision is made once, at dependency selection, like build.rs and postinstall before us. The safety model is not permission dialogs but total observability (§3.5). PROP-020 §2.3 now records this successor at its owning anchors; the old allow-list/first-run/non-interactive permission design remains historical text only.

19The lifecycle is a framework, not a universal coding agent: it runs deterministic mechanics and hands agentic work to whatever agent hosts it.

20 Owner ruling (2026-08-27): VibeVM builds the mechanics, not a universal coding agent. The lifecycle is a passive, extensible execution framework: phases, contributions, fingerprints, artifacts, reports, durable park/resume and CLI/MCP adapters. It contains no built-in Plan/Act policy, no automatic create → verify → create transition, no replanning heuristic, no hidden attempt/token loop and no rule for when a human must intervene. Any human, Codex, Claude Code, OpenCode or future agent may orchestrate repeated invocations; a reference coding agent is explicitly a separate future campaign.

Edge cases and rules

21A failing step stops the chain; the phases before it keep their results, and the failure names the contribution that failed.

22 Failure semantics generalise PROP-020 §2.5: a failing contribution in validate/install/generate/build/test stops the chain (the phase reports which execution failed); a failing create/verify contribution stops before package (nothing half-created is packaged); package/deploy failures stop the chain trivially (they are last). slot:pre-install keeps its rollback; slot:post-install keeps installed-but-flagged. A skip reply is bookkept, never an error.

23The older verbs keep their meaning beside the lifecycle: vibe check, vibe bin build, vibe skill and vibe cache are not phases.

24 Existing verbs are untouched: vibe check, vibe bin build, vibe skill, vibe cache … keep their meanings as directly-invoked tools — Maven's «a goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation». vibe install the verb IS the install phase invoked directly (one implementation, two spellings of the same thing). Mixing direct verbs into a phase chain on one command line (Maven's mvn clean dependency:copy-dependencies package) is not adopted now — each verb keeps its own invocation; revisit behind this anchor if the need shows.

25Fingerprints and last-run records live in .vibe/lifecycle.toml, machine state that is not committed; deleting it costs one full run.

26 Fingerprints and last-run records live in .vibe/lifecycle.toml at the workspace root — machine state beside the project settings that already live in .vibe/, inside the shippable-tree denylist (PROP-024 §2.2), never committed, never hashed. vibe clean does NOT remove it (it describes work, it is not derived prompt state); a --force flag on any phase ignores it for one run.