mister-wolf 2.14.1 → 2.15.0

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

@@ -10,15 +10,15 @@ description: Используй при реализации любой фичи
 
 ## Трассировка адаптации
 
-| Пункт 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"` (брать наибольшую версию) |
+| Пункт 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"` (брать наибольшую версию)          |
 
 ## Обзор
 
@@ -31,12 +31,14 @@ description: Используй при реализации любой фичи
 ## Когда применять
 
 **Всегда:**
+
 - Новые фичи
 - Багфиксы
 - Рефакторинг
 - Изменения поведения
 
 **Исключения (только с явного разрешения владельца — эскалируй через executor-lead):**
+
 - Одноразовые прототипы
 - Генерированный код
 - Конфигурационные файлы
@@ -52,6 +54,7 @@ description: Используй при реализации любой фичи
 Написал код до теста? Удали. Начни заново.
 
 **Без исключений:**
+
 - Не оставляй «как референс»
 - Не «адаптируй» его при написании тестов
 - Не смотри на него
@@ -97,12 +100,13 @@ test('повторяет неудачную операцию 3 раза', async
     return 'success';
   };
 
-  const result = await retryOperation(operation);
+const result = await retryOperation(operation);
 
-  expect(result).toBe('success');
-  expect(attempts).toBe(3);
+expect(result).toBe('success');
+expect(attempts).toBe(3);
 });
-```
+
+````
 Ясное имя, тестирует реальное поведение, одно
 </Good>
 
@@ -116,11 +120,13 @@ test('retry works', async () => {
   await retryOperation(mock);
   expect(mock).toHaveBeenCalledTimes(3);
 });
-```
+````
+
 Расплывчатое имя, тестирует мок, а не код
 </Bad>
 
 **Требования:**
+
 - Одно поведение
 - Ясное имя
 - Реальный код (моки — только при неизбежности)
@@ -134,6 +140,7 @@ npx vitest run <путь-к-тесту>
 ```
 
 Подтверди:
+
 - Тест падает (а не ошибается)
 - Сообщение об ошибке ожидаемое
 - Падает из-за отсутствия фичи (не из-за опечаток)
@@ -189,6 +196,7 @@ npx vitest run <путь-к-тесту>
 ```
 
 Подтверди:
+
 - Тест проходит
 - Остальные тесты всё ещё проходят
 - Вывод чистый (без ошибок и предупреждений)
@@ -200,6 +208,7 @@ npx vitest run <путь-к-тесту>
 ### РЕФАКТОРИНГ — приберись
 
 Только после зелёного:
+
 - Убери дублирование
 - Улучши имена
 - Вынеси хелперы
@@ -212,17 +221,18 @@ npx vitest run <путь-к-тесту>
 
 ## Хорошие тесты
 
-| Качество | Хорошо | Плохо |
-|---------|------|-----|
+| Качество          | Хорошо                                | Плохо                                      |
+| ----------------- | ------------------------------------- | ------------------------------------------ |
 | **Минимальность** | Одно поведение. «И» в имени? Раздели. | `test('проверяет email, домен и пробелы')` |
-| **Ясность** | Имя описывает поведение | `test('test1')` |
-| **Намерение** | Демонстрирует желаемый API | Затуманивает, что код должен делать |
+| **Ясность**       | Имя описывает поведение               | `test('test1')`                            |
+| **Намерение**     | Демонстрирует желаемый API            | Затуманивает, что код должен делать        |
 
 ## Почему важен порядок
 
 **«Я напишу тесты после, чтобы проверить, что работает»**
 
 Тесты, написанные после кода, проходят сразу. Прохождение сразу не доказывает ничего:
+
 - Может тестировать не то
 - Может тестировать реализацию, а не поведение
 - Может упускать пограничные случаи, которые ты забыл
@@ -233,6 +243,7 @@ npx vitest run <путь-к-тесту>
 **«Я уже вручно протестировал все пограничные случаи»**
 
 Ручное тестирование ад-хок. Ты думаешь, что проверил всё, но:
+
 - Нет записи о том, что проверено
 - Нельзя перезапустить при изменении кода
 - Легко забыть случаи под давлением
@@ -243,6 +254,7 @@ npx vitest run <путь-к-тесту>
 **«Удалить X часов работы расточительно»**
 
 Ошибка невозвратных издержек. Время уже потрачено. Выбор сейчас:
