mister-wolf 2.21.0 → 2.21.2

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

@@ -24,12 +24,29 @@ description: "Применять перед утверждением о гото
 
 Результат применим, пока не изменились проверенный код, значимые зависимости, данные или среда. Новое сообщение/сессия не инвалидирует evidence само по себе. При изменениях повтори затронутые проверки; перед интеграцией проверь объединённое состояние. Если точное соответствие dirty-state установить нельзя, запусти проверку повторно.
 
-Evidence содержит claim/AC, command/procedure, cwd, revision, время, exit/status, результат и ссылку на лог; при dirty-tree — digest относящихся файлов/patch, включая untracked. Отсутствующие поля отмечай, не выдумывай. Секреты в evidence не включай.
+Evidence содержит claim/AC, command/procedure, cwd, revision, время, exit/status, результат и ссылку на имеющееся подтверждение; отдельный файл лога не обязателен; при dirty-tree — digest относящихся файлов/patch, включая untracked. Отсутствующие поля отмечай, не выдумывай. Секреты в evidence не включай.
+
+## Состав поставки
+
+L1 перед приёмкой сверяет новые файлы docs/dev (в том числе untracked) с
+основными документами и обоснованными дополнениями из plan/брифа. Частные
+отчёты/логи/скрипты не входят в документацию этапа. Полезное интегрируй,
+нужное evidence сохрани долговечно вне документации; не подтверждай приёмку
+до разбора посторонних новых файлов. Прежние/чужие файлы не удаляй автоматически.
+L2 сообщает отклонение L1, не проводит самостоятельную уборку проекта.
 
 ## Масштаб проверки
 
 Targeted-проверка подтверждает только свою область; full gate — свойства своего набора. Для NFR нужны соответствующие измерения. Ручная проверка допустима с воспроизводимым протоколом и известными ограничениями. Не запускай full suite на каждый ответ, если валидный результат уже есть.
 
+## Стоп после доказательства
+
+По каждому утверждению проверь достаточность evidence один раз. Повтор — при
+изменении входов, новой ошибке или конкретном непокрытом критерии. Убедительный
+рассказ не evidence, но уже прочитанный актуальный лог не требует повторного
+запуска. Непроверенное свойство ограничивает именно соответствующий claim;
+не отменяй доказанный дефект или независимое подтверждённое свойство.
+
 ## Приёмочный пакет
 
 По каждому AC: подтверждено/не подтверждено, evidence, revision; далее независимое ревью, отклонения, нерешённые риски и план восстановления при необходимости. L1 передаёт пакет L0; L0 выдаёт ACCEPTED | PARTIAL | REJECTED | INCONCLUSIVE. Перед вердиктом приёмщик сверяет revision и dirty-digest из evidence с фактическим состоянием (например, git rev-parse HEAD); evidence без revision по умолчанию неактуален. Отчёт исполнителя — не доказательство.

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

@@ -12,18 +12,52 @@ description: "Применять при баге, неожиданном пов
 Загрузи полный текст назначенной методики до её выполнения. Обязательные пункты отслеживай в доступном трекере или рабочем брифе; не добавляй новые статусы памяти. Недоступное действие передай ответственному уровню.
 
 
+## Масштаб диагностики
+
+Полный цикл организует L1. L2 получает один диагностический вопрос/различающий
+эксперимент с входами, ожидаемым свидетельством, проверкой и конечным лимитом.
+Отрицательный результат эксперимента тоже результат; следующую гипотезу выбирает
+L1. Если её нужно выбирать уже до выполнения — верни вопрос сразу. Полный fix
+назначай лишь после достаточного основания, отдельным коротким мандатом.
+Шаги ниже относятся к своему назначенному этапу; L2 не обязан проходить весь
+цикл root-cause → архитектура → реализация. Неожиданная сложность → возврат,
+даже если осталось время. Две неудачи не обязательная квота перед обращением L1.
+
 ## Процесс
 
 1. Зафиксируй симптом, ожидаемое, revision, среду, частоту, точные шаги и исходный лог. Не воспроизводится — сохраняй наблюдение и собирай данные, не объявляй причину установленной.
 2. Проверь недавние изменения и работающий аналог. Прочитай относящиеся к проблеме контракты и зависимости; не требуй читать несвязанный большой референс целиком.
