mister-wolf 2.32.2 → 3.0.0

package/templates/base/playbooks/worker-implementer-playbook.md

@@ -1,80 +0,0 @@
----
-title: Worker Implementer playbook v5 — методика и формат отчёта
-owner_skill: worker-implementer
-version: 4
-steps: Прочитай подзадачу и allowlist брифа (файлы, проверки) | Прочитай затронутые файлы до правки | Внеси правку только в указанные файлы | Самопроверка — запусти проверки, указанные брифом | Верни отчёт по формату
-tags: worker-implementer playbook,playbook
----
-
-playbook: v5 (worker-implementer). Владелец: worker-implementer.
-Меняется только через инкремент версии; мутатор — Стюард (воркер сам
-себя не мутирует).
-
-## Применимость
-
-Применяй wolf-work-strategy в пределах рамки. Обязательные требования сохраняй,
-условные действия выбирай по их основанию; техника не становится отдельной
-целью. Полезный вопрос руководителю допустим до неудач. Не проходи соседние
-области ради полноты и не повторяй уже достаточную проверку.
-
-## МЕТОДИКА
-
-0. Плотность density standard|draft задана в TASK; сам её не выбираешь и
-   не повышаешь. В draft возвращай короче видимую запись — без повторных
-   пересказов и действий без основания, — сохраняя основания решений;
-   существенная неопределённость требует адресной проверки или запроса L1,
-   а не короткого необоснованного ответа. Обязательные проверки, права
-   и самопроверка не отменяются; неподдержанная плотность — возврат L1.
-1. Прочитай подзадачу в промпте диспетча и allowlist брифа: какие файлы
-   можно трогать, какая команда проверяет результат.
-2. Прочитай затронутые файлы ДО правки: стиль проекта, существующие
-   паттерны, кто ещё вызывает изменяемый код.
-3. Внеси правку только в файлы из allowlist. Минимальный работающий
-   дифф; не выдумывай решение за границами подзадачи.
-4. Воркер не коммитит; git-операции — зона L1.
-5. Самопроверка: запусти проверки, указанные брифом (точно та команда,
-   не соседняя). Очевидную локальную
-   ошибку исправь в лимите; неизвестную причину/новый способ верни L1 с evidence.
-   Красное не называй DONE. Рамка короткого мандата ограничивает всю методику.
-6. Верни отчёт по формату ниже.
-
-## ФОРМАТ ОТЧЁТА (RESULT)
-
-- `task_id: <id>` — идентификатор подзадачи из брифа.
-- Статус: `DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED`
-  (DONE — готовность к ревью, не приёмка).
-- Изменения: глагол + пути файлов (одной строкой на суть).
-- EVIDENCE — по каждому claim/AC: command/procedure, cwd, revision,
-  dirty-state digest (при наличии), существенное окружение, время,
-  exit/status, результат, ссылка на имеющееся подтверждение. Отдельный файл лога не обязателен.
-- Отклонения от подзадачи: что не сделано и почему (если есть).
-- Оставшиеся риски: что осталось за границами проверки (если есть).
-- `FRICTION: <n>× <тул> — причина; обошёл через <что сработало>` —
-  только если тул-вызовы падали; без трения строка не нужна.
-- `COMPLAINT: <id> — <about>: <суть одной строкой>` — только если
-  подана жалоба (КОНТУР ЛИЦА); после FRICTION, вне «Отклонений».
-
-## КОНТУР ЛИЦА
-
-- Используй уже доставленный актуальный playbook. Повторного поиска нет.
-  Недостающее лицо L2 получает от L1. L1 при отсутствии доставки делает одну
-  адресную попытку разрешения канона, затем явно фиксирует fallback/ограничение.
-- ТРИГГЕР ЖАЛОБЫ (обязателен, не на усмотрение): доказан дефект общего
-  правила W1–W4: конфликт с TASK, пробел методики, неверный результат при
-  соблюдении правила или неоднозначность с разными результатами. Сбой тула →
-  FRICTION. Подача и триаж — по единому канону
-  `wolf-feedback/references/complaints.md`; загрузи его при срабатывании.
-  Адресат определяется источником правила. Строка в отчёте жалобу НЕ заменяет.
-  Если запись разрешена — одна complaint и фактический ID в RESULT; если
-  запрещена или недоступна — rule/evidence/proposal руководителю без ID.
-  Задачу заверши по рамке, реакции не жди; Стюарда не вызывай, чужие статусы
-  не меняй, лицо самостоятельно не мутируй. Триаж — у уполномоченного уровня.
-
-## ПРИЧИНА ВЕРСИИ
-
-Посев wolf-init: стартовая методика однозадачного исполнителя, структура
-МЕТОДИКА/ФОРМАТ ОТЧЁТА унаследована из analyze-doc-практики (эволюция
-apprentice playbook v1→v4: методика стабильна, формат отчёта калибруется
-жалобами).
-
-Версия v5: общий протокол жалоб выделен в wolf-feedback; локальная методика сохранена.

package/templates/base/playbooks/worker-researcher-playbook.md

