Настроить рабочее пространство

Что происходит

03Агент добавляет в корневой манифест таблицу [workspace] с путями участников и пишет vibe.toml каждого участника руками, с таблицей [package]: участник — обычная папка пакета, а vibe init package размечает другую раскладку, слот в дереве, который описывают страницы для авторов. Членство явное: папка с манифестом, которой нет в списке, участником не считается. Затем он выполняет vibe install в корне: vibe обнаруживает рабочее пространство, разрешает требования всех участников одним общим разрешением и пишет один лок-файл в корне.

04 Membership is explicit — there is no auto-discovery of directories that happen to carry a vibe.toml. The structure is declared, per the owner's "the whole structure is in the project description" requirement.

05Одно дерево исходников и один лок-файл в его корне: участники — это папки, разбиение на пакеты логическое, а публикация копирует папку участника в его собственный репозиторий. Команда, запущенная внутри участника, поднимается до корня и работает с корневым локом, так что разработчик может работать внутри подпроекта, не замечая рабочего пространства вокруг.

06 Decision. The development tree is one source tree (one git repository, or not in git at all if the project is private). Workspace members are subdirectories; the split into packages is logical, at the vibevm resolver level. Publishing is a separate operation that copies the content of a package's directory into a new, separate repository in the registry org and tags the version — exactly what vibe registry publish does today for one package, repeated per self-published member by vibe workspace publish.

07 Decision. One vibe.lock, at the absolute root of the workspace tree (§2.3). No per-member lockfiles.

08 Command bubbling. A command (vibe install, vibe build) run inside a member's directory walks up to the absolute root, finds vibe.lock, and operates against it. The member "does not notice" it is part of something larger — this realises the owner's requirement that a developer can work inside a sub-project unaware of the surrounding workspace.

Руками

091. В корневом vibe.toml объявите участников; глобы разрешены:

112. Дайте каждому участнику свой vibe.toml с таблицей [package]: те же поля, что пишет vibe init package, с тем видом, который вы имеете в виду:

133. Установите из корня или из любого места внутри рабочего пространства; команда находит корень и разрешает всё дерево:

Один манифест, три роли

15У каждого узла есть файл с именем vibe.toml, и содержимое файла решает, что это за узел. Таблица [package] делает его публикуемым пакетом; таблица [project] — потребителем, который никогда не публикуется; таблица [workspace] — тем, кто координирует участников. Узел не может быть одновременно пакетом и проектом, а корень рабочего пространства может быть любым из двух или ни тем, ни другим.

16 [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.)

Участники ссылаются друг на друга

17Участник требует соседа по пути, а не через реестр: источником path в своих требованиях. Лок-файл записывает такую зависимость с видом источника path и папкой участника относительно корня, так что лок остаётся переносимым между машинами. Когда рабочее пространство публикуется, путь становится обычной координатой в каждой опубликованной копии.

18 Each member is a directory carrying its own vibe.toml (§2.2).

19Путь — третий источник пакетов рядом с реестрами и git. Участник требует другого по пути во время разработки и по версии после публикации, одной строкой из двух половин: { path = "../flow-wal", version = "^0.1" }. Опубликованная копия называет версию в реестре, которую сможет разрешить внешний потребитель, а путь никогда не покидает рабочего пространства. Плейсхолдер версии, объявленный один раз в корне, заменяет номер, который повторяется у участников.

20 Decision. A third dependency source-kind joins registry-resolved (PROP-002 §2.2) and git-source (PROP-002 §2.4.1): path-source.

21 Dual-form. path is used during local development inside the workspace; version takes effect when the consuming node is itself published — the published copy references org.vibevm.world/wal@^0.1 from a registry, not ../flow-wal (which an external consumer does not have). This is cargo's { path = ..., version = ... } shape. Dual-form is required for any path-dep whose consumer is publishable.

22 Decision. Named version placeholders, the equivalent of Maven <properties>:

23Каждый публикуемый участник объявляет свою позицию полем publish в [package]. vibe workspace publish обходит участников от зависимостей к зависимым, пропускает publish = false и останавливается на первой неудаче с отчётом, что опубликовано и что осталось; отката нет, потому что честный частичный отчёт лучше притворной транзакции.

24 Decision. Each publishable node declares its publish posture in [package]:

25 vibe workspace publish [--member <m>] walks members in topological order (dependency-first) and skips publish = false.

26 Publish is not atomic: on the first failure the command stops and reports what was already published and what remains. (Distributed publishing across N independent host repos has no transaction; a rollback would be a worse lie than a clear partial-progress report.)

Особые случаи и правила

27Рабочие пространства вкладываются: участник может сам нести таблицу [workspace]. Вложенность группирует участников; отдельных областей разрешения она не создаёт, и единственный лок-файл остаётся в самом верхнем корне.

28 Nesting is hierarchical grouping, not independent resolution domains. The lockfile and unified resolution always live at the absolute root of the workspace tree. A nested [workspace] provides (a) the [workspace.versions] matryoshka (§2.6) and (b) logical grouping of members — never its own lockfile, never its own resolution pass.

29vibe install -p <member> сужает то, о чём сообщается, а не то, что разрешается: лок-файл и дерево зависимостей всегда общие для всего рабочего пространства.

30 -p <member> scopes resolution reporting to one member; the materialisation and the single root lockfile are always workspace-wide — unified resolution admits no per-member subset.

31Дерево зависимостей живёт один раз, в корне; участники не получают собственных копий общих пакетов.

32 Materialised dependencies — a vibedeps/ tree at the absolute workspace root (PROP-007 §2.3), written only by vibe. One slot per resolved package, vibedeps/<group>.<name>/<version>/ (identity-keyed, PROP-022 §2.1 — owner ruling 2026-08-13), holding the package's published tree verbatim (PROP-024 §2.2 re-scopes "published" to the shippable tree — source minus build output — for code-bearing packages). A package's prompt content lives under its own spec/, so a boot snippet materialises at vibedeps/<slot>/spec/boot/<file> (PROP-024 §2.1). Unified resolution (PROP-007 §2.4) guarantees one version per package, so one slot serves the whole workspace.