+
 - Удалить и переписать по TDD (ещё X часов, высокая уверенность)
 - Оставить и дописать тесты после (30 минут, низкая уверенность, вероятные баги)
 
@@ -251,6 +263,7 @@ npx vitest run <путь-к-тесту>
 **«TDD догматично, прагматизм означает адаптацию»**
 
 TDD — И есть прагматизм:
+
 - Находит баги до коммита (быстрее отладки после)
 - Предотвращает регрессии (тесты ловят поломки сразу)
 - Документирует поведение (тесты показывают, как использовать код)
@@ -270,19 +283,19 @@ TDD — И есть прагматизм:
 
 ## Распространённые рационализации
 
-| Оправдание | Реальность |
-|--------|---------|
-| «Слишком просто, чтобы тестировать» | Простой код ломается. Тест занимает 30 секунд. |
-| «Напишу тесты после» | Тесты, проходящие сразу, не доказывают ничего. |
-| «Тесты после достигают тех же целей» | Тесты-после = «что это делает?». Тесты-первый = «что это должно делать?» |
-| «Уже протестировал вручную» | Ад-хок ≠ систематично. Нет записи, нельзя перезапустить. |
-| «Удалить X часов работы расточительно» | Ошибка невозвратных издержек. Держать непроверенный код — техдолг. |
-| «Оставлю как референс, напишу тесты с нуля» | Ты его адаптируешь. Это тесты-после. Удалить = удалить. |
-| «Нужно сначала поисследовать» | Ок. Выброси исследование, начни с TDD. |
-| «Тест сложный — дизайн неясен» | Слушай тест. Сложно тестировать = сложно использовать. |
-| «TDD меня замедлит» | TDD быстрее отладки. Прагматизм = тест-первый. |
-| «Ручной тест быстрее» | Ручной не доказывает пограничные случаи. Перепроверять при каждом изменении. |
-| «В существующем коде нет тестов» | Ты его улучшаешь. Добавляй тесты для существующего кода. |
+| Оправдание                                  | Реальность                                                                   |
+| ------------------------------------------- | ---------------------------------------------------------------------------- |
+| «Слишком просто, чтобы тестировать»         | Простой код ломается. Тест занимает 30 секунд.                               |
+| «Напишу тесты после»                        | Тесты, проходящие сразу, не доказывают ничего.                               |
+| «Тесты после достигают тех же целей»        | Тесты-после = «что это делает?». Тесты-первый = «что это должно делать?»     |
+| «Уже протестировал вручную»                 | Ад-хок ≠ систематично. Нет записи, нельзя перезапустить.                     |
+| «Удалить X часов работы расточительно»      | Ошибка невозвратных издержек. Держать непроверенный код — техдолг.           |
+| «Оставлю как референс, напишу тесты с нуля» | Ты его адаптируешь. Это тесты-после. Удалить = удалить.                      |
+| «Нужно сначала поисследовать»               | Ок. Выброси исследование, начни с TDD.                                       |
+| «Тест сложный — дизайн неясен»              | Слушай тест. Сложно тестировать = сложно использовать.                       |
+| «TDD меня замедлит»                         | TDD быстрее отладки. Прагматизм = тест-первый.                               |
+| «Ручной тест быстрее»                       | Ручной не доказывает пограничные случаи. Перепроверять при каждом изменении. |
+| «В существующем коде нет тестов»            | Ты его улучшаешь. Добавляй тесты для существующего кода.                     |
 
 ## Red flags — ОСТАНОВИСЬ и начни заново
 
@@ -307,6 +320,7 @@ TDD — И есть прагматизм:
 **Баг:** принимается пустой email
 
 **КРАСНЫЙ**
+
 ```typescript
 test('отклоняет пустой email', async () => {
   const result = await submitForm({ email: '' });
@@ -315,12 +329,14 @@ test('отклоняет пустой email', async () => {
 ```
 
 **Верифицируй КРАСНЫЙ**
+
 ```bash
 $ npx vitest run <путь-к-тесту>
 FAIL: expected 'Email required', got undefined
 ```
 
 **ЗЕЛЁНЫЙ**
+
 ```typescript
 function submitForm(data: FormData) {
   if (!data.email?.trim()) {
@@ -331,6 +347,7 @@ function submitForm(data: FormData) {
 ```
 
 **Верифицируй ЗЕЛЁНЫЙ**
