@gian-tiaga/eda 0.5.4 → 0.6.0

package/README.md

@@ -3,7 +3,7 @@
 > Поточная разработка с AI-агентами — на русском языке.
 > Набор готовых скилов для **Claude Code** и **Codex CLI**, которые ведут тебя через весь цикл: от исследования до коммита.
 
-`eda` — это одиннадцать скилов, каждый отвечает за свой кусок работы. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
+`eda` — это тринадцать скилов, каждый отвечает за свой кусок работы. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
 
 ---
 
@@ -36,6 +36,8 @@ eda init
 | `eda-fix-by-review` | Применяет замечания из ревью. Обязательные — сразу. Спорные — спрашивает. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |
 | `eda-send-review` | Отправляет ревью на GitHub PR через `gh` — как комментарий, review, approve или request-changes. Сам определяет PR по текущей ветке | (комментарий в PR) |
 | `eda-commit` | Делает один аккуратный коммит в стиле проекта. В конце спрашивает: push, merge в main + удалить ветку, или ничего | (git) |
+| `eda-worktree` | Создаёт git worktree рядом с основным проектом в папке `{name}-work-{n}` и одноимённую ветку. Базу берёт из аргумента или спрашивает | соседняя папка `{name}-work-{n}` |
+| `eda-merge-worktree` | Мержит ветку из соседнего worktree в текущую ветку. Принимает номер `1`, короткое имя `work-1` или полное имя `{name}-work-1`. Worktree и ветку после merge не удаляет | (git) |
 | `eda-docs` | Создаёт или обновляет `docs/rules.md` (максимально строгие правила для твоего стека), `docs/arch.md` (архитектура проекта) и шапку `AGENTS.md`. Может предлагать инструменты, которых ещё нет в проекте | `docs/rules.md`, `docs/arch.md`, `AGENTS.md` |
 | `eda-automate` | Анализирует историю ревью и фиксов. Если какое-то замечание встречается раз за разом — предлагает кастомное правило линтера или статанализатора, чтобы ловить это автоматически | `docs/automations/` |
 
