mister-wolf 2.15.1 → 2.16.0

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

@@ -1,101 +1,35 @@
 ---
 name: wolf-handoff
-description: "Используй, когда текущая сессия перегружена контекстом, обросла ошибками, дрейфует или работу нужно продолжить в свежей сессии без потери прогресса. Экономика тёплых/холодных сессий: значимое — в память Wolf, продолжение — свежему субагенту."
+description: "Передай работу в новую сессию или замени исполнителя без потери цели, состояния и evidence. Сохрани snapshot и явно передай владение; не создавай вложенных агентов в обход L0/L1/L2."
 ---
 
-# wolf-handoff: передача в свежую сессию
+# Передача состояния
 
-## Обзор
+## Выбор действия
 
-Когда контекст перегружен, сессия обросла ошибками или впереди много шагов — запиши сжатое резюме handoff и продолжи работу в свежем субагенте через {{tool.task}}.
+Различай: продолжение той же роли в новой сессии, замена исполнителя и новая подзадача. L0 передаёт цель преемнику L0 либо поручает L1 поставку; L1 заменяет L2/исполнительскую сессию; L2 возвращает checkpoint и запрос L1. L2 не спавнит преемника. Указание tool.task не гарантирует сброс контекста родителя — проверь возможности платформы.
 
-**Экономика тёплых/холодных сессий:** тёплая сессия дорожает с каждым токеном истории; холодная стартует дёшево, но не знает ничего. Память Wolf ломает этот компромисс: сначала зафиксируй значимое в памяти (`wolf add` — решения, уроки, блокеры), затем передай минимум — свежая сессия подтянет состояние сама (`wolf call` + `wolf brief` на холодном старте).
+## Snapshot
 
-## Когда использовать
+До передачи сохрани в артефакте или разрешённой памяти:
+- task/thread ID, цель, AC, scope и текущий ответственный;
+- base/current revision, cwd, branch/worktree, dirty/untracked, patch или другой доступный способ восстановления;
+- выполненное и оставшееся, dependencies, ожидающий внешний исход;
+- утверждённые решения и активные методики — IDs/версии;
+- проверки с evidence и областью актуальности;
+- гипотезы и неудачные эксперименты, вопросы и блокеры;
+- следующий безопасный шаг, права и действия, уже разрешённые пользователем.
 
-- Окно контекста заполняется или сессия дрейфует
-- Переключение с исследования на реализацию
-- Нужно сбросить якорь после серии неудачных попыток
-- У задачи несколько оставшихся независимых шагов
-- Ты сам запущен как субагент и тебе нужно делегировать дальше
+Не копируй весь чат, код и секреты. Ссылки должны быть доступны преемнику; проверь это. Достаточный snapshot важнее предположения, что wolf call доставит любую запись.
 
-## Шаги
+## Передача владения
 
-1. **Зафиксируй значимое в памяти Wolf.** До передачи:
-   - Решения и их обоснование → `wolf add --type decision`
-   - Уроки (что сработало / что нет) → `wolf add --type lesson`
-   - Открытые блокеры → `wolf add --type blocker`
-   Преемник получит их через `wolf call` / `wolf brief` — дублировать в промпте не нужно.
+1. Зафиксируй snapshot revision и место. При недоступной записи L2 передаёт его L1, не обходит permissions.
+2. Действующим механизмом останови или отзови право записи старого исполнителя; проверь незавершённые инструменты/процессы. При неизвестном исходе сначала выясни состояние.
+3. L1/L0 передаёт преемнику TASK, snapshot и доступные источники. Если технической блокировки нет, установи протокольного единственного владельца и явно обозначь ограничение.
+4. Преемник подтверждает цель, revision, dirty-state и следующий шаг; сверяет память/план с фактом. Несовпадение → NEEDS_CONTEXT, не слепое продолжение.
+5. Только после подтверждения отметь передачу завершённой и сообщи ответственному уровню ID/статус.
 
-2. **Запиши резюме handoff.** Включи:
-   - Что сделано
-   - Что осталось
-   - Ключевые решения и их логика (ссылками на объекты памяти)
-   - Релевантные пути файлов, URL, ссылки на issues/PR
-   - Какие скиллы преемнику стоит задействовать
-   - Отметку о редактированных секретах, API-ключах, токенах, PII
+## Ограничения
 
