mister-wolf 2.15.1 → 2.15.2

package/templates/base/skills/receiving-code-review/SKILL.md

@@ -1,39 +1,23 @@
 ---
 name: receiving-code-review
-description: 'Фидбек владельца и ревью-линз: высший приоритет лестницы, но не слепое внедрение — техническая строгость, проверка возражений, протокол несогласия.'
+description: "Разбирай замечания пользователя или ревьюера: проверь основание, ответь на каждый пункт, исправь подтверждённый дефект и повтори затронутые проверки. Не принимай и не отвергай фидбек без evidence."
 ---
 
-# receiving-code-review: приём фидбека
-
-## Обзор
-
-Фидбек владельца = высший приоритет лестницы приоритетов. Но «внедри совет» — не
-поведение по умолчанию: ревью может быть технически неверным.
+# Обработка ревью
 
 ## Процесс
 
-1. Прочитать фидбек целиком; классифицировать каждый пункт: факт-исправление /
-   вопрос / возражение.
-2. Согласен → внедрить + коммит + строка «что исправлено» в отчёт.
-3. Сомневаешься → проверить по коду/документу ДО ответа; возражение обосновать
-   пруфом (file:line), не мнением.
-4. Фидбек противоречит памяти Wolf/рамке → по лестнице приоритетов (память выше
-   скиллов); расхождение правил → жалоба по протоколу жалоб, не самовольная
-   правка правила.
-5. Уроки фидбека (воспроизводимый паттерн ошибки) → `wolf add --type lesson`.
+1. Прочитай весь набор; различи исправление факта, вопрос, дефект, предпочтение и изменение требований. Свяжи с finding_id; если его нет, создай локальный идентификатор ответа.
+2. Проверь воспроизводимость по исходным требованиям, коду и evidence. Ответ на каждый пункт: ACCEPTED, REFUTED, DEFERRED или NEEDS_CLARIFICATION; добавь основание и действие. Эти метки — отчёт, не типы памяти.
+3. Подтверждённый Critical/Major исправь до приёмки; Minor назначь или отложи с причиной. Пользовательское указание о цели имеет приоритет; техническую неверность рекомендации объясни и предложи способ достичь цели.
+4. Изменение AC/scope проведи через CR и L0; не переписывай контракт, чтобы обойти находку. Конфликт действующих методик передай жалобным контуром, но не останавливай независимую полезную работу без необходимости.
+5. Правь минимально; проверки выбери по влиянию. Коммиты делает роль с действующим разрешением. Зафиксируй revision исправления, evidence и незакрытые риски.
+6. Запроси повторное ревью affected mandates. Отсутствие ответа ревьюера не означает одобрения; лимит циклов заканчивается явной эскалацией.
 
-## Запреты
+## Память
 
-- Перформативное согласие без проверки.
-- Внедрение совета вслепую при явном техническом возражении.
-- Тихое игнорирование пункта фидбека.
+Наблюдение о конкретной незавершённой работе фиксируй задачей/заметкой; обобщаемый повторяемый паттерн — lesson с областью применимости и evidence. Не создавай правило из каждого комментария. Недоступную запись передай L1; не обходи permissions.
 
-## Трассировка адаптации
+## Запреты
 
-| Пункт источника (superpowers receiving-code-review) | Судьба                                           | Почему            |
-| --------------------------------------------------- | ------------------------------------------------ | ----------------- |
-| Техническая строгость, не перформативное согласие   | сохранено                                        | ядро              |
-| Проверка перед внедрением                           | сохранено                                        | ядро              |
-| «Совет может быть неверным»                         | сохранено                                        | ядро              |
-| —                                                   | добавлено: лестница приоритетов + протокол жалоб | Wolf-переплетение |
-| —                                                   | добавлено: уроки фидбека → память Wolf           | самообучение      |
+Не изображай согласие без проверки, не игнорируй пункт молча, не превращай ревью в бесконечный косметический цикл. Техническое возражение подкрепи проверяемым основанием, а не уверенностью.

package/templates/base/skills/requesting-code-review/SKILL.md

@@ -1,123 +1,24 @@
 ---
 name: requesting-code-review
-description: Используй при завершении задач, реализации крупных фич или перед мержем — проверить соответствие работы требованиям
+description: "Запрашивай независимое ревью изменений перед интеграцией или при существенном риске. Передай точный диапазон изменений, требования, проверки и мандат; диспетчер L1, ревьюер L2."
 ---
 
-# Requesting Code Review
+# Запрос ревью кода
 
-> Источник: ~/.config/opencode/superpowers/skills/requesting-code-review/SKILL.md, upstream 6efe32c (2026-04-23).
-> Ревью-контур executor'а: диспетчер — executor-lead, ревьюер — worker-reviewer.
+## Подготовка
 
-## Трассировка адаптации
+L1 фиксирует base_sha ДО исполнения задачи, current/head revision и dirty-state. Не используй HEAD~1 как универсальную границу: задача может включать несколько коммитов. Для незакоммиченного результата передай проверяемый diff и состояние файлов; не требуй коммита ради ревью.
 
-| Пункт upstream | Судьба |
-|---|---|
-| Когда запрашивать (2 списка), контекстный шаблон ревьюера (5 полей), таблица act-on-feedback, пример, red flags Never (4) + «если ревьюер неправ» (3), интеграционные привязки | **сохранено полностью** (H6/H7: act-on-feedback и red flags переносятся дословно по смыслу) |
-| Task tool с типом `superpowers:code-reviewer` | **заменено**: спавн worker-reviewer через {{tool.task}}; методика ревьюера — в памяти (контур лица worker-reviewer) |
-| Внешний шаблон `agents/code-reviewer.md` | **заменено**: поля шаблона встроены в этот скилл (BASE_SHA/HEAD_SHA и др.) |
-| Minor → «note for later» | **дополнено**: фиксация через `wolf add --type lesson` (техдолг виден следующим сессиям) |
-| Префикс `superpowers:`, имя code-reviewer | **отброшено**: имена harness'а upstream |
+## Пакет ревьюера
 
