mister-wolf 2.15.1 → 2.15.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mister-wolf",
-  "version": "2.15.1",
+  "version": "2.15.2",
   "description": "Local-first project memory for AI coding agents: decisions, lessons, tools and processes that outlive the session",
   "keywords": [
     "ai-agents",

package/templates/.wolf/router.log

@@ -1 +1 @@
-2026-10-09T00:33:23.581Z agent-id=v2-router-probe-xyz playbook=hit name=fallback variant=fallback injected=yes ms=1 bytes=1208
+2026-10-09T16:24:53.230Z agent-id=v2-router-probe-xyz playbook=hit name=fallback variant=fallback injected=yes ms=1 bytes=1274

package/templates/base/AGENTS.md

@@ -7,10 +7,11 @@
 ## Протокол холодного старта (каждая свежая сессия)
 
 1. **Начинай с состояния проекта:** запусти `wolf call` и `wolf brief`
-   (CLI: `node dist/bootstrap/cli.js`; MCP-инструменты: `mr-wolf_*`).
+   (CLI: установленный `wolf`, или `node <путь-к-repo-wolf>/dist/bootstrap/cli.js` в репо Wolf; MCP-инструменты: `mr-wolf_*`).
    Возвращённые injections и brief — активное руководство проекта.
 2. **Фиксируй значимое через Wolf:** решения — `wolf add --type decision`,
-   уроки — `--type lesson`, блокеры — `--type blocker`; устаревшее —
+   уроки — `--type lesson`, блокеры — thread со статусом `blocked`
+   (`wolf thread add`, затем `wolf transition <id> blocked`); устаревшее —
    `wolf supersede <old-id> <new-id>`.
 3. **Состояние проекта — только у Wolf** (`wolf search`, `wolf get`,
    `wolf brief`): статические списки в файлах устаревают. Память Wolf —

package/templates/base/agents/executor-lead.md

@@ -50,6 +50,10 @@ Used / Validation Results).
   результата, критерий проверки, блок «Инструменты» (какие тула и
   известные ловушки). Передал подходящие — снял с воркера расход витков
   на пробы. Плохой промпт = мусор в ответе — твоя ошибка, не его.
+  В бриф воркера включай назначенную методику (имена скиллов) и
+  common-контракты TASK/RESULT/EVIDENCE/ACCEPTANCE из using-skills,
+  если платформа не доставляет using-skills автоматически; L2 сам
+  каталог скиллов не перебирает.
 - Исследовательские подзадачи («как устроен X», «почему в Z так») →
   `worker-researcher`, не делай сам.
 - Лимит воркеров на сессию: 5; фикс не удался за 2 попытки → partial.

package/templates/base/agents/mr-wolf.md

@@ -47,8 +47,9 @@ git-метаданные, веб), не для исполнения работы
 2. **Бриф и диспетч**: контекст (2–5 предложений), критерии приёмки
    (каждый проверяем по отчёту, без чтения кода), команда валидации,
    scope. Диспетчеризуй `executor-lead`.
-3. **Приёмка**: по каждому критерию вердикт строго по отчёту;
-   основание — цитата из отчёта, не догадка. Правдоподобие без ответа
+3. **Приёмка**: L0 принимает по ACCEPTANCE-критериям и актуальности
+   evidence, а не по цитате отчёта; сам проверки не запускает —
+   независимый запуск поручает L1. Правдоподобие без ответа
    «как проверяли» = критерий НЕ подтверждён.
 4. **Циклы**: rejected → возврат executor'у с перечнем несоответствий;
    максимум 2 цикла, дальше — эскалация пользователю.

package/templates/base/agents/steward.md

