# Жизненный цикл: от validate до deploy {#root} @status:doc/work @audience:user,author [p01] У сборки программ есть фиксированный порядок шагов, и vibe называет их: проверить дерево, произвести сгенерированные исходники, собрать, протестировать, дать агенту создать то, что может только агент, проверить результат, упаковать, выложить. Каждый шаг выполняется, только когда изменилось что-то, от чего он зависит. [p02] Example `deploy-plan` is copied from the source page at projection time. ## Девять фаз {#the-phases} [p03] У vibe два [жизненных цикла](../glossary/index.xml#lifecycle). У `clean` одна [фаза](../glossary/index.xml#phase), и он удаляет выведенное состояние. У `default` девять фаз в фиксированном порядке: `validate`, `install`, `generate`, `build`, `test`, `create`, `verify`, `package`, `deploy`. Назвать фазу — значит выполнить и все фазы до неё: `vibe test` проверяет, ставит, генерирует, собирает и тестирует. > [p04] `vibe ` executes every default-lifecycle phase up to and including the named one, in order — the Maven ritual verbatim. `vibe clean ` runs the clean lifecycle first, then the default lifecycle up to `` (§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). > > [p05] | Фаза | Что делает | | --- | --- | | `validate` | дешёвая предварительная проверка: манифест разбирается, объявленные расширения и профили правильно оформлены; без сети | | `install` | установка пакетов, описанная в других местах этого руководства: разрешить, скачать, скопировать, сгенерировать стартовые файлы | | `generate` | выведенные исходники из спецификаций и промптов, записанные туда, куда говорит стек проекта | | `build` | детерминированная сборка стека проекта | | `test` | детерминированные проверки: тестовый прогон стека и ворота дисциплины, которые вносят установленные пакеты | | `create` | необязательный агентный шаг: работа, которую может сделать только агент, долгая и недетерминированная, выключена, пока проект её не включит | | `verify` | поздние ворота качества над тем, что собрано и создано | | `package` | собрать дистрибутивы, не трогая ни одного места назначения | | `deploy` | применить упакованные артефакты к явным местам назначения через именованный профиль | > [p06] vibe has **two** lifecycles. **`clean`** — one phase, exactly PROP-053. **`default`** — nine phases, in this fixed order: > > > [p07] **`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. > > > [p08] **`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. > > > [p09] **`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. > > ## Ничто не выполняется дважды впустую {#fresh} [p10] Каждый прогон фазы записывает [отпечаток](../glossary/index.xml#fingerprint) входов, которые она объявила; следующий прогон пропускает фазу, чьи входы не изменились. Свежесть судится по каждому [вкладу](../glossary/index.xml#contribution) отдельно, так что один устаревший шаг перезапускается сам по себе, а соседи остаются пропущенными. Именно поэтому `vibe deploy` дёшево набрать дважды: во второй раз он в основном сообщает, что всё свежее. > [p11] **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. > > > [p12] 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. > > ## Увидеть прежде, чем сделать {#the-plan} [p13] `--plan` сообщает, что сделал бы прогон фазы, и ничего не меняет; каждый настоящий прогон печатает перед выполнением вклады, которые выполнит: их идентификатор, точку, к которой они привязаны, вид обработчика и откуда они взялись. Ничто в жизненном цикле не выполняется невидимо. > [p14] **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. > > [p15] `vibe clean ` ставит цикл очистки перед любой фазой `default`: `vibe clean build` удаляет выведенное состояние, а затем проверяет, ставит, генерирует и собирает. > [p16] **`vibe [clean] […] [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-steps-come-from} [p17] Фазы фиксированы; то, что выполняется внутри них, вносят пакеты. Пакет стека привязывает сборщик и тестовый прогон языка, пакет дисциплины привязывает свои ворота, проект может привязать собственные скрипты. Установить пакет — значит согласиться на выполнение его вкладов, а [манифест](../glossary/index.xml#manifest) проекта может выключить вклад или заменить его по идентификатору. > [p18] **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. > > [p19] Жизненный цикл — каркас, а не универсальный агент для кода: он выполняет детерминированную механику, а агентную работу передаёт тому агенту, который его запустил. > [p20] **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} [p21] Упавший шаг останавливает цепочку; фазы до него сохраняют результаты, а сообщение об ошибке называет вклад, который упал. > [p22] **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. > > [p23] Старые глаголы сохраняют смысл рядом с жизненным циклом: `vibe check`, `vibe bin build`, `vibe skill` и `vibe cache` не фазы. > [p24] 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. > > [p25] Отпечатки и записи о последнем прогоне живут в `.vibe/lifecycle.toml`, машинном состоянии, которое не коммитят; удалить его стоит одного полного прогона. > [p26] 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. > >