# Глоссарий {#root}

@status:doc/work @audience:user,author,dev,agent

[p01] Одно определение на термин, и это единственное место, где термин определён. Каждая другая страница ведёт сюда, когда впервые употребляет слово из этого списка; рядом с русским термином стоит английский, потому что команды, манифесты и спецификации говорят по-английски.

## адаптация {#adaptation}

[p02] Версия документации на другом языке (*adaptation*): отдельный пакет, который зеркалит источник блок в блок и свободен предложение за предложением. В этом руководстве «перевод» и «адаптация» значат одно и то же. См. *перевод*.

> [p03] **The source language is English.** `org.vibevm.core/vibevm-docs` carries `[i18n].canonical = "en"`. Every other language, Russian included, is an **adaptation** published as its own package (§5): a mirror block for block, free sentence for sentence, with its own jokes and its own glossary of terms. Machine translation may produce a draft and never the text.
>
> <spec://org.vibevm.core/vibevm/common/PROP-057#STYLE-SOURCE-LANGUAGE>

## сессия агента {#agent-session}

[p04] Один запуск агента-кодера в проекте (*agent session*): от момента, когда он читает файл с инструкциями, до момента, когда останавливается. Стартовая полоса — это то, что vibe готовит к началу сессии.

## якорь {#anchor}

[p05] Идентификатор раздела или факта внутри спецификации (*anchor*), часть адреса после `#`. Опубликованный якорь никогда не меняется; переименование оставляет надгробие.

> [p06] **Anchors are immutable; a rename is a tombstone** — for published documentation pages as for specs, and for translations, which must match their source.
>
> <spec://org.vibevm.core/vibevm/common/PROP-057#INV-ANCHORS-IMMUTABLE>

## номер блока {#block-number}

[p07] Порядковый номер `pNN`, который каждый блок страницы документации получает при сборке (*block number*); он один и тот же в веб-странице, в Markdown и в XML, так что человек и агент ссылаются на одно место. Он называет текущий текст и может сдвинуться после правки, как номер строки.

> [p08] **Numbered blocks.** Every flow block of the pivot — paragraph, list, table, fence, quote, `example`, `rule`, `note`, `figure`, `prompt`; a heading keeps its own id and is not numbered (clarified 2026-09-12 at implementation, following `PIPE-NUMBERING`) — receives an ordinal number and the id `pNN` **at build time** in the Rust pipeline (§10), never by a client script. The number is the block's position in the **current** text of the page, counted before `when` filtering, so that `p12` names the same block in the build for any platform and agent and in every translation; gaps in the rendered output are accepted. The number appears in the HTML island, in the `.md` and `.xml` projections (as `[p12]` at the start of the block) and in `llms-full.txt`, so a human and an agent cite one place. After an edit an old `#p12` may point at a neighbouring block, as a link to a file line does after an edit; this is accepted and nothing tries to «remember» it. Headings keep their named anchors `{#id}` above the number; named anchors are immutable and renamed only by tombstone, positional `pNN` live by the current text.
>
> <spec://org.vibevm.core/vibevm/common/PROP-057#READER-NUMBERED-BLOCKS>

## стартовая полоса {#boot-lane}

[p09] Упорядоченный список чтения, по которому агент идёт в начале сессии (*boot lane*): управляемый блок в файле с инструкциями, затем `STATIC.md` целиком, затем записи `INDEX.md`. Вычисляется vibe из графа зависимостей, руками не пишется никогда.

> [p10] **Session-start order:** the `CLAUDE.md` / `AGENTS.md` / `GEMINI.md` redirect → `vibevm/vibespecs/boot/STATIC.xml` (if present) → `vibevm/vibespecs/boot/INDEX.md` and the entries it names, in order.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-workspace/PROP-009#SESSION-START-ORDER>

## стартовый фрагмент {#boot-snippet}

[p11] Вклад пакета в стартовую полосу (*boot snippet*): один короткий текст, объявленный в `[boot_snippet]` с категорией, который каждый потребитель читает при каждом старте сессии. У пакетов документации его нет.

> [p12] `[boot_snippet]` (package-role) drops the `filename` field (the `NN-` target name) and gains `category` (§2.5); `source` — the path to the boot file inside the package — is retained. It may carry an optional suggested `link` default, and an optional **`when`** activation condition — the declaration site for §2.3's dynamic-entry `when`, closing the gap Phase 4 flagged. For v1 the only `when` is an operating-system match, the wire string `"os:<name>"` with `<name>` one of `windows` / `macos` / `linux`; a snippet carrying a `when` is `dynamic` (§2.4). The package author owns this declaration: whether a boot snippet is OS-specific is the author's knowledge, not the consumer's.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-workspace/PROP-009#SCHEMA-BOOT-SNIPPET>