+
 ```bash
 $ npx vitest run <путь-к-тесту>
 PASS
@@ -356,12 +373,12 @@ PASS
 
 ## Когда застрял
 
-| Проблема | Решение |
-|---------|----------|
-| Не знаю, как тестировать | Напиши желаемый API. Сначала напиши assertion. Запроси подсказку владельца через executor-lead. |
-| Тест слишком сложный | Дизайн слишком сложный. Упрости интерфейс. |
-| Приходится мокать всё | Код слишком связан. Используй внедрение зависимостей. |
-| Подготовка теста огромная | Вынеси хелперы. Всё ещё сложно? Упрости дизайн. |
+| Проблема                  | Решение                                                                                         |
+| ------------------------- | ----------------------------------------------------------------------------------------------- |
+| Не знаю, как тестировать  | Напиши желаемый API. Сначала напиши assertion. Запроси подсказку владельца через executor-lead. |
+| Тест слишком сложный      | Дизайн слишком сложный. Упрости интерфейс.                                                      |
+| Приходится мокать всё     | Код слишком связан. Используй внедрение зависимостей.                                           |
+| Подготовка теста огромная | Вынеси хелперы. Всё ещё сложно? Упрости дизайн.                                                 |
 
 ## Интеграция с отладкой
 
@@ -389,3 +406,8 @@ PASS
 ```
 
 Без исключений — кроме явного разрешения владельца.
+
+## Конвейер (2.15)
+
+Сценарии `docs/dev/<дата>-<slug>/test-plan.md` — заготовки КРАСНОЙ фазы: TDD-цикл
+фичи конвейера начинается с переноса сценария в падающий тест, не с изобретения теста.

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

@@ -10,14 +10,14 @@ description: Используй при старте фичи, которой н
 
 ## Трассировка адаптации
 
-| Пункт 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/`; правило «чинить сломанное сразу» сохранено как механика без имени |
+| Пункт 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/`; правило «чинить сломанное сразу» сохранено как механика без имени               |
 
 ## Обзор
 
@@ -106,13 +106,13 @@ Worktree готов: <полный-путь>
 
 ## Быстрая шпаргалка
 
-| Ситуация | Действие |
-|-----------|--------|
-| `.worktrees/` существует | Использовать (проверить игнор) |
-| Не существует | Создать внутри проекта `.worktrees/` (правило проекта) |
-| Каталог не игнорируется | Добавить в .gitignore + коммит |
-| Тесты падают на бейзлайне | Доложить о падениях + спросить |
-| Нет package.json / Cargo.toml и т.п. | Скипнуть установку зависимостей |
+| Ситуация                             | Действие                                               |
+| ------------------------------------ | ------------------------------------------------------ |
+| `.worktrees/` существует             | Использовать (проверить игнор)                         |
+| Не существует                        | Создать внутри проекта `.worktrees/` (правило проекта) |
+| Каталог не игнорируется              | Добавить в .gitignore + коммит                         |
+| Тесты падают на бейзлайне            | Доложить о падениях + спросить                         |
+| Нет package.json / Cargo.toml и т.п. | Скипнуть установку зависимостей                        |
 
 ## Частые ошибки
 
@@ -155,6 +155,7 @@ Worktree готов: /путь/к/проекту/.worktrees/auth
 ## Red flags
 
 **Никогда:**
+
 - Не создавать worktree без проверки игнора (project-local)
 - Не пропускать бейзлайн-верификацию тестов
 - Не продолжать с падающими тестами без вопроса
@@ -162,6 +163,7 @@ Worktree готов: /путь/к/проекту/.worktrees/auth
 - Не пропускать проверку AGENTS.md
 
 **Всегда:**
+
 - Следовать правилу проекта: worktree внутри проекта, `.worktrees/<имя-задачи>`
 - Верифицировать игнор для project-local каталогов
 - Автодетектить и запускать сетап проекта
@@ -170,9 +172,17 @@ Worktree готов: /путь/к/проекту/.worktrees/auth
 ## Интеграция
 
 **Вызывается из:**
+
 - **wolf-sdd** — REQUIRED до старта исполнения задач (H5)
 - **wolf-execute** — REQUIRED до старта исполнения задач (H5)
 - Любого скилла, которому нужен изолированный workspace
 
 **Пара с:**
+
 - **finishing-a-development-branch** — REQUIRED для уборки после завершения работы
