# Собрать, упаковать и выложить проект {#root} @status:doc/work @audience:user,author [p01] Эта страница проводит проект от исходников до работающей выкладки тремя командами, показывает, что каждая оставляет на диске, и как снять выкладку, не гадая, чем она владела. [p02] ```prompt Для проекта VibeVM в текущей папке покажи мне план выкладки для профиля с именем local, затем выполни выкладку, перечисли выкладки, которые теперь есть на этой машине, и наконец сними тот же профиль. Остановись и спроси меня перед выкладкой и перед снятием. ``` - needs: навык vibevm, установленный у вашего агента; проект, чей манифест объявляет артефакт сборки, цель выкладки с механизмом `deploy:vibe-bin` и профиль с именем `local`, как показывают таблицы на этой странице; `cargo` в `PATH` outcome: план называет цели по порядку; после выкладки `vibe deployments` показывает профиль с поколением и статусом; после снятия каждый ресурс, которым владела квитанция, исчез, а список показывает профиль как снятый - assert: `vibe deploy --plan --profile local` - assert: `vibe deployments --json` ## Что происходит {#what-happens} [p03] `vibe deploy --plan` прогоняет весь [жизненный цикл](../glossary/index.xml#lifecycle) `default` в режиме планирования и печатает, что сделала бы каждая [фаза](../glossary/index.xml#phase), заканчивая упорядоченными целями профиля; ничего не записывается. Настоящий `vibe deploy` затем проверяет, ставит, генерирует, собирает, тестирует, создаёт, верифицирует и упаковывает, пропуская каждый шаг, чьи входы не изменились, и применяет упакованные артефакты к целям профиля по порядку. На каждый созданный ресурс он пишет *[квитанцию](../glossary/index.xml#receipt)*: что и куда положено, под каким поколением, каким профилем владеется. `vibe deployments` читает квитанции, которые есть на этой машине. `vibe undeploy --profile local` обходит квитанции в обратном порядке зависимостей и удаляет ровно то, чем они владеют, отказываясь трогать путь, который изменился после выкладки. > [p04] Deploy profiles select ordered targets; plan is read-only. The engine owns provider selection, collision locks, intent/checkpoints, receipts, three-digest recovery, inverse sequencing and exact resource ownership. `vibe-bin` plus isolated Claude/Codex/OpenCode skill/plugin adapters implement plan/apply/verify/recover/remove without touching foreign neighbours. Evidence: `0a42456e`, `45d88e80`, `ae36ac48`. > > ## Руками {#by-hand} [p05] 1. Объявите, что собирать, что выкладывать и куда. Цель называет артефакт и механизм, который его размещает; профиль — упорядоченный список целей: [p06] ```toml [[artifacts.build]] id = "build-hello" mechanism = "build:cargo" outputs = [{ id = "hello", kind = "executable", select = { package = "hello", bin = "hello" } }] config = { offline = true } [[deploy.target]] id = "local" artifact = "hello" mechanism = "deploy:vibe-bin" config = { command = "hello" } [deploy] default_profile = "local" [deploy.profiles.local] targets = ["local"] ``` [p07] Механизм `deploy:vibe-bin` размещает исполняемый файл как лаунчер в собственной папке `bin/` vibe на этой машине. После этого команда запускается из любого терминала; остальные механизмы перечислены в [спецификации](../glossary/index.xml#specification). [p08] 2. Соберите дистрибутивы, не трогая ни одного места назначения: [p09] Example `package` is copied from the source page at projection time. [p10] 3. Посмотрите план для профиля, затем выложите его: [p11] Example `deploy-plan` is copied from the source page at projection time. [p12] 4. Перечислите, что есть на этой машине, и снимите профиль: [p13] Example `deployments` is copied from the source page at projection time. [p14] `vibe undeploy --profile ` откатывает этот профиль. Список никогда не показывает секретов. ## Артефакты и цели {#artifacts} [p15] [Манифест](../glossary/index.xml#manifest) объявляет, что производит `build` и что собирает `package`, как цели-артефакты с зависимостями между ними. vibe сводит их в один проверенный граф и записывает каждый произведённый артефакт. Поэтому `package` потребляет ровно то, что проверил `build`, а `deploy` применяет ровно то, что собрал `package`. Артефакт или цель может объявить операционные системы, к которым относится, и цель, которая к текущей машине не относится, пропускается с пометкой. > [p16] The strict manifest grammar lowers build/package targets into one dependency-validated artifact DAG. Engine records bind artifact id/kind/path/digest, producer target, logical mechanism, exact provider/version/content, platform and build-affecting input/config/toolchain identity; output existence alone is never freshness. Builtin Cargo selects compiler artifacts only from Cargo JSON messages. Evidence: `2a3f3b44`, `a22da2a3`. > > > [p17] Artifact/package and deploy target `when.os` use the closed `windows|linux|macos` vocabulary and one injected loading-model OS observation. Global validation remains, then inactive rows project out before provider/source/record/collision/build/load; an active consumer of an inactive producer refuses. Human/JSON output reports deterministic skips and undeploy remains receipt-owned. Evidence: `d4edb3ae`, `8ff4b711`, `bb50aeab`. > > [p18] [Профиль выкладки](../glossary/index.xml#deploy-profile) называет свои цели по порядку и [провайдера](../glossary/index.xml#provider), который применяет каждую: папка на этой машине, проектная или пользовательская конфигурация агента и те жанры, что перечисляет спецификация. Установленный пакет может заменить встроенного провайдера точным пином, так что команда может поставлять собственный способ выкладки. > [p19] A real installed package may displace a builtin deploy mechanism through an exact route/pin. The engine reuses ABI-1, R5 prebuilt/source record and immutable-image carriage, admits the generated mechanism manifest and exact operation, and invokes all six deploy operations while retaining plan/receipt/recovery ownership. Restart plan/recovery/undeploy re-resolve once at the command boundary and exact-compare the durable sidecar binding, existing record/image/digest/path without build, repair, publication or builtin fallback. Evidence: `854707a1`, `9465291e`, `24b1fe4a`, `269bec0d`, `370ea177`, `a24e4aff`, `d475963c`. > > ## Особые случаи и правила {#edge-cases} [p20] Две выкладки одного профиля не гоняются наперегонки: движок берёт замок от столкновений на профиль, и вторая ждёт или отказывается, но никогда не перемешивается с первой. [p21] Квитанция — единственное основание для удаления. Если файл, которым владеет квитанция, правили после выкладки, `undeploy` оставляет его на месте и говорит об этом, вместо того чтобы удалить чью-то работу. [p22] `--force` у глагола жизненного цикла игнорирует записанные [отпечатки](../glossary/index.xml#fingerprint) на один прогон; смысла прогона он не меняет. [p23] Фаза выкладки применяет упакованные артефакты и ничего больше: шаг, которому нужен агент, например написать заметки о выпуске, принадлежит `create` и выполняется, только когда проект его включает. > [p24] **`create`** — the optional agentic producer, our phase Maven does not have. Long, non-deterministic and potentially expensive — therefore LATE (after test: the deterministic baseline is proven before tokens are spent) but before verify/package/deploy. Contributions may use `handler = { kind = "agent" }`: from a terminal the configured `vibe-llm` provider executes each explicitly activated contribution as one bounded execution; under an agent host the §6.5 handshake delegates it. An agent handler is a declared workload in its own right, not an LLM enhancement of some hidden algorithmic twin: once activated it fails honestly when neither a provider nor an agent host can execute it, rather than silently disappearing. Provider/config/credential presence activates nothing; omission, host disable or freshness keeps the ordinary chain algorithmic and spends nothing. The phase itself is not a coding agent, planner or repair loop: it executes declared contributions, records/parks their outputs and returns. Skip-when-fresh is vital so an unchanged prompt/spec fingerprint never re-spends tokens (§4.3). > >