## возможность {#capability}

[p13] Абстрактное умение, которое пакет предоставляет или требует (*capability*), записывается как `namespace:name` с необязательным ограничением версии; при установке резолвер сводит требующих с предоставляющими.

> [p14] **Decision.** A package's identity is the tuple `(kind, name, version, content_hash)`. The `content_hash` is a digest over the deterministically-ordered concatenation of `(rel_path_bytes || 0x00 || file_bytes || 0x00)` for every file in the package directory, and **the value names the recipe that produced it** ([PROP-044 §4.7](../../common/PROP-044-change-native-formats.xml#machinery)): `sha256-tree/1:<hex>` is recipe 1, whose exclusion list, path normalisation and traversal order are carried as data in `formats/hash_recipes/1.toml`; the bare `sha256:<hex>` is recipe 0, the pre-recipe form, frozen verbatim in code — not configurable, because a frozen recipe that can be edited is not frozen — so that values written before recipes were named stay readable. Two hashes are comparable only **at the same recipe**; comparing across recipes answers a question nobody asked, and is never done silently. [PROP-024 §2.2](../../common/PROP-024-code-bearing-packages.xml#shippable-tree) re-scopes this to the package's **shippable tree** — its source, minus build output (`.git/`, `.vibe/`, `target/`, `node_modules/`, `.vibeignore` globs) — so a code-bearing package's identity is its source, not its build state; that exclusion lands with the code that implements it. The URL used to fetch the content is **informational** — recorded in the lockfile for debuggability, not for identity.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-registry/PROP-002#IDENTITY-TUPLE>

## документация сообщества {#community}

[p15] Документация пакета, которая объявляет свой предмет, но предметом не названа (*community documentation*): на сайте показывается со своим издателем, ниже официальной полки. См. *официальная документация*.

> [p16] **Official** documentation is the one whose edges converge: the subject named the package and the package declared the subject. **Community** documentation has only the edge from the documentation. An edge from the subject alone reads «not published or an error», and the site shows a warning.
>
> <spec://org.vibevm.core/vibevm/common/PROP-057#REL-OFFICIAL-IS-CONVERGENCE>

## компаньон {#companion}

[p17] Пакет, связанный с другим по имени ради умолчания об официальности и ничем больше (*companion*): документация `<name>-docs` пакета или перевод `<docname>-<lang>` документации. Компаньон держит собственную линию версий и не входит в унисон семейства.

> [p18] **`<family>-docs`** — the *documentation companion* (`kind = "doc"`,
>   [PROP-057 §3](PROP-057-documentation-packages-and-site.xml)): the
>   official-by-default documentation of the family's subject, in the subject's
>   group. Unlike the three code roles it is a **companion, not a member**: it
>   is never pinned by the aggregator, it does not take part in the family's
>   unison (§2.2), it keeps its own version line, and it states compatibility
>   with its subject through the version constraint of its `[[documents]]`
>   table. Its translations follow the same companion form, one package per
>   language, named `<family>-docs-<lang>` with a lower-case BCP-47 tag
>   (`rust-ai-native-docs-ru`). Amended 2026-09-11.
>
> <spec://org.vibevm.core/vibevm/common/PROP-028#ROLE-DOCS>

## вклад {#contribution}

[p19] Привязка обработчика к точке расширения (*contribution*), объявленная таблицей `[[extension]]` в пакете или проекте; единица, которую жизненный цикл выполняет и о которой отчитывается.

> [p20] A **contribution** binds a handler to a point. It is declared as an `[[extension]]` table — in a **package** manifest (the package ships and offers the behaviour) or in the **project** manifest (the host adds its own). The shape is one grammar for every family:
>
> <spec://org.vibevm.core/vibevm/common/PROP-054#CONTRIB-GRAMMAR>

## координата {#coordinate}

[p21] Имя пакета (*coordinate*): группа, косая черта и имя, `org.vibevm.world/wal`, с `@version`, когда имеется в виду версия. Вид в неё не входит.

> [p22] **Decision.** Package identity becomes `(group, name, version, content_hash)`. `kind` **leaves the identity tuple**.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-registry/PROP-008#IDENTITY-TUPLE>

## профиль выкладки {#deploy-profile}