@@ -25,8 +25,10 @@ agent-id: steward
 - **ЛИЦО** — матрица лиц (теги playbook'ов Стюарда), выбор по существу
   жалобы. Нет playbook'а лица — работай по рамке (безликий режим).
 - **ДОСТАВКА** — plugin-inject (основной); fallback: сам сделай
-  `wolf search "steward:<лицо> playbook"` перед задачей и возьми
-  наибольшую версию.
+  `wolf search "steward:<лицо> playbook" --hide-superseded` перед
+  задачей — работай по актуальному (не суперседенному) playbook'у,
+  проверь owner_skill (steward или skill:steward); канона нет —
+  работай по fallback-контуру, доставленному плагином.
 
 ## Матрица лиц
 

package/templates/base/agents/worker-implementer.md

@@ -24,8 +24,11 @@ agent-id: worker-implementer
 - **ЛИЦО** — playbook с тегом `worker-implementer playbook` (методика и
   формат отчёта). Нет playbook'а — работай по рамке (безликий режим).
 - **ДОСТАВКА** — plugin-inject (основной, ноль расходов в рантайме);
-  fallback: сам сделай `wolf search "worker-implementer playbook"`
-  перед задачей и возьми наибольшую версию.
+  fallback: сам сделай `wolf search "worker-implementer playbook"
+  --hide-superseded` перед задачей — работай по актуальному
+  (не суперседенному) playbook'у, проверь owner_skill
+  (worker-implementer или skill:worker-implementer); канона нет —
+  работай по fallback-контуру, доставленному плагином.
 
 ## Контекст-бюджет уровня L2
 

package/templates/base/agents/worker-researcher.md

@@ -30,8 +30,10 @@ GAPS: <чего не удалось выяснить, если есть>
   анализа, формат findings). Нет playbook'а — работай по рамке
   (безликий режим).
 - **ДОСТАВКА** — plugin-inject (основной); fallback: сам сделай
-  `wolf search "worker-researcher playbook"` перед задачей и возьми
-  наибольшую версию.
+  `wolf search "worker-researcher playbook" --hide-superseded` перед
+  задачей — работай по актуальному (не суперседенному) playbook'у,
+  проверь owner_skill (worker-researcher или skill:worker-researcher);
+  канона нет — работай по fallback-контуру, доставленному плагином.
 
 ## Контекст-бюджет уровня L2
 

package/templates/base/agents/worker-reviewer.md

@@ -16,7 +16,7 @@ agent-id: worker-reviewer
 
 ```
 SUMMARY: X critical / Y major / Z minor
-VERDICT: APPROVED | CHANGES_REQUIRED
+VERDICT: APPROVED | CHANGES_REQUIRED | INCONCLUSIVE
 ```
 
 ## Обязательная тройка (рамка + лицо + доставка)
@@ -24,19 +24,21 @@ VERDICT: APPROVED | CHANGES_REQUIRED
 - **РАМКА** — этот файл: роль, границы, запреты. Статична; меняется
   только `wolf sync`.
 - **ЛИЦО** — playbook с тегом `worker-reviewer playbook` (зоны обзора,
-  категории Critical/Important/Suggestions). Нет playbook'а — работай
+  категории Critical/Major/Minor). Нет playbook'а — работай
   по рамке (безликий режим).
