vibe is one binary built from a set of Rust libraries, each owning one concern: reading the description of a project, choosing versions, fetching from where packages are published, writing the tree on disk, talking to agents. This page maps the libraries, the seams between them, and the path an install takes through them.
Read the product bottom-up. *Identity*: a package is a [coordinate](../glossary/index.xml#coordinate) plus a content [fingerprint](../glossary/index.xml#fingerprint), and the kind is metadata. *[Registry](../glossary/index.xml#registry)*: ordered package sources with mirrors, [overrides](../glossary/index.xml#override) and an optional [index](../glossary/index.xml#index-registry). *[Store](../glossary/index.xml#store)*: every fetched package version kept once per machine.
*Materialisation*: the resolved graph copied into the project's dependency tree and recorded in the [lock file](../glossary/index.xml#lock-file). *Computed boot*: the packages' [contributions](../glossary/index.xml#contribution) projected into the two generated files an agent reads. Everything a user sees is one of these five layers or a surface over them.
| Concern | Crates | What they own |
| core vocabulary | `vibe-core`, `vibe-wire` | manifests, the lock file, identities and content hashes; the generated types of every registered machine format |
| specifications | `vibe-spec`, `vibe-specdoc`, `progress-core`, `vibe-facts`, `vibe-trace` | addresses and the deterministic router; the document model with its Markdown and XML frontends and backends; the status markup parser and reports; the adoption-facts registry; traceability queries |
| registries and the store | `vibe-registry`, `vibe-index`, `vibe-publish`, `vibe-package-source` | git transport, mirrors and overrides, the clone cache and the machine store; the searchable index and its server; publishing; the one production composition of package sources |
| resolution and installation | `vibe-resolver`, `vibe-install`, `vibe-workspace`, `vibe-safefs` | the solver seams and cells; plan and apply; workspace discovery, materialisation, the computed boot; capability-relative filesystem mutation |
| the lifecycle | `vibe-lifecycle`, `vibe-extension-registry`, `vibe-orchestrator`, `vibe-ext`, `vibe-native-loader`, `vibe-llm`, `vibe-scrape` | the nine-phase model and chaining; the pure extension registry; surface-neutral orchestration; the safe author SDK and the quarantined loader of native extensions; the model provider seam; scrape planning |
| agents and preferences | `vibe-mcp`, `vibe-agent-projection`, `vibe-settings`, `vibe-actions`, `vibe-requirements` | the MCP server and integration manager; skill projection into agents; three-level preferences; frontend-agnostic actions; the read-only requirements query |
| surfaces and checks | `vibe-cli`, `vibe-check` | the command line; the deterministic project linter |
| documentation | `vibe-doc`, `vibe-doc-server`, `vibe-doc-shell` | the page pipeline behind `vibe doc`: build, check, manifest, surface snapshots, the maintenance queue and the site builder; the local reader's server on the loopback address; the reader's shell carried inside the binary |
| reserved and tooling | `vibe-graph`, `vibe-test-support`, `xtask` | a reserved task-graph slot; test isolation of the settings home; the maintainer gates: code generation, the traceability map, engine synchronisation, mirroring, the release build |
The dependency direction is fixed: a surface calls an orchestrator, an orchestrator calls a library through a seam, a library returns typed values. Domain libraries never prompt, never format terminal output and never decide authentication; those choices are made at the composition root, in the CLI or the [MCP server](../glossary/index.xml#mcp-server).
Four decisions hold the tree together. The repository is one Cargo workspace with every crate under `crates/`. Each ability of the product lives in a library, and the command line, the terminal interface and the MCP server are thin surfaces over it. JSON Type Definition schemas are the single source of truth for every machine contract. And the commit discipline is the installed git-practices family, read at the start of every session.
1. Discover the workspace root and read the [manifests](../glossary/index.xml#manifest), the lock file, the user configuration, the registries, mirrors, overrides and local package sources.
2. Compare the manifests with the lock file; if nothing changed, skip resolution.
3. Otherwise qualify every requested coordinate and build the solver's view of available versions. Solve the whole graph, holding every pin the change does not touch.
4. Fetch every selected identity: a store hit is reused, a miss walks the allowed sources and inserts the verified tree into the store.
5. Build the plan, validate the [managed blocks](../glossary/index.xml#managed-block) of the instruction files, and ask for confirmation.
6. Materialise the graph into the dependency tree by diff, regenerate the boot files, prune stale slots.
7. Record the graph, the provenance and the fingerprints in the lock file.
8. Render the human, quiet or JSON report.
`GitBackend` isolates git: the production implementation shells out to the system git, so SSH agents and credential helpers behave as they do everywhere else. `Registry` enumerates, resolves and fetches across local and git-backed sources; `MultiRegistryResolver` owns the ordered walk, mirrors, overrides, authentication and the offline posture. `DepProvider` is the solver's view of the world and `DepSolver` turns roots into a graph; the default cell is resolvo, with a backtracking SAT cell and a naive cell selectable. `InstallSource` separates the transaction from the construction of cells. `RepoCreator` isolates the hosts' repository creation for publishing. Each seam has more than one implementation, and tests run the seam, not the production cell.
The specifications are the authority: `PROP-000` for the foundational decisions, `PROP-009` for the loading model, `PROP-002` and `PROP-010` for registries and the store, `PROP-054` for the [lifecycle](../glossary/index.xml#lifecycle) and the extension machine, `PROP-045` for the document model, `PROP-057` and `PROP-058` for documentation packages, the site and how this manual is maintained. The traceability page of this manual explains how code cites them and how to ask the map which code implements which rule. The developer guide in the repository covers building, testing and the self-check panel.