[p23] Именованный упорядоченный список целей и провайдеров, которые применяют к ним упакованные артефакты (*deploy profile*); `vibe deploy` выполняет один профиль, `vibe undeploy` откатывает его.

> [p24] 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`.
>
> <spec://org.vibevm.core/vibevm/common/PROP-054#R8-DEPLOY-RUNTIME>

## действующее множество {#effective-set}

[p25] Пакеты, которые метки видимости пропускают от вашего корня (*effective set*): то, что видит подбор версий, что записывает лок-файл и что держит дерево зависимостей. Приватное ребро пакета, который не ваш корень, лежит вне его.

> [p26] Version resolution operates on `E(R)` only: private edges of non-root packages contribute no constraints, fetch nothing, and cannot conflict. `vibe.lock` records `E(R)` — the lock of a consumer no longer contains other packages' dev-world entries. Version unification (one node per `(group, name)`, PROP-003/017) is unchanged *within* the effective set. A welcome simplification vs code ecosystems: the Cargo-RFC-1977 problem («may private deps duplicate at different versions?») does not arise — an invisible package has no copies at all.
>
> <spec://org.vibevm.core/vibevm/common/PROP-050#RESOLVE-EFFECTIVE-ONLY>

## встроенный реестр {#embedded-registry}

[p27] Пакеты из дерева исходников собранного из них vibe, к которым он обращается автоматически как к реестру (*embedded registry*): первым — в сборке разработчика, после объявленных реестров — в распространяемой.

> [p28] This PROP makes the in-tree `packages/` of a source-installed `vibe` an
> **ambient default registry** — resolved automatically, with zero configuration
> in the consuming project.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-registry/PROP-030#AMBIENT-DEFAULT>

## точка расширения {#extension-point}

[p29] Именованное место в жизненном цикле, к которому привязывается вклад (*extension point*): фаза, слот внутри фазы или позиция в компиляторе полосы, записывается как `family:name`.

> [p30] An **extension point** is a string `<family>:<name>`. Three families: **`phase:`** — the default-lifecycle phases and `clean` (project-scoped moments: `phase:build`, `phase:create`, …); **`compile:`** — the compiler's two tiers: the §7.2 staged positions (`compile:source`, `compile:document`, `compile:lane`, `compile:emitted`) and the §7.4 pass tier's single point `compile:pass`, whose position inside the pipeline is carried by the contribution's `pass = { … }` declaration; **`slot:`** — the per-package materialisation moments that already exist as PROP-020 (`slot:pre-install`, `slot:post-install`), re-stated in this vocabulary without changing their semantics, timing, or manifest spelling ([`[hooks]`](../modules/vibe-workspace/PROP-020-install-hooks.xml#manifest) keeps working verbatim; it is now sugar for two `slot:` contributions).
>
> <spec://org.vibevm.core/vibevm/common/PROP-054#POINT-GRAMMAR>

## факт {#fact}

[p31] Одна заякоренная единица спецификации со статусом (*fact*): правило, решение, вводная. В XML — элемент, названный по своему идентификатору, с `fact="true"`; в Markdown — абзац, начинающийся с `@fact:ID`. Адресуемый атом, на который ссылается агент.

> [p32] **Decision (ADR-part; owner ruling 2026-08-22,
> verbatim): «сконвертируй и факты тоже. Предлагаю такой формат
> `<fact-name fact="true" ...>`. Таким образом кастомный XML-парсер всегда
> может найти соответствующие элементы».** A fact serialises with its ID
> as the element name, carrying the DISCRIMINATOR attribute —
> `<THE-LAW fact="true" status="impl/done">body</THE-LAW>` — so a reader
> that knows nothing of the vocabulary still finds every fact by one
> attribute test. The recognition law: an element IS a fact iff its name
> is `fact` (the generic form, which stays in the dialect) or it carries
> `fact="true"`. The named form is emitted whenever the id passes the
> same elementability predicate sections use (fact-id grammar already
> forbids leading digits, so the fallback tail is vocabulary collisions
> only); the typed-fact fence binding stays by id and does not change.
> The owner's second clause binds the scanners: the progress machinery
> must work when a fact's SOURCE — not a materialised copy — is authored
> XML; the host lane holds by construction (XML sources enter progress
> through the canonical MD projection) and is PINNED by explicit tests
> (an observed .xml source scans unit-for-unit equal to its MD twin),
> while the specmap engine's native reader learns the named form
> mirror-wise. The converter recipe bumps again (`specdoc/2` →
> `specdoc/3`); the host re-materialises once, after both shapes land.
> The owner's third clause (2026-08-22, same sitting) binds the boot
> lanes: «статические и динамические лоадеры должны хорошо работать с
> новым синтаксисом фактов» — pinned at the transition's landing by (a)
> the static-splice determinism test running over a NAMED-shape snippet
> whose projected facts survive into STATIC, (b) the vibe-spec
> normal-closure byte-equality test running over BOTH serialisations
> (generic and named) of one dependency, and (c) the polygon re-run at
> specdoc/3, whose control package auto-adopts the named shape through
> to_xml — INDEX targets, STATIC splice and every machine loader then
> exercise the final syntax end-to-end; the agent half of the dynamic
> router is §5a's measurement, deliberately run AFTER this transition so
> it measures the shape that ships. Landed: the recipe is `specdoc/3`,
> the host's 37 slots re-materialised once with named facts live (the
> redbook README golden pins 45), the recognition law holds in both
> readers with `fact="false"` a loud error, progress holds full
> ParsedDoc parity between an XML source and its hand-pinned MD twin
> across two scans, and pins (a)–(c) are in the tree — the splice
> snippet ships `<BOOT-RULE fact="true">`, the normal closure compiles
> three lanes byte-equal, the polygon re-ran 3/3. A live lesson worth
> its line: XML reserves every case-insensitive `xml`-prefixed name, so
> `XMLBOOT` cannot be an element — the predicate refuses it and the
> generic form carries such ids.
>
> <spec://org.vibevm.core/vibevm/common/PROP-045#NAMED-FACT-ELEMENTS>

## семейство {#family}

[p33] Набор пакетов с общей основой имени, которые движутся в унисон (*family*): бандл `<family>`, языковой гайд `<family>-lang`, сервер `<family>-mcp`. Изменение любого члена поднимает всех до одной версии.

> [p34] A **package family** is a set of packages sharing a `<family>` stem and
> delivering one coherent capability across three roles:
>
> <spec://org.vibevm.core/vibevm/common/PROP-028#FAMILY-DEF>

## фича {#feature}

[p35] Необязательный добавочный набор содержимого пакета (*feature*), объявленный в `[features]` и включаемый при установке; фичи могут зависеть от фич.

> [p36] **Decision.** A package's `vibe-package.toml` gains a `[features]` table describing optional, conditionally-activated components:
>
> <spec://org.vibevm.core/vibevm/modules/vibe-resolver/PROP-003#FEATURES-TABLE>

## отпечаток {#fingerprint}

[p37] Хэш поставляемого дерева пакета (*fingerprint*), половина идентичности версии пакета; записывается как `content_hash` в лок-файл и проверяется при каждом скачивании.

> [p38] `content_hash` is unchanged — computed over package file bytes per [PROP-002 §2.1](PROP-002-decentralized-registry.xml#identity). `group` lives in `vibe.toml`, so it influences the hash only as ordinary file content; the tuple lists it explicitly so that changing `group` yields a different package.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-registry/PROP-008#HASH-UNCHANGED>

## отпечаток свежести {#freshness-fingerprint}

[p39] Хэш объявленных входов прогона фазы (*freshness fingerprint*), записанный под `.vibe/`; фаза, чей отпечаток свежести не изменился, при следующем прогоне пропускается.

> [p40] **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.
>
> <spec://org.vibevm.core/vibevm/common/PROP-054#PHASE-FINGERPRINT>

## замыкание друзей {#friend-closure}

[p41] Пакеты, с которыми проект подружился (*friend closure*): напрямую, через `friend = true` или строку `friends`, либо по цепочке рёбер «только для друзей». Зависимость «только для друзей» доходит лишь до проектов, чьё замыкание друзей содержит её поставщика.

> [p42] `access = "friends-only"` — `Q` seeps through `P` only into consumers whose friend closure contains `P` (§2.4): those who deliberately named `P` (directly or transitively) a friend. The curated middle.
>
> <spec://org.vibevm.core/vibevm/common/PROP-050#ACCESS-FRIENDS>

## git-источник {#git-source}

[p43] Зависимость, объявленная git-репозиторием и тегом, коммитом или веткой вместо реестра (*git source*); дисциплина идентичности и отпечатков та же, а ветка при обновлении обходится заново.

> [p44] **Identity.** Identical content-hash discipline as registry-resolved (§2.1): identity is `(kind, name, version, content_hash)`; the URL is informational. Two projects that pull the same git-source from different mirrors and produce the same `content_hash` are bit-identical installs. Force-pushed tag rewrite caught as `IntegrityError`.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-registry/PROP-002#GS-IDENTITY>

## обработчик {#handler}

[p45] То, что выполняет вклад (*handler*): встроенная функция, скрипт, бинарник, нативная библиотека или промпт агента.

> [p46] A contribution's `handler.kind` is one of five. Two wrap machinery that exists; three are new. All five are legal at every `phase:`/`slot:` point; the `compile:` family accepts `builtin` and `native` only (§8.5 explains why).
>
> <spec://org.vibevm.core/vibevm/common/PROP-054#HANDLER-KINDS>

## хук {#hook}

[p47] Скрипт пакета `pre-install` или `post-install` (*hook*), выполняемый в слоте пакета; установка пакета и есть согласие его запустить, а его последствия не отслеживаются.

> [p48] A package may declare `pre-install` / `post-install` scripts in its manifest.
>   vibevm runs them at fixed points in the install pipeline, in the package's own
>   materialised slot, choosing the right interpreter for the host OS.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-workspace/PROP-020#WHAT-HOOKS-ARE>

## индекс (реестра) {#index-registry}

[p49] Репозиторий рядом с пакетами реестра, где записаны сводка и отпечаток каждой опубликованной версии (*index*); кэш, который ускоряет поиск и холодные установки и никогда не служит истиной.

> [p50] **Decision.** Package repositories are the **source of truth** for content (manifests, files, tags). The index is a **derived hot cache**, regeneratable from the authoritative package state.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-index/PROP-005#REPOS-AUTHORITATIVE>

## вид {#kind}

[p51] Для чего пакет нужен (*kind*), один из восьми: `flow`, `feat`, `stack`, `tool`, `lang`, `mcp`, `doc`, `app`. Метаданные, а не идентичность; набор растёт только поправкой.

> [p52] `kind ∈ {flow, feat, stack, tool, mcp, lang, doc, app}` — eight kinds; `mcp` shipped with [PROP-027](../modules/vibe-mcp/PROP-027-mcp-packages.xml); `doc` and `app` admitted by [PROP-057](PROP-057-documentation-packages-and-site.xml) through the `VIBEVM-SPEC.md` §4.1 amendment of 2026-09-12 (pending the owner's ratification at the merge of the docs-2026-09 branch; the code learns the two kinds in that campaign's phase 2). (§Invariants `INV-VOCABULARY` in this file carries the same list.)
>
> <spec://org.vibevm.core/vibevm/common/PROP-000#KIND-SET>

## жизненный цикл {#lifecycle}

[p53] Фиксированный порядок шагов сборки, которые выполняет vibe (*lifecycle*): однофазный цикл `clean` и девятифазный цикл `default` от `validate` до `deploy`. См. *фаза*.

> [p54] vibe has **two** lifecycles. **`clean`** — one phase, exactly PROP-053. **`default`** — nine phases, in this fixed order:
>
> <spec://org.vibevm.core/vibevm/common/PROP-054#LIFECYCLES>

## тип связи {#link-type}

[p55] Как стартовый фрагмент зависимости попадает в полосу потребителя (*link type*): `static` — вкомпилирован в `STATIC.md`, или `dynamic` — перечислен в `INDEX.md` и читается по требованию; задаёт потребитель, предлагает пакет.

> [p56] **Decision.** Each dependency declares an **inclusion type**, set by the consumer in its `vibe.toml` on the `[requires.packages]` entry:
>
> <spec://org.vibevm.core/vibevm/modules/vibe-workspace/PROP-009#INCLUSION-TYPES>

## лок-файл {#lock-file}

[p57] `vibe.lock`: записанный результат подбора (*lock file*), один на рабочее пространство, с точной версией, отпечатком и происхождением каждого пакета. Пишет vibe, коммитите вы.

> [p58] With the freshness check, **`vibe install` becomes lockfile-respecting**: unchanged `[requires]` ⇒ the locked versions are honoured verbatim.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-workspace/PROP-011#LOCKFILE-RESPECTING>

## управляемый блок {#managed-block}

[p59] Область между строками `<vibevm>` и `</vibevm>` в конце `CLAUDE.md`, `AGENTS.md` и `GEMINI.md` (*managed block*), единственная часть этих файлов, которую пишет vibe; она указывает агенту на стартовую полосу.

> [p60] **Decision.** `vibe` owns exactly one **managed block** inside each agent instruction file — a contiguous region bounded by an opening and a closing marker.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-workspace/PROP-012#ONE-BLOCK-LAW>

## манифест {#manifest}

[p61] `vibe.toml`: единственный файл, который вы пишете, чтобы описать проект, пакет или рабочее пространство (*manifest*); его таблицы решают, какую роль играет узел.

> [p62] **Decision.** `vibe-package.toml` is **retired as a distinct filename**. Every node — project root, workspace member, published package — carries a single `vibe.toml`; the role is expressed by which sections are present. This is the cargo model: one `Cargo.toml` carries `[package]` and/or `[workspace]`.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-workspace/PROP-007#ONE-MANIFEST>

## MCP-сервер {#mcp-server}

[p63] Программа, с которой агент общается по Model Context Protocol (*MCP server*). Собственный сервер vibe открывает пакеты проекта; пакет вида `mcp` поставляет свои серверы.

> [p64] An **`mcp` package** is one whose primary deliverable is one or more
> Model Context Protocol servers.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-mcp/PROP-027#MCP-KIND-DEF>

## зеркало {#mirror}

[p65] Запасной адрес того же реестра (*mirror*), к которому обращаются ради доступности и который проверяют по тем же отпечаткам; в лок-файл не записывается никогда.

> [p66] A `[[mirror]]` is an **availability copy of the same source** — same naming, same identity, same `content_hash`. The mirror walk falls through on **any availability failure** (`NetworkUnreachable`, `AuthFailed` on the mirror, server error, `content_hash` mismatch). `RepoNotFound` from a mirror bubbles up to the registry-walk layer (same policy as if the canonical primary had said `UnknownPackage`), because absence-of-package is a registry-level fact, not a mirror-level one.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-registry/PROP-002#MIRROR-WALK-SEMANTICS>

## официальная документация {#official}

[p67] Документация, у которой сходятся рёбра (*official documentation*): предмет называет пакет в `[documentation]` или по соглашению `-docs`, а пакет называет предмет в `[[documents]]`. Одна из них может быть первичной. Вычисляется при каждом рендере, флагом не хранится нигде.

> [p68] Officiality is never stored as a flag: it is computed from the convergence of edges at every render. A field `official = true` in a manifest or an index is a design error.
>
> <spec://org.vibevm.core/vibevm/common/PROP-057#REL-NO-OFFICIAL-FLAG>

## переопределение {#override}

[p69] Замещающий источник для одной координаты, который обходит реестры (*override*); в лок-файле помечен, чтобы никто не принял его за опубликованную версию. Тем же словом названа таблица `[override]`, переписывающая метки видимости рёбер, которыми вы не владеете.

> [p70] **Decision.** `[[override]]` bypasses the registry layer for a named pkgref:
>
> <spec://org.vibevm.core/vibevm/modules/vibe-registry/PROP-002#OVERRIDE-SHORT-CIRCUIT>

> [p71] **Owner-ruled (2026-08-23): `override` is lawful in any manifest, not only the root** («разрешён не только в корневом манифесте, а где угодно»). Any node `N` may carry an `[override]` table whose entries rewrite *foreign* edges — their `access`, `friend`, presence (`exclude = true`), or a target's `allow-friends` — and the rewrite acts wherever `N` stands on the chain: an aggregator repairs or reshapes a member's edge for **all of its own consumers**, exactly as it curates its delivery with `exclude`. The threat model follows the owner's earlier ruling: a deliberate break-in is not an attack (the developer can edit any file on disk anyway); this is the official verb that replaces reflection-style hacks — and it stays **quiet** (pull-based provenance only).
>
> <spec://org.vibevm.core/vibevm/common/PROP-050#OVERRIDE-ANYWHERE>

## пакет {#package}

[p72] Единица, которую устанавливает vibe (*package*): папка с манифестом и тем текстом или инструментами, которые она приносит; публикуется как собственный репозиторий, опознаётся по координате, версии и хэшу содержимого. Пакет — это проект, который сделали устанавливаемым.

> [p73] **Decision.** A package has the identical on-disk shape as a consumer project:
>
> <spec://org.vibevm.core/vibevm/common/PROP-024#PKG-PROJECT-LAW>

## фаза {#phase}

[p74] Один шаг жизненного цикла (*phase*): `validate`, `install`, `generate`, `build`, `test`, `create`, `verify`, `package`, `deploy`. Назвать фазу — значит выполнить все фазы до неё.

> [p75] `vibe <phase>` executes every default-lifecycle phase up to and including the named one, in order — the Maven ritual verbatim. `vibe clean <phase>` runs the clean lifecycle first, then the default lifecycle up to `<phase>` (§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).
>
> <spec://org.vibevm.core/vibevm/common/PROP-054#INVOKE-RUNS-PRIORS>

## проект {#project}

[p76] Любая папка с `vibe.toml` (*project*); потребитель пакетов, помеченный таблицей `[project]`, или рабочее пространство таких потребителей.

> [p77] `[package]` and `[project]` are **mutually exclusive** in one file — a node is either a publishable package or a plain project, not both. (Decision 7-α from the design session: keep the two sections distinct rather than folding `[project]` into a `[package]` with optional `kind`. Explicitness wins; `kind` stays strictly mandatory wherever `[package]` appears.)
>
> <spec://org.vibevm.core/vibevm/modules/vibe-workspace/PROP-007#PACKAGE-XOR-PROJECT>

## провайдер {#provider}

[p78] То, что отвечает за исполнение механизма (*provider*): встроенная или поставленная пакетом реализация шага сборки, упаковки или выкладки либо модельная конечная точка за обработчиком-агентом. Выбирается точным маршрутом или пином.

> [p79] 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`.
>
> <spec://org.vibevm.core/vibevm/common/PROP-054#R8-NATIVE-DEPLOY-PROVIDER>