-3. Трассируй входы/выходы на подозреваемых границах. Логируй минимальные метаданные с редактированием секретов/PII; не печатай окружение и payload полностью. Диагностические изменения должны иметь cleanup.
-4. Веди журнал: hypothesis, evidence for/against, discriminating experiment, result, next step. Рассматривай альтернативы; каждый эксперимент меняет одну существенную переменную или явно описывает связанные изменения.
+3. Трассируй входы/выходы на подозреваемых границах. Логируй минимальные метаданные с редактированием секретов/PII; не печатай окружение и payload полностью. Диагностические изменения должны иметь cleanup. Временные скрипты/логи не клади в docs/dev; постоянная проверка идёт в штатные tests/scripts по scope. Нужное evidence сохрани до cleanup.
+4. Веди компактный рабочий журнал в назначенной области/памяти, не отдельный документ docs/dev: hypothesis, evidence for/against, discriminating experiment, result, next step. Рассматривай альтернативы; каждый эксперимент меняет одну существенную переменную или явно описывает связанные изменения.
 5. Подтверждённую причину зафиксируй воспроизводимой проверкой. Исправление проведи по test-driven-development; проверь исходный сценарий, регрессии и важные взаимодействия.
 6. По завершении укажи root cause, fix, evidence, остаточные риски и удалённую временную диагностику. Урок записывай только при возможности переиспользования и с областью применимости.
 
 ## Повторы и эскалация
 
-После 2 неудачных исправлений либо повторения одной гипотезы останови угадывание: проверь качество воспроизведения, полноту модели и входы. Третья неудача — сигнал независимого разбора, не доказательство дефекта архитектуры. L2 возвращает BLOCKED с журналом; L1 решает о новом контексте, модели, декомпозиции или архитектурном исследовании. Scope не расширяй сам.
+L2 не перебирает неизвестные исправления: выполни назначенный эксперимент или
+очевидную локальную коррекцию, затем верни evidence/остаток/вопрос. Новый способ,
+гипотеза или зависимость требуют решения L1. Два шага без продвижения или лимит
+(без заданного — 8 обращений) также завершают вызов, без ложного DONE.
+После 2 назначенных неудачных исправлений L1 пересматривает воспроизведение,
+входы и план; это не доказательство дефекта архитектуры. Неудача не продлевает
+самостоятельность L2 и не запускает консилиум автоматически.
+
+## Средства и помощь
+
+Повторяющееся инструментальное трение не превращай автоматически в продуктовый
+баг. L1 сначала проверяет готовое средство в tool-библиотеке и его контракт;
+L2 применяет переданное разрешённое средство или возвращает FRICTION.
+Универсальный обход/новый скрипт — отдельная разрешённая задача с проверкой и
+регистрацией через существующий wolf tool register, не самовольная работа
+ревьювера. wolf tool use — учёт, не запуск.
+
+Если следующего различающего эксперимента нет либо решение вне полномочий,
+L2 передаёт L1 вопрос, evidence, исключённое и что разблокирует ответ.
+L1 сначала решает сам/уточняет вход/использует готовое средство; при точном
+пробеле — один эксперт. Консилиум лишь для сложного существенно блокирующего
+решения, когда меньшего средства недостаточно и польза оправдывает стоимость.
+Дефект общего правила передаётся Стюарду после жалобного триажа.
+Ответ эксперта не установленная причина; нужны назначенные проверки.
 
 ## Инцидент
 

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

@@ -19,21 +19,31 @@ description: "Применять при линейном исполнении у
 ## Процесс
 
 1. Сверь входы с текущим кодом; обозначь несовместимость до правок. Зафиксируй зависимости и исходные падения проверок.