-- **ДОСТАВКА** — plugin-inject (основной); fallback: сам сделай
-  `wolf search "worker-reviewer playbook"` перед задачей и возьми
-  наибольшую версию.
+- **ДОСТАВКА** — plugin-inject (основной); fallback: работай по
+  актуальному (не суперседенному) playbook'у — `wolf search
+  "worker-reviewer playbook" --hide-superseded`, проверь owner_skill
+  (agent-id или skill:<agent-id>); канона нет — работай по
+  fallback-контуру, доставленному плагином.
 
 ## Контекст-бюджет уровня L2
 
 - Ровно одна задача ревью; без права спавна агентов.
 - Результат — вердикт по контракту + находки по пунктам (файл:строка,
   что не так, предлагаемая правка); не код.
-- Узкий ревьюер: работаешь в своей линзе; чужие замечания вне порученной
-  зоны — не твои, не собирай их.
+- Узкий ревьюер: работаешь в своей линзе. Чужую зону не разрабатывай;
+  существенную находку вне мандата отметь отдельно для маршрутизации.
 
 ## Дисциплина роли
 

package/templates/base/commands/analyze-doc.md

@@ -6,6 +6,6 @@ agent: worker-researcher
 
 Протокол (рамочная команда — методика в памяти Wolf):
 
-1. ДО анализа получи актуальный playbook: `wolf search "worker-researcher playbook"` — запись с наибольшей версией.
+1. ДО анализа получи актуальный playbook: `wolf search "worker-researcher playbook" --hide-superseded` — актуальная (не суперседенная) запись, проверь owner_skill (worker-researcher или skill:worker-researcher); канона нет — работай по fallback-контуру, доставленному плагином.
 2. Анализ выполняй строго по разделам «МЕТОДИКА» и «ФОРМАТ ОТЧЁТА» playbook. Формат отчёта (шапка с версией, структура, футер) — из playbook, не отсюда.
 3. Фидбек владельца о методике/формате → жалобный контур (`wolf complain`, тег complaint), не самомутация: мутатор playbook'ов — Стюард. Без фидбека версию не меняй.

package/templates/base/commands/complain.md

@@ -8,6 +8,6 @@ agent: mr-wolf
 
 1. Прими жалобу дословно — без пересказа и интерпретаций.
 2. Внеси её объектом: `wolf complain --about <цель> --rule <какое правило плохо> --evidence <дословная цитата + что произошло> --proposal <что изменить> --created-by owner` — объект `complaint` со статусом `open`.
-3. Триаж — по дереву ветвей playbook'а `complaint-protocol` (`wolf search "complaint playbook"`, наибольшая версия): сам владелец или передача координатору (executor-lead).
+3. Триаж — по дереву ветвей playbook'а `complaint-protocol` (`wolf search "complaint playbook" --hide-superseded`, актуальная/не суперседенная запись): сам владелец или передача координатору (executor-lead).
 4. Мутация (ветвь steward-mutation) — вложенный вызов Стюарда: `opencode run --agent steward`, вход = id жалобы; мутация через supersede, авторство `steward:<лицо>`. Это путь владельца/координатора — не воркера.
 5. Доложи владельцу: что принял, что изменилось в памяти.

package/templates/base/commands/doc-review.md

@@ -6,7 +6,7 @@ agent: mr-wolf
 
 Ты — оркестратор цикла; протокол — скилл wolf-review, правила цикла (MIN-3):
 
-1. Получи линзы: `wolf search "wolf-review playbook"` — наибольшая версия. Порядок: полнота → консистентность → типоспецифичные; состав каждой линзы — из playbook.
+1. Получи линзы: `wolf search "wolf-review playbook" --hide-superseded` — актуальная (не суперседенная) запись, проверь owner_skill (wolf-review или skill:wolf-review); канона нет — работай по fallback-контуру, доставленному плагином. Порядок: полнота → консистентность → типоспецифичные; состав каждой линзы — из playbook.
 2. Спавнь worker-reviewer'ов через {{tool.task}} — одна линза = один воркер в чистой сессии, узкий мандат: чужие замечания запрещены (воркер видит только документ + свою линзу).
 3. От каждой линзы требуй контракты: `SUMMARY: X critical / Y major / Z minor` + `VERDICT: APPROVED | CHANGES_REQUIRED`.
 4. Дедуп находок между линзами; подсчёт critical/major/minor — по итоговому набору.

package/templates/base/playbooks/executor-lead-playbook.md

@@ -24,9 +24,12 @@ playbook: v1 (executor-lead). Владелец: executor-lead. Меняется
 
 Полный текст подзадачи (не ссылка) + точные пути файлов + контракт
 результата + критерий проверки + блок «Инструменты» (какие тула, известные
-ловушки). Передал подходящее — снял с воркера расход на пробы. Плохой
-промпт = мусор в ответе — ошибка lead'а. Исследовательские подзадачи
-(«как устроен X», «почему в Z так») → `worker-researcher`, не делай сам.
+ловушки) + назначенная методика (имена скиллов) и common-контракты
+TASK/RESULT/EVIDENCE/ACCEPTANCE, если платформа не доставляет
+using-skills автоматически. Передал подходящее — снял с воркера расход
+на пробы. Плохой промпт = мусор в ответе — ошибка lead'а.
+Исследовательские подзадачи («как устроен X», «почему в Z так») →
+`worker-researcher`, не делай сам.
 
 ## КОНТРАКТ ФИНАЛЬНОГО ОТВЕТА
 
@@ -46,8 +49,10 @@ Task Decomposition / Workers Used / Validation Results).
 
 ## КОНТУР ЛИЦА
 
-- ДО задачи: `wolf search "executor-lead playbook"` — работай по
-  наибольшей версии.
+- ДО задачи: работай по актуальному (не суперседенному) playbook'у:
+  `wolf search "executor-lead playbook" --hide-superseded`, проверь
+  owner_skill (agent-id или skill:<agent-id>); канона нет — работай по
+  fallback-контуру, доставленному плагином.
 - ТРИГГЕР ЖАЛОБЫ (обязателен, не на усмотрение): систематически плохо
   ПРАВИЛО (декомпозиция/промпт воркера/контракт ответа), не тул и не
   разовый случай: **W1** предписание противоречит брифу — следовать

package/templates/base/playbooks/steward-nastavnik.md

@@ -2,7 +2,7 @@
 title: Наставник v1 — протокол мутации playbook'ов
 owner_skill: steward
 version: 1
-steps: Прочитай текущий playbook агента (wolf search "<тег> playbook", наибольшая версия) | Осмысли жалобу — какое измерение поведения меняется | Зафиксируй новую версию полным содержимым (не диффом), причина в конце | Supersede старой версии | Отчитайся: что изменено, версия, причина
+steps: Прочитай текущий playbook агента (wolf search "<тег> playbook" --hide-superseded, актуальная/не суперседенная версия) | Осмысли жалобу — какое измерение поведения меняется | Зафиксируй новую версию полным содержимым (не диффом), причина в конце | Supersede старой версии | Отчитайся: что изменено, версия, причина
 tags: steward:наставник,playbook
 ---
 
@@ -14,9 +14,10 @@ tags: steward:наставник,playbook
 
 ## Протокол мутации (обязателен)
 
-1. **Прочитай текущий контекст агента**: `wolf search "<тег> playbook"` —
-   возьми запись с наибольшей версией. Playbook'а нет → создаёшь первую
-   версию, supersede не нужен.
+1. **Прочитай текущий контекст агента**: `wolf search "<тег> playbook"
+   --hide-superseded` — возьми актуальную (не суперседенную) запись,
+   проверь owner_skill (тег-агент или skill:<агент>). Актуального
+   playbook'а нет → создаёшь первую версию, supersede не нужен.
 2. **Осмысли жалобу**: какое измерение поведения меняется — методика,
    формат отчёта, границы, инструмент. Жалоба без конкретики → верни
    вопрос передавшему жалобу (в жалобном контуре v2 жалобу передаёт

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

@@ -18,15 +18,22 @@ playbook: v1 (worker-implementer). Владелец: worker-implementer.
    паттерны, кто ещё вызывает изменяемый код.
 3. Внеси правку только в файлы из allowlist. Минимальный работающий
    дифф; не выдумывай решение за границами подзадачи.
-4. Самопроверка: запусти проверки, указанные брифом (точно та команда,
+4. Воркер не коммитит; git-операции — зона L1.
+5. Самопроверка: запусти проверки, указанные брифом (точно та команда,
    не соседняя). Красный тест по твоей вине — исправь до ответа.
-5. Верни отчёт по формату ниже.
+6. Верни отчёт по формату ниже.
 
-## ФОРМАТ ОТЧЁТА
+## ФОРМАТ ОТЧЁТА (RESULT)
 
-- Что сделано: глагол + пути файлов (одной строкой на суть).
-- Результаты проверок: команда + вывод (pass/fail, числа).
+- `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>: <суть одной строкой>` — только если
@@ -34,8 +41,11 @@ playbook: v1 (worker-implementer). Владелец: worker-implementer.
 
 ## КОНТУР ЛИЦА
 
-- ДО задачи: `wolf search "worker-implementer playbook"` — работай по
-  наибольшей версии (МЕТОДИКА и ФОРМАТ ОТЧЁТА из неё, не из рамки).
+- ДО задачи: работай по актуальному (не суперседенному) playbook'у:
+  `wolf search "worker-implementer playbook" --hide-superseded`, проверь
+  owner_skill (agent-id или skill:<agent-id>); канона нет — работай по
+  fallback-контуру, доставленному плагином (МЕТОДИКА и ФОРМАТ ОТЧЁТА
+  из него, не из рамки).
 - ТРИГГЕР ЖАЛОБЫ (обязателен, не на усмотрение): систематически плохо
   ПРАВИЛО (МЕТОДИКА/ФОРМАТ ОТЧЁТА), не тул и не разовый случай:
   **W1** предписание методики противоречит брифу — следовать обоим

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

@@ -35,8 +35,11 @@ COMPLAINT: <опционально: "<id> — <about>: <суть одной ст
 
 ## КОНТУР ЛИЦА
 
-- ДО задачи: `wolf search "worker-researcher playbook"` — работай по
-  наибольшей версии (МЕТОДИКА и ФОРМАТ ОТЧЁТА из неё).
+- ДО задачи: `wolf search "worker-researcher playbook" --hide-superseded`
+  — работай по актуальному (не суперседенному) playbook'у, проверь
+  owner_skill (worker-researcher или skill:worker-researcher); канона
+  нет — работай по fallback-контуру, доставленному плагином
+  (МЕТОДИКА и ФОРМАТ ОТЧЁТА из неё).
 - ТРИГГЕР ЖАЛОБЫ (обязателен, не на усмотрение): систематически плохо
   ПРАВИЛО (методика/формат findings), не тул и не разовый случай:
   **W1** предписание методики противоречит брифу — следовать обоим

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

@@ -2,7 +2,7 @@
 title: Worker Reviewer playbook v1 — зоны обзора и VERDICT-контракт
 owner_skill: worker-reviewer
 version: 1
-steps: Прочитай файлы и требования брифа | Пройди 6 зон обзора по порядку | Классифицируй проблемы Critical, Important, Suggestions | Верни SUMMARY и VERDICT | FRICTION-строка только при тул-сбоях
+steps: Прочитай файлы и требования брифа | Пройди зоны в границах мандата, назначенного L1 | Классифицируй проблемы Critical/Major/Minor | Верни SUMMARY и VERDICT | FRICTION-строка только при тул-сбоях
 tags: worker-reviewer playbook,playbook
 ---
 
@@ -13,10 +13,17 @@ playbook: v1 (worker-reviewer). Владелец: worker-reviewer. Меняет
 
 ```
 SUMMARY: X critical / Y major / Z minor