-3. **Запусти свежий субагент через {{tool.task}}.**
-   - `description`: короткое описательное имя задачи
-   - `subagent_type`: роль преемника — исполнительская роль проекта (например, worker-implementer для реализации, worker-researcher для исследования; координация — через executor-lead)
-   - `prompt`: резюме handoff
-
-4. **Отчитайся владельцу: ID и статус задачи субагента.**
-
-## Пример
-
-Резюме handoff:
-- Решили оставить публикацию v9-сигналов в `adviser/` (решение: mem от 2026-08-30).
-- Реализован `adviser/src/publishers/signal_v9.py`.
-- Осталось: подключить в DI-контейнер `adviser/services/di.py` и добавить тесты.
-- Файлы: `adviser/src/publishers/signal_v9.py`, `adviser/services/di.py`.
-- Скиллы преемнику: test-driven-development, verification-before-completion.
-
-Затем диспетчеризация:
-```
-{{tool.task}}
-  description: Подключить v9-паблишер в DI и тесты
-  subagent_type: worker-implementer
-  prompt: <резюме handoff>
-```
-
-## Что включить
-
-- Конкретные пути файлов и имена символов
-- Принятые решения и почему (или ссылки на них в памяти)
-- Открытые вопросы и блокеры
-- Релевантные тесты, команды, шаги верификации
-
-## Что исключить
-
-- Длинные транскрипты и полные листинги кода
-- Секреты, учётные данные, персональные данные
-- Контент, уже зафиксированный в артефактах (планы, спеки, коммиты, диффы, память Wolf)
-
-## Red Flags
-
-- Передача без письменного резюме
-- Копирование всей беседы в промпт субагента
-- Включение API-ключей или токенов
-- «Кажется» и размытые следующие шаги вместо исполнимых задач
-
----
-
-## Трассировка адаптации
-
-> Источник: `~/.config/opencode/superpowers/skills/opencode-handoff/SKILL.md`, upstream 6efe32c (2026-04-23)
-
-| Пункт источника | Судьба | Почему |
-|---|---|---|
-| Обзор (перегрузка → свежий субагент) | сохранено + экономика тёплых/холодных сессий | Спека §5.2 |
-| Тула `task` с `subagent_type` | заменено → `{{tool.task}}` (subagent_type сохранён как параметр) | Research §1: opencode-тул; плейсхолдер |
-| When to Use (5) | сохранено полностью (5/5) | H7 |
-| Шаги (3) | сохранено; + шаг 0 «зафиксируй в памяти Wolf» (`wolf add`) | Wolf-переплетение |
-| `subagent_type: general/explore` | заменено → роли проекта (worker-implementer / worker-researcher / executor-lead) | Generic-типы не переносимы |
-| Пример | адаптировано (тип → worker-implementer, ссылка на объект памяти) | Иллюстрация |
-| What to Include (4) | сохранено полностью (4/4); + память как артефакт | H7 |
-| What to Exclude (3) | сохранено полностью (3/3); + «память Wolf» | H7 |
-| Red Flags (4) | сохранено полностью (4/4) | H7 |
-| — | добавлено: холодный старт преемника — `wolf call` + `wolf brief` | Протокол проекта |
-
-Перенесённые списки: red flags 4/4, include 4/4, exclude 3/3, when-to-use 5/5.
+Handoff не повышает права и не разрешает незапрошенные внешние действия. Новая сессия не исправляет неправильный план сама по себе. При дрейфе проверь источник ошибки и достаточность snapshot, а не только уменьши текст.

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

@@ -1,194 +1,31 @@
 ---
 name: wolf-plan
-description: 'Используй, когда есть спека или требования для многошаговой задачи — до касания кода. Пишет zero-context планы: каждая задача = самодостаточный бриф воркера, исполнитель не обязан знать кодовую базу.'
+description: "Составляй исполнимые задачи по утверждённым требованиям и дизайну. Планируй зависимости, allowlist, интеграцию, проверки и восстановление без копирования реализации в план."
 ---
 
-# wolf-plan: план для zero-context исполнителя
+# Дизайн → задачи
 
-## Обзор
+## Вход и выход
 
