Да. `vibevm/vibedeps/` коммитят намеренно: агент, который клонирует репозиторий, читает всю полосу, ничего не запуская, а ревьюер видит, какой именно текст изменился, когда сдвинулась зависимость. Это дерево vibe, а не ваше: никогда не правьте его, а в сомнении дайте `vibe reinstall` пересобрать его. См. [Два дерева](../model/two-trees.xml).

Сначала прочитайте объяснение резолвера: оно называет два ограничения, которые не сходятся, а пересекающиеся диапазоны — не конфликт. Затем поднимайтесь по лестнице от лёгкого к тяжёлому. Расширьте ограничение, которое вы сузили сверх нужного. Сдвиньте промежуточную зависимость на версию с совместимым ограничением через `vibe update`. Добавьте `[[override]]` для одной [координаты](../glossary/index.xml#coordinate), с `reason`. Форкните и используйте [git-источник](../glossary/index.xml#git-source), когда должно измениться собственное ограничение зависимости. Правило: одна версия на пакет во всём рабочем пространстве, поэтому vibe останавливается, а не ставит две.

Потому что установка пишет в ваш репозиторий: дерево зависимостей, [лок-файл](../glossary/index.xml#lock-file), стартовые файлы, [управляемый блок](../glossary/index.xml#managed-block) в файлах инструкций. План сначала показывает всё это. В скрипте за вас отвечает `--assume-yes` или `--unattended`; отказ — не ошибка, и он не оставляет ничего написанным наполовину.

Сам по себе нет. Внутри vibe нет модели, и каждая подсистема работает алгоритмически. Когда шагу нужно рассуждение, vibe откладывает инструкцию для агента, который его запустил, или, за терминалом, вызывает настроенный вами сервис модели, только для этого шага и только если вы включили эту функцию. См. [Поручите работу агенту](../agent/ask-your-agent.xml).

Нет. Разрешение выбирает одну версию на пакет во всём рабочем пространстве, иначе полоса, которую читает агент, содержала бы две версии одних правил. Если двум участникам рабочего пространства действительно нужны разные мажорные версии, это два рабочих пространства.

Нет, пока пакеты лежат в машинном [хранилище](../glossary/index.xml#store): сохранённой версией можно пользоваться, даже когда её больше не перечисляет ни один [реестр](../glossary/index.xml#registry), а `vibe reinstall` пересобирает дерево из лок-файла и хранилища. На долгий срок `vibe registry vendor` записывает папку со всем, на что ссылается лок-файл, и любая машина может использовать её как [зеркало](../glossary/index.xml#mirror) по адресу `file://`.

Установите его с `@=1.2.0` или передайте `--exact` в `vibe install` или `vibe update`, чтобы записать разрешённую версию точным пином в [манифест](../glossary/index.xml#manifest). Без `--exact` манифест хранит диапазон, а пин держит лок-файл; большинству проектов нужно именно это.

Нет. Несовпадение [отпечатка](../glossary/index.xml#fingerprint) значит, что отданные байты не те, что помнил лок-файл: тег после force-push, сломанное зеркало или намеренное [переопределение](../glossary/index.xml#override). Выясните, что именно, затем удалите и установите заново, чтобы перепинить, уберите сломанное зеркало или запишите переопределение с его причиной. Правка лок-файла отключает единственную проверку целостности, которая у вас есть.

Потому что инструмент, который знает, для чего пакет, ещё до того, как его открыл, может рано отказать неправильному: пакет документации не может нести [стартовый фрагмент](../glossary/index.xml#boot-snippet), пакет сервера обязан закрепить то, что обслуживает, фича не может назвать фреймворк. Каждый вид — один жанр, и слово, которое значило два жанра, разделили в тот момент, когда это случилось.

Всё, что читает хранилище и проект: установка из хранилища с `--offline`, reinstall, check, tree, локальная читалка документации. То, что не работает, говорит об этом, называя недостающую координату, и никогда не ставит частичный результат. Прогрейте хранилище перед отъездом через `vibe cache add`. См. [Работать без сети](../howto/work-offline.xml).

`vibe scrape` удаляет слой vibe по контракту и доказывает, что родная сборка по-прежнему проходит: в новую папку или на месте с возможностью восстановления. Это не то же, что `vibe clean`, который удаляет только то, что vibe может сгенерировать заново. См. [Убрать VibeVM из проекта](../lifecycle/scrape.xml).

Документацию читают, а не выполняют, и она не должна попадать в полосу, которую агент читает на каждом старте сессии. Поэтому пакет документации прогревается в машинное хранилище через `vibe cache add`, читается локально через `vibe doc serve`, а агент добирается до него через [навык](../glossary/index.xml#skill) или по адресу. См. [Читать документацию локально](../howto/read-documentation-locally.xml).