## квитанция {#receipt}

[p80] Запись, которую выкладка делает о каждом созданном ресурсе (*receipt*): что, где, под каким поколением, каким профилем владеется. Единственное основание для удаления.

> [p81] 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`.
>
> <spec://org.vibevm.core/vibevm/common/PROP-054#R8-DEPLOY-RUNTIME>

## реестр {#registry}

[p82] Хостинг-организация, где публикуются пакеты, по репозиторию на пакет (*registry*); проект перечисляет реестры, которым доверяет, по порядку.

> [p83] Each package is its **own** git repository — no monorepo. Per-package maintainer permissions are hosting-native (a package repo's owner controls access); no central merge queue.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-registry/PROP-002#SHAPE-OWN-REPO>

## эстафета {#relay}

[p84] Почтовый ящик под `.vibe/agentic/`, куда vibe кладёт инструкцию, которую не может выполнить сам (*relay*); агент разбирает его командой `vibe command`.

> [p85] **Decision.** When a reasoning operation runs under the relay backend, it
>   does not act. It writes an `Intent` — a markdown prompt with light
>   frontmatter (id, source command, created-at, status) — to a **single-slot
>   mailbox**, the project-local `.vibe/agentic/command.md` (§3), and returns a
>   pointer telling the caller to drain it.
>
> <spec://org.vibevm.core/vibevm/common/PROP-018#RELAY-PARKS>

## scrape {#scrape}

[p86] Окончательное снятие слоя vibe с проекта, по контракту, с планом и доказательством здоровья; у слова нет устоявшегося русского эквивалента, команда так и называется — `vibe scrape`. Не путать с `clean`.

> [p87] Scrape
>     is the terminal cleaning operation defined here: it removes the selected
>     VibeVM repository layer while preserving the native product. The command
>     vocabulary deliberately reserves attach and
>     detach for a future live-tool relationship such as connecting
>     and disconnecting a debugger. Scrape is never an alias for that future
>     runtime operation, and no detach spelling is accepted by this command.
>
> <spec://org.vibevm.core/vibevm/common/PROP-056#SCRAPE-TERM-BOUNDARY>

## навык {#skill}

[p88] Файл, который пакет объявляет в `[[skill]]` и который чему-то учит агента (*skill*); `vibe skill install` проецирует его в папки навыков агентов.

> [p89] **Decision.** Installing a skill into an agent is a **projection**: read the
>   declared skill body from the package (in `vibedeps/…` once installed) or an
>   external source authenticated by the package's matching lock record, and
>   write it into each target agent's skill directory in that agent's own
>   convention (`.claude/skills/<name>/…`, `.opencode/skills/<name>/…`,
>   `.agents/skills/<name>/…` — the paths PROP-015 §2.6 already resolves).
>
> <spec://org.vibevm.core/vibevm/common/PROP-018#PROJECTION-DEF>

## спецификация {#specification}

[p90] Нормативный текст пакета или проекта под `vibevm/vibespecs/` (*specification*): адресуемые единицы со статусами, в Markdown или в XML-диалекте. То, что документация цитирует и никогда не пересказывает.

> [p91] <spec://org.vibevm.world/addressable-specs/flows/addressable-specs/ADDRESSABLE-SPECS-PROTOCOL#THE-SPEC-TREE-IS-THE-ONLY-CHANNEL>

## хранилище {#store}

[p92] Общий для машины кэш скачанных версий пакетов под `~/.vibe/cache/` (*store*), с ключом по идентичности, общий для всех проектов, очищается только по просьбе.

> [p93] **Decision (override clause corrected 2026-08-20 to the later, more specific ruling).** The package store is **machine-global**, not project-scoped — one store per machine at `<settings-home>/cache`, relocated only with the settings home (`$VIBE_SETTINGS`); **no store-specific override exists** — [`##THE-STORE-IS-DOT-VIBE-CACHE`](#layout) is the governing ruling. (`VIBE_REGISTRY_CACHE`, which this decision originally named, governs the registry **clone** cache — a different layer that keeps its own job.)
>
> <spec://org.vibevm.core/vibevm/modules/vibe-registry/PROP-010#CACHE-MACHINE-GLOBAL>