-Пиши исчерпывающие планы реализации в предположении, что исполнитель имеет **нулевой контекст** кодовой базы этой задачи и сомнительный вкус. Задокументируй всё, что ему нужно знать: какие файлы трогать в каждой задаче, код, тесты, какие доки проверить, как проверить работу. Отдай весь план как bite-sized задачи. DRY. YAGNI. TDD. Частые коммиты.
+Вход: approved requirements/design либо разрешённый LITE/FIX-бриф; baseline SHA, профиль проекта и известный test-plan. Выход: plan.md или список TASK с зависимостями и точками интеграции. Автор планирования не выполняет реализацию.
 
-Считай, что исполнитель — умелый разработчик, но почти ничего не знает о нашем тулсете и проблемном домене. Считай, что он плохо умеет в хороший дизайн тестов.
+## Процесс
 
-**Вход воркеров — по брифам:** каждая задача плана становится брифом однозадачного воркера (worker-implementer). Воркер не читает кодовую базу и не видит твою сессию — план обязан содержать всё. Сомнительное качество плана = гарантированные вопросы и переделки на исполнении.
+1. Проверь версии входов. Отнеси каждый REQ/NFR к задаче и проверке; зафиксируй пробелы до исполнения.
+2. Раздели работу по результатам и ответственности. Размер задачи определяется независимой проверкой и доступным контекстом, а не обязательными 2–5 минутами.
+3. Для каждой задачи заполни TASK из using-skills: цель, AC, baseline, ссылки на контракт, allowlist, зависимости, проверки, ограничение scope и ожидаемый RESULT. Разреши читать затронутый код и потребителей; отсутствие истории сессии не означает запрета чтения.
+4. Укажи достаточно точные действия и символы, не полный код реализации. Примеры допустимы для неоднозначного контракта, но не дублируют design. Не предписывай точный код теста вместо проверяемого свойства.
+5. Построй зависимости. Параллельность разреши только для независимых outputs, изолированной записи и определённого владельца интеграции. Общие контракты и миграции сериализуй.
+6. Добавь отдельную интеграционную задачу: порядок объединения, проверка взаимодействий, полный гейт и правила разрешения конфликтов. Укажи промежуточные чекпоинты для длительной работы.
+7. Сверь plan с test-plan: сценарии входят в соответствующие задачи, NFR имеют измерения, тесты запускаются проектными командами. Исполнение FULL не стартует до этой сверки.
+8. Проведи саморевью и назначенное независимое ревью. Ошибку плана исправляй с повторной проверкой затронутых зависимостей.
 
-**Анонс на старте:** «Использую скилл wolf-plan для создания плана реализации».
+## Трекинг
 
-**Контекст:** исполнение плана начинается только в worktree `.worktrees/<имя-задачи>` (правило проекта; создаётся ДО старта исполнения — см. wolf-sdd / wolf-execute). Сам план можно писать и до worktree.
+Пиши задачи чекбоксами с task_id. [x] ставит L1 после проверки результата и необходимых ревью; рядом фиксирует revision/evidence и статус интеграции. Коммит или чекбокс отдельно не доказывает приёмку. Общий plan изменяет L1, не параллельные L2.
 
-## Вход (v2)
+При восстановлении сравни [x] с кодом, доказательствами и вердиктами; несовпадение возвращает задачу в проверку. Не повторяй уже подтверждённые действия автоматически.
 
-- `docs/dev/<дата>-<slug>/requirements.md` (approved).
-- `docs/dev/<дата>-<slug>/design.md` (approved линзами/владельцем).
-  Спека-монолит больше не вход: план не пересказывает требования и не переопределяет
-  контракты — единственный источник контрактов — design.md.
+## Передача
 
