mister-wolf 2.20.1 → 2.21.1

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,36 +1,36 @@
 {
-  "version": "2.20.1",
-  "prev": "2.20.0",
+  "version": "2.21.1",
+  "prev": "2.21.0",
   "files": [
     {
       "path": "base/agents/executor-lead.md",
       "kind": "agent",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/agents/mr-wolf.md",
       "kind": "agent",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/agents/steward.md",
       "kind": "agent",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/agents/worker-implementer.md",
       "kind": "agent",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/agents/worker-researcher.md",
       "kind": "agent",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/agents/worker-reviewer.md",
       "kind": "agent",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/commands/analyze-doc.md",
@@ -55,12 +55,12 @@
     {
       "path": "base/skills/receiving-code-review/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/requesting-code-review/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/test-driven-development/SKILL.md",
@@ -75,12 +75,12 @@
     {
       "path": "base/skills/using-skills/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/verification-before-completion/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/wolf-brainstorm/SKILL.md",
@@ -90,7 +90,7 @@
     {
       "path": "base/skills/wolf-debug/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/wolf-design/SKILL.md",
@@ -100,7 +100,7 @@
     {
       "path": "base/skills/wolf-execute/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/wolf-explain/SKILL.md",
@@ -110,22 +110,22 @@
     {
       "path": "base/skills/wolf-handoff/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/wolf-plan/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/wolf-review/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/wolf-sdd/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/wolf-skill-intake/SKILL.md",
@@ -157,42 +157,42 @@
     {
       "template": "base/playbooks/complaint-protocol.md",
       "owner_skill": "mr-wolf",
-      "category": "unchanged",
+      "category": "changed",
       "seed": true
     },
     {
       "template": "base/playbooks/executor-lead-playbook.md",
       "owner_skill": "executor-lead",
-      "category": "unchanged",
+      "category": "changed",
       "seed": true
     },
     {
       "template": "base/playbooks/steward-nastavnik.md",
       "owner_skill": "steward",
-      "category": "unchanged",
+      "category": "changed",
       "seed": true
     },
     {
       "template": "base/playbooks/worker-implementer-playbook.md",
       "owner_skill": "worker-implementer",
-      "category": "unchanged",
+      "category": "changed",
       "seed": true
     },
     {
       "template": "base/playbooks/worker-researcher-playbook.md",
       "owner_skill": "worker-researcher",
-      "category": "unchanged",
+      "category": "changed",
       "seed": true
     },
     {
       "template": "base/playbooks/worker-reviewer-playbook.md",
       "owner_skill": "worker-reviewer",
-      "category": "unchanged",
+      "category": "changed",
       "seed": true
     }
   ],
   "agents_md": {
-    "category": "unchanged",
+    "category": "changed",
     "mode": "append-block"
   },
   "schema_migrations": [],