A version of documentation in another language: a separate package that mirrors the source block for block and is free sentence by sentence. This manual says «translation» and «adaptation» for the same thing. See *translation*.

One run of a coding agent in a project, from the moment it reads its instruction file to the moment it stops. The boot lane is what vibe prepares for the start of a session.

The identifier of a section or a fact inside a specification, the part after `#` in an address. Once published, an anchor never changes; a rename leaves a tombstone.

The ordinal `pNN` every block of a documentation page receives at build time; the same in the web page, the Markdown and the XML, so a human and an agent cite one place. It names the current text and may shift after an edit, like a line number.

The ordered reading list an agent follows at the start of a session: the managed block in the instruction file, then `STATIC.md` in full, then the entries of `INDEX.md`. Computed by vibe from the dependency graph, never written by hand.

A package's contribution to the boot lane: one short text declared in `[boot_snippet]` with a category, read at every session start by every consumer. Documentation packages have none.

An abstract ability a package provides or requires, written `namespace:name` with an optional version constraint; the resolver matches requirers with providers at install time.

Documentation of a package that declares its subject but is not named by the subject: shown on the site with its publisher, below the official shelf. See *official documentation*.

A package tied to another by name for the default case of officiality and by nothing else: the documentation `<name>-docs` of a package, or the translation `<docname>-<lang>` of a documentation. A companion keeps its own version line and stays outside family unison.

A binding of a handler to an extension point, declared as an `[[extension]]` table in a package or a project; the unit the lifecycle runs and reports.

The name of a package: a group, a slash and a name, `org.vibevm.world/wal`, with `@version` when a version is meant. The kind is not part of it.

A named, ordered list of targets and the providers that apply packaged artifacts to them; `vibe deploy` runs one profile, `vibe undeploy` reverses it.

The packages that the visibility marks admit from your root: what version resolution sees, what the lock file records and what the dependency tree holds. A private edge of a package that is not your root lies outside it.

The in-tree packages of a source-built vibe, consulted automatically as a registry: first for a developer's build, after the declared registries for a distributed one.

A named place in the lifecycle a contribution binds to: a phase, a slot inside a phase, or a position in the boot compiler, written `family:name`.

One anchored unit of a specification with a status: a rule, a decision, a lead-in. In XML an element named after its id with `fact="true"`; in Markdown a paragraph opening with `@fact:ID`. The addressable atom an agent cites.

A set of packages sharing a name stem that move in unison: the bundle `<family>`, the language guide `<family>-lang`, the server `<family>-mcp`. A change to any member bumps every member to one version.

An optional, additive content set of a package, declared in `[features]` and activated at install; features may depend on features.

The hash of a package's shippable tree, the identity half of a package version, recorded as `content_hash` in the lock file and verified on every fetch.

The hash of a phase run's declared inputs, recorded under `.vibe/`; a phase whose freshness fingerprint did not change is skipped on the next run.

The packages a project has befriended, directly with `friend = true` or a `friends` line, or through a chain of friends-only edges. A friends-only dependency reaches only the projects whose friend closure contains its provider.

A dependency declared by a git repository and a tag, commit or branch instead of a registry; identity and fingerprint discipline are the same, and a branch is re-walked on update.

What a contribution runs: a built-in, a script, a binary, a native library, or an agent prompt.

A package's `pre-install` or `post-install` script, run in the package's slot; installing the package is the consent to run it, and its effects are not tracked.

A repository beside a registry's packages that records every published version's summary and fingerprint; a cache that speeds search and cold installs and is never the truth.

What a package is for, one of eight: `flow`, `feat`, `stack`, `tool`, `lang`, `mcp`, `doc`, `app`. Metadata, not identity; the set grows only by amendment.

The fixed order of build steps vibe runs: the one-phase `clean` lifecycle and the nine-phase `default` lifecycle from `validate` to `deploy`. See *phase*.

How a dependency's boot snippet enters a consumer's lane: `static`, compiled into `STATIC.md`, or `dynamic`, listed in `INDEX.md` and read on demand; set by the consumer, suggested by the package.

`vibe.lock`: the recorded resolution, one per workspace, with every package's exact version, fingerprint and provenance. Written by vibe, committed by you.

The region between the lines `<vibevm>` and `</vibevm>` at the end of `CLAUDE.md`, `AGENTS.md` and `GEMINI.md`, the only part of those files vibe writes; it points an agent at the boot lane.

`vibe.toml`: the one file you write to describe a project, a package or a workspace; its tables decide the node's role.

A program an agent talks to over the Model Context Protocol. vibe's own server exposes a project's packages; a package of kind `mcp` delivers servers of its own.

An alternative address for the same registry, tried for availability and verified against the same fingerprints; never recorded in the lock file.

Documentation whose edges converge: the subject names the package in `[documentation]` or by the `-docs` convention, and the package names the subject in `[[documents]]`. One may be primary. Computed at every render, stored nowhere as a flag.

A replacement source for one coordinate that short-circuits the registries; marked in the lock file so nobody mistakes it for a published version. The same word names the `[override]` table that rewrites the visibility marks of edges you do not own.

The unit vibe installs: a folder with a manifest and the text or tools it delivers, published as its own repository, identified by its coordinate, version and content hash. A package is a project made installable.

One step of a lifecycle: `validate`, `install`, `generate`, `build`, `test`, `create`, `verify`, `package`, `deploy`. Naming a phase runs every phase before it.

Any folder with a `vibe.toml`; a consumer of packages, marked by a `[project]` table, or a workspace of them.

What answers how a mechanism runs: a built-in or a package-supplied implementation of a build, package or deploy step, or a model endpoint behind an agent handler. Selected by exact route or pin.

The record a deploy writes for every resource it created: what, where, under which generation, owned by which profile. The only authority for removal.

A hosting organisation where packages are published, one repository per package; a project lists the registries it trusts in order.

The mailbox under `.vibe/agentic/` where vibe parks an instruction it cannot execute itself; the agent drains it with `vibe command`.

The terminal removal of the vibe layer from a project, by contract, with a plan and a health proof; not to be confused with `clean`.

A file a package declares in `[[skill]]` that teaches an agent something; `vibe skill install` projects it into the agents' skill folders.

The normative text of a package or a project under `vibevm/vibespecs/`: addressable units with statuses, in Markdown or the XML dialect. What documentation quotes and never restates.

The machine-wide cache of fetched package versions under `~/.vibe/cache/`, keyed by identity, shared by every project, emptied only on request.

A package that a documentation package documents, named in its `[[documents]]` table with a version range.

A selectable cut of a package's content, activated by the consumer's context, such as the library version a project uses.

`specmap.json`: the generated graph of specification units, tagged code items and the edges between them, checked by the build and queried by `vibe explain`, `vibe query` and `vibe select`.

A separate documentation package in another language that names its source in `[translates]` and mirrors its tree; official when published by the source's group under `<docname>-<lang>`. See *adaptation*.

What a manifest asks for: a range such as `^1.0`, an exact `=1.2.0`, or nothing for the newest stable. The lock file records the one version the resolver chose within it.

A repository developing several packages together, declared by a `[workspace]` table listing member paths; one lock file at the root and one unified resolution across members.