-## Выход: plan.md (в папке фичи)
-
-План остаётся обзорным. Каждая задача плана:
-
-- цель задачи (одно предложение);
-- ссылка на §design, откуда берутся контракты (`design §Компоненты`, `ADR-2`);
-- file:line базлайна кода, куда вносится изменение;
-- без копипасты реализации продукта; крупные детали — ссылками на design, не пересказом.
-
-Каждая задача — чекбокс `- [ ]`. Исполнитель переворачивает чекбокс в `[x]` в конце
-задачи вместе со строкой «сделано → коммит <hash>». Чекбокс — истина завершённости
-для восстановления прерванной работы; вердикты и контекст — в памяти Wolf. Линза
-«соответствие» сверяет чекбоксы с отчётами при приёмке волны.
-
-## Структура файлов
-
-До определения задач спроектируй, какие файлы будут созданы или изменены и за что каждый отвечает. Здесь фиксируются решения декомпозиции.
-
-- Проектируй блоки с ясными границами и определёнными интерфейсами. У каждого файла — одна ясная ответственность.
-- Над кодом, который держится в контексте целиком, ты рассуждаешь лучше, а правки точечнее. Предпочитай маленькие сфокусированные файлы разросшимся.
-- Файлы, меняющиеся вместе, живут вместе. Дели по ответственности, не по техническим слоям.
-- В существующей кодовой базе следуй устоявшимся паттернам. Если она использует большие файлы — не перестраивай в одиночку; но если файл, который ты правишь, разросся — включить разбиение в план разумно.
-
-Эта структура определяет декомпозицию задач. Каждая задача должна давать самодостаточные изменения, осмысленные независимо.
-
-## Гранулярность bite-sized
-
-**Каждый шаг — одно действие (2–5 минут):**
-
-- «Напиши падающий тест» — шаг
-- «Запусти и убедись, что он падает» — шаг
-- «Напиши минимальный код, чтобы тест прошёл» — шаг
-- «Запусти тесты и убедись, что проходят» — шаг
-- «Закоммить» — шаг
-
-## Заголовок плана
-
-**Каждый план ОБЯЗАН начинаться с этого заголовка:**
-
-```markdown
-# [Имя фичи] — план реализации
-
-> **Исполнителям:** REQUIRED-СКИЛЛ: используй wolf-sdd (рекомендуется) ИЛИ wolf-execute
-> для поэтапной реализации этого плана. Шаги оформлены чекбоксами (`- [ ]`) для трекинга.
-
-**Цель:** [Одно предложение — что строим]
-
-**Архитектура:** [2–3 предложения о подходе]
-
-**Стек:** [Ключевые технологии/библиотеки]
-
----
-```
-
-## Структура задачи
-
-````markdown
-### Задача N: [Имя компонента]
-
-**Файлы:**
-
-- Create: `точный/путь/к/file.ts`
-- Modify: `точный/путь/к/existing.ts:123-145`
-- Test: `tests/точный/путь/к/test.ts`
-
-- [ ] **Шаг 1: Напиши падающий тест**
-
-```typescript
-it('конкретное поведение', () => {
-  expect(fn(input)).toBe(expected);
-});
-```
-
-- [ ] **Шаг 2: Запусти тест — убедись, что падает**
-
-Запуск: `npx vitest run tests/path/test.ts -t "конкретное поведение"`
-Ожидание: FAIL — «fn is not defined»
-
-- [ ] **Шаг 3: Напиши минимальную реализацию**
-
-```typescript
-export function fn(input: string): string {
-  return 'expected';
-}
-```
-
-- [ ] **Шаг 4: Запусти тест — убедись, что проходит**
-
-Запуск: `npx vitest run tests/path/test.ts -t "конкретное поведение"`
-Ожидание: PASS
-
-- [ ] **Шаг 5: Закоммить**
-
-```bash
-git add tests/path/test.ts src/path/file.ts
-git commit -m "feat: add specific feature"
-```
-````
-
-## Никаких плейсхолдеров
-
-Каждый шаг обязан содержать фактический контент, нужный исполнителю. Это **провалы плана** — никогда так не пиши:
-
-- «TBD», «TODO», «сделаем позже», «заполнить детали»
-- «Добавить соответствующую обработку ошибок» / «добавить валидацию» / «обработать краевые случаи»
-- «Написать тесты для вышенаписанного» (без фактического кода теста)
-- «Аналогично задаче N» (повтори код — исполнитель может читать задачи не по порядку)
-- Шаги, описывающие ЧТО делать, без КАК (для шагов с кодом — блоки кода обязательны)
-- Ссылки на типы, функции или методы, не определённые ни в одной задаче
-
-## Помни
-
-- Всегда точные пути файлов
-- Полный код в каждом шаге — если шаг меняет код, покажи код
-- Точные команды с ожидаемым выводом
-- DRY, YAGNI, TDD, частые коммиты
-
-## Саморевью
-
-После написания полного плана посмотри на него свежим взглядом и сверь со спекой. Это чеклист для себя, не диспетчеризация субагентов.
-
-**1. Покрытие спеки:** пробегись по каждой секции/требованию спеки. Можешь указать задачу, которая её реализует? Перечисли пробелы.
-
-**2. Скан плейсхолдеров:** поищи в плане red flags — паттерны из секции «Никаких плейсхолдеров» выше. Исправь.
-
-**3. Консистентность типов:** совпадают ли типы, сигнатуры методов и имена свойств в поздних задачах с определёнными в ранних? Функция `clearLayers()` в задаче 3 и `clearFullLayers()` в задаче 7 — это баг.
-
-Нашёл проблемы — исправь на месте. Пересматривать заново не нужно. Требование спеки без задачи — добавь задачу.
-
-## Передача в исполнение
-
-После сохранения плана предложи выбор режима исполнения:
-
-**«План готов и сохранён в `docs/plans/<файл>.md`. Два режима исполнения:**
-
-**1. Через субагентов (wolf-sdd, рекомендуется)** — свежий воркер на каждую задачу через executor-lead, 2-стадийное ревью между задачами, быстрая итерация
-
-**2. Линейно (wolf-execute)** — исполнение задач в этой сессии без субагентов, батчами с чекпоинтами
-
-**Какой режим?»**
-
-**Выбран wolf-sdd:** свежий воркер на задачу + двухстадийное ревью (спека → качество) силами worker-reviewer.
-
-**Выбран wolf-execute:** батч-исполнение с чекпоинтами; верификация — `npm run check` после завершённых блоков работы.
-
----
-
-## Трассировка адаптации
-
-> Источник: `~/.config/opencode/superpowers/skills/writing-plans/SKILL.md`, upstream 6efe32c (2026-04-23)
-
-| Пункт источника                                        | Судьба                                                                                            | Почему                                                                 |
-| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
-| Zero-context принцип                                   | сохранено + усилено «вход воркеров по брифам»                                                     | Спека §5.2                                                             |
-| «created by brainstorming skill» (worktree)            | заменено: worktree до старта исполнения, правило `.worktrees/<имя-задачи>`                        | H5; upstream-ребро brainstorm→worktree одностороннее, не воспроизводим |
-| Путь `docs/superpowers/plans/`                         | заменено → `docs/plans/…`                                                                         | Harness-привязка (research §1)                                         |
-| Заголовок «REQUIRED SUB-SKILL: sdd or executing-plans» | заменено → wolf-sdd ИЛИ wolf-execute                                                              | Рёбра набора Wolf                                                      |
-| Проверка масштаба                                      | сохранено                                                                                         | Ядро                                                                   |
-| Структура файлов                                       | сохранено                                                                                         | Ядро                                                                   |
-| Bite-sized гранулярность                               | сохранено                                                                                         | Ядро                                                                   |
-| Структура задачи (пример)                              | сохранено; пример переведён (vitest вместо pytest)                                                | Нейтральная иллюстрация под стек проекта                               |
-| «No Placeholders» (6 провалов)                         | сохранено полностью (6/6)                                                                         | H7                                                                     |
-| «Remember» (4)                                         | сохранено полностью (4/4)                                                                         | H7                                                                     |
-| Саморевью (3 проверки)                                 | сохранено полностью (3/3)                                                                         | Чеклист-ядро                                                           |
-| Execution Handoff (2 опции)                            | сохранено; sdd-опция → executor-lead/worker-\*, ревью → worker-reviewer; добавлен `npm run check` | Wolf-переплетение                                                      |
-| —                                                      | добавлено: задача = бриф воркера (worker-implementer)                                             | Zero-context вход по брифам                                            |
-
-Перенесённые списки: anti-patterns «No Placeholders» 6/6, «Remember» 4/4, саморевью 3/3.
+При доступной и разрешённой диспетчеризации L1 использует wolf-sdd. Иначе исполнитель с подходящей ролью использует wolf-execute. Не проси пользователя выбирать внутренний механизм без существенного влияния на стоимость, риск или его предпочтения.

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

