# Настроить рабочее пространство {#root} @status:doc/work @audience:user,author [p01] Несколько пакетов, которые разрабатывают вместе, могут жить в одном репозитории и делить одну запись о версиях, которыми пользуются. Эта страница превращает папку в такое рабочее пространство и показывает, как участники ссылаются друг на друга по пути. [p02] ```prompt Преврати проект VibeVM в текущей папке в рабочее пространство с двумя пакетами-участниками под packages/: org.acme/notes-flow и org.acme/notes-docs, где notes-docs документирует notes-flow. Выполни установку и покажи мне, что один лок-файл в корне покрывает обоих участников. ``` - needs: навык vibevm, установленный у вашего агента; проект с `vibe.toml` в корне outcome: корневой `vibe.toml` несёт таблицу `[workspace]` с обоими участниками, в папке каждого участника лежит свой `vibe.toml` с таблицей `[package]`, а один `vibe.lock` в корне записывает разрешение - assert: `test -f packages/notes-flow/vibe.toml` - assert: `test -f packages/notes-docs/vibe.toml` - assert: `test ! -e packages/notes-flow/vibe.lock` - assert: `vibe check --quiet` ## Что происходит {#what-happens} [p03] Агент добавляет в корневой [манифест](../glossary/index.xml#manifest) таблицу `[workspace]` с путями участников и пишет `vibe.toml` каждого участника руками, с таблицей `[package]`: участник — обычная папка пакета, а `vibe init package` размечает другую раскладку, слот в дереве, который описывают страницы для авторов. Членство явное: папка с манифестом, которой нет в списке, участником не считается. Затем он выполняет `vibe install` в корне: vibe обнаруживает рабочее пространство, разрешает требования всех участников одним общим разрешением и пишет один [лок-файл](../glossary/index.xml#lock-file) в корне. > [p04] 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. > > [p05] Одно дерево исходников и один лок-файл в его корне: участники — это папки, разбиение на пакеты логическое, а публикация копирует папку участника в его собственный репозиторий. Команда, запущенная внутри участника, поднимается до корня и работает с корневым локом, так что разработчик может работать внутри подпроекта, не замечая рабочего пространства вокруг. > [p06] **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`. > > > [p07] **Decision.** One `vibe.lock`, at the absolute root of the workspace tree (§2.3). No per-member lockfiles. > > > [p08] **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. > > ## Руками {#by-hand} [p09] 1. В корневом `vibe.toml` объявите участников; глобы разрешены: [p10] Example `workspace-table` is copied from the source page at projection time. [p11] 2. Дайте каждому участнику свой `vibe.toml` с таблицей `[package]`: те же поля, что пишет `vibe init package`, с тем видом, который вы имеете в виду: [p12] Example `member-manifest` is copied from the source page at projection time. [p13] 3. Установите из корня или из любого места внутри рабочего пространства; команда находит корень и разрешает всё дерево: [p14] Example `install` is copied from the source page at projection time. ## Один манифест, три роли {#one-manifest} [p15] У каждого узла есть файл с именем `vibe.toml`, и содержимое файла решает, что это за узел. Таблица `[package]` делает его публикуемым пакетом; таблица `[project]` — потребителем, который никогда не публикуется; таблица `[workspace]` — тем, кто [координирует](../glossary/index.xml#coordinate) участников. Узел не может быть одновременно пакетом и проектом, а корень рабочего пространства может быть любым из двух или ни тем, ни другим. > [p16] `[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.) > > ## Участники ссылаются друг на друга {#members-referring} [p17] Участник требует соседа по пути, а не через [реестр](../glossary/index.xml#registry): источником `path` в своих требованиях. Лок-файл записывает такую зависимость с видом источника `path` и папкой участника относительно корня, так что лок остаётся переносимым между машинами. Когда рабочее пространство публикуется, путь становится обычной координатой в каждой опубликованной копии. > [p18] Each member is a directory carrying its own `vibe.toml` (§2.2). > > [p19] Путь — третий источник пакетов рядом с реестрами и git. Участник требует другого по пути во время разработки и по версии после публикации, одной строкой из двух половин: `{ path = "../flow-wal", version = "^0.1" }`. Опубликованная копия называет версию в реестре, которую сможет разрешить внешний потребитель, а путь никогда не покидает рабочего пространства. Плейсхолдер версии, объявленный один раз в корне, заменяет номер, который повторяется у участников. > [p20] **Decision.** A third dependency source-kind joins registry-resolved (PROP-002 §2.2) and git-source (PROP-002 §2.4.1): **path-source**. > > > [p21] **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. > > > [p22] **Decision.** Named version placeholders, the equivalent of Maven ``: > > [p23] Каждый публикуемый участник объявляет свою позицию полем `publish` в `[package]`. `vibe workspace publish` обходит участников от зависимостей к зависимым, пропускает `publish = false` и останавливается на первой неудаче с отчётом, что опубликовано и что осталось; отката нет, потому что честный частичный отчёт лучше притворной транзакции. > [p24] **Decision.** Each publishable node declares its publish posture in `[package]`: > > > [p25] `vibe workspace publish [--member ]` walks members in **topological order** (dependency-first) and skips `publish = false`. > > > [p26] 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.) > > ## Особые случаи и правила {#edge-cases} [p27] Рабочие пространства вкладываются: участник может сам нести таблицу `[workspace]`. Вложенность группирует участников; отдельных областей разрешения она не создаёт, и единственный лок-файл остаётся в самом верхнем корне. > [p28] 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. > > [p29] `vibe install -p ` сужает то, о чём сообщается, а не то, что разрешается: лок-файл и дерево зависимостей всегда общие для всего рабочего пространства. > [p30] `-p ` scopes resolution *reporting* to one member; the materialisation and the single root lockfile are always workspace-wide — unified resolution admits no per-member subset. > > [p31] Дерево зависимостей живёт один раз, в корне; участники не получают собственных копий общих пакетов. > [p32] Materialised dependencies — a `vibedeps/` tree at the **absolute workspace root** (PROP-007 §2.3), written only by `vibe`. One slot per resolved package, `vibedeps/.//` (identity-keyed, PROP-022 §2.1 — owner ruling 2026-08-13), holding the package's published tree verbatim ([PROP-024 §2.2](../../common/PROP-024-code-bearing-packages.xml#shippable-tree) 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//spec/boot/` (PROP-024 §2.1). Unified resolution (PROP-007 §2.4) guarantees one version per package, so one slot serves the whole workspace. > >