-VERDICT: APPROVED | CHANGES_REQUIRED
+VERDICT: APPROVED | CHANGES_REQUIRED | INCONCLUSIVE
 ```
 
-## ЗОНЫ ОБЗОРА (проходи все 6)
+- `INCONCLUSIVE` — нехватка входов или невозможность проверки.
+- `SUMMARY` и `VERDICT` сами по себе не доказательство — выводы
+  привязывай к evidence и revision.
+
+## ЗОНЫ ОБЗОРА (узкий мандат)
+
+Узкий мандат: L1 назначает линзе область; обязательный проход
+несвязанных зон исключён.
 
 1. **Соответствие плану**: реализация против требований брифа; отклонения
    от плана — оцени, проблемные они или оправданные; всё ли запланированное
@@ -28,17 +35,23 @@ VERDICT: APPROVED | CHANGES_REQUIRED
    кодом, расширяемость.
 4. **Документация и стандарты**: комментарии и докстринги на месте и
    точны, стандарты проекта соблюдены.
-5. **Классификация проблем**: Critical (исправить обязательно) /
-   Important (следует исправить) / Suggestions (желательно); по каждой —
-   конкретное место (файл:строка) и действенное предложение.
+5. **Классификация проблем**: Critical — потеря данных/полномочий/
+   существенная неверность; Major — блокирующий дефект заявленного
+   результата; Minor — неблокирующее улучшение; по каждой — конкретное
+   место (файл:строка) и действенное предложение.
 6. **Коммуникация**: сначала подтверди, что сделано хорошо; существенные
    отклонения от плана — запрос на подтверждение; ошибки самого плана —
    рекомендация правки плана, а не кода.
 
+«Отметь, а не молчи»: существенную находку вне мандата отметь отдельно
+для маршрутизации; чужую зону не разрабатывай.
+
 ## КОНТУР ЛИЦА
 
-- ДО задачи: `wolf search "worker-reviewer playbook"` — работай по
-  наибольшей версии.
+- ДО задачи: работай по актуальному (не суперседенному) playbook'у:
+  `wolf search "worker-reviewer playbook" --hide-superseded`, проверь
+  owner_skill (agent-id или skill:<agent-id>); канона нет — работай по
+  fallback-контуру, доставленному плагином.
 - ТРИГГЕР ЖАЛОБЫ (обязателен, не на усмотрение): систематически плохо
   ПРАВИЛО (мандат/зоны обзора/формат вердикта), не тул и не разовый
   случай: **W1** предписание противоречит брифу — следовать обоим

package/templates/base/skills/finishing-a-development-branch/SKILL.md

@@ -1,232 +1,40 @@
 ---
 name: finishing-a-development-branch
-description: Используй, когда реализация завершена, все тесты зелёные и нужно решить, как интегрировать работу — ведёт финал через структурированные опции мержа, PR или уборки
+description: "Заверши проверенную git-поставку: выполни уже согласованный merge/PR/сохранение либо запроси недостающий выбор. Безопасно сохрани или убери worktree, учитывая незакоммиченную и неотправленную работу."
 ---
 
-# Finishing a Development Branch
+# Завершение git-поставки
 
-> Источник: ~/.config/opencode/superpowers/skills/finishing-a-development-branch/SKILL.md, upstream 6efe32c (2026-04-23).
-> Владелец шага: executor-lead; финальное решение (особенно мерж в main) — за владельцем.
+## Предусловия
 
-## Трассировка адаптации
+Ответственный — L1 с действующими правами. Проверь ACCEPTANCE/ограничения, валидные проверки, project base branch, worktree list и состояние рабочей копии. Сохрани task branch, абсолютный worktree path, base/head и uncommitted/untracked до переключений. Не повторяй full check, если evidence всё ещё применимо; объединённый результат требует проверки.
 
-| Пункт upstream                                                                                                                                                                | Судьба                                                                                                             |
-| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
-| Процесс 5 шагов, ровно 4 опции финала, подтверждение «discard», шпаргалка (4 опции), частые ошибки (4), red flags Never/Always (4/4), cleanup worktree только для опций 1 и 4 | **сохранено** («переносим почти без правок», research §1; red flags — дословно по смыслу, H7)                      |
-| Тестовая команда                                                                                                                                                              | **заменено**: `npm run check` (верификационный примитив проекта)                                                   |
-| Базовая ветка: `main \|\| master`                                                                                                                                             | **заменено**: всегда `main` — правило проекта trunk-based (main — истина, работа в worktree-ветках, релизы тегами) |
-| Опция 1 (мерж локально)                                                                                                                                                       | **дополнено** правилом проекта: мерж в main — только по явному поручению владельца                                 |
-| Решение о финале ветки                                                                                                                                                        | **добавлено**: значимое решение (особенно discard) фиксируется `wolf add --type decision`                          |
+## Выбор
 
-## Обзор
+Если пользователь уже поручил конкретный финал и условия выполнены, исполни его без повторного вопроса. Иначе предъяви применимые варианты с последствиями: merge, push/PR, оставить, удалить. Не предлагай недоступное действие как исполнимое.
 
-Проведи финал работы через ясные опции и исполнение выбранного сценария.
+### Merge
 
-**Принцип:** верифицируй тесты → предъяви опции → исполни выбор → приберись.
+Требуется действующее поручение на merge. Проверь актуальность согласованного base; fetch/pull выполняй по политике, не слепо. Если base уже занят другим worktree, интегрируй в его рабочей копии только с проверкой чистоты и владельца; не делай checkout занятой ветки.
 
-**Анонс в начале:** «Использую скилл finishing-a-development-branch для завершения этой работы».
+Конфликты разрешай по требованиям, проверяй итоговые изменения и integration/full gate на merged revision. Не удаляй branch/worktree до подтверждения успешной интеграции и сохранности нужных evidence.
 
-## Процесс
+### Push и PR
 
-### Шаг 1: верифицируй тесты
+Используй разрешённый remote/branch. PR описывает проблему, итоговое поведение, проверки и ограничения; тело передавай структурированно или файлом. Draft допустим для незавершённого ревью/известных падений, если это явно соответствует поручению; ready PR не должен скрывать провал обязательных проверок.
 
-**До предъявления опций — прогнать тесты:**
+После PR сохраняй ветку и worktree для исправлений, если пользователь не поручил безопасную уборку отдельно. Сообщи ссылку и статус; создание PR не означает merge.
 
-```bash
-npm run check   # тестовая команда проекта
-```
+### Оставить
 
-**Упали:**
+Сохрани ветку/worktree, сообщи head, путь, dirty-state и следующий шаг. Не запускай cleanup.
 
-```
-Тесты падают (<N> падений). Надо починить до завершения:
+### Удалить
 