-2. Выполняй ready-задачи последовательно: прочитай затронутый код, пройди подходящую тестовую дисциплину, внеси allowlist-изменения, проверь результат и сохранённые инварианты.
-3. После каждой задачи запиши RESULT/evidence. Коммит выполняй только при разрешении роли и пользователя. Отметку [x] ставь после нужного ревью; до него сохрани состояние «готово к ревью» без выдуманного значения таксономии.
-4. Чекпоинт делай на завершённом компоненте, перед сменой этапа или сессии; default не более 3 небольших задач без сохранения состояния. В него включи baseline/current state, completed/remaining, evidence и dirty-state.
-5. Независимое ревью запроси через доступный разрешённый канал. Если его нет, сообщи ограничение и передай результат L0/владельцу; саморевью не выдавай за независимое.
-6. После интеграции выполни test-plan и полный применимый гейт; сформируй ACCEPTANCE. Дальнейший git-финал — finishing-a-development-branch.
+2. L1 при недоступной/ненужной диспетчеризации выполняет разрешённую линейную работу; L2 — только один назначенный конечный мандат без интеграции поставки. Выполняй свои ready-шаги последовательно: прочитай затронутый код, пройди подходящую тестовую дисциплину, внеси allowlist-изменения, проверь результат и сохранённые инварианты.
+3. После каждой задачи запиши RESULT/evidence. Коммит выполняй только при разрешении роли и пользователя. L1 ставит отметку [x] после нужного ревью; до него сохрани состояние «готово к ревью» без выдуманного значения таксономии.
+4. L2 возвращает checkpoint по своему стоп-условию. L1 сохраняет checkpoint на завершённом компоненте, перед сменой этапа или сессии; default не более 3 небольших задач без сохранения состояния. В него включи baseline/current state, completed/remaining, evidence и dirty-state.
+5. L2 возвращает результат/запрос ревью L1. L1 организует независимое ревью разрешённым каналом; при его отсутствии передаёт ограничение L0/владельцу. Саморевью не независимо.
+6. L1 после интеграции выполняет test-plan и полный применимый гейт, формирует ACCEPTANCE; L2 возвращает RESULT, не выполняет этот этап. Дальнейший git-финал — finishing-a-development-branch.
+
+## Завершение без повторов
+
+Режим execute не открывает заново утверждённое решение. Читай только нужные
+источники; повторяй проверку при изменении её входов, новой ошибке или явном
+требовании. L2 при неожиданной сложности/новом способе или двух шагах без
+продвижения возвращает результат и вопрос L1; сам исследование не выбирает.
+Конечный лимит обязателен, без заданного — возврат через 8 обращений. Сбой инструмента: один осмысленный обход, затем FRICTION и остаток,
+не отдельное исследование устройства среды. После назначенных проверок верни
+RESULT; не увеличивай объём работы ради более длинного отчёта.
 
 ## Блокер и восстановление
 
-При недостатке контекста верни NEEDS_CONTEXT; при невозможности продолжения — BLOCKED с причиной, выполненным и безопасным следующим действием. Исправимые технические сбои исследуй wolf-debug, не спрашивая владельца на каждый локальный шаг. Изменение scope/контракта эскалируй.
+При недостатке контекста верни NEEDS_CONTEXT; при невозможности продолжения — BLOCKED с причиной, выполненным и безопасным следующим действием. Локальную очевидную ошибку исправь в лимите. Неизвестная причина/новый способ для L2 — возврат L1, а не самостоятельный запуск wolf-debug. L1 выбирает следующую диагностическую подзадачу без опроса владельца о локальных деталях. Изменение scope/контракта эскалируй.
 
