mister-wolf 2.15.1 → 2.16.0

package/templates/base/skills/test-driven-development/SKILL.md

@@ -1,413 +1,35 @@
 ---
 name: test-driven-development
-description: Используй при реализации любой фичи или багфикса, до написания кода реализации
+description: "Проверяй новое поведение и багфиксы через чувствительный к дефекту тест до реализации. Для рефакторинга сохраняй существующее поведение characterization-тестами; выбирай проверку по риску и контракту."
 ---
 
-# Test-Driven Development (TDD)
+# Тестовая дисциплина исполнения
 
-> Источник: ~/.config/opencode/superpowers/skills/test-driven-development/SKILL.md, upstream 6efe32c (2026-04-23).
-> Адресат: worker-implementer — пассивный процесс: читаешь и следуешь в рамках своей единственной задачи, без диспетчеризации.
+## Вход
 
-## Трассировка адаптации
+L2 получает назначенные AC, сценарии test-plan, allowlist и команды профиля проекта. Читай необходимый существующий код. Не меняй AC и не добавляй продуктовые функции ради удобства тестирования без согласования.
 
-| Пункт upstream                                                                                                                                                                                | Судьба                                                                                                    |
-| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
-| Iron Law, цикл RED-GREEN-REFACTOR, обязательные верификации RED/GREEN, dot-диаграмма                                                                                                          | **сохранено** дословно (перевод)                                                                          |
-| Таблица рационализаций (11), red flags (13), «Why Order Matters» (5 аргументов), анти-паттерны тестирования (3), чеклист верификации (8), «When Stuck» (4), примеры Good/Bad, пример багфикса | **сохранено полностью** по смыслу дословно (H7)                                                           |
-| `npm test <путь>`                                                                                                                                                                             | **заменено**: точечный прогон — `npx vitest run <путь>` (стек проекта — vitest); полный — `npm run check` |
-| «Ask your human partner» (исключения из Iron Law)                                                                                                                                             | **заменено**: явное разрешение владельца; воркер эскалирует запрос через executor-lead, сам не решает     |
-| Чеклист верификации                                                                                                                                                                           | **дополнено**: механика {{tool.todowrite}} — один пункт на чекбокс                                        |
-| Ссылка на внешний `@testing-anti-patterns.md`                                                                                                                                                 | **отброшено**: reference-файл вне шаблона; суть (3 пункта) встроена в раздел «Анти-паттерны тестирования» |
-| Контур лица                                                                                                                                                                                   | **добавлено**: до задачи — `wolf search "worker-implementer playbook"` (брать наибольшую версию)          |
+## Новое поведение и багфикс
 
-## Обзор
+1. Напиши минимальную проверку наблюдаемого контракта с независимым ожидаемым результатом. Для бага воспроизведи исходный симптом.
+2. Запусти RED. Проверь, что причиной является отсутствующее/неверное поведение, а не опечатка, сломанный setup или недоступная зависимость. Отсутствующий публичный интерфейс допустим в начале, но после его появления проверка должна проверять поведение.
+3. Напиши минимальную реализацию; запусти GREEN и связанные регрессии. Не ослабляй assertion ради зелёного результата; ошибку самого теста исправляй с обоснованием.
+4. Рефакторь в пределах задачи, сохраняя зелёные проверки. Зафиксируй RED/GREEN evidence и область регрессий.
 
-Сначала напиши тест. Посмотри, как он падает. Напиши минимальный код, чтобы он прошёл.
+## Существующее поведение и рефакторинг
 
-**Принцип:** если ты не видел, как тест падает, ты не знаешь, проверяет ли он то, что нужно.
+Characterization-тесты могут проходить сразу: они фиксируют baseline. Затем проверь, что изменение сохраняет контракт. Не требуй искусственно ломать рабочий код для каждого такого теста. Чувствительность важной регрессионной проверки подтверди на исходной версии или изолированным временным возвратом дефекта; чужие изменения не откатывай.
 
-**Нарушение буквы правил — это нарушение духа правил.**
+## Если код уже написан
 
-## Когда применять
+Не удаляй результат автоматически. Сохрани его и отметь отклонение процесса; для нового поведения код-первый — задокументированное отклонение, которое L1 обязан провести через ревью качества тестов (минимум DONE_WITH_CONCERNS), а не молчаливая норма. Добавь независимые проверки по требованиям. Для исправления дефекта покажи падение на baseline и прохождение на текущем коде. Если это невозможно, обозначь предел уверенности и передай L1. Историю RED не выдумывай.
 