@@ -119,7 +121,7 @@ roadmap ────────> explore ─────> plan ───> execu
 automate может запускаться от review, fix-by-review или fix.
 ```
 
-Использовать всю цепочку не обязательно — каждый скил самодостаточен. Можно начать с `eda-roadmap`, `eda-explore`, или сразу с `eda-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны.
+Использовать всю цепочку не обязательно — каждый скил самодостаточен. Можно начать с `eda-roadmap`, `eda-explore`, или сразу с `eda-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны. Для параллельной работы есть `eda-worktree`, а для возврата ветки из worktree в текущую ветку — `eda-merge-worktree`.
 
 ---
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "0.5.4",
-  "description": "Набор скилов eda-* для Claude Code и Codex CLI: roadmap, explore, plan, execute, fix, review, fix-by-review, send-review, commit, docs, automate",
+  "version": "0.6.0",
+  "description": "Набор скилов eda-* для Claude Code и Codex CLI: roadmap, explore, plan, execute, fix, review, fix-by-review, send-review, commit, worktree, merge-worktree, docs, automate",
   "type": "module",
   "bin": {
     "eda": "bin/cli.js"

package/skills/eda-merge-worktree.md

@@ -0,0 +1,131 @@
+---
+name: eda-merge-worktree
+description: 'Мержит ветку из соседнего git worktree `{name}-work-{n}` в текущую ветку. Аргумент принимает как номер `1`, короткое имя `work-1` или полное имя `{name}-work-1`. Перед merge проверяет текущий worktree и исходный worktree на незакоммиченные изменения. После успешного merge не удаляет worktree и ветку.'
+---
+
+# Скил: Merge из worktree (eda-merge-worktree)
+
+Мержишь ветку из соседнего worktree в текущую ветку. Этот скил не чистит worktree после merge: папка и ветка остаются на месте.
+
+## Режимы вызова
+
+| Режим | Запуск | Что делает |
+|---|---|---|
+| По номеру | `eda-merge-worktree 1` | Мержит ветку из `{name}-work-1` |
+| По короткому имени | `eda-merge-worktree work-1` | Мержит ветку из `{name}-work-1` |
+| По полному имени | `eda-merge-worktree app-work-1` | Мержит ветку из указанного worktree |
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: номер worktree, короткое имя `work-<n>`, полное имя `{name}-work-<n>`, ограничения и прямые указания.
+
+Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если аргумент не указан, он противоречивый, найдено несколько равных вариантов или есть риск смержить не ту ветку. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Главные правила
+
+1. **Merge только в текущую ветку.** Не переключайся на другую целевую ветку без явного указания пользователя.
+2. **Аргумент worktree обязателен.** Принимай `1`, `work-1` или полное имя `{name}-work-1`.
+3. **Не удаляй worktree и ветку после merge.** Даже при успешном merge cleanup не выполняется.
+4. **Не правь код вручную.** Если merge дал конфликт, остановись и покажи, какие файлы требуют ручного решения.
+5. **Не коммить и не пушь.** Merge-коммит создаёт только сам `git merge`, если Git решит, что он нужен.
+6. **Простой язык** в сообщениях пользователю.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале.
+
+## Этапы
+
+### 1. Проверить git-репозиторий
+
+Выполни:
+
+```bash
+git rev-parse --show-toplevel
+git worktree list --porcelain
+git rev-parse --abbrev-ref HEAD
+```
+
+Если это не git-репозиторий — остановись и сообщи. Если текущий worktree в detached HEAD — остановись: merge должен идти в именованную ветку.
+
+Определи основной worktree по первой записи `worktree <path>` из `git worktree list --porcelain`. Из его basename получи `$PROJECT_NAME`.
+
+### 2. Нормализовать аргумент
+
+Пусть `$ARG` — значение рядом с вызовом.
+
+Правила:
+- `1` → `$WORKTREE_NAME=$PROJECT_NAME-work-1`;
+- `work-1` → `$WORKTREE_NAME=$PROJECT_NAME-work-1`;
+- `$PROJECT_NAME-work-1` → `$WORKTREE_NAME=$ARG`;
+- другое значение → попробуй найти worktree с basename `$ARG`; если не найден — остановись и покажи доступные worktree.
+
+Если `$ARG` не указан, спроси через `AskUserQuestion` и предложи найденные worktree с именами по шаблону `$PROJECT_NAME-work-<n>`.
+
+### 3. Найти исходный worktree и ветку
+
+Из `git worktree list --porcelain` найди запись, у которой basename пути равен `$WORKTREE_NAME`.
+
+Для найденной записи определи:
+- `$SOURCE_WORKTREE_PATH`;
+- `$SOURCE_BRANCH` из строки `branch refs/heads/<name>`.
+
+Если worktree не найден — остановись и покажи доступные варианты. Если исходный worktree в detached HEAD или ветку определить нельзя — остановись: нечего безопасно мержить по имени ветки.
+
+Если `$SOURCE_WORKTREE_PATH` совпадает с текущим worktree — остановись: нужно запускать merge из целевого worktree, а не из исходного.
+
+### 4. Проверить чистоту
+
+Проверь текущий worktree:
+
+```bash
+git status --porcelain
+```
+
+Проверь исходный worktree:
+
+```bash
+git -C "$SOURCE_WORKTREE_PATH" status --porcelain
+```
+
+Если где-то есть незакоммиченные изменения — остановись и объясни, где именно. Нельзя мержить, пока изменения не закоммичены, не застешены или не убраны пользователем.
+
+Если текущая ветка уже содержит `$SOURCE_BRANCH`, сообщи, что merge не нужен, и выйди без действий.
+
+### 5. Выполнить merge
+
+Выполни:
+
+```bash
+git merge "$SOURCE_BRANCH"
+```
+
+Если Git сообщает `Already up to date`, это успешный результат.
+
+Если появились конфликты, остановись. Покажи:
+- что merge начат и требует ручного решения;
+- список конфликтных файлов из `git status --short`;
+- что пользователь должен разрешить конфликты и завершить merge вручную.
+
+Не пытайся автоматически разрешать конфликты.
+
+### 6. Финал
+
+Короткое сообщение:
+- какая ветка смержена;
+- в какую текущую ветку;
+- из какого worktree;
+- статус результата (`merged`, `already up to date` или `conflict`);
+- явно: worktree и исходная ветка не удалялись.
+
+## Чего НЕ делать
+
+- Удалять worktree через `git worktree remove`.
+- Удалять исходную ветку через `git branch -d` или `git branch -D`.
+- Делать push.
+- Править файлы для решения конфликтов.
+- Мержить грязный исходный worktree, потому что незакоммиченные изменения не попадут в merge.

package/skills/eda-review.md

@@ -5,7 +5,7 @@ description: 'Ревью изменений (незакоммиченный diff
 
 # Скил: Ревьюер (eda-review)
 
-Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь только найденные проблемы, ставишь оценку, сохраняешь файл. Не перечисляешь, что выполнено хорошо или без замечаний. Затем проверяешь ревью параллельными специализированными агентами; в `strict` — ещё и через соседний CLI. После каждой проверки **сам корректируешь** своё ревью: что-то добавляешь, что-то убираешь, что-то переформулируешь.
+Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь только найденные проблемы, ставишь оценку, сохраняешь файл. Каждый пункт начинаешь с короткого человеческого объяснения риска, без технической перегрузки; файлы, строки, детали кода и способ исправления даёшь ниже в блоке «Технические детали». Не перечисляешь, что выполнено хорошо или без замечаний. Затем проверяешь ревью параллельными специализированными агентами; в `strict` — ещё и через соседний CLI. После каждой проверки **сам корректируешь** своё ревью: что-то добавляешь, что-то убираешь, что-то переформулируешь.
 
 ## Режимы вызова
 
@@ -40,8 +40,33 @@ description: 'Ревью изменений (незакоммиченный diff
 6. **Главный ревьюер — ты.** Мета-ревьюеры дают подсказки; решение — добавить, убрать или оставить пункт — за тобой. Не вставляй чужие пункты механически.
 7. **Простой язык** в формулировках замечаний и рекомендаций. Технические термины — только если без них нельзя, и сразу с пояснением.
 8. **Ревью содержит только проблемы.** Не пиши отчёт о выполненной работе, список успешно сделанных пунктов, похвалу или нейтральное перечисление изменений. В файл попадают только ошибки, недоделки, неточности, спорные решения, нарушения правил/архитектуры, риски и недостающие проверки. Если проблем нет, напиши коротко: «Явных проблем не найдено», без пересказа diff.
-9. **Формат файла ревью — Markdown-блоки по шаблону из этапа 2.** Проблемы сверки с планом, каждое замечание и рекомендации пиши отдельными блоками с подзаголовками. Между заголовком блока, статусом/типом, контекстом, риском, локациями, деталями и исправлением всегда оставляй одну пустую строку.
-10. **В каждом замечании сначала объясняй контекст без привязки к коду**, чтобы читатель понял проблему и риск. Только после этого давай конкретные файлы/строки. Исправление оформляй так же: сначала общий подход, затем конкретные шаги по коду.
+9. **Формат файла ревью — Markdown-блоки по шаблону из этапа 2.** Проблемы сверки с планом, каждое замечание и рекомендации пиши отдельными блоками с подзаголовками. Внутри каждого пункта сначала идёт основная часть простым языком, затем блок `Технические детали`.
+10. **Основная часть замечания — главный ответ.** Пиши 2–4 коротких абзаца: что происходит, почему это проблема, какой практический риск, когда риск проявится. Не начинай с имён классов, методов, строк, SQL, DTO, конфигов и внутренних деталей.
+11. **Технические детали — ниже основной части.** Там укажи тип, рекомендацию, файлы/строки, что в коде подтверждает проблему, общий подход к исправлению и конкретные шаги. Если деталь не помогает понять или исправить проблему — не пиши её.
+
+## Стиль замечаний
+
+Пиши так, чтобы первый экран пункта можно было прочитать без глубокого знания кода. Хороший пункт похож на короткое объяснение ревьюера человеку:
+
+```markdown
+### 1. Может быть слишком много запросов во внешний сервис
+
+Сейчас проверка идёт по одному ответу за раз: один ответ в нашей системе — один запрос во внешний сервис.
+
+Если таких ответов 50, задача может сделать 50 запросов подряд. У внешнего сервиса на такие методы обычно есть ограничения по частоте. Если общая защита от лимитов реально разруливает это снаружи, пункт можно ослабить. Но по самому PR этого не видно.
+
+Риск такой: внешний сервис начнёт отвечать ошибками, а ответы в нашей системе продолжат висеть «на проверке».
+
+Технические детали:
+
+- **Тип:** `performance`
+- **Рекомендация:** `править обязательно`
+- **Где:** `path/to/file.ts:42` — цикл с запросом на каждый ответ.
+- **Как исправить:** добавить батчинг, ограничение параллелизма или явную обработку rate limit.
+- **Тесты:** проверить несколько ответов, ошибку внешнего сервиса и повторный запуск задачи.
+```
+
+Это ориентир по стилю, а не текст для копирования. Не растягивай пункт: основная часть должна быть короче технических деталей или сопоставима с ними, без канцелярита и без пересказа всего diff.
 
 ## Интерактивные вопросы
 
@@ -80,17 +105,12 @@ description: 'Ревью изменений (незакоммиченный diff
 
 Каждое замечание должно быть самостоятельным блоком:
 - заголовок с номером и коротким смыслом;
-- тип и рекомендация: `править обязательно` или `на усмотрение автора`;
-- контекст: объяснение проблемы без привязки к конкретному коду;
-- риск: почему это важно для поведения, сопровождения, денег, безопасности или эксплуатации;
-- где: конкретные файлы/строки;
-- детали: что именно в коде подтверждает проблему;
-- как исправить: сначала общий подход без привязки к коду;
-- конкретные шаги: что поменять в файлах/тестах.
+- основная часть простым языком: контекст, проблема и риск без привязки к конкретному коду;
+- `Технические детали`: тип, рекомендация, конкретные файлы/строки, что именно в коде подтверждает проблему, как исправить и какие тесты добавить или обновить.
 
 Поставь оценку 0–100 (100 — идеально, 0 — переделывать).
 
-Сохрани в `docs/reviews/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Соблюдай этот формат буквально: смысловые части идут отдельными блоками, между соседними блоками всегда есть одна пустая строка.
+Сохрани в `docs/reviews/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Соблюдай этот формат буквально: каждый пункт сначала читается как короткий человеческий ответ, а технические детали идут ниже отдельным блоком.
 
 ```markdown
 ---
