# What the lifecycle epic delivered {#root} @status:doc/work @audience:dev [p01] Between July and September 2026 vibe grew from a package installer into a build system with an extension machine, a native ABI, a record of every deployment and a terminal export. This page tells that route as one system, what was decided on the way, and what was left for later. ## The route, in eight stages {#the-route} [p02] The work ran as eight numbered stages, each landed as atomic commits with tests and a [traceability map](../glossary/index.xml#traceability-map), and recorded in a ledger that names every commit. Read them as one story rather than eight features. [p03] | Stage | What it delivered | | --- | --- | | R1, diff materialisation | a strict record per dependency slot, so an install writes only what changed and never wipes a tree; a hash gate for mutable sources; hooks that run only on a real change | | R2, the lifecycle engine | the strict `[[extension]]` grammar, the nine-phase line with its verbs and the clean chain, ordered collection of contributions, the context envelope, durable freshness with `--force`, script and binary handlers, data presets, `vibe extensions` | | R3, the compiler | an explicit intermediate representation of the boot compiler with five levels and six carriers, a typed pass manager, the pass pipeline from parse to emit, a verifier, and compile traces with snapshots and timings | | R4, staged transforms | one pure extension registry below the lifecycle and the workspace, four transform positions with owner-scoped activation and per-unit fingerprints, a built-in XML minifier, and the lane analyser that attributes the compiled lane's bytes | | R5, the native tier | a C-and-JSON ABI for extensions, the safe author SDK and the quarantined loader, source and prebuilt resolution with in-slot builds, and parity proofs between a native minifier and the built-in one | | R6, full compiler passes | the pass grammar behind `compiler_internals`, a lossless wire projection of the whole IR, before, after and replace positions, the mandatory verifier after plugin passes, and an end-to-end plain-text frontend with a JSON backend | | R7, [providers](../glossary/index.xml#provider) and agents | the model provider seam with an OpenAI-compatible adapter, the CLI agent handler, the hosted outbox with delegated resume, the MCP lifecycle surfaces, and the substrate for external orchestration | | R8, package, build and deploy | the project skill binding, the mechanism and artifact grammar, artifact records and the target graph, the Cargo build provider, one-file skills, the Agent Plugins directory, client projections, deploy profiles with intents, receipts and recovery, a deterministic zip, platform applicability, and package-supplied native providers | [p04] Beside the route, the [scrape](../glossary/index.xml#scrape) operation landed as its own contract: the deterministic removal of the vibe layer from a finished project, with a plan, a health proof and a recoverable in-place transaction. > [p05] A scraped tree is a project > tree for which every contract-selected Vibe path, dependency, managed > marker, source annotation, tool script and environment reference is absent > or explicitly retained under a neutral identity, and whose required > native health panel is accepted after scraping under the declared strict > or no-regression baseline policy. A retained non-pass verdict is never > described as an unconditional pass. > > ## Decisions that hold {#decisions} [p06] One line of nine [phases](../glossary/index.xml#phase): dependency materialisation is `install`, placement outside the project is `deploy`, and `package` mutates no destination. One extension plane: scheduled [contributions](../glossary/index.xml#contribution) answer when, sibling mechanism [providers](../glossary/index.xml#provider) answer how, and built-ins are ordinary providers a host may replace by an exact pin. Native wire is C plus JSON, schema first; the author SDK is safe Rust and the loader is quarantined. Every external mutation has a plan, an intent, an independent verification and a [receipt](../glossary/index.xml#receipt), and a third observed digest refuses. Automatic [skill](../glossary/index.xml#skill) binding is project-only; user and client installation is an explicit deploy. Every subsystem keeps a complete algorithmic mode; a model enhances and never gates. > [p07] **Decision.** The lifecycle hooks and the compiler plugins are ONE machine with two families of extension points, not two machines. One declaration grammar, one context-envelope shape, one handler taxonomy, one trust gate, one ordering rule. A user who has written a lifecycle contribution knows how to write a compiler transform, and vice versa — this is the mandate's «похоже и синергично» made structural. > > > [p08] 8.1 The ABI is C + JSON, never the Rust ABI > > > [p09] Every core VibeVM subsystem retains a complete algorithmic mode. An LLM may improve quality when the operator explicitly enables that feature; credentials, endpoint presence, provider configuration or construction never activate a feature. VibeVM remains useful with no provider, no API access and no agent host. > > ## Compatibility boundaries and migrations {#boundaries} [p10] The dependency slot record and the [lifecycle](../glossary/index.xml#lifecycle) state are strict, versioned machine formats; older trees are migrated once on the next install, never read in place. The compiler IR's wire projection is versioned per carrier. Deploy receipts and [freshness fingerprints](../glossary/index.xml#freshness-fingerprint) live under `.vibe/`, machine state that is not committed; losing them costs one full run, not correctness. Handwritten wire types are counted by a ratchet against a frozen baseline, so a new machine format cannot arrive without a schema. > [p11] 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. > > ## Deliberately left for later {#deferred} [p12] Deploy targets beyond the first genres, a WebAssembly extension tier, per-language and per-resource preference overrides, cloud sync of user preferences, a built-in inference backend, and the general phase grammar beyond `clean install` for the clean lifecycle. Each is named in its [specification](../glossary/index.xml#specification) with a compatibility law, so the door stays open without a half-built feature behind it. > [p13] **Deploy first targets — CLOSED (owner, 2026-08-26; extended 2026-09-04):** selected genres are project/user agent projections for Claude Code, Codex and OpenCode; VibeVM-owned local tools under `~/.vibe/bin`; receipt-owned operator launchers under the VibeVM-controlled `~/.vibe/opt/bin`; an explicit custom installer for ordinary applications; registry/marketplace/server/remote providers; and future system-scope package/config/service providers. The first commissioning cut is isolated local projection/`vibe-bin`/`vibe-opt-launcher`, never a live publish/server mutation. The commissioned local and native provider statuses are closed at the R8 successor anchors; live remote/system mutation remains future work under ordinary authority boundaries. > > > [p14] **WASM handlers — deferred, not rejected:** a wasm component would buy sandboxing (the PROP-020 §4 accepted-risk posture could tighten) and cross-platform artifacts, at the cost of a runtime dependency and awkward filesystem/process access — exactly the operations phase handlers exist to do. When the sandboxing need fires (third-party plugin ecosystems beyond the allow-list), this anchor is where the design resumes. Until then the trust gate is the boundary, exactly as PROP-020 records it. > > ## Retired lanes, kept as history {#retired} [p15] The campaign also ran execution lanes that are no longer current: a subscription-backed external worker lane was retired by the owner in September 2026, and its package source stays in the tree as history while its host dependency and boot contribution were removed. A reader who meets its name in old ledgers should treat it as evidence of how the work was done, not as a supported way to use the product. ## Where the evidence lives {#edge-cases} [p16] The stage-by-stage ledger with commit hashes is `campaigns/packages-2026-09/LIFECYCLE-EXTENSIONS-IMPLEMENTATION-LEDGER.md` in the repository; the contract is `PROP-054`, the scrape contract `PROP-056`, the native ABI and the compiler architecture documents sit beside the ledger. The ledger is a record, not a plan: it names what landed and what was measured, and nothing in this manual restates a number from it. > [p17] **R8 — package/build/deploy substance accepted in implementation.** Artifact DAG/records, Cargo, static skill, Agent Plugin, three client adapters, `vibe-bin`, profiles/intent/receipt/recovery, platform applicability and package-supplied native deploy/build/package providers are implemented. Deploy restart rehydration remains read-only; Build/Package replacement executes through exact prepared carriage and a real installed two-cdylib build→A2→package E2E with no builtin fallback. Evidence through deploy `d475963c`, then M-007 `00cabac8`, `93df9d28`, `e9388559`, `2193e6e7`, `fe0eb9df`, `0ca2b781`, `123ac504`, `68ce9078`, `55cfbf94`. This node is done. All technical/full/conform/generated/specmap/no-transform and mirror work is complete at `39fa498a34d30c7744c8598c9f1a0673a6aeee62`; the PROP root remains `impl/work` solely because owner final inspection in the current chat is pending. > >