+
+## Конвейер (2.15)
+
+Параллельные потоки волны — отдельные worktree `.worktrees/<имя-задачи>` (агрегат
+Стюарда по параллельным воркерам): независимые потоки стартуют параллельно,
+конфликт-точки сериализуются порядком влитий.

package/templates/base/skills/verification-before-completion/SKILL.md

@@ -10,12 +10,12 @@ description: Используй перед любым заявлением о з
 
 ## Трассировка адаптации
 
-| Пункт upstream | Судьба |
-|---|---|
-| Iron Law, функция-гейт (5 шагов), таблица типовых сбоев (7), red flags (8), рационализации (8), ключевые паттерны (5), «Why This Matters» (5), «When To Apply» (2 списка) | **сохранено полностью** по смыслу дословно (H7; research §1: «Нет — полностью переносим») |
-| «Agent delegation» | **заменено**: агенты → воркеры контура Wolf (worker-\*); отчёт воркера — не доказательство, dispatcher проверяет git-дифф и верификацию |
-| Тестовая команда | **конкретизировано**: `npm run check` — верификационный примитив проекта (+ точечные прогоны `npx vitest run <путь>`) |
-| Nothing | **отброшено**: ничего — привязок к harness у источника нет |
+| Пункт upstream                                                                                                                                                            | Судьба                                                                                                                                  |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
+| Iron Law, функция-гейт (5 шагов), таблица типовых сбоев (7), red flags (8), рационализации (8), ключевые паттерны (5), «Why This Matters» (5), «When To Apply» (2 списка) | **сохранено полностью** по смыслу дословно (H7; research §1: «Нет — полностью переносим»)                                               |
+| «Agent delegation»                                                                                                                                                        | **заменено**: агенты → воркеры контура Wolf (worker-\*); отчёт воркера — не доказательство, dispatcher проверяет git-дифф и верификацию |
+| Тестовая команда                                                                                                                                                          | **конкретизировано**: `npm run check` — верификационный примитив проекта (+ точечные прогоны `npx vitest run <путь>`)                   |
+| Nothing                                                                                                                                                                   | **отброшено**: ничего — привязок к harness у источника нет                                                                              |
 
 ## Обзор
 
@@ -51,15 +51,15 @@ description: Используй перед любым заявлением о з
 
 ## Типовые сбои
 
-| Заявление | Требуется | Недостаточно |
-|-------|----------|----------------|
-| Тесты проходят | Вывод тестовой команды: 0 падений | Прошлый прогон, «должно пройти» |
-| Линтер чист | Вывод линтера: 0 ошибок | Частичная проверка, экстраполяция |
-| Сборка проходит | Команда сборки: exit 0 | Линтер зелёный, логи выглядят хорошо |
-| Баг исправлен | Тест исходного симптома: проходит | Код изменён, «предположительно исправлено» |
-| Регрессионный тест работает | Проверен цикл красный-зелёный | Тест прошёл один раз |
-| Воркер завершил задачу | git-дифф показывает изменения | Отчёт воркера «успех» |
-| Требования выполнены | Построчный чеклист | Тесты проходят |
+| Заявление                   | Требуется                         | Недостаточно                               |
+| --------------------------- | --------------------------------- | ------------------------------------------ |
+| Тесты проходят              | Вывод тестовой команды: 0 падений | Прошлый прогон, «должно пройти»            |
+| Линтер чист                 | Вывод линтера: 0 ошибок           | Частичная проверка, экстраполяция          |
+| Сборка проходит             | Команда сборки: exit 0            | Линтер зелёный, логи выглядят хорошо       |
+| Баг исправлен               | Тест исходного симптома: проходит | Код изменён, «предположительно исправлено» |
+| Регрессионный тест работает | Проверен цикл красный-зелёный     | Тест прошёл один раз                       |
+| Воркер завершил задачу      | git-дифф показывает изменения     | Отчёт воркера «успех»                      |
+| Требования выполнены        | Построчный чеклист                | Тесты проходят                             |
 
 ## Red flags — СТОП
 
@@ -74,44 +74,49 @@ description: Используй перед любым заявлением о з
 
 ## Профилактика рационализаций
 