-После прерывания сверяй план с фактическими файлами, git и evidence. Не повторяй миграции, публикации и внешние действия без проверки их исхода. По лимиту повторов (default 2) пересмотри подход. Недоступную запись памяти передай ответственному уровню.
+После прерывания сверяй план с фактическими файлами, git и evidence. Не повторяй миграции, публикации и внешние действия без проверки их исхода. По лимиту назначенных повторов (default 2) L1 пересматривает подход; L2 возвращается раньше по своему стоп-условию. Недоступную запись памяти передай ответственному уровню.
 
 ## Гейт перехода
 
-Завершение задачи требует актуальных проверок и предусмотренного ревью; завершение поставки — интеграции и ACCEPTANCE. Без независимого канала ревью обозначь ограничение. Затем примени verification-before-completion и согласованный git-финал, не придумывая новый scope.
+L2 после самопроверки возвращает RESULT/evidence L1; DONE означает готовность к ревью. L1 организует предусмотренное ревью, интеграцию, ACCEPTANCE и согласованный git-финал. verification-before-completion применяет каждая роль к собственным утверждениям. Недоступный канал явно ограничивает результат, не расширяет роль.
 
 ## Не пропускай процесс
 

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

@@ -18,7 +18,14 @@ description: "Применять перед сменой сессии или и
 
 ## Snapshot
 
-До передачи сохрани в артефакте или разрешённой памяти:
+До передачи L0/L1 сохраняет checkpoint как адресную рабочую note/history Wolf
+по using-skills, связанную с действующим thread; текущий контекст — note/context.
+Сначала сверь уже существующий checkpoint: не создавай дубликат на каждый вызов.
+Файловый fallback вне docs — при недоступной памяти/файловых данных; новый
+checkpoint/report в docs/dev для каждой сессии не создавай. L2 передаёт
+состояние сообщением L1; тот обеспечивает долговечность и доступность файлов,
+включая нужные материалы из tmp, прежде чем закрыть сессию/очистить рабочее место.
+Snapshot не становится проектным документом автоматически. Состав:
 - task/thread ID, цель, AC, scope и текущий ответственный;
 - base/current revision, cwd, branch/worktree, dirty/untracked, patch или другой доступный способ восстановления;
 - выполненное и оставшееся, dependencies, ожидающий внешний исход;

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

@@ -23,7 +23,7 @@ description: "Применять перед декомпозицией утве
 3. Для каждой задачи заполни TASK из using-skills: цель, AC, baseline, ссылки на контракт, allowlist, зависимости, проверки, ограничение scope и ожидаемый RESULT. Разреши читать затронутый код и потребителей; отсутствие истории сессии не означает запрета чтения.
 4. Укажи достаточно точные действия и символы, не полный код реализации. Примеры допустимы для неоднозначного контракта, но не дублируют design. Не предписывай точный код теста вместо проверяемого свойства.
 5. Построй зависимости. Параллельность разреши только для независимых outputs, изолированной записи и определённого владельца интеграции. Общие контракты и миграции сериализуй.
-6. Добавь отдельную интеграционную задачу: порядок объединения, проверка взаимодействий, полный гейт и правила разрешения конфликтов. Укажи промежуточные чекпоинты для длительной работы.
+6. Для выходов TASK укажи сообщение либо точный файл/раздел; временную область назначь вне документации. Дополнительному документу этапа задай назначение, читателя и владельца прямо в plan, без отдельного реестра. Добавь отдельную интеграционную задачу: порядок объединения, проверка взаимодействий, полный гейт и правила разрешения конфликтов. Укажи промежуточные чекпоинты для длительной работы.
 7. Сверь plan с test-plan: сценарии входят в соответствующие задачи, NFR имеют измерения, тесты запускаются проектными командами. Исполнение FULL не стартует до этой сверки.
 8. Проведи саморевью и назначенное независимое ревью. Ошибку плана исправляй с повторной проверкой затронутых зависимостей.
 

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

@@ -1,60 +1,80 @@
 ---
 name: wolf-review