@@ -1,80 +1,41 @@
 ---
 name: wolf-review
-description: Мульти-линзовое ревью документов (doc-review): mr-wolf оркестрирует линзы-воркеров, цикл до сходимости. Use when the user asks to review a document, run doc-review, or critique a spec/plan/report.
+description: "Проверяй requirements, design, plan, test-plan или отчёт независимыми линзами. Привязывай вывод к версии, разрешай конфликты и отличай одобрение от исчерпания бюджета ревью."
 ---
 
-# wolf-review — мульти-линзовое ревью документов
+# Ревью артефактов
 
-> Источник: новый; рамка analyze-doc (PoC) + REVIEW-001 (архив v2.0 §2.5) +
-> практика мульти-линзового ревью; отклонение: security-линза опущена
-> (спека §6).
+## Владение и вход
 
-## Трассировка переноса
+L0 задаёт критерии и поручает цикл executor-lead; L1 вызывает worker-reviewer. L0 не спавнит L2 напрямую. Вход: цель ревью, документы с revision/hash, baseline, применимые требования/политика и бюджет. Получи активную методику линз; при отсутствии используй приведённый минимальный набор и обозначь fallback.
 
-| Пункт источника                                                           | Судьба                                                                                                  |
-| ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
-| Рамочный паттерн analyze-doc: методика в памяти, файл — тонкая рамка      | Сохранено                                                                                               |
-| Протокол подтягивания playbook перед прогоном                             | Сохранено; запрос `wolf search "wolf-review playbook"`, наибольшая версия                               |
-| Мульти-линзовость, изоляция линз в чистых сессиях (REVIEW-001)            | Сохранено                                                                                               |
-| Перспектива линз полнота → консистентность → типоспецифичные (REVIEW-001) | Сохранено                                                                                               |
-| Контракты SUMMARY/VERDICT (REVIEW-001: вердикт «CHANGES»)                 | Сохранено; «CHANGES» заменён на `CHANGES_REQUIRED` (стандартизация по спеке §6)                         |
-| Дедуп находок, подсчёт, счётчик раундов, критерий сходимости (REVIEW-001) | Сохранено                                                                                               |
-| Конфликты находок между линзами решает владелец (REVIEW-001)              | Сохранено                                                                                               |
-| Security-линза (REVIEW-001)                                               | Отброшено: осознанное отклонение — для документов не тянем (спека §6)                                   |
-| Самомутация playbook по фидбеку (analyze-doc PoC, п. 3)                   | Заменено: фидбек о методике/линзах → жалобный контур (`wolf complain`, тег complaint); мутатор — Стюард |
-| Исполнитель-аналитик PoC (apprentice)                                     | Заменено: линзы исполняют worker-reviewer; оркестратор цикла — mr-wolf                                  |
-| Продуктовый код оркестрации                                               | Отброшено: весь цикл ведёт mr-wolf по протоколу этого скилла (спека §10)                                |
+## Мандаты линз
 