-| Оправдание | Реальность |
-|--------|---------|
-| «Сейчас должно работать» | ЗАПУСТИ верификацию |
-| «Я уверен» | Уверенность ≠ доказательство |
-| «Только этот раз» | Без исключений |
-| «Линтер прошёл» | Линтер ≠ компилятор |
-| «Воркер доложил об успехе» | Проверь независимо |
-| «Я устал» | Усталость ≠ оправдание |
-| «Частичной проверки хватит» | Частичное не доказывает ничего |
-| «Другие слова — правило не применяется» | Дух важнее буквы |
+| Оправдание                              | Реальность                     |
+| --------------------------------------- | ------------------------------ |
+| «Сейчас должно работать»                | ЗАПУСТИ верификацию            |
+| «Я уверен»                              | Уверенность ≠ доказательство   |
+| «Только этот раз»                       | Без исключений                 |
+| «Линтер прошёл»                         | Линтер ≠ компилятор            |
+| «Воркер доложил об успехе»              | Проверь независимо             |
+| «Я устал»                               | Усталость ≠ оправдание         |
+| «Частичной проверки хватит»             | Частичное не доказывает ничего |
+| «Другие слова — правило не применяется» | Дух важнее буквы               |
 
 ## Ключевые паттерны
 
 **Тесты:**
+
 ```
 ✅ [npm run check] [Видно: 591/591 pass] «Все тесты проходят»
 ❌ «Сейчас должно пройти» / «Выглядит корректно»
 ```
 
 **Регрессионные тесты (TDD красный-зелёный):**
+
 ```
 ✅ Написал → Запустил (проходит) → Откатил фикс → Запустил (ОБЯЗАН УПАСТЬ) → Вернул → Запустил (проходит)
 ❌ «Я написал регрессионный тест» (без красно-зелёной верификации)
 ```
 
 **Сборка:**
+
 ```
 ✅ [npm run build] [Видно: exit 0] «Сборка проходит»
 ❌ «Линтер прошёл» (линтер не проверяет компиляцию)
 ```
 
 **Требования:**
+
 ```
 ✅ Перечитай план → составь чеклист → проверь каждый пункт → доложи пробелы или завершение
 ❌ «Тесты проходят, фаза завершена»
 ```
 
 **Делегирование воркерам:**