@@ -115,20 +135,14 @@ meta_reviewers: []
 
 ### 1. <недоделка, отклонение или непроверенный пункт>
 
-Статус: <частично | не выполнено | не проверялось | отклонение>
+<2–4 коротких абзаца: что требовал план, что не сделано или не подтверждено, почему это важно. Без имён файлов, строк и внутренних деталей в начале пункта.>
 
-Контекст:
-<что требовал план простыми словами, без привязки к коду>
+Технические детали:
 
-Проблема:
-<что не сделано, сделано неточно или не подтверждено>
-
-Риск:
-<почему это важно>
-
-Где:
-
-- `<path/file.ts:42>` — <что смотреть>
+- **Статус:** <частично | не выполнено | не проверялось | отклонение>
+- **Где:** `<path/file.ts:42>` — <что смотреть>
+- **Что подтверждает проблему:** <конкретная деталь по коду, diff или плану>
+- **Как исправить:** <общий подход и конкретные шаги по коду/тестам>
 
 ## Замечания
 
@@ -136,30 +150,16 @@ meta_reviewers: []
 
 ### 1. <короткий заголовок проблемы>
 
-Тип: `bug`
-
-Рекомендация: `править обязательно`
-
-Контекст:
-<объясни проблему и предметную причину без привязки к конкретному коду>
-
-Риск:
-<что сломается или почему это важно>
-
-Где:
-
-- `<path/file.py:42>` — <что смотреть>
-
-Детали:
-<конкретное объяснение по коду>
-
-Как исправить:
-<общий подход без привязки к конкретному файлу>
+<2–4 коротких абзаца: что происходит, почему это проблема, какой практический риск, когда он проявится. Без технической перегрузки и без пересказа diff.>
 