-description: "Применять перед утверждением requirements, design, plan, test-plan или приёмочного отчёта; при повторном ревью изменённой версии и при противоречивых выводах проверяющих."
+description: "Применять L0/L1 для организации независимого ревью артефактов, повторной проверки изменённых оснований и разрешения противоречивых вердиктов."
 ---
 
-# Ревью артефактов
-
-## Обязательный вход
-
-До чтения артефакта зафиксируй предмет, версии, мандат и бюджет ревью. L0 поручает цикл L1; L1 назначает независимых L2. Автор не является независимым ревьюером собственного результата. Передай сырые документы и критерии без ожидаемого вердикта. Если входы неполны, запроси их или ограничь вывод; не подменяй ревью предположением.
-
-Загрузи полный текст назначенной методики до её выполнения. Обязательные пункты отслеживай в доступном трекере или рабочем брифе; не добавляй новые статусы памяти. Недоступное действие передай ответственному уровню.
-
+# Организация ревью — L0/L1
 
 ## Владение и вход
 
-L0 задаёт критерии и поручает цикл executor-lead; L1 вызывает worker-reviewer. L0 не спавнит L2 напрямую. Вход: цель ревью, документы с revision/hash, baseline, применимые требования/политика и бюджет. Получи активную методику линз; при отсутствии используй приведённый минимальный набор и обозначь fallback.
-
-## Мандаты линз
-
-- Requirements: смысл, scope, атомарность, AC и неизвестное.
-- Design ↔ requirements/code: покрытие, контракты, решения и отказы.
-- Plan ↔ design/test-plan: зависимости, исполнимость, проверки и интеграция.
-- Test-plan ↔ requirements/design: oracle, сценарии, NFR и риски.
-- Условная security/trust: внешние инструкции, права, секреты, установка, исполнение, хранение и миграции. Запускай линзу, когда документ затрагивает перечисленное; решение о пропуске security-линзы зафиксируй в review.md.
-
-Своему ревьюеру передай только мандат и исходные артефакты, не чужие находки и не ожидаемый вердикт. Общий playbook задаёт дисциплину; узкий мандат задаёт область и исключает обязательный проход несвязанных зон. Существенную находку вне мандата отметь отдельно для маршрутизации.
-
-## Находка и вердикт
-
-Находка: finding_id, severity, location/revision, нарушенный AC/инвариант, evidence, влияние, рекомендуемая проверка. Critical — потеря данных/полномочий/существенная неверность; Major — блокирующий дефект заявленного результата; Minor — неблокирующее улучшение. Блокировка допускается отдельно при обоснованном риске, а не по стилю.
-
-Отчёт:
-SUMMARY: N critical / N major / N minor
-VERDICT: APPROVED | CHANGES_REQUIRED | INCONCLUSIVE
-Список находок, область проверки и ограничения. APPROVED требует отсутствия Critical/Major и обоснованных blocking-рисков. Нехватка входов означает INCONCLUSIVE.
-
-## Цикл
-
-1. L1 фиксирует версии и запускает независимые линзы; дедуплицирует, сохраняя источники и разные основания.
-2. Автор отвечает по каждой находке: принято/опровергнуто/отложено/нужно уточнение с evidence. Продуктовые конфликты решает L0/владелец; технические в мандате — L1 с обоснованием.
-3. После исправлений определяет изменённые основания. Перезапускает все затронутые линзы; неизменённые вердикты переиспользует с доказанным соответствием revision.
-4. По умолчанию максимум 3 раунда; лимит задаётся до цикла. Исчерпание бюджета → UNRESOLVED в сводке L1, незакрытые находки и эскалация; это не APPROVED.
-5. Сохраняет в review.md append-only: artifact revision, линза/версия методики, verdict, finding IDs, ответы и evidence. По новой версии документа прежнее одобрение не переносится без анализа влияния.
-
-## Гейты
-
-Владелец утверждает требования и существенные ADR; технические артефакты утверждает назначенный ответственный после ревью. Следующий этап получает одобренные версии. Пакет ревью подтверждает проверенные свойства, не гарантирует отсутствие всех дефектов.
-
-## Гейт перехода
-
-Переход дальше требует вердикта по нужной версии, закрытых блокирующих находок и предусмотренных утверждений. После изменения основания вердикт перепроверь по влиянию. Исчерпанный бюджет означает нерешённый исход в сводке, а не одобрение. Сохрани область проверки и ограничения.
-
-## Не пропускай процесс
-
-| Мысль | Действие |
-| --- | --- |
-| «Другой ревьюер уже всё нашёл» | Проведи свой мандат независимо, затем сопоставь находки. |
-| «Лимит раундов исчерпан» | Эскалируй незакрытое, не выдавай APPROVED. |
-| «Стиль не нравится» | Отделяй предпочтение от доказанного блокирующего дефекта. |
+L0 задаёт цель/критерии и принимает поставку; L1 организует цикл и вызывает
+worker-reviewer. L2 не получает полномочий диспетчера. Автор не является
+независимым ревьюером своего результата. Полную методику загрузи один раз.
+Процедура L2 — в полной рамке worker-reviewer и доставленном лице; не копируй
+эту организационную методику в каждый worker-TASK. При явно назначенной иной
+специализированной методике доставь её полный текст, не самодельное сокращение.
+
+TASK: цель владельца одной строкой → вклад подзадачи → проверяемый результат,
+baseline/revision/digest/cwd, норма и относящиеся политики, источники, границы,
+полный мандат/AC, инструменты/контракты, RESULT/evidence, бюджет и стоп-условие.
+Обязательные нормативные фрагменты передай без потери исключений и приоритета;
+сохрани точные ссылки для дочитывания, не подменяй норму пересказом. Историю
+родителя, чужие находки и ожидаемый вердикт в независимый первый проход не передавай.
+
+L1 выбирает реальные доступные model/variant существующим harness; не выдумывай
+поля или ID и не считай текст TASK доказательством настройки. Роли не шкала
+reasoning. Механика — низкий режим, смысловое ревью — достаточный по риску;
+повышение адресное, выбор владельца приоритетен. Раздели большой аудит на
+короткие мандаты с конечным лимитом (без заданного — 8 обращений) и владельцем
+межчастной согласованности/общего покрытия. Возврат при неожиданной сложности
+не требует исчерпания лимита. На лимите — остаток, не APPROVED.
+
+## Scope и средства
+
+Для diff-review проверяй изменения и связанные нормы. Явное поручение общей
+смысловой проверки не сужай до таблиц/ID. Укажи допустимые внешние ссылки.
+Линзы выбираются по объекту: Requirements, Design, Plan, Test-plan, Code.
+Security/trust обязателен по релевантным правам, секретам, внешним инструкциям,
+исполнению, установке, хранению/миграциям. Новый риск позволяет запросить линзу.
+
+Для регулярной процедуры/известного трения L1 сначала ищет подходящее средство
+в tool-библиотеке, если актуальный результат ещё не доставлен. Передай L2 только
+нужный путь/команду, contract-in/out/env, ограничения и ловушку, не весь каталог.
+Библиотечный скрипт не даёт новых прав: reviewer не запускает проверяемую систему.
+Запрос из LIMITS сначала решает L1: контекст, решение, средство или разбиение.
+Один эксперт — по точному пробелу; консилиум — дорогой резерв для сложного
+существенно блокирующего решения по рамке L1. Дефект правила — триаж/Стюард,
+не экспертный совет. Следующий L2 получает решение и узкий остаток; совет не
+утверждает scope. Явное общее ревью сохраняет все критерии в суммарном покрытии,
+не превращается в набор механических проверок.
+
+## Цикл и журнал
+
+1. Зафиксируй применимые линзы и версии, запусти независимые мандаты.
+2. Получи SUMMARY/VERDICT/FINDINGS/SCOPE/LIMITS/EVIDENCE по рамке. Сопоставь
+   фактическое покрытие с AC, не только заголовок вердикта. Дедуплицируй,
+   сохраняя источники и разные основания. Передай вопрос надлежащему владельцу.
+3. Ответ автора по finding ID: принято/опровергнуто/отложено/нужно уточнение
+   с evidence. Продуктовый конфликт — L0/владелец, технический в полномочиях — L1.
+4. После исправлений перепроверь затронутые основания/линзы и регрессионный риск;
+   неизменённые результаты переиспользуй только при доказанной применимости.
+   Не начинай новый полный аудит без причины. По умолчанию максимум 3 раунда;
+   исчерпание → UNRESOLVED в сводке L1 и эскалация, не одобрение.
+5. L1 сохраняет единый append-only след ревью: artifact revision/digest, линза
+   и версия методики, coverage, verdict, finding IDs, ответы, evidence и ограничения.
+   Сохраняй значимые вердикты адресными рабочими note/history Wolf с ревизией,
+   связью с thread и ссылками на предыдущие записи; частные ответы L2 — сообщениями.
+   Это аудит, не lesson/complaint и не предлагаемое правило. Не сохраняй каждый
+   инструментальный шаг; прежние записи/вердикты не переписывай.
+   review.md допустим как единичный заранее обоснованный документ этапа, когда
+   нужен долговечный аудит. Не создавай файл на каждого ревьювера или раунд;
+   без отдельного документа обязательный след и его актуальность сохраняются.
+
+## Гейт
+
+Critical/Major и обоснованный блокирующий риск запрещают переход. Без доказанного
+блокера существенное непроверенное свойство означает INCONCLUSIVE; полное покрытие
+без блокеров — APPROVED. Справочный пробел не отменяет доказанный дефект.
+Требования/существенные ADR утверждает владелец; другие артефакты — назначенный
+ответственный после ревью. Совет и мнение эксперта не заменяют утверждение,
+независимое ревью или проверку. Следующий этап получает нужную одобренную версию.

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