## предмет {#subject}

[p94] Пакет, который документирует пакет документации (*subject*); назван в его таблице `[[documents]]` с диапазоном версий.

> [p95] `[[documents]]` is REQUIRED in a `doc` package, may list several subjects, and its `version` is a semver constraint.
>
> <spec://org.vibevm.core/vibevm/common/PROP-057#REL-DOCUMENTS-REQUIRED>

## поднавык {#subskill}

[p96] Выбираемый срез содержимого пакета (*subskill*), включаемый контекстом потребителя, например версией библиотеки, которую использует проект.

> [p97] Per §2.7 of [PROP-004](../../../legacy-spec/research/PROP-004-tessl-comparative-research.md#purl), Tessl's headline marketing claim — version-matched documentation — rides on the `describes` field at the tile level. vibevm goes one step further: the field is available **on subskills as well as packages**. A `flow:wal` package as a whole may not bind to any one library, but its `subskills/stack/rust/` cut binds specifically to `pkg:cargo/sqlx@0.8.0`; another `subskills/stack/rust-diesel/` cut binds to `pkg:cargo/diesel@2.x`. The two coexist in the same package, and the activation channel `context.if_describes_match` selects the right one for the consumer's actual library version.
>
> <spec://org.vibevm.core/vibevm/modules/vibe-resolver/PROP-003#DESCRIBES-ON-SUBSKILLS>

## карта прослеживаемости {#traceability-map}

[p98] `specmap.json`: сгенерированный граф единиц спецификации, помеченных элементов кода и рёбер между ними (*traceability map*); его проверяет сборка и запрашивают `vibe explain`, `vibe query` и `vibe select`.

> [p99] **Invariants are machine-checked.** Dangling references, uncovered requirements, orphan code, and — the load-bearing one — **staleness**: a spec unit carries a revision + content hash; when it changes, every edge pinned to the old revision flips to *suspect* until re-affirmed.
>
> <spec://org.vibevm.ai-native/core-ai-native/mechanisms/PROP-014#FORCE-INVARIANTS-ARE-MACHINE-CHECKED>

## перевод {#translation}

[p100] Отдельный пакет документации на другом языке (*translation*), который называет свой источник в `[translates]` и зеркалит его дерево; официален, когда опубликован группой источника под именем `<docname>-<lang>`. См. *адаптация*.

> [p101] An **official** translation is one that declared `translates` on the source and is published by the **same group** as the source under the name `<docname>-<lang>`; everything else is a community translation (§6).
>
> <spec://org.vibevm.core/vibevm/common/PROP-057#LOC-OFFICIAL-TRANSLATION>

## ограничение версии {#version-constraint}

[p102] То, что просит манифест (*version constraint*): диапазон вроде `^1.0`, точная `=1.2.0` или ничего — тогда новейшая стабильная. Лок-файл записывает ту одну версию, которую резолвер выбрал внутри него.

> [p103] `flow:wal@^0.3` → semver range.
>
> <spec://org.vibevm.core/vibevm/common/PROP-000#CF-RANGE>

## рабочее пространство {#workspace}

[p104] Репозиторий, разрабатывающий несколько пакетов вместе (*workspace*); объявляется таблицей `[workspace]` со списком путей участников; один лок-файл в корне и один общий подбор версий на всех участников.

> [p105] **Decision.** A `vibe.toml` may carry a `[workspace]` table declaring member packages:
>
> <spec://org.vibevm.core/vibevm/modules/vibe-workspace/PROP-007#WORKSPACE-TABLE>