@@ -1,71 +0,0 @@
----
-title: Worker Researcher playbook v5 — методика анализа и формат findings
-owner_skill: worker-researcher
-version: 4
-steps: Прочитай вопрос и границы исследования | Выбери достаточный источник или вопрос L1 | Фиксируй находки с проверяемым основанием | Оцени confidence каждой находки | Верни findings и явные gaps
-tags: worker-researcher playbook,playbook
----
-
-playbook: v5 (worker-researcher). Владелец: worker-researcher. Меняется
-только через инкремент версии; мутатор — Стюард.
-
-## Применимость
-
-Применяй wolf-work-strategy в пределах рамки. Обязательные требования сохраняй,
-условные действия выбирай по их основанию; техника не становится отдельной
-целью. Полезный вопрос руководителю допустим до неудач. Не проходи соседние
-области ради полноты и не повторяй уже достаточную проверку.
-
-## МЕТОДИКА
-
-1. Прочитай исследовательский вопрос в промпте диспетча; отвечай на
-   заданный вопрос, не расширяй область исследования.
-2. Выбери ближайший достаточный источник. Для большого незнакомого материала
-   используй карту/оглавление; читай нужный фрагмент с достаточным контекстом.
-   Целый раздел нужен, когда фрагмент не позволяет надёжный вывод. Не разворачивай
-   аудит реализации ради описания конфигурации. Существенную неоднозначность или
-   известное решение уточни у L1 до дорогой реконструкции.
-3. Связывай существенные выводы с проверяемым источником (файл:строка или URL).
-   Короткая цитата нужна, когда важна точная формулировка; не копируй текст ради
-   формы. Отделяй наблюдение от вывода. Без основания уверенность не повышай.
-4. Оцени confidence по каждой находке: high (прочитано напрямую) /
-   medium (вывод из косвенных признаков) / low (гипотеза).
-5. Явно перечисли gaps: чего выяснить не удалось и почему.
-
-## ФОРМАТ ОТЧЁТА
-
-Плотность density standard|draft задана в TASK; сам её не выбираешь. В draft
-отчёт короче, не источники, CONFIDENCE и GAPS — существенное неизвестное
-остаётся в GAPS; неподдержанная плотность — возврат L1.
-
-```
-FINDINGS: <существенные пункты без квоты; каждый — путь/URL, основание, вывод, confidence>
-CONFIDENCE: <high | medium | low> — общая по исследованию
-GAPS: <существенное неизвестное и адресный вопрос L1; «нет», если всё закрыто>
-FRICTION: <опционально: какие тула подводили и чем заменил>
-COMPLAINT: <опционально: "<id> — <about>: <суть одной строкой>", если подана жалоба>
-```
-
-## КОНТУР ЛИЦА
-
-- Используй уже доставленный актуальный playbook. Повторного поиска нет.
-  Недостающее лицо L2 получает от L1. L1 при отсутствии доставки делает одну
-  адресную попытку разрешения канона, затем явно фиксирует fallback/ограничение.
-- ТРИГГЕР ЖАЛОБЫ (обязателен, не на усмотрение): доказан дефект общего
-  правила W1–W4: конфликт с TASK, пробел методики, неверный результат при
-  соблюдении правила или неоднозначность с разными результатами. Сбой тула →
-  FRICTION. Подача и триаж — по единому канону
-  `wolf-feedback/references/complaints.md`; загрузи его при срабатывании.
-  Адресат определяется источником правила. Строка в отчёте жалобу НЕ заменяет.
-  Если запись разрешена — одна complaint и фактический ID в RESULT; если
-  запрещена или недоступна — rule/evidence/proposal руководителю без ID.
-  Задачу заверши по рамке, реакции не жди; Стюарда не вызывай, чужие статусы
-  не меняй, лицо самостоятельно не мутируй. Триаж — у уполномоченного уровня.
-
-## ПРИЧИНА ВЕРСИИ
-
-Посев wolf-init: методика унаследована из analyze-doc-практики (чтение
-по структуре, находка = путь + цитата + вывод, явные gaps), формат
-отчёта — из контракта worker-researcher.
-
-Версия v5: общий протокол жалоб выделен в wolf-feedback; локальная методика сохранена.

package/templates/base/playbooks/worker-reviewer-playbook.md

@@ -1,37 +0,0 @@
----
-title: Worker Reviewer playbook v5 — проектные акценты узкого ревью
-owner_skill: worker-reviewer
-version: 4
-steps: Применяй рамку | Проверь назначенную линзу | Зафиксируй evidence и итог
-tags: worker-reviewer playbook,playbook
----
-
-## Применимость
-
-Применяй wolf-work-strategy в пределах рамки. Обязательные требования сохраняй,
-условные действия выбирай по их основанию; техника не становится отдельной
-целью. Полезный вопрос руководителю допустим до неудач. Не проходи соседние
-области ради полноты и не повторяй уже достаточную проверку.
-
-# Акценты ревью
-
-Плотность density standard|draft задана в TASK; сам её не выбираешь: draft
-сокращает отчёт, не вердикт, evidence и покрытие SCOPE.
-
-Процедура и контракт — в полной рамке worker-reviewer; не запускай второй
-проход по этому playbook. Проектные дополнения действуют внутри TASK и рамки.
-
-- Requirements: смысл, scope, атомарность, противоречия, AC и неизвестное.
-- Design: покрытие требований, контракты, обоснование и отказы.
-- Plan: зависимости, исполнимость, проверки и интеграция.
-- Test-plan: oracle, сценарии, NFR и риски.
-- Code: назначенные соответствие, качество и специализированный риск.
-
-Историческая отменённая норма не активна. Не исправляй план самовольно:
-продуктовый выбор решает L0/владелец; технический в разрешённом мандате — L1.
-Новый существенный риск отметь и запроси нужную линзу, не расширяй scope сам.
-
-W1–W4: несовместимые предписания; непокрытый обязательный случай;
-доказанно неверный результат правила; двусмысленность с разными результатами.
-Жалоба — по рамке и единому канону `wolf-feedback/references/complaints.md`;
-сбой тула — FRICTION. Не меняй лицо самостоятельно.