@@ -18,17 +18,32 @@ description: "Применять при исполнении утверждён
 
 ## Цикл задачи
 
-1. Выбери ready-задачу; собери TASK из using-skills. Передай ссылки и минимальный достаточный контекст, проверенные контракты и expected RESULT. L2 разрешено читать нужные файлы и потребителей; история родительской сессии не наследуется.
-2. Доставь назначенную методику и активный playbook. L2 не выбирает организационную структуру и не спавнит агентов.
-3. Получи RESULT: DONE → проверить diff и evidence; DONE_WITH_CONCERNS → разобрать риск до ревью; NEEDS_CONTEXT → дополнить вход; BLOCKED → изменить контекст, размер задачи, модель или план. Не повторяй идентичный провал без нового основания.
-4. Проверь allowlist и отсутствие посторонних изменений. Воркер не коммитит; L1 фиксирует результат разрешённым git-действием после проверок, включая авторизованность самого коммита.
+1. Разрежь работу до конечных мандатов L2; архитектуру, стратегию поиска и зависимости определяет L1. Назначь владельца проверки общих связей. Выбери независимые ready-задачи, запусти параллельно в бюджете и с изоляцией; собери каждому TASK из using-skills. Передай ссылки и минимальный достаточный контекст, проверенные контракты и expected RESULT. L2 разрешено читать нужные файлы и потребителей; история родительской сессии не наследуется.
+2. Доставь полную методику действия L2 и активный playbook, относящиеся нормы и TASK/RESULT/EVIDENCE; не весь процесс L1/ACCEPTANCE. Для регулярного шага/трения L1 проверяет tool-библиотеку и передаёт подходящий контракт. L2 не выбирает организацию и не спавнит.
+3. Принимай RESULT по готовности: DONE → diff/evidence; DONE_WITH_CONCERNS → риск до ревью; NEEDS_CONTEXT → точный вход; BLOCKED → решение L1, готовое средство или разбиение. Следующий вызов получает решённый вопрос, короткий остаток и новый конечный лимит. Один эксперт — при точном пробеле; дорогой консилиум — только по критериям рамки L1. Изменение цели → L0. Дефект правила → жалобный триаж/Стюард. Не возвращай L2 прежнее «разберись» и не запускай идентичный провал.
+4. Проверь allowlist и новые файлы, включая untracked: RESULT L2 не требует отдельного документа. Частные отчёты/скрипты в docs/dev нарушают состав папки; L1 встраивает полезные выводы в основные документы. Не удаляй чужое/прежнее автоматически. Проверь отсутствие посторонних изменений. Воркер не коммитит; L1 фиксирует результат разрешённым git-действием после проверок, включая авторизованность самого коммита.
 5. Организуй независимое ревью соответствия, затем качества. Для малой задачи два мандата может выполнить один независимый reviewer в явном порядке; для значимого риска используй отдельные чистые ревью. Независимость от исполнителя обязательна.
 6. Правки возвращай исполнителю с finding IDs. Изменения контракта повторно проверяются на соответствие, даже если проблема пришла с стадии качества. Minor не блокирует без объяснённого риска; сохрани техдолг в подходящем существующем объекте.
 7. L1 отмечает задачу проверенной в плане с revision/evidence. Принятой поставкой она становится после интеграции и финального verdict L0.
 
