vibe — один бинарник, собранный из набора библиотек на Rust, каждая из которых владеет одной заботой: прочитать описание проекта, выбрать версии, скачать оттуда, где пакеты опубликованы, записать дерево на диск, поговорить с агентами. Эта страница — карта библиотек, швов между ними и пути, который проходит через них установка.
Читайте продукт снизу вверх. *Идентичность*: пакет — это [координата](../glossary/index.xml#coordinate) плюс [отпечаток](../glossary/index.xml#fingerprint) содержимого, а вид — метаданные. *[Реестр](../glossary/index.xml#registry)*: упорядоченные источники пакетов с зеркалами, [переопределениями](../glossary/index.xml#override) и необязательным [индексом](../glossary/index.xml#index-registry). *[Хранилище](../glossary/index.xml#store)*: каждая скачанная версия пакета хранится на машине один раз.
*Материализация*: разрешённый граф, скопированный в дерево зависимостей проекта и записанный в [лок-файл](../glossary/index.xml#lock-file). *Вычисленный старт*: [вклады](../glossary/index.xml#contribution) пакетов, спроецированные в два сгенерированных файла, которые читает агент. Всё, что видит пользователь, — один из этих пяти слоёв или поверхность над ними.
| Забота | Крейты | Чем владеют |
| базовый словарь | `vibe-core`, `vibe-wire` | манифесты, лок-файл, идентичности и хеши содержимого; сгенерированные типы каждого зарегистрированного машинного формата |
| спецификации | `vibe-spec`, `vibe-specdoc`, `progress-core`, `vibe-facts`, `vibe-trace` | адреса и детерминированный маршрутизатор; модель документа с её Markdown- и XML-фронтендами и бэкендами; парсер разметки статусов и отчёты; реестр фактов принятия; запросы прослеживаемости |
| реестры и хранилище | `vibe-registry`, `vibe-index`, `vibe-publish`, `vibe-package-source` | git-транспорт, зеркала и переопределения, кэш клонов и машинное хранилище; поисковый индекс и его сервер; публикация; единственная продуктивная композиция источников пакетов |
| разрешение и установка | `vibe-resolver`, `vibe-install`, `vibe-workspace`, `vibe-safefs` | швы и ячейки решателя; план и применение; обнаружение рабочего пространства, материализация, вычисленный старт; изменение файловой системы строго по выданным правам |
| жизненный цикл | `vibe-lifecycle`, `vibe-extension-registry`, `vibe-orchestrator`, `vibe-ext`, `vibe-native-loader`, `vibe-llm`, `vibe-scrape` | модель девяти фаз и цепочки; чистый реестр расширений; оркестрация, независимая от поверхности; безопасный SDK автора и карантинный загрузчик нативных расширений; шов провайдера модели; планирование зачистки |
| агенты и предпочтения | `vibe-mcp`, `vibe-agent-projection`, `vibe-settings`, `vibe-actions`, `vibe-requirements` | MCP-сервер и менеджер интеграций; проекция навыков в агентов; трёхуровневые предпочтения; действия, независимые от фронтенда; запрос требований только для чтения |
| поверхности и проверки | `vibe-cli`, `vibe-check` | командная строка; детерминированный линтер проекта |
| документация | `vibe-doc`, `vibe-doc-server`, `vibe-doc-shell` | конвейер страниц за `vibe doc`: сборка, проверка, манифест, снимки поверхности, очередь сопровождения и сборщик сайта; сервер локальной читалки на loopback-адресе; оболочка читалки внутри бинарника |
| зарезервированное и инструменты | `vibe-graph`, `vibe-test-support`, `xtask` | зарезервированный слот графа задач; изоляция домашней папки настроек в тестах; ворота сопровождающего: генерация кода, карта прослеживаемости, синхронизация движков, зеркалирование, сборка выпуска |
Направление зависимостей фиксировано: поверхность вызывает оркестратор, оркестратор вызывает библиотеку через шов, библиотека возвращает типизированные значения. Доменные библиотеки никогда не спрашивают, никогда не форматируют вывод терминала и никогда не решают вопросы аутентификации; эти решения принимаются в корне композиции, в CLI или в [MCP-сервере](../glossary/index.xml#mcp-server).
Дерево держат вместе четыре решения. Репозиторий — один Cargo-workspace, все крейты под `crates/`. Каждое умение продукта живёт в библиотеке, а командная строка, терминальный интерфейс и MCP-сервер — тонкие поверхности над ней. Схемы JSON Type Definition — единственный источник истины для каждого машинного контракта. А дисциплина коммитов — установленное [семейство](../glossary/index.xml#family) git-practices, которое читают в начале каждой сессии.
1. Найти корень рабочего пространства и прочитать [манифесты](../glossary/index.xml#manifest), лок-файл, пользовательскую конфигурацию, реестры, зеркала, переопределения и локальные источники пакетов.
2. Сравнить манифесты с лок-файлом; если ничего не изменилось, пропустить разрешение.
3. Иначе квалифицировать каждую запрошенную координату и построить представление доступных версий для решателя. Решить весь граф, удерживая каждый пин, которого изменение не касается.
4. Скачать каждую выбранную идентичность: попадание в хранилище переиспользуется, промах обходит разрешённые источники и кладёт проверенное дерево в хранилище.
5. Построить план, проверить [управляемые блоки](../glossary/index.xml#managed-block) файлов инструкций и спросить подтверждения.
6. Материализовать граф в дерево зависимостей через диф, перегенерировать стартовые файлы, убрать устаревшие слоты.
7. Записать граф, происхождение и отпечатки в лок-файл.
8. Отрисовать человеческий, тихий или JSON-отчёт.
`GitBackend` изолирует git: продуктивная реализация вызывает системный git, так что SSH-агенты и помощники учётных данных ведут себя как везде. `Registry` перечисляет, разрешает и скачивает по локальным и git-источникам; `MultiRegistryResolver` владеет упорядоченным обходом, зеркалами, переопределениями, аутентификацией и офлайн-позицией. `DepProvider` — представление мира для решателя, а `DepSolver` превращает корни в граф; ячейка по умолчанию — resolvo, а ячейка SAT с откатами и наивная ячейка выбираются по желанию. `InstallSource` отделяет транзакцию от построения ячеек. `RepoCreator` изолирует создание репозиториев на хостах для публикации. У каждого шва больше одной реализации, и тесты гоняют шов, а не продуктивную ячейку.
Спецификации — авторитет: `PROP-000` об основополагающих решениях, `PROP-009` о модели загрузки, `PROP-002` и `PROP-010` о реестрах и хранилище, `PROP-054` о [жизненном цикле](../glossary/index.xml#lifecycle) и машине расширений, `PROP-045` о модели документа, `PROP-057` и `PROP-058` о пакетах документации, сайте и о том, как сопровождается это руководство. Страница о прослеживаемости в этом руководстве объясняет, как код их цитирует и как спросить карту, какой код стоит за каким правилом. Руководство разработчика в репозитории описывает сборку, тесты и панель самопроверки.