-## Рамка (методика — НЕ в этом файле)
+- Requirements: смысл, scope, атомарность, AC и неизвестное.
+- Design ↔ requirements/code: покрытие, контракты, решения и отказы.
+- Plan ↔ design/test-plan: зависимости, исполнимость, проверки и интеграция.
+- Test-plan ↔ requirements/design: oracle, сценарии, NFR и риски.
+- Условная security/trust: внешние инструкции, права, секреты, установка, исполнение, хранение и миграции. Запускай линзу, когда документ затрагивает перечисленное; решение о пропуске security-линзы зафиксируй в review.md.
 
-Линзы — playbook-объекты памяти Wolf: они эволюционируют без рестарта
-(мутатор — Стюард, через жалобы). Этот файл — только рамка: протокол цикла
-и границы.
+Своему ревьюеру передай только мандат и исходные артефакты, не чужие находки и не ожидаемый вердикт. Общий playbook задаёт дисциплину; узкий мандат задаёт область и исключает обязательный проход несвязанных зон. Существенную находку вне мандата отметь отдельно для маршрутизации.
 
-### Протокол цикла (оркестратор — mr-wolf)
+## Находка и вердикт
 
-1. **До прогона** получи актуальный playbook линз:
-   `wolf search "wolf-review playbook"` — запись с наибольшей версией.
-   Состав и параметры каждой линзы — из playbook, не отсюда.
-2. **Порядок линз**: полнота → консистентность → типоспецифичные.
-3. **Спавн**: каждую линзу исполняет ОТДЕЛЬНЫЙ worker-reviewer в чистой
-   сессии через {{tool.task}}. Изоляция бьёт по слепым зонам саморевью.
-   Узкий ревьюер: чужие замечания запрещены — воркер получает только свой
-   мандат (документ + своя линза), находки других линз ему не показываются.
-4. **Контракты** — обязательные строки отчёта каждой линзы:
-   - `SUMMARY: X critical / Y major / Z minor`
-   - `VERDICT: APPROVED | CHANGES_REQUIRED`
-5. **Дедуп и подсчёт**: mr-wolf сводит находки всех линз, убирает
-   дубликаты, считает critical/major/minor по итоговому набору.
-6. **Сходимость**: цикл останавливается при 0 critical / 0 blocking ИЛИ
-   по лимиту раундов (по умолчанию 3).
-7. **Цикл правок**: автор правит документ → перезапуск ТОЛЬКО упавшей
-   линзы; прошедшие линзы не перегоняются.
-8. **Конфликты**: противоречащие находки разных линз разрешает владелец
-   (слепой судьи в MVP нет) — mr-wolf докладывает конфликт, не выбирает сам.
+Находка: finding_id, severity, location/revision, нарушенный AC/инвариант, evidence, влияние, рекомендуемая проверка. Critical — потеря данных/полномочий/существенная неверность; Major — блокирующий дефект заявленного результата; Minor — неблокирующее улучшение. Блокировка допускается отдельно при обоснованном риске, а не по стилю.
 