-Конкретные шаги:
+Технические детали:
 
-- <что поменять в коде>
-- <какой тест добавить или обновить>
+- **Тип:** `bug | security | performance | architecture | rules | tests | quality | docs`
+- **Рекомендация:** `править обязательно | на усмотрение автора`
+- **Где:** `<path/file.py:42>` — <что смотреть>
+- **Что подтверждает проблему:** <конкретное объяснение по коду>
+- **Как исправить:** <общий подход, затем конкретные шаги по файлам>
+- **Тесты:** <какой тест добавить или обновить; если тест не нужен, почему>
 
 ## Рекомендации
 

package/skills/eda-worktree.md

@@ -0,0 +1,126 @@
+---
+name: eda-worktree
+description: 'Создаёт новый git worktree рядом с основным проектом в папке `{name}-work-{n}` и одноимённую ветку. Базовую ветку берёт из текста рядом с вызовом, если она указана, иначе спрашивает интерактивно. Не правит код, не коммитит, не мержит обратно. В финале показывает путь worktree, имя ветки и команду перехода в новую папку.'
+---
+
+# Скил: Создатель worktree (eda-worktree)
+
+Создаёшь отдельный git worktree для параллельной работы. Worktree всегда появляется рядом с основным проектом, а имя выбирается автоматически.
+
+## Режимы вызова
+
+| Режим | Запуск | Что делает |
+|---|---|---|
+| С выбранной базой | `eda-worktree main` | Создаёт worktree от указанной ветки, тега или commit-ref |
+| С вопросом | `eda-worktree` | Спрашивает, от какой базы создать worktree |
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: базовую ветку или ref, ограничения и прямые указания.
+
+Если вход содержит ветку, tag, commit hash или выражение вроде `от main` / `from main` / `base main`, используй это как `$BASE_REF`. Если входа нет или база не указана, спроси через `AskUserQuestion`. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Главные правила
+
+1. **Только git worktree.** Не правь код, docs, конфиги и зависимости.
+2. **Имя строго по шаблону.** Папка и ветка называются `{name}-work-{n}`, где `{name}` — имя папки основного worktree проекта, а `{n}` — первый свободный положительный номер.
+3. **Папка рядом с основным проектом.** Если основной worktree лежит в `/path/app`, новый путь: `/path/app-work-1`, `/path/app-work-2` и так далее.
+4. **Базу не додумывай молча.** Если пользователь не указал `$BASE_REF`, спроси интерактивно.
+5. **Не удаляй и не мержь.** Этот скил только создаёт worktree. Обратный merge — `eda-merge-worktree`.
+6. **Простой язык** в сообщениях пользователю.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале.
+
+## Этапы
+
+### 1. Проверить git-репозиторий
+
+Выполни:
+
+```bash
+git rev-parse --show-toplevel
+git worktree list --porcelain
+```
+
+Если это не git-репозиторий — остановись и сообщи. Основной worktree бери из первой записи `worktree <path>` в `git worktree list --porcelain`. Если список не удалось прочитать, используй `git rev-parse --show-toplevel`.
+
+Определи:
+- `$MAIN_WORKTREE` — путь основного worktree;
+- `$PROJECT_NAME` — basename от `$MAIN_WORKTREE`;
+- `$PROJECT_PARENT` — родительская папка `$MAIN_WORKTREE`.
+
+### 2. Выбрать базу
+
+Если `$BASE_REF` указан в сообщении пользователя, проверь его:
+
+```bash
+git rev-parse --verify "$BASE_REF^{commit}"
+```
+
+Если ref не найден — остановись и сообщи, что база не существует.
+
+Если `$BASE_REF` не указан, спроси через `AskUserQuestion`, откуда создавать worktree. Предлагай реальные варианты:
+- текущая ветка или `HEAD`;
+- default branch из `origin/HEAD`, если она есть;
+- `main` или `master`, если такая ветка существует.
+
+Если пользователь выбирает свой ref, проверь его через `git rev-parse --verify "$BASE_REF^{commit}"`.
+
+Если текущий worktree содержит незакоммиченные изменения, коротко предупреди: они не попадут в новый worktree. Это не блокер, если база выбрана явно или подтверждена через вопрос.
+
+### 3. Найти свободное имя
+
+Начиная с `n = 1`, найди первый номер, для которого одновременно свободны:
+- соседняя папка `$PROJECT_PARENT/$PROJECT_NAME-work-$n`;
+- локальная ветка `$PROJECT_NAME-work-$n`.
+
+Проверяй ветку так:
+
+```bash
+git show-ref --verify --quiet "refs/heads/$BRANCH_NAME"
+```
+
+Результат:
+- `$WORKTREE_NAME=$PROJECT_NAME-work-$n`;
+- `$BRANCH_NAME=$WORKTREE_NAME`;
+- `$WORKTREE_PATH=$PROJECT_PARENT/$WORKTREE_NAME`.
+
+Если папка уже есть, не перезаписывай её и не удаляй. Просто бери следующий номер.
+
+### 4. Создать worktree
+
+Выполни:
+
+```bash
+git worktree add -b "$BRANCH_NAME" "$WORKTREE_PATH" "$BASE_REF"
+```
+
+Если команда упала, покажи понятную причину и не пытайся чистить вручную. Если ошибка говорит, что ветка или папка уже существует, вернись к шагу 3 и выбери следующий номер.
+
+### 5. Финал
+
+Короткое сообщение:
+- созданный путь worktree;
+- имя ветки;
+- выбранная база;
+- готовая команда:
+
+```bash
+cd "$WORKTREE_PATH"
+```
+
+Напомни, что обратный merge выполняет `eda-merge-worktree <n>` или `eda-merge-worktree work-<n>`.
+
+## Чего НЕ делать
+
+- Править файлы проекта.
+- Создавать docs-артефакты.
+- Коммитить, пушить, мержить.
+- Удалять существующие worktree, ветки или папки.
+- Создавать worktree внутри текущего проекта вместо соседней папки.