-## Обзор
+Передай task_id, цель, AC/REQ и утверждённый design, base/head, cwd/worktree, изменённые и релевантные файлы, contract dependencies, проверки/evidence, известные ограничения. Не передавай самооценку автора как ожидаемый вывод. Независимый reviewer проверяет код и основания, а не только пересказ.
 
-Диспетчеризуй воркера-ревьюера, чтобы поймать проблемы до того, как они каскадируют. Ревьюер получает точно сконструированный контекст для оценки — никогда не историю твоей сессии. Это держит ревьюера сфокусированным на продукте работы, а не на твоём мыслительном процессе, и сохраняет твой контекст для продолжения работы.
+Назначь мандат: соответствие, качество/интеграция или специализированный риск. Для значимых изменений проверь security, миграции и failures; для небольших — пропорциональный объём. L0 вызывает executor, L1 — worker-reviewer. Недоступное независимое ревью явно отметь, не имитируй второй голос.
 
-**Принцип:** ревьюруй рано, ревьюруй часто.
+## Результат
 
-## Когда запрашивать ревью
+Используй контракт wolf-review: finding_id, severity, location/revision, evidence, impact; verdict APPROVED | CHANGES_REQUIRED | INCONCLUSIVE. Critical/Major блокируют приёмку; Minor — нет, кроме явно обоснованного риска. Технический долг — отдельная задача/заметка, lesson только для повторяемого знания.
 
-**Обязательно:**
-- После каждой задачи в wolf-sdd
-- После завершения крупной фичи
-- Перед мержем в main
+## Обработка
 
-**Опционально, но ценно:**
-- Когда застрял (свежий взгляд)
-- Перед рефакторингом (базовая проверка)
-- После фиксации сложного бага
-
-## Как запросить
-
-**1. Получить git SHA:**
-```bash
-BASE_SHA=$(git rev-parse HEAD~1)   # или origin/main
-HEAD_SHA=$(git rev-parse HEAD)
-```
-
-**2. Диспетчеризовать воркера-ревьюера через {{tool.task}}:**
-
-Спавн worker-reviewer; контекст ревьюера заполняет диспетчер (executor-lead). Ревьюер сам подтягивает методику перед задачей: `wolf search "worker-reviewer playbook"` (контур лица, наибольшая версия).
-
-**Поля контекста:**
-- `{WHAT_WAS_IMPLEMENTED}` — что только что построено
-- `{PLAN_OR_REQUIREMENTS}` — что оно должно делать (задача из плана / бриф)
-- `{BASE_SHA}` — стартовый коммит
-- `{HEAD_SHA}` — конечный коммит
-- `{DESCRIPTION}` — краткое описание
-
-**3. Действовать по фидбеку (act-on-feedback):**
-
-| Категория | Действие |
-|---|---|
-| Critical | Исправить немедленно |
-| Important | Исправить до продолжения работы |
-| Minor | Зафиксировать и учесть позже (`wolf add --type lesson`) |
-
-Возражай, если ревьюер неправ (с обоснованием).
-
-## Пример
-
-```
-[Завершена задача 2: функция верификации]
-
-Ты: Запрошу ревью перед продолжением.
-
-BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
-HEAD_SHA=$(git rev-parse HEAD)
-
-[Диспетчеризую worker-reviewer через {{tool.task}}]
-  WHAT_WAS_IMPLEMENTED: Функции verifyIndex() и repairIndex() для индекса диалогов
-  PLAN_OR_REQUIREMENTS: Задача 2 из docs/plans/deployment-plan.md
-  BASE_SHA: a7981ec
-  HEAD_SHA: 3df7661
-  DESCRIPTION: Добавлены verifyIndex() и repairIndex() с 4 типами проблем
-
-[Воркер вернул]:
-  Strengths: чистая архитектура, настоящие тесты
-  Issues:
-    Important: нет индикаторов прогресса
-    Minor: магическое число (100) для интервала отчётности
-  Assessment: готов к продолжению
-
-Ты: [фиксируешь индикаторы прогресса]
-[Minor фиксируешь: wolf add --type lesson "техдолг: магическое число 100 ..."]
-[Продолжаешь задачу 3]
-```
-
-## Интеграция с процессами
-
-**wolf-sdd (субагентная разработка):**
-- Ревью после КАЖДОЙ задачи
-- Ловить проблемы до того, как они накопятся
-- Исправить до перехода к следующей задаче
-
-**wolf-execute (исполнение плана):**
-- Ревью после каждого батча (3 задачи)
-- Получить фидбек, применить, продолжить
-
-**Ad-hoc разработка:**
-- Ревью перед мержем
-- Ревью при застревании
-
-## Red flags
-
-**Никогда:**
-- Не пропускать ревью со словами «это же просто»
-- Не игнорировать Critical-находки
-- Не продолжать с неисправленными Important-находками
-- Не спорить с валидным техническим фидбеком
-
-**Если ревьюер неправ:**
-- Возразить с техническим обоснованием
-- Показать код/тесты, доказывающие работу
-- Попросить уточнение
+Прими фидбек через receiving-code-review. Перед повторным ревью обозначь изменённые версии и закрываемые finding IDs. Сохрани действительные результаты неизменённых проверок; повтори затронутые. Открытие PR и его приёмка — разные состояния, отчёт должен это различать.

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.