mister-wolf 1.0.3 → 1.1.0

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

@@ -0,0 +1,391 @@
+---
+name: test-driven-development
+description: Используй при реализации любой фичи или багфикса, до написания кода реализации
+---
+
+# Test-Driven Development (TDD)
+
+> Источник: ~/.config/opencode/superpowers/skills/test-driven-development/SKILL.md, upstream 6efe32c (2026-04-23).
+> Адресат: worker-implementer — пассивный процесс: читаешь и следуешь в рамках своей единственной задачи, без диспетчеризации.
+
+## Трассировка адаптации
+
+| Пункт 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"` (брать наибольшую версию) |
+
+## Обзор
+
+Сначала напиши тест. Посмотри, как он падает. Напиши минимальный код, чтобы он прошёл.
+
+**Принцип:** если ты не видел, как тест падает, ты не знаешь, проверяет ли он то, что нужно.
+
+**Нарушение буквы правил — это нарушение духа правил.**
+
+## Когда применять
+
+**Всегда:**
+- Новые фичи
+- Багфиксы
+- Рефакторинг
+- Изменения поведения
+
+**Исключения (только с явного разрешения владельца — эскалируй через executor-lead):**
+- Одноразовые прототипы
+- Генерированный код
+- Конфигурационные файлы
+
+Думаешь «пропущу 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
+```
+
+Без исключений — кроме явного разрешения владельца.

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

@@ -0,0 +1,178 @@
+---
+name: using-git-worktrees
+description: Используй при старте фичи, которой нужна изоляция от текущего workspace, или перед исполнением планов — создаёт изолированные git-worktree с проверкой безопасности
+---
+
+# 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).
+
+## Трассировка адаптации
+
+| Пункт 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/`; правило «чинить сломанное сразу» сохранено как механика без имени |
+
+## Обзор
+
+Git worktree создаёт изолированное рабочее пространство с общим репозиторием: работа в нескольких ветках одновременно без переключений.
+
+**Принцип:** систематический выбор каталога + верификация безопасности = надёжная изоляция.
+
+**Анонс в начале:** «Использую скилл 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 для уборки после завершения работы