+
 ```
 ✅ Воркер доложил успех → проверь git-дифф → верифицируй изменения → доложи фактическое состояние
 ❌ Доверять отчёту воркера (воркер, спавненный через {{tool.task}}, мог ошибиться)
@@ -120,6 +125,7 @@ description: Используй перед любым заявлением о з
 ## Почему это важно
 
 Из 24 воспоминаний о сбоях:
+
 - партнёр сказал «я тебе не верю» — доверие разрушено
 - В прод уехали неопределённые функции — урон
 - В прод уехали пропущенные требования — незавершённые фичи
@@ -129,6 +135,7 @@ description: Используй перед любым заявлением о з
 ## Когда применять
 
 **ВСЕГДА перед:**
+
 - Любой вариацией заявлений об успехе/завершённости
 - Любым выражением удовлетворения
 - Любым позитивным утверждением о состоянии работы
@@ -137,6 +144,7 @@ description: Используй перед любым заявлением о з
 - Делегированием воркерам
 
 **Правило распространяется на:**
+
 - Точные формулировки
 - Парафразы и синонимы
 - Импликации успеха
@@ -155,3 +163,9 @@ description: Используй перед любым заявлением о з
 Запусти команду. Прочитай вывод. ТОЛЬКО ПОТОМ заявляй результат.
 
 Это не обсуждается.
+
+## Конвейер (2.15)
+
+Верификация — условие переворота чекбокса plan.md: `- [ ]` → `- [x]` допустимо
+только после прогона проверок задачи (точечные тесты зелёные) + строка
+«сделано → коммит <hash>». Чекбокс — истина завершённости.

package/templates/base/skills/wolf-brainstorm/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wolf-brainstorm
-description: "Обязателен до любой творческой работы — новых фич, компонентов, изменения поведения. Превращает идею в дизайн через диалог: вопросы по одному, варианты с трейд-оффами, аппрув владельца. Discovery-режим координатора."
+description: 'Обязателен до любой творческой работы — новых фич, компонентов, изменения поведения. Превращает идею в дизайн через диалог: вопросы по одному, варианты с трейд-оффами, аппрув владельца. Discovery-режим координатора.'
 ---
 
 # wolf-brainstorm: идея → дизайн
@@ -102,35 +102,50 @@ digraph wolf_brainstorm {
 - Если существующий код мешает работе (файл разросся, границы размыты, ответственности перепутаны) — включи точечные улучшения в дизайн, как хороший разработчик, улучшающий код, в котором работает.
 - Не предлагай несвязанный рефакторинг. Фокус на том, что служит текущей цели.
 
-## После дизайна
+## Выход: requirements.md (v2 — анатомия §4.1 спеки конвейера)
 
-**Документация:**
+Диалог с владельцем завершается артефактом `docs/dev/<дата>-<slug>/requirements.md`.
+Папку создаёт `wolf scaffold artifact <slug>` — файлы артефактов вручную не создавать.
 
-- Запиши валидированный дизайн (спеку) в каталог спек проекта (по умолчанию `docs/specs/YYYY-MM-DD-<тема>-design.md`; предпочтения проекта приоритетнее)
-- Закоммить дизайн-документ (правило проекта: коммит после завершённой работы)
-- Ключевые решения дизайна зафиксируй в памяти: `wolf add --type decision` — с обоснованием; они переживут сессию и достанутся исполнителям
+Структура документа — 7 секций:
 
-**Саморевью спеки:**
-После записи спеки посмотри на неё свежим взглядом:
+1. Контекст и проблема — зачем, прозой, бизнес-языком; метрика успеха.
+2. Область — что входит; НЕ входит (не-цели уровня требований).
+3. Глоссарий — бизнес-термины фичи, если появились новые.
+4. Функциональные требования — записи REQ-NN.
+5. Нефункциональные (NFR-NN) — производительность, безопасность, совместимость;
+   каждая с измеримым критерием.
+6. Ограничения и допущения — что считаем данным.
+7. Журнал изменений (CR) — append-only: дата, затронутый REQ/NFR, что/почему,
+   кем утверждено, downstream-перегенерации.
 
-1. **Скан плейсхолдеров:** есть ли «TBD», «TODO», незаполненные секции, размытые требования? Исправь.
-2. **Внутренняя согласованность:** противоречат ли секции друг другу? Согласуется ли архитектура с описанием фич?
-3. **Проверка scope:** достаточно ли фокусировки для одного плана реализации, или нужна декомпозиция?
-4. **Проверка двусмысленности:** можно ли истолковать требование двумя способами? Если да — выбери одну трактовку и сделай явной.
+Анатомия записи (обязательные поля каждой записи REQ/NFR):
 
-Исправляй на месте. Пересматривать заново не нужно — исправил и двигайся дальше.
+- История: Как <роль>, я хочу <возможность>, чтобы <выгода>.
+- Требование: Когда <условие>, система должна <поведение>.
+- Обоснование: <зачем это бизнесу — словами владельца>.
+- AC: <измеримый критерий; нетривиальные — Given/When/Then>.
+- Приоритет: Must | Should | Could.
+- Источник: <диалог <дата> / жалоба mem-… / ревью-линза>.
 
-**Гейт ревью владельца:**
-После прохождения саморевью попроси владельца прочитать записанную спеку до продолжения:
+Критерии готовности записи (гейт линзы полноты; часть проверяет линт):
+одно требование — одна запись; есть история И формальная запись; есть AC
+(REQ без AC — находка линта); есть источник; неопределённость помечена
+`[НЕОПРЕДЕЛЕНО: вопрос]`, не сжата; владелец пересказывает требование своими
+словами — не может, это дефект требования, а не читателя.
 
-> «Спека записана и закоммичена в `<путь>`. Посмотри её и скажи, нужны ли правки, прежде чем начнём писать план реализации».
+Язык: полные предложения, ноль сленга, термины домена без сокращений, новое
+понятие объясняется при первом употреблении, смысловое сжатие запрещено.
 
-Жди ответа. Запрошены правки — внеси и прогони саморевью заново. Продолжай только после аппрува владельца.
+## Второй режим: roadmap-триаж
 
-**Реализация:**
+Диалог с владельцем по кандидатурам волн → вердикт по каждой: «волна N / бэклог /
+отклонено + причина». Запись — перемещением, не копированием (пункт живёт ровно
+в одном файле; дубль — находка линта doctor):
 
-- Вызови {{tool.skill}} wolf-plan для создания детального плана реализации
-- НЕ вызывай никаких других скиллов. Следующий шаг — только wolf-plan.
+- волна N → `docs/dev/roadmap/wave-N.md` (состав волны, источник вердикта);
+- бэклог → `docs/dev/roadmap/backlog.md`;
+- отклонено → `docs/dev/roadmap/rejected.md` (+ причина).
 
 ## Ключевые принципы
 
@@ -147,21 +162,21 @@ digraph wolf_brainstorm {
 
 > Источник: `~/.config/opencode/superpowers/skills/brainstorming/SKILL.md`, upstream 6efe32c (2026-04-23)
 
-| Пункт источника | Судьба | Почему |
-|---|---|---|
-| HARD-GATE до аппрува | сохранено | Ядро скилла; «user» → «владелец» |
-| Анти-паттерн «слишком просто для дизайна» | сохранено полностью (1/1) | H7 |
-| Чеклист (9 пунктов) | сохранено; п.2 (visual companion) отброшен, п.9 → wolf-plan | Браузерный компаньон вне базового набора |
-| Пункт «Invoke writing-plans skill» | заменено → `{{tool.skill}} wolf-plan` | H4: терминальное состояние — только wolf-plan |
-| TodoWrite | заменено → `{{tool.todowrite}}` | Плейсхолдер |
-| Flowchart | сохранено; терминальный узел → wolf-plan | Ядро-флоу |
-| «The Process» (5 блоков) | сохранено | Переносимое ядро |
-| Путь `docs/superpowers/specs/` | заменено → `docs/specs/…` + предпочтения проекта | Harness-привязка (research §1) |
-| Саморевью спеки (4 проверки) | сохранено полностью (4/4) | Чеклист-ядро |
-| Гейт ревью владельца | сохранено | Ядро |
-| Ключевые принципы (6) | сохранено полностью (6/6) | H7 |
-| Скилл elements-of-style (секция «Документация») | отброшено | Скилл вне базового набора (research §6) |
-| Visual Companion (секция + `visual-companion.md`) | отброшено | Браузерный компаньон и sibling-файл не переносятся |
-| — | добавлено: Discovery-режим; worktree НЕ создаёт; `wolf add --type decision` | Спека §5.2 (архив §2.3), H5-распределение владения worktree |
+| Пункт источника                                   | Судьба                                                                      | Почему                                                      |
+| ------------------------------------------------- | --------------------------------------------------------------------------- | ----------------------------------------------------------- |
+| HARD-GATE до аппрува                              | сохранено                                                                   | Ядро скилла; «user» → «владелец»                            |
+| Анти-паттерн «слишком просто для дизайна»         | сохранено полностью (1/1)                                                   | H7                                                          |
+| Чеклист (9 пунктов)                               | сохранено; п.2 (visual companion) отброшен, п.9 → wolf-plan                 | Браузерный компаньон вне базового набора                    |
+| Пункт «Invoke writing-plans skill»                | заменено → `{{tool.skill}} wolf-plan`                                       | H4: терминальное состояние — только wolf-plan               |
+| TodoWrite                                         | заменено → `{{tool.todowrite}}`                                             | Плейсхолдер                                                 |
+| Flowchart                                         | сохранено; терминальный узел → wolf-plan                                    | Ядро-флоу                                                   |
+| «The Process» (5 блоков)                          | сохранено                                                                   | Переносимое ядро                                            |
+| Путь `docs/superpowers/specs/`                    | заменено → `docs/specs/…` + предпочтения проекта                            | Harness-привязка (research §1)                              |
+| Саморевью спеки (4 проверки)                      | сохранено полностью (4/4)                                                   | Чеклист-ядро                                                |
+| Гейт ревью владельца                              | сохранено                                                                   | Ядро                                                        |
+| Ключевые принципы (6)                             | сохранено полностью (6/6)                                                   | H7                                                          |
+| Скилл elements-of-style (секция «Документация»)   | отброшено                                                                   | Скилл вне базового набора (research §6)                     |
+| Visual Companion (секция + `visual-companion.md`) | отброшено                                                                   | Браузерный компаньон и sibling-файл не переносятся          |
+| —                                                 | добавлено: Discovery-режим; worktree НЕ создаёт; `wolf add --type decision` | Спека §5.2 (архив §2.3), H5-распределение владения worktree |
 
 Перенесённые списки: анти-паттерны 1/1, принципы 6/6, саморевью 4/4.