-## Линзы конвейера (v2): один вопрос — одна пара файлов
+Отчёт:
+SUMMARY: N critical / N major / N minor
+VERDICT: APPROVED | CHANGES_REQUIRED | INCONCLUSIVE
+Список находок, область проверки и ограничения. APPROVED требует отсутствия Critical/Major и обоснованных blocking-рисков. Нехватка входов означает INCONCLUSIVE.
 
-| Линза           | Пара файлов                    | Вопрос                                                                                                                                                                                          |
-| --------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Полнота         | requirements.md (целиком)      | Атомарность, недвусмысленность, проверяемость записей; критерии готовности анатомии (история+формальная запись, AC, источник, `[НЕОПРЕДЕЛЕНО]` не сжат). Семантика; механику ловит линт doctor. |
-| Консистентность | design.md                      | Соответствие requirements (REQ/NFR покрыты), базлайну кода (контракты с file:line), ADR-карточки полны.                                                                                         |
-| Соответствие    | plan.md ↔ design.md            | Каждая задача ссылается на §design; контракты не переопределены; чекбоксы `[x]` сверены с отчётами при приёмке волны.                                                                           |
-| Покрытие AC     | test-plan.md ↔ requirements.md | Сценарий на каждый REQ-NN; AC не переизобретены; маппинг на файлы существует.                                                                                                                   |
+## Цикл
 
-## Гейты (Kiro-паттерн)
+1. L1 фиксирует версии и запускает независимые линзы; дедуплицирует, сохраняя источники и разные основания.
+2. Автор отвечает по каждой находке: принято/опровергнуто/отложено/нужно уточнение с evidence. Продуктовые конфликты решает L0/владелец; технические в мандате — L1 с обоснованием.
+3. После исправлений определяет изменённые основания. Перезапускает все затронутые линзы; неизменённые вердикты переиспользует с доказанным соответствием revision.
+4. По умолчанию максимум 3 раунда; лимит задаётся до цикла. Исчерпание бюджета → UNRESOLVED в сводке L1, незакрытые находки и эскалация; это не APPROVED.
+5. Сохраняет в review.md append-only: artifact revision, линза/версия методики, verdict, finding IDs, ответы и evidence. По новой версии документа прежнее одобрение не переносится без анализа влияния.
 
-1. Владелец аппрувит requirements.md до запуска технических ступеней.
-2. ADR-карточки design.md — владельцу на визу отдельно (продуктовые выборы, не техника).
-3. Следующая ступень (design → plan → test-plan) генерируется только после аппрува предыдущей.
-4. Технические артефакты ревьюят линзы; владельцу — выжимка на визу.
-5. Журнал вердиктов: вердикты линз и гейтов владельца — append-only строкой
-   (линза | дата | вердикт | ключевые находки | что исправлено) в `review.md`
-   папки фичи — каждую линзо-итерацию; детали — в памяти Wolf, в git — свод.
+## Гейты
 
-### Границы рамки
-
-- Критичные запреты: `rm -rf`, `sudo`, деструктивный git, секреты.
-- Продуктового кода оркестрации нет — цикл ведёт mr-wolf по этому протоколу.
-- Этот файл не содержит методику линз и не должен её содержать:
-  версии линз живут в памяти Wolf.
+Владелец утверждает требования и существенные ADR; технические артефакты утверждает назначенный ответственный после ревью. Следующий этап получает одобренные версии. Пакет ревью подтверждает проверенные свойства, не гарантирует отсутствие всех дефектов.