-[показать падения]
+Покажи точный путь, ветку, неслитые/неотправленные коммиты, uncommitted/untracked и последствия. При отсутствии уже однозначного разрешения запроси подтверждение конкретного удаления. Не требуй кодовое слово, если разрешение ясно и соответствует этой работе.
 
-Нельзя продолжать merge/PR, пока тесты не зелёные.
-```
+Для сохранения предложи patch/backup при необходимости. Удали собственный worktree обычной git worktree remove; затем свою ветку. Если git отказывается из-за dirty-state, не добавляй force автоматически. Force допустим только в явно разрешённом объёме. Не удаляй общую base branch.
 
-Стоп. Не переходить к шагу 2.
+## Итог
 
-**Зелёные:** → шаг 2.
-
-### Шаг 2: определи базовую ветку
-
-Правило проекта — trunk-based: базовая ветка всегда `main` (main — истина).
-
-```bash
-git merge-base HEAD main
-```
-
-При сомнении спроси: «Ветка отделилась от main — верно?»
-
-### Шаг 3: предъяви опции
-
-Ровно эти 4 опции:
-
-```
-Реализация завершена. Что делаем?
-
-1. Смержить обратно в <base-branch> локально
-2. Запушить и создать Pull Request
-3. Оставить ветку как есть (разберусь позже)
-4. Выбросить эту работу
-
-Какая опция?
-```
-
-**Без пояснений** — опции краткие.
-
-### Шаг 4: исполни выбор
-
-#### Опция 1: мерж локально
-
-Только по явному поручению владельца (правило проекта: main — истина, мерж — осознанное решение владельца).
-
-```bash
-git checkout main
-git pull
-git merge <feature-branch>
-
-# Верифицировать тесты на смерженном результате
-npm run check
-
-# Если зелёные
-git branch -d <feature-branch>
-```
-
-Затем: уборка worktree (шаг 5).
-
-#### Опция 2: пуш и PR
-
-```bash
-git push -u origin <feature-branch>
-
-gh pr create --title "<заголовок>" --body "$(cat <<'EOF'
-## Summary
-<2-3 буллета что изменилось>
-
-## Test Plan
-- [ ] <шаги верификации>
-EOF
-)"
-```
-
-Затем: уборка worktree (шаг 5).
-
-#### Опция 3: оставить как есть
-
-Доложить: «Оставляю ветку <имя>. Worktree сохранён: <путь>».
-
-**Worktree не убирать.**
-
-#### Опция 4: выбросить
-
-**Сначала подтверждение:**
-
-```
-Это навсегда удалит:
-- Ветку <имя>
-- Все коммиты: <список-коммитов>
-- Worktree <путь>
-
-Введи 'discard' для подтверждения.
-```
-
-Ждать дословного подтверждения.
-
-Если подтверждено:
-
-```bash
-git checkout main
-git branch -D <feature-branch>
-```
-
-Затем: уборка worktree (шаг 5).
-
-### Шаг 5: уборка worktree
-
-**Для опций 1, 2, 4:**
-
-Проверить, находишься ли в worktree:
-
-```bash
-git worktree list | grep $(git branch --show-current)
-```
-
-Если да:
-
-```bash
-git worktree remove <worktree-path>
-```
-
-**Для опции 3:** worktree сохранить.
-
-## Быстрая шпаргалка
-
-| Опция                | Мерж | Пуш | Сохранить worktree | Удалить ветку |
-| -------------------- | ---- | --- | ------------------ | ------------- |
-| 1. Мерж локально     | ✓    | -   | -                  | ✓             |
-| 2. Создать PR        | -    | ✓   | ✓                  | -             |
-| 3. Оставить как есть | -    | -   | ✓                  | -             |
-| 4. Выбросить         | -    | -   | -                  | ✓ (force)     |
-
-## Частые ошибки
-
-**Пропуск верификации тестов**
-
-- **Проблема:** смержить сломанный код, создать падающий PR
-- **Фикс:** всегда верифицировать тесты до предъявления опций
-
-**Открытые вопросы**
-
-- **Проблема:** «Что делать дальше?» → двусмысленность
-- **Фикс:** предъявлять ровно 4 структурированные опции
-
-**Автоматическая уборка worktree**
-
-- **Проблема:** удалить worktree, который ещё нужен (опции 2, 3)
-- **Фикс:** уборка только для опций 1 и 4
-
-**Без подтверждения для discard**
-
-- **Проблема:** случайно удалить работу
-- **Фикс:** требовать дословный ввод «discard»
-
-## Red flags
-
-**Никогда:**
-
-- Не продолжать с падающими тестами
-- Не мержить без верификации тестов на результате
-- Не удалять работу без подтверждения
-- Не форс-пушить без явного запроса
-
-**Всегда:**
-
-- Верифицировать тесты до предъявления опций
-- Предъявлять ровно 4 опции
-- Получать дословное подтверждение для опции 4
-- Убирать worktree только для опций 1 и 4
-
-## Интеграция
-
-**Вызывается из:**
-
-- **wolf-sdd** (финальный шаг) — после завершения всех задач
-- **wolf-execute** (финальный шаг) — после завершения всех батчей
-
-**Пара с:**
-
-- **using-git-worktrees** — убирает worktree, созданный тем скиллом
-
-## Интеграция с Wolf
-
-- **Правило проекта**: trunk-based — main = истина, работа в worktree-ветках, релизы тегами; мерж в main — только по явному поручению владельца.
-- **Решение о финале ветки** (выбрана опция, особенно discard) — значимое решение: `wolf add --type decision` с контекстом («ветка X выброшена, потому что...»).
-
-## Конвейер (2.15)
-
-Проект на trunk-based: main = истина; работа в worktree-ветках; влитие потока —
-merge в main с зелёным `npm run check`; релизы — тегами `v*` (npm version).
-«Ветвь» не живёт дольше волны.
+Запиши выполненное действие, revision, проверки, PR/merge outcome и сохранённое/удалённое. Неопределённый исход внешнего действия сначала проверь, не повторяй push/PR вслепую. Значимое решение сохраняй разрешённым каналом памяти. Автоматическая публикация релиза не входит в этот скилл.