+## Бюджет действий
+
+В каждом TASK задай execution: доступные model/variant, mode execute|solve,
+лимит обращений и условие завершения. Механические действия — низкая глубина,
+смысловая проверка — средняя; высокий режим только на адресный блокер, с учётом
+явного выбора владельца. Проверяй фактическое применение по метаданным запуска,
+не выдумывай поддержку полей. Доставленные методики и лица не ищутся повторно.
+Каждый L2 возвращается после результата, первой неожиданной сложности или
+конечного лимита; без заданного — не позднее 8 обращений к инструментам.
+Неисчерпанный бюджет не разрешает новый способ поиска, исчерпанный — ложный успех. Повторный вызов получает только изменённые
+основания, findings и остаток; свежий независимый первый проход — сырые входы.
+
 ## Параллельность
 
-Разрешай несколько исполнителей только при независимых задачах, изолированных write sets/worktree, отсутствии общей незащищённой памяти и известном порядке интеграции. При сомнении сериализуй. Общие plan.md и .wolf/ изменяет назначенный владелец; .wolf/ в linked worktree резолвится в общий main-чекоут, записи по умолчанию `scope: worktree:<name>`, перенос в общую память — `wolf promote`; передача незакоммиченного состояния между рабочими копиями — wolf-handoff snapshot. Не объявляй одинаковые файлы в разных ветках доказательством семантической независимости.
+Разрешай несколько исполнителей только при независимых задачах, изолированных write sets/worktree, отсутствии общей незащищённой памяти и известном порядке интеграции. Не сериализуй ready-задачи без конкретной зависимости/риска. При неизвестной
+общей границе сначала выясни её коротким мандатом. Блокер приостанавливает
+зависимых; остальные идут дальше. Обновление общего контракта требует сверки
+затронутых задач, не слепой интеграции. Общие plan.md и .wolf/ изменяет назначенный владелец; .wolf/ в linked worktree резолвится в общий main-чекоут, записи по умолчанию `scope: worktree:<name>`, перенос в общую память — `wolf promote`; передача незакоммиченного состояния между рабочими копиями — wolf-handoff snapshot. Не объявляй одинаковые файлы в разных ветках доказательством семантической независимости.
 
 ## Интеграция и завершение
 

package/update-map.json

@@ -1,6 +1,6 @@
 {
-  "version": "2.21.0",
-  "prev": "2.20.1",
+  "version": "2.21.2",
+  "prev": "2.21.1",
   "files": [
     {
       "path": "base/agents/executor-lead.md",