-**Всегда:**
+## Качество тестов
 
-- Новые фичи
-- Багфиксы
-- Рефакторинг
-- Изменения поведения
+Проверяй публичное поведение, границы, ошибки и инварианты; не требуй отдельного теста для каждой внутренней функции. Моки используй для внешних границ, сохраняя интеграционную проверку там, где взаимодействие несёт риск. Fixtures должны быть изолированы, seed/time контролируемы, cleanup безопасен. Не тестируй только конфигурацию собственного мока.
 
-**Исключения (только с явного разрешения владельца — эскалируй через executor-lead):**
+Для документации, конфигураций и генерации выбирай валидатор, snapshot, smoke или воспроизводимую ручную проверку. Отказ от релевантной автоматической проверки должен иметь основание по политике проекта, а не обязательный вопрос владельцу на каждую мелочь.
 
-- Одноразовые прототипы
-- Генерированный код
-- Конфигурационные файлы
+## Готовность
 
-Думаешь «пропущу TDD только этот раз»? Стоп. Это рационализация.
-
-## Iron Law
-
-```
-НИКАКОГО ПРОДАКШЕН-КОДА БЕЗ ПАДАЮЩЕГО ТЕСТА
-```
-
-Написал код до теста? Удали. Начни заново.
-
-**Без исключений:**
-
-- Не оставляй «как референс»
-- Не «адаптируй» его при написании тестов
-- Не смотри на него
-- Удалить означает удалить
-
-Реализуй с нуля из тестов. Точка.
-
-## Красный-Зелёный-Рефакторинг
-
-```dot
-digraph tdd_cycle {
-    rankdir=LR;
-    red [label="КРАСНЫЙ\nНапиши падающий тест", shape=box, style=filled, fillcolor="#ffcccc"];
-    verify_red [label="Падает\nпо правильной причине", shape=diamond];
-    green [label="ЗЕЛЁНЫЙ\nМинимальный код", shape=box, style=filled, fillcolor="#ccffcc"];
-    verify_green [label="Проходит\nВсё зелёное", shape=diamond];
-    refactor [label="РЕФАКТОРИНГ\nПрибраться", shape=box, style=filled, fillcolor="#ccccff"];
-    next [label="Дальше", shape=ellipse];
-
-    red -> verify_red;
-    verify_red -> green [label="да"];
-    verify_red -> red [label="не та\nпричина"];
-    green -> verify_green;
-    verify_green -> refactor [label="да"];
-    verify_green -> green [label="нет"];
-    refactor -> verify_green [label="остаёмся\nзелёными"];
-    verify_green -> next;
-    next -> red;
-}
-```
-
-### КРАСНЫЙ — напиши падающий тест
-
-Напиши один минимальный тест, показывающий, что должно происходить.
-
-<Good>
-```typescript
-test('повторяет неудачную операцию 3 раза', async () => {
-  let attempts = 0;
-  const operation = () => {
-    attempts++;
-    if (attempts < 3) throw new Error('fail');
-    return 'success';
-  };
-
-const result = await retryOperation(operation);
-
-expect(result).toBe('success');
-expect(attempts).toBe(3);
-});
-
-````
-Ясное имя, тестирует реальное поведение, одно
-</Good>
-
-<Bad>
-```typescript
-test('retry works', async () => {
-  const mock = jest.fn()
-    .mockRejectedValueOnce(new Error())
-    .mockRejectedValueOnce(new Error())
-    .mockResolvedValueOnce('success');
-  await retryOperation(mock);
-  expect(mock).toHaveBeenCalledTimes(3);
-});
-````
-
-Расплывчатое имя, тестирует мок, а не код
-</Bad>
-
-**Требования:**
-
-- Одно поведение
-- Ясное имя
-- Реальный код (моки — только при неизбежности)
-
-### Верифицируй КРАСНЫЙ — посмотри, как падает
-
-**ОБЯЗАТЕЛЬНО. Никогда не пропускай.**
-
-```bash
-npx vitest run <путь-к-тесту>
-```
-
-Подтверди:
-
-- Тест падает (а не ошибается)
-- Сообщение об ошибке ожидаемое
-- Падает из-за отсутствия фичи (не из-за опечаток)
-
-**Тест проходит?** Ты тестируешь существующее поведение. Почини тест.
-
-**Тест ошибается?** Почини ошибку, гоняй, пока не упадёт корректно.
-
-### ЗЕЛЁНЫЙ — минимальный код
-
-Напиши простейший код, чтобы тест прошёл.
-
-<Good>
-```typescript
-async function retryOperation<T>(fn: () => Promise<T>): Promise<T> {
-  for (let i = 0; i < 3; i++) {
-    try {
-      return await fn();
-    } catch (e) {
-      if (i === 2) throw e;
-    }
-  }
-  throw new Error('unreachable');
-}
-```
-Ровно столько, чтобы пройти
-</Good>
-
-<Bad>
-```typescript
-async function retryOperation<T>(
-  fn: () => Promise<T>,
-  options?: {
-    maxRetries?: number;
-    backoff?: 'linear' | 'exponential';
-    onRetry?: (attempt: number) => void;
-  }
-): Promise<T> {
-  // YAGNI
-}
-```
-Оверинжиниринг
-</Bad>
-
-Не добавляй фичи, не рефакторь другой код, не «улучшай» сверх теста.
-
-### Верифицируй ЗЕЛЁНЫЙ — посмотри, как проходит
-
-**ОБЯЗАТЕЛЬНО.**
-
-```bash
-npx vitest run <путь-к-тесту>
-```
-
-Подтверди:
-
-- Тест проходит
-- Остальные тесты всё ещё проходят
-- Вывод чистый (без ошибок и предупреждений)
-
-**Тест упал?** Чини код, а не тест.
-
-**Другие тесты упали?** Чини сейчас.
-
-### РЕФАКТОРИНГ — приберись
-
-Только после зелёного:
-
-- Убери дублирование
-- Улучши имена
-- Вынеси хелперы
-
-Тесты остаются зелёными. Поведение не добавляется.
-
-### Повтори
-
-Следующий падающий тест для следующей фичи.
-
-## Хорошие тесты
-
-| Качество          | Хорошо                                | Плохо                                      |
-| ----------------- | ------------------------------------- | ------------------------------------------ |
-| **Минимальность** | Одно поведение. «И» в имени? Раздели. | `test('проверяет email, домен и пробелы')` |
-| **Ясность**       | Имя описывает поведение               | `test('test1')`                            |
-| **Намерение**     | Демонстрирует желаемый API            | Затуманивает, что код должен делать        |
-
-## Почему важен порядок
-
-**«Я напишу тесты после, чтобы проверить, что работает»**
-
-Тесты, написанные после кода, проходят сразу. Прохождение сразу не доказывает ничего:
-
-- Может тестировать не то
-- Может тестировать реализацию, а не поведение
-- Может упускать пограничные случаи, которые ты забыл
-- Ты никогда не видел, как тест ловит баг
-
-Тест-первый заставляет увидеть падение теста — доказательство, что он реально что-то проверяет.
-
-**«Я уже вручно протестировал все пограничные случаи»**
-
-Ручное тестирование ад-хок. Ты думаешь, что проверил всё, но:
-
-- Нет записи о том, что проверено
-- Нельзя перезапустить при изменении кода
-- Легко забыть случаи под давлением
-- «Работало, когда я пробовал» ≠ исчерпывающе
-
-Автотесты систематичны. Они выполняются одинаково каждый раз.
-
-**«Удалить X часов работы расточительно»**
-
-Ошибка невозвратных издержек. Время уже потрачено. Выбор сейчас:
-
-- Удалить и переписать по TDD (ещё X часов, высокая уверенность)
-- Оставить и дописать тесты после (30 минут, низкая уверенность, вероятные баги)
-
-«Расточительство» — держать код, которому не можешь доверять. Работающий код без настоящих тестов — техдолг.
-
-**«TDD догматично, прагматизм означает адаптацию»**
-
-TDD — И есть прагматизм:
-
-- Находит баги до коммита (быстрее отладки после)
-- Предотвращает регрессии (тесты ловят поломки сразу)
-- Документирует поведение (тесты показывают, как использовать код)
-- Даёт рефакторинг (меняй свободно, тесты ловят поломки)
-
-«Прагматичные» сокращения = отладка в проде = медленнее.
-
-**«Тесты после достигают тех же целей — важен дух, а не ритуал»**
-
-Нет. Тесты-после отвечают «что это делает?». Тесты-первый отвечают «что это должно делать?».
-
-Тесты-после смещены твоей реализацией: ты тестируешь то, что построил, а не то, что требуется. Верифицируешь запомненные пограничные случаи, а не обнаруженные.
-
-Тест-первый заставляет обнаружить пограничные случаи до реализации. Тесты-после проверяют, что ты всё запомнил (ты не запомнил).
-
-30 минут тестов после ≠ TDD. Получаешь покрытие, теряешь доказательство, что тесты работают.
-
-## Распространённые рационализации
-
-| Оправдание                                  | Реальность                                                                   |
-| ------------------------------------------- | ---------------------------------------------------------------------------- |
-| «Слишком просто, чтобы тестировать»         | Простой код ломается. Тест занимает 30 секунд.                               |
-| «Напишу тесты после»                        | Тесты, проходящие сразу, не доказывают ничего.                               |
-| «Тесты после достигают тех же целей»        | Тесты-после = «что это делает?». Тесты-первый = «что это должно делать?»     |
-| «Уже протестировал вручную»                 | Ад-хок ≠ систематично. Нет записи, нельзя перезапустить.                     |
-| «Удалить X часов работы расточительно»      | Ошибка невозвратных издержек. Держать непроверенный код — техдолг.           |
-| «Оставлю как референс, напишу тесты с нуля» | Ты его адаптируешь. Это тесты-после. Удалить = удалить.                      |
-| «Нужно сначала поисследовать»               | Ок. Выброси исследование, начни с TDD.                                       |
-| «Тест сложный — дизайн неясен»              | Слушай тест. Сложно тестировать = сложно использовать.                       |
-| «TDD меня замедлит»                         | TDD быстрее отладки. Прагматизм = тест-первый.                               |
-| «Ручной тест быстрее»                       | Ручной не доказывает пограничные случаи. Перепроверять при каждом изменении. |
-| «В существующем коде нет тестов»            | Ты его улучшаешь. Добавляй тесты для существующего кода.                     |
-
-## Red flags — ОСТАНОВИСЬ и начни заново
-
-- Код до теста
-- Тест после реализации
-- Тест проходит сразу
-- Не можешь объяснить, почему тест упал
-- Тесты «добавим позже»
-- Рационализация «только этот раз»
-- «Я уже вручную протестировал»
-- «Тесты после достигают той же цели»
-- «Дело в духе, а не в ритуале»
-- «Оставлю как референс» или «адаптирую существующий код»
-- «Уже потратил X часов, удалять расточительно»
-- «TDD догматично, я прагматик»
-- «Это другой случай, потому что...»
-
-**Любой из этих пунктов означает: удали код. Начни заново по TDD.**
-
-## Пример: багфикс
-
-**Баг:** принимается пустой email
-
-**КРАСНЫЙ**
-
-```typescript
-test('отклоняет пустой email', async () => {
-  const result = await submitForm({ email: '' });
-  expect(result.error).toBe('Email required');
-});
-```
-
-**Верифицируй КРАСНЫЙ**
-
-```bash
-$ npx vitest run <путь-к-тесту>
-FAIL: expected 'Email required', got undefined
-```
-
-**ЗЕЛЁНЫЙ**
-
-```typescript
-function submitForm(data: FormData) {
-  if (!data.email?.trim()) {
-    return { error: 'Email required' };
-  }
-  // ...
-}
-```
-
-**Верифицируй ЗЕЛЁНЫЙ**
-
-```bash
-$ npx vitest run <путь-к-тесту>
-PASS
-```
-
-**РЕФАКТОРИНГ**
-Вынеси валидацию для нескольких полей, если нужно.
-
-## Чеклист верификации
-
-Перед отметкой работы как завершённой размести пункты в {{tool.todowrite}} (один пункт — один чекбокс) и отметь по факту:
-
-- [ ] У каждой новой функции/метода есть тест
-- [ ] Видел каждый тест падающим до реализации
-- [ ] Каждый тест падал по ожидаемой причине (фича отсутствует, не опечатка)
-- [ ] Написал минимальный код для прохождения каждого теста
-- [ ] Все тесты проходят
-- [ ] Вывод чистый (без ошибок и предупреждений)
-- [ ] Тесты используют реальный код (моки — только при неизбежности)
-- [ ] Пограничные случаи и ошибки покрыты
-
-Не можешь отметить все пункты? Ты пропустил TDD. Начни заново.
-
-## Когда застрял
-
-| Проблема                  | Решение                                                                                         |
-| ------------------------- | ----------------------------------------------------------------------------------------------- |
-| Не знаю, как тестировать  | Напиши желаемый API. Сначала напиши assertion. Запроси подсказку владельца через executor-lead. |
-| Тест слишком сложный      | Дизайн слишком сложный. Упрости интерфейс.                                                      |
-| Приходится мокать всё     | Код слишком связан. Используй внедрение зависимостей.                                           |
-| Подготовка теста огромная | Вынеси хелперы. Всё ещё сложно? Упрости дизайн.                                                 |
-
-## Интеграция с отладкой
-
-Найден баг? Напиши падающий тест, воспроизводящий его. Пройди цикл TDD. Тест доказывает фикс и предотвращает регрессию.
-
-Никогда не чини баги без теста.
-
-## Анти-паттерны тестирования
-
-- Тестирование поведения мока вместо реального поведения
-- Тест-методы в продакшен-классах
-- Моки без понимания зависимостей
-
-## Интеграция с Wolf
-
-- **Контур лица**: до задачи — `wolf search "worker-implementer playbook"` (наибольшая версия); методика эволюционирует в памяти, этот файл — только процесс.
-- **Полная верификация** в конце задачи — `npm run check`.
-- **Урок**: наткнулся на нетривиальную ловушку TDD-цикла — зафиксируй `wolf add --type lesson`, чтобы следующий воркер её обошёл.
-
-## Финальное правило
-
-```
-Продакшен-код → тест существует и упал первым
-Иначе → не TDD
-```
-
-Без исключений — кроме явного разрешения владельца.
-
-## Конвейер (2.15)
-
-Сценарии `docs/dev/<дата>-<slug>/test-plan.md` — заготовки КРАСНОЙ фазы: TDD-цикл
-фичи конвейера начинается с переноса сценария в падающий тест, не с изобретения теста.
+AC покрыты, исходный дефект воспроизводился, новые проверки чувствительны к неверному поведению, связанные регрессии пройдены или ограничение явно указано. RESULT не подменяет независимое ревью и приёмку. Коммиты — зона L1.

package/templates/base/skills/using-git-worktrees/SKILL.md

@@ -1,188 +1,26 @@
 ---
 name: using-git-worktrees
-description: Используй при старте фичи, которой нужна изоляция от текущего workspace, или перед исполнением планов — создаёт изолированные git-worktree с проверкой безопасности
+description: "Подготовь изолированную git-рабочую копию перед изменениями, когда этого требует проект или параллельная работа. Определи baseline, воспроизводимый setup, владение памятью и write sets."
 ---
 
-# Using Git Worktrees
+# Подготовка рабочего пространства
 
-> Источник: ~/.config/opencode/superpowers/skills/using-git-worktrees/SKILL.md, upstream 6efe32c (2026-04-23).
-> Владелец шага: executor-lead — worktree создаётся ДО старта исполнения (REQUIRED-предусловие wolf-sdd и wolf-execute, H5).
+## Владелец
 
-## Трассировка адаптации
+Создание, настройка и git-операции — L1 либо разрешённая исполнительская роль. L2 получает готовые cwd, branch и allowlist. Следуй профилю проекта; local .worktrees/<task> — рекомендуемый fallback, не универсальный запрет других путей.
 
-| Пункт upstream                                                                                                                                                                  | Судьба                                                                                                                         |
-| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
-| Верификация gitignore (`git check-ignore`), автодетект сетапа, бейзлайн-тесты, механика `git worktree add`, отчёт о готовности, частые ошибки (4), red flags Never/Always (5/4) | **сохранено** (red flags — дословно по смыслу, H7)                                                                             |
-| Приоритет каталогов upstream (`.worktrees` / `worktrees` / глобальный / опрос)                                                                                                  | **заменено** правилом проекта: worktree всегда ВНУТРИ проекта — `.worktrees/<имя-задачи>`                                      |
-| `grep CLAUDE.md`                                                                                                                                                                | **заменено**: чтение AGENTS.md                                                                                                 |
-| Бейзлайн `npm test`                                                                                                                                                             | **заменено**: `npm run check` (верификационный примитив проекта)                                                               |
-| Глобальный путь `~/.config/superpowers/worktrees/`                                                                                                                              | **отброшено**: противоречит правилу проекта (worktree внутри проекта) и непереносим (research §1: «глобальный путь worktrees») |
-| Ветка-альтернатива `worktrees/` (без точки), персоналия upstream («Jesse's rule»)                                                                                               | **отброшено**: единая конвенция `.worktrees/`; правило «чинить сломанное сразу» сохранено как механика без имени               |
+## Процесс
 
-## Обзор
+1. Прочитай AGENTS.md/CI, проверь git status, worktree list, текущую ветку, base branch/SHA и наличие нужной ветки. Зафиксируй чужие незакоммиченные изменения; не убирай их автоматически.
+2. Выбери уникальные branch и абсолютный путь. Для внутреннего каталога проверь ignore. Если нужно изменить .gitignore — делай это в пределах scope и полномочий; коммит не является автоматическим условием setup.
+3. Создай worktree от явно выбранного baseline, не от случайного текущего HEAD. При существующей ветке/пути выясни владельца; не удаляй и не переиспользуй чужую работу.
+4. Установи зависимости согласно lockfile, package manager и CI: frozen/reproducible install, где доступно. Не предполагай npm install или poetry по одному наличию файла. Не меняй lockfile ради setup без причины.
+5. Определи .wolf/: проектная память или task-local копия, владелец записи, путь общего состояния и порядок интеграции. Существующая runtime-поддержка должна быть проверена; не предполагай автоматический shared-root. При отсутствии модели синхронизации сериализуй запись и передай память L1.
+6. Выполни baseline-проверки профиля; сохрани evidence и исходные падения. Детерминированное известное нерелевантное падение допускается при разрешённой политике с явным ограничением; блокирующее или неизвестное передай L1/L0.
+7. Передай TASK: cwd, branch, base_sha, allowlist, setup, checks, memory ownership и baseline limitations.
 
-Git worktree создаёт изолированное рабочее пространство с общим репозиторием: работа в нескольких ветках одновременно без переключений.
+## Параллельность и cleanup
 
-**Принцип:** систематический выбор каталога + верификация безопасности = надёжная изоляция.
+Отдельные worktree изолируют файлы, но не общую внешнюю БД, процессы, порты и память. Назначь раздельные fixtures/ports и write ownership. Совместимые изменения интегрирует L1 в известном порядке. Память Wolf — task-local: `wolf` резолвит `.wolf/` от текущего каталога; новый worktree без wolf init общей памяти основного репозитория не видит — состояние переноси через wolf-handoff, а не шаринг `.wolf/`.
 
-**Анонс в начале:** «Использую скилл using-git-worktrees для настройки изолированного workspace».
-
-## Выбор каталога
-
-Правило проекта: worktree — **внутри проекта**, `.worktrees/<имя-задачи>` (никаких глобальных путей).
-
-Приоритет:
-
-1. **Существует `.worktrees/`** → использовать его.
-2. **AGENTS.md проекта** → прочитать; если указана иная конвенция — следовать ей без вопросов.
-3. **Ничего не указано** → создать `.worktrees/` внутри проекта; при сомнениях спросить владельца.
-
-`<имя-задачи>` берётся из брифа executor-lead'а (слаг задачи/фичи).
-
-## Верификация безопасности
-
-Каталог project-local → **ОБЯЗАТЕЛЬНО проверить игнор до создания worktree:**
-
-```bash
-# Учитывает локальный, глобальный и системный gitignore
-git check-ignore -q .worktrees
-```
-
-**НЕ игнорируется?** Правило «почини сломанное сразу»:
-
-1. Добавь строку в `.gitignore`
-2. Закоммить изменение
-3. Продолжай создание worktree
-
-**Почему критично:** предотвращает случайный коммит содержимого worktree в репозиторий.
-
-## Шаги создания
-
-### 1. Создать worktree
-
-```bash
-git worktree add .worktrees/<имя-задачи> -b <имя-ветки>
-cd .worktrees/<имя-задачи>
-```
-
-### 2. Запустить сетап проекта
-
-Автодетект по файлам проекта:
-
-```bash
-# Node.js
-if [ -f package.json ]; then npm install; fi
-
-# Rust
-if [ -f Cargo.toml ]; then cargo build; fi
-
-# Python
-if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
-if [ -f pyproject.toml ]; then poetry install; fi
-
-# Go
-if [ -f go.mod ]; then go mod download; fi
-```
-
-### 3. Верифицировать чистый бейзлайн
-
-Прогнать тесты, чтобы worktree стартовал с чистого состояния (в проектах Wolf — `npm run check`):
-
-```bash
-npm run check   # или тестовая команда проекта
-```
-
-**Упали?** Доложить о падениях, спросить: продолжать или исследовать.
-
-**Зелёные?** Доложить о готовности.
-
-### 4. Отчитаться о расположении
-
-```
-Worktree готов: <полный-путь>
-Тесты проходят (<N> тестов, 0 падений)
-Готов к реализации <имя-фичи>
-```
-
-## Быстрая шпаргалка
-
-| Ситуация                             | Действие                                               |
-| ------------------------------------ | ------------------------------------------------------ |
-| `.worktrees/` существует             | Использовать (проверить игнор)                         |
-| Не существует                        | Создать внутри проекта `.worktrees/` (правило проекта) |
-| Каталог не игнорируется              | Добавить в .gitignore + коммит                         |
-| Тесты падают на бейзлайне            | Доложить о падениях + спросить                         |
-| Нет package.json / Cargo.toml и т.п. | Скипнуть установку зависимостей                        |
-
-## Частые ошибки
-
-### Пропуск проверки игнора
-
-- **Проблема:** содержимое worktree попадает под трекинг, замусоривает git status
-- **Фикс:** всегда `git check-ignore` перед созданием project-local worktree
-
-### Предположение о расположении каталога
-
-- **Проблема:** неконсистентность, нарушение конвенций проекта
-- **Фикс:** следовать приоритету: существующий `.worktrees/` → AGENTS.md → правило проекта (внутри проекта)
-
-### Продолжение с падающими тестами
-
-- **Проблема:** не отличить новые баги от существующих
-- **Фикс:** доложить о падениях, получить явное разрешение на продолжение
-
-### Хардкод команд сетапа
-
-- **Проблема:** ломается на проектах с другими инструментами
-- **Фикс:** автодетект по файлам проекта (package.json и т.д.)
-
-## Пример workflow
-
-```
-Ты: Использую скилл using-git-worktrees для настройки изолированного workspace.
-
-[Проверяю .worktrees/ — существует]
-[Верифицирую игнор — git check-ignore подтверждает: .worktrees/ игнорируется]
-[Создаю: git worktree add .worktrees/auth -b feature/auth]
-[npm install]
-[npm run check — 47 passing]
-
-Worktree готов: /путь/к/проекту/.worktrees/auth
-Тесты проходят (47 тестов, 0 падений)
-Готов к реализации фичи auth
-```
-
-## Red flags
-
-**Никогда:**
-
-- Не создавать worktree без проверки игнора (project-local)
-- Не пропускать бейзлайн-верификацию тестов
-- Не продолжать с падающими тестами без вопроса
-- Не предполагать расположение каталога при неоднозначности
-- Не пропускать проверку AGENTS.md
-
-**Всегда:**
-
-- Следовать правилу проекта: worktree внутри проекта, `.worktrees/<имя-задачи>`
-- Верифицировать игнор для project-local каталогов
-- Автодетектить и запускать сетап проекта
-- Верифицировать чистый тестовый бейзлайн
-
-## Интеграция
-
-**Вызывается из:**
-
-- **wolf-sdd** — REQUIRED до старта исполнения задач (H5)
-- **wolf-execute** — REQUIRED до старта исполнения задач (H5)
-- Любого скилла, которому нужен изолированный workspace
-
-**Пара с:**
-
-- **finishing-a-development-branch** — REQUIRED для уборки после завершения работы
-
-## Конвейер (2.15)
-
-Параллельные потоки волны — отдельные worktree `.worktrees/<имя-задачи>` (агрегат
-Стюарда по параллельным воркерам): независимые потоки стартуют параллельно,
-конфликт-точки сериализуются порядком влитий.
+Путь worktree и имя ветки сохраняй до checkout/cleanup. Уборка — finishing-a-development-branch: после PR рабочая копия сохраняется, пока она нужна для исправлений; грязную или чужую копию не удалять.