mister-wolf 2.27.1 → 2.29.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mister-wolf",
-  "version": "2.27.1",
+  "version": "2.29.0",
   "description": "A local-first project organization for AI assistants: goal-directed processes, project memory and governed learning",
   "keywords": [
     "ai-agents",

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

@@ -40,8 +40,12 @@ GAPS: <чего не удалось выяснить, если есть>
 ## Короткий мандат и возврат L1
 
 Один TASK — конечный результат/вопрос с входами, scope, проверкой и стоп-условием,
-не весь компонент или свободный поиск. Поручение требует выбрать архитектуру,
-состав работ или цепочку исследований → вопрос L1 до исполнения. Локальные
+не весь компонент или свободный поиск. Выбор архитектуры без явного архитектурного вопроса в TASK,
+смена состава работ или новая цепочка исследований → вопрос L1 до исполнения.
+При явно назначенном архитектурном вопросе можно сравнить варианты и дать
+рекомендацию по wolf-software-design в границах TASK; это не утверждение
+архитектуры и не разрешение реализации. Результат — FINDINGS/CONFIDENCE/GAPS
+сообщением, запись файлов и остальные ограничения роли сохраняются. Локальные
 детали, нужное чтение и одна очевидная коррекция назначенного способа допустимы.
 Методику/доставленное лицо используй один раз; общий процесс L0/L1 не разворачивай.
 Нет обязательного входа → запрос L1; fallback не заменяет обязательный канон.

package/templates/base/skills/requesting-code-review/SKILL.md

@@ -11,7 +11,6 @@ description: "Применять перед интеграцией измене
 
 Загрузи полный текст назначенной методики до её выполнения. Обязательные пункты отслеживай в доступном трекере или рабочем брифе; не добавляй новые статусы памяти. Недоступное действие передай ответственному уровню.
 
-
 ## Подготовка
 
 L1 фиксирует base_sha ДО исполнения задачи, current/head revision и dirty-state. Не используй HEAD~1 как универсальную границу: задача может включать несколько коммитов. Для незакоммиченного результата передай проверяемый diff и состояние файлов; не требуй коммита ради ревью.
@@ -22,6 +21,12 @@ L1 фиксирует base_sha ДО исполнения задачи, current/h
 
 Назначь мандат: соответствие, качество/интеграция или специализированный риск. Для значимых изменений проверь security, миграции и failures; для небольших — пропорциональный объём. L0 вызывает executor, L1 — worker-reviewer. Недоступное независимое ревью явно отметь, не имитируй второй голос.
 
+Для инженерной оценки реализации доставь reviewer wolf-code-craft как критерии
+без права правки; для назначенного разбора упрощения — wolf-code-simplify.
+Предпочтение другого стиля или паттерна не блокирует приёмку без доказанного
+нарушения требования/нормы либо конкретного блокирующего последствия.
+Не добавляй отдельного ревьюера или раунда только ради нового скилла.
+
 ## Конечный мандат
 
 L1 применяет цикл wolf-review; L2 получает полную рамку/лицо reviewer и

package/templates/base/skills/using-skills/references/agent-language.md

@@ -0,0 +1,97 @@
+# Спецификация внутреннего языка агентов Wolf
+
+**Статус:** действующая спецификация; этап наблюдения (утверждено владельцем
+2026-11-04, решение mem_20261104_vnutrenniy_yazyk_wolf_etap_nablyudeniya_19ed1f;
+рамка и обоснования — docs/dev/2026-11-04-agent-language/pre-requirements.md).
+
+**Назначение:** уточняет термины и правила употребления внутреннего языка
+агентов (агенты — ИИ-помощники, выполняющие задачи проекта через фиксированные
+формы сообщений). Формы сообщений — обязательные поля (слоты) каждого типа
+высказывания — нормативно определены в contracts.md (соседний файл) и здесь НЕ
+дублируются: спецификация ссылается на него. Новых обязательных полей документ
+не вводит — только существующие конструкции.
+
+## Границы покрытия
+
+Язык покрывает только высказывания, меняющие состояние работы: поручения,
+отчёты, вердикты, передачи, жалобы, предложения, переходы статусов.
+Описательная зона свободна: обсуждения, объяснения и рассуждения остаются
+обычным текстом (двухслойность рамки). Ситуации, которые формы не выражают,
+покрывает escape-высказывание (R6).
+
+## Термины
+
+Определения следуют действующим контрактам (contracts.md, complaints.md) и рамке
+решения владельца; при первом употреблении термин сопровождается расшифровкой.
+
+- **TASK** — поручение исполнителю: ядро (обязательные элементы поручения)
+  плюс поля применимого профиля (implement | review | research). Полный состав
+  слотов — contracts.md.
+- **RESULT** — отчёт исполнителя по форме своей роли. Статусы implement-профиля:
+  DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED. DONE — готовность к
+  ревью, не приёмка.
+- **DONE ≠ ACCEPTED** — разные высказывания разных уровней: DONE сообщает
+  готовность к ревью; ACCEPTED — решение назначенного принимающего по
+  результатам приёмки (L1 принимает результат L2 в пределах полномочий;
+  владелец — там, где предусмотрено его решение).
+- **EVIDENCE** — подтверждение утверждения/критерия: команда или процедура,
+  cwd, revision, exit/статус, результат. Состав — contracts.md.
+- **ACCEPTANCE** — сверка каждого критерия приёмки с evidence и итоговый
+  вердикт принимающего: ACCEPTED | PARTIAL | REJECTED | INCONCLUSIVE.
+  Вердикт независимого ревью: APPROVED | CHANGES_REQUIRED | INCONCLUSIVE.
+- **SCOPE** — граница допустимого: что входит в задачу и что запрещено;
+  для ревью SCOPE — покрытие проверки.
+- **LIMITS/GAPS** — что не проверено, где нет данных или остался риск;
+  отсутствие данных не равно нулю или успеху.
+- **BLOCKED** — статус: работа не может продолжаться без внешнего
+  входа/решения.
+- **NEEDS_CONTEXT** — статус: недостаёт обязательного входа поручения;
+  запрашивается, не додумывается.
+- **HANDOFF** — фиксация передачи работы (результата, ответственности,
+  открытых вопросов) между исполнителями/сессиями.
+- **VERDICT** — итоговое решение проверки/приёмки одним из перечисленных
+  статусов, с evidence.
+- **COMPLAINT** — жалоба на правило (методика/рамка/правило памяти), не на
+  разовый случай; подавается объектом памяти через wolf-feedback (поля
+  rule/evidence/proposal, класс дефекта — kind: technical|behavioral).
+  Предмет LANGUAGE — см. раздел жалоб wolf-feedback.
+- **PROPOSAL** — предложение улучшения/изменения с основанием.
+- **TRANSITION** — переход объекта работы в новый статус по допустимым
+  переходам.
+
+## Правила употребления R1–R6
+
+- **R1** — одно понятие — одно имя.
+- **R2** — запрет анафоры (анафора — отсылки вроде «то же, что выше», «эта
+  задача»); ссылки — по идентификатору с версией, например T-42@v2.
+- **R3** — полная поставка: документ языка приезжает со скиллами целиком;
+  частичная доставка не предусмотрена.
+- **R4** — человек получает обычный язык; термины — с расшифровкой при первом
+  употреблении.
+- **R5** — DONE ≠ ACCEPTED: исполнитель сообщает готовность к ревью; признание
+  результата — решение назначенного принимающего (см. определение
+  DONE ≠ ACCEPTED выше).
+- **R6** — escape (выход): свободный текст с пометкой «вне контракта» для
+  ситуаций, которые форма не покрывает.
+
+## Правило при недопонимании
+
+Смысл понятен — продолжать. Недостающая информация влияет на действие —
+уточнить, не угадывать. Несоблюдение языка оставляет текущий уровень — не хуже
+сегодняшнего (соблюдение даёт лаконичность и точность, не штраф).
+
+## Примеры (условные, для иллюстрации — не шаблоны)
+
+1. Обмен TASK→RESULT:
+   TASK: «T-7@v1: обнови справочник команд в guides/cli.md — добавь раздел
+   про sync. Проверка: раздел виден в оглавлении. Лимит: 6 обращений».
+   RESULT: «T-7 DONE: раздел добавлен; проверка пройдена (оглавление содержит
+   sync); без отклонений».
+2. Вердикт и приёмка:
+   VERDICT: «T-7 APPROVED: замечаний нет». ACCEPTANCE: «T-7 ACCEPTED: оба
+   критерия подтверждены evidence».
+3. LANGUAGE-жалоба:
+   COMPLAINT (предмет LANGUAGE): rule: «LANGUAGE/ambiguous-definition —
+   определение DONE допускает чтение как окончательной приёмки»; evidence:
+   «в задаче X RESULT со статусом DONE принят без ревью, ревью не
+   состоялось»; proposal: «уточнить определение DONE примером».

package/templates/base/skills/using-skills/references/contracts.md

@@ -100,3 +100,5 @@ EVIDENCE: claim/AC, command или процедура, cwd, revision, dirty-stat
 ACCEPTANCE: по каждому AC подтверждение/не подтверждено, актуальные evidence, независимое ревью, ограничения; финальный verdict L0: ACCEPTED | PARTIAL | REJECTED | INCONCLUSIVE.
 
 Контракты веди сообщениями и адресными note Wolf; файловый fallback — по правилам рабочей памяти выше. Не добавляй команды или типы Wolf без отдельной реализации. Следы жалоб и вердиктов сохраняй разрешённым каналом; при недоступной записи передай L1.
+
+Термины и правила употребления внутреннего языка агентов — см. agent-language.md; формы сообщений (слоты) остаются нормативными здесь.

package/templates/base/skills/using-skills/references/routes-execution.md

@@ -8,6 +8,7 @@ L1 до назначения читает [канон TASK](contracts.md). Не
 | Нужно определить проверки | wolf-testplan: связать критерии с независимым oracle | Сценарии и команды |
 | Начинается поставка | wolf-sdd: L1 выбирает лица/скиллы и назначает ready-задачи L2 | Проверенные и интегрированные результаты |
 | L2 выполняет назначенный мандат | wolf-execute: линейно выполнить только свою часть | RESULT/evidence либо конкретный вопрос L1 |
+| Пишется или изменяется программный код  | wolf-code-craft: полная реализация понятными средствами в принятой архитектуре | Код без ненужной сложности; проверки по действующей методике |
 | Реализуется поведение или исправление | test-driven-development: наблюдаемые RED/GREEN по применимости | Чувствительная проверка и реализация |
 | Готовится заявление о завершении | verification-before-completion: сверить claim с актуальным evidence | Обоснованное заявление, не автоматический ACCEPTED |
 

package/templates/base/skills/using-skills/references/routes-intent.md

@@ -6,6 +6,7 @@
 | Ясное поручение с достаточными входами | wolf-brainstorm: показать понимание и продолжить без ритуального вопроса | Исполнение в согласованном scope |
 | Нужен ответ исследованием | L1 назначает вопрос worker-researcher с лицом/скиллом, источниками и остановкой | FINDINGS/CONFIDENCE/GAPS |
 | Утверждены требования, нужен дизайн | wolf-design: контракты и решения по FULL/новым интерфейсам | Проверяемое решение без реализации |
+| Нужен выбор программных границ, контрактов или зависимостей | wolf-software-design внутри wolf-design; назначенный researcher сравнивает варианты и рекомендует | Обоснованная конструкция для решения ответственным уровнем |
 
 Продолжение неизменившейся цели не возвращай в discovery. Понимание цели не
 утверждает ещё не показанные requirements/design. Пользователь может выбирать

package/templates/base/skills/using-skills/references/routes-quality.md

@@ -5,9 +5,15 @@
 | Назначен баг/неожиданное поведение | wolf-debug: локализовать причину адресными экспериментами | Evidence причины либо предел вывода |
 | Ревью документа | wolf-review: назначенная линза и критерии на revision | SUMMARY/VERDICT/FINDINGS/SCOPE/LIMITS/EVIDENCE |
 | Ревью реализации | requesting-code-review: независимому L2 передать материалы, нормы, evidence | Соответствие, затем качество |
+| Найдена конкретная лишняя сложность или назначено упрощение | wolf-code-simplify: сохранить контракт и проверить выгоду; reviewer только оценивает | Адресное упрощение либо обоснованный отказ от преобразования |
 | Получены замечания | receiving-code-review: проверить основания и исправить относящееся | Решение по finding IDs и адресная перепроверка |
 | Вопрос, FRICTION, отклонение или W1–W4 | wolf-feedback: выбрать адресата, не расследовать всё | Вопрос, коррекция, жалоба либо назначенная диагностика |
 
+Для инженерной оценки кода используй wolf-code-craft как критерии, а не право
+правки. Предпочтение другой формы кода не блокирует приёмку без доказанного
+нарушения. Упрощение не обязательная стадия после каждой правки; все три
+инженерных скилла одновременно по умолчанию не загружай.
+
 Первый reviewer не получает ожидаемый verdict и чужие findings. Повторный проход
 проверяет исправления и затронутые изменения; расширение требует основания.
 Не запускай аудит соседнего дефекта. Очевидный W1–W4 не требует повторов или

package/templates/base/skills/wolf-code-craft/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: wolf-code-craft
+description: 'Применять при написании и изменении кода: полностью реализовать назначенное поведение понятными средствами без ненужной сложности. При ревью использовать как критерии оценки в пределах мандата.'
+---
+
+# Качество реализации
+
+Сначала выполни требования и сохрани необходимые гарантии.
+Среди подходящих решений выбирай наиболее понятное и согласованное с проектом.
+Сокращай код и зависимости, когда это не ухудшает первые условия.
+
+Работай по TASK, принятому дизайну и действующей методике проверки.
+Скилл не расширяет полномочия роли.
+
+## Перед правкой
+
+Прочитай затронутый код и необходимые контракты потребителей.
+Найди существующие средства и соглашения проекта.
+
+Определи, куда должно дойти изменение: вызовы, типы, конфигурация,
+экспорты, тесты и документация — по фактической связи с задачей.
+Необходимую правку вне разрешённого scope передай L1.
+
+Существенную неоднозначность требований уточни.
+Не сокращай функциональность молча до удобной реализации.
+
+## Выбирай прямой путь
+
+Используй первый достаточный способ:
+
+1. Существующее решение проекта или исправление общего источника ошибки.
+2. Возможность стандартной библиотеки или платформы с учётом правил проекта.
+3. Подходящую установленную зависимость.
+4. Прямую реализацию недостающего поведения.
+
+Новую зависимость оцени по выгоде и стоимости сопровождения;
+соблюдай проектный порядок её добавления.
+Не пиши сложный аналог библиотеки ради отсутствия пакета.
+
+Поиск готового средства ограничивай разумной областью задачи.
+
+## Строй понятную реализацию
+
+- Используй предметные имена, привычные средства языка и явный поток управления.
+- Держи связанные действия рядом; не дроби код ради размера функций или файлов.
+- Выделяй функцию, когда она называет значимую операцию,
+  скрывает сложность или концентрирует общее правило.
+- Не создавай прослойку, которая только переименовывает вызов
+  без полезного контракта или границы.
+- Убирай ненужные преобразования данных, промежуточное состояние и вложенность.
+- Не добавляй режимы, настройки и точки расширения без текущего основания.
+- Комментируй неочевидную причину, ограничение или инвариант;
+  соблюдай требования проекта к документации.
+
+Несколько явных строк лучше выражения, которое приходится расшифровывать.
+Количество строк и минимальный diff сами по себе не являются целью.
+
+## Структура и полнота
+
+В пределах scope можно улучшить локальную структуру,
+если её сохранение требует дублирования, обходов или нарушает гарантии.
+Пересмотр общих контрактов и архитектуры передай ответственному уровню.
+
+При исправлении бага устраняй подтверждённую причину
+и учитывай другие затронутые вызовы. Не размножай обход по потребителям.
+
+Сохраняй необходимые валидацию, права доступа, обработку ошибок,
+управление ресурсами, совместимость и гарантии состояния.
+Не превращай сбой в успешный ответ или пустой результат без основания в контракте.
+
+Не добавляй защитные ветки для состояний, исключённых надёжным контрактом.
+Недоверенные входы и внешние данные проверяй на соответствующих границах.
+
+Не объединяй похожий код, если он выражает независимо меняющиеся правила.
+
+## Проверка и завершение
+
+Применяй действующую методику тестирования и обязательные проверки проекта.
+Проверяй поведение, существенные границы и регрессию,
+а не воспроизводи реализацию в тестах.
+
+Если назначенные проверки не покрывают существенное изменённое поведение,
+добавь адресную проверку в пределах полномочий либо обозначь пробел L1.
+
+Просмотри diff: требования доведены до потребителей,
+случайных изменений нет, новые конструкции имеют понятную причину.
+Обнаруженную лишнюю сложность устрани в текущем мандате;
+отдельный проход wolf-code-simplify не обязателен.
+
+Верни результат и evidence в штатном формате роли.
+
+## Применение при ревью
+
+Предпочтение другой формы кода само по себе не является дефектом.
+Для замечания укажи нарушенное требование, принятую норму
+либо конкретное последствие.
+
+Рекомендация без доказанного блокирующего нарушения не блокирует приёмку.
+Следуй действующей шкале severity; не вводи собственную.

package/templates/base/skills/wolf-code-simplify/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: wolf-code-simplify
+description: 'Применять по назначенной задаче упрощения или при конкретной лишней сложности, требующей отдельного разбора. Сохраняет поведение и контракты; не является обязательной стадией после каждой правки.'
+---
+
+# Упрощение существующего кода
+
+Устрани конкретную сложность, сохранив необходимое поведение.
+Результат должен быть проще понимать, использовать или изменять.
+
+Работай в назначенном scope. Reviewer оценивает и предлагает;
+правки выполняет уполномоченный исполнитель.
+
+## 1. Назови проблему
+
+Определи, что именно мешает:
+повторение правила, ненужная косвенность, запутанный поток,
+избыточное состояние или сложный протокол для потребителей.
+
+Одной возможности сократить строки недостаточно.
+Если проблема неясна, не начинай переписывание.
+
+## 2. Установи сохраняемый контракт
+
+Используй требования, тесты и потребителей. Учти относящиеся свойства:
+
+- результаты и ошибки;
+- значимые побочные эффекты и их порядок;
+- состояние и управление ресурсами;
+- совместимость, конкурентные и транзакционные гарантии;
+- необходимые характеристики производительности.
+
+Отсутствие теста не означает отсутствия обязательства.
+При существенной неопределённости нужна адресная проверка
+или уточнение до преобразования.
+
+Обнаруженный баг отдели от рефакторинга:
+исправление поведения требует соответствующего scope и проверки.
+
+## 3. Выбери преобразование
+
+Примени прямое средство против установленной проблемы:
+
+- повторяемое правило → одно место его определения;
+- лишнее состояние → вычисление из надёжного источника;
+- запутанная вложенность → явные ветви или ранний выход;
+- повторяемый протокол → операция, владеющая его гарантиями;
+- бесполезная прослойка → удаление без переноса сложности потребителям;
+- самодельный механизм → подходящее существующее средство;
+- мёртвый код → удаление после достаточной проверки потребителей.
+
+Сохраняй полезные границы безопасности, совместимости и тестируемости.
+Внешние, динамические и конфигурационные вызовы учитывай по устройству проекта;
+отсутствия текстового совпадения может быть недостаточно для удаления.
+
+Не смешивай преобразование с несвязанными перемещениями,
+переименованиями и форматированием.
+
+## 4. Проверь сохранение и выгоду
+
+Выполни относящиеся проверки и обязательные гейты проекта.
+При изменении I/O или состояния проверь соответствующие гарантии,
+а не только возвращаемое значение.
+
+Сопоставь результат с исходной проблемой:
+
+- сложность действительно уменьшилась;
+- потребителям не добавлена новая обязанность;
+- поведение и гарантии сохранены;
+- код не стал плотнее ценой ясности.
+
+Если выгода сомнительна, не включай преобразование в результат.
+Если сохранение контракта не подтверждено, не объявляй работу завершённой.
+
+Остановись после устранения назначенной сложности.
+Верни суть преобразования и evidence в штатном формате TASK.
+
+При ревью отличай доказанный дефект от необязательной рекомендации;
+применяй действующие нормы и severity проекта.

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

@@ -11,11 +11,18 @@ L0 назначает процесс и согласует продуктовы
 
 Используй полный актуальный текст назначенной методики. По wolf-work-strategy различай обязательные требования, условные действия и доступные техники; отслеживай применимые обязательства в существующем TASK/трекере. Не создавай новые статусы памяти; недоступное обязательное действие передай ответственному уровню.
 
-
 ## Вход и выход
 
 Вход: approved requirements или утверждённый бриф, baseline SHA, существующая архитектура и профиль проекта. Выход: design.md с состоянием review, картой покрытия REQ/NFR и решениями для согласования. Автор — назначенный L1/L2; утверждение — по политике проекта через L0.
 
+## Инженерная методика
+
+Для программного решения с выбором границ, контрактов, зависимостей или состояния
+подключи wolf-software-design. Встроенная методика не создаёт отдельного гейта.
+L1 может поручить researcher один архитектурный вопрос с вариантами и рекомендацией;
+утверждение остаётся у ответственного уровня. Researcher отвечает сообщением,
+его лицо не разрешает запись design.md или реализацию.
+
 ## Процесс
 
 1. Проверь актуальность требований и прочитай код затронутых компонентов и потребителей. Ссылки задавай как revision:path:symbol; номера строк — дополнительный ориентир.

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

@@ -11,6 +11,11 @@ TASK/RESULT/EVIDENCE — по using-skills/references/contracts.md. L0 не вы
 не разрешает ему заменять воркеров универсальным исполнением. Если диспетчеризация
 недоступна, L1 возвращает конкретное ограничение, не имитирует вызов.
 
+При написании/изменении кода применяй доставленный wolf-code-craft;
+при отдельном поручении на упрощение — wolf-code-simplify. Недостающую назначенную
+методику запроси L1. Это не отменяет test-driven-development и проектные проверки
+и не запускает второй проход после каждой правки.
+
 ## Исполнение
 
 1. Сверь назначенные входы с фактической revision, allowlist и правами.

package/templates/base/skills/wolf-feedback/references/complaints.md

@@ -45,6 +45,34 @@
      несогласие с триажем — эскалация (about=executor-lead), не новая
      жалоба той же сути.
 
+### Языковые жалобы (предмет LANGUAGE)
+
+Языковая жалоба — предмет «что не так в терминах или формах внутреннего
+языка» (термины и правила — using-skills/references/agent-language.md).
+Класс дефекта остаётся в kind (technical|behavioral): LANGUAGE — предмет
+жалобы, не новый kind и не новый маршрут.
+
+Маркер в поле rule — `LANGUAGE/<причина>`, причины:
+- `LANGUAGE/ambiguous-definition` — термин допускает разные толкования
+  (пример: «DONE поняли как окончательную приёмку»);
+- `LANGUAGE/insufficient-form` — нужное сообщение нельзя выразить
+  существующими слотами (пример: «в RESULT нельзя понятно выразить
+  частично завершённый результат»);
+- `LANGUAGE/excessive-requirement` — форма требует лишнего для простой
+  ситуации (пример: «для простой задачи пришлось повторить уже доступные
+  ограничения»).
+
+Критерий подачи: конкретная помеха работе (переспрос, неверное действие,
+лишний шаг), а не каждое формальное отклонение от формы.
+
+Подача, триаж и мутация — как для обычных жалоб W1–W4 (разделы А и Б);
+отдельного маршрута нет.
+
+Примечание (открытый вопрос владельцу): на момент правки поле proposal
+обязательно при записи жалобы (схема: `proposal: { required: true }` в
+src/domain/memory-types.ts); до решения владельца, если решения не видно,
+пиши в proposal: «решения не вижу; основание: …».
+
 ## Б. ТРИАЖ (диспетчер)
 
 1. **Стоящее обязательство**: при приёмке КАЖДОГО отчёта до вердикта —

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

@@ -13,11 +13,19 @@ description: "Применять при исполнении утверждён
 
 Используй полный актуальный текст назначенной методики. По wolf-work-strategy различай обязательные требования, условные действия и доступные техники; отслеживай применимые обязательства в существующем TASK/трекере. Не создавай новые статусы памяти; недоступное обязательное действие передай ответственному уровню.
 
-
 ## Предусловия
 
 Оркестратор исполнения — executor-lead. L0 поручает ему поставку. Проверь утверждённые входы, plan/test-plan, профиль проекта, разрешённые git-операции, baseline и workspace. Создай worktree по using-git-worktrees, если этого требует политика. До начала зафиксируй budget/retry limit и dependencies; default — 2 цикла исправления на задачу, затем пересмотр.
 
+## Инженерные навыки по задаче
+
+При назначении написания/изменения кода доставь worker-implementer полный
+wolf-code-craft вместе с действующей тестовой методикой. Для отдельного поручения
+на упрощение доставь wolf-code-simplify; обычная реализация не требует ещё одной
+стадии. Архитектурный вопрос направь по wolf-design/wolf-software-design,
+не поручай implementer самовольный пересмотр решения. Документы, исследования
+и операции без программной реализации не получают инженерный набор автоматически.
+
 ## Цикл задачи
 
 1. Разрежь работу до конечных мандатов L2; архитектуру, стратегию поиска и зависимости определяет L1. Назначь владельца проверки общих связей. Выбери независимые ready-задачи, запусти параллельно в бюджете и с изоляцией; собери каждому TASK из using-skills по канону ядра. Выбор сеанса L2 — по канону executor-lead. Передай ссылки и минимальный достаточный контекст, проверенные контракты и expected RESULT. L2 разрешено читать нужные файлы и потребителей; история родительской сессии не наследуется.

package/templates/base/skills/wolf-software-design/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: wolf-software-design
+description: 'Применять внутри wolf-design или по назначенному архитектурному вопросу: выбрать границы программных модулей, контракты, зависимости и владение состоянием. Не запускает перепроектирование при обычной реализации.'
+---
+
+# Проектирование программного решения
+
+Выбирай конструкцию, которая выполняет требования с наименьшей совокупной
+сложностью для реализации, потребителей, проверки и эксплуатации.
+
+Используй действующие требования, ADR, профиль проекта и рамку TASK.
+Скилл не расширяет полномочия роли и не заменяет маршрут wolf-design.
+Назначенный researcher возвращает варианты и рекомендацию, а не утверждение
+архитектуры; решение принимает ответственный по действующим правилам проекта.
+
+## От задачи к конструкции
+
+Начни с существующего решения и затронутых потребителей. Определи,
+какое поведение требуется, какие гарантии существенны и что должно измениться.
+
+Проверь, достаточно ли текущего модуля, готовой возможности проекта
+или платформы. Для существенной развилки сравни простейший достаточный
+вариант с разумной альтернативой. Очевидная правка не требует конкурса решений.
+
+Неизвестное, меняющее выбор, разреши адресным вопросом, источником
+или разрешённой ограниченной проверкой. Не проектируй цепочку на существенном
+допущении; read-only роль не создаёт код эксперимента.
+
+## Границы и ответственность
+
+Держи вместе поведение, которое использует общие знания и меняется
+по одной причине. Разделяй независимые причины изменения и разные гарантии.
+
+Для изменяемого состояния определи владельца, допустимые переходы
+и место обеспечения инвариантов. Не распределяй одно правило
+по нескольким потребителям.
+
+Выбирай модуль с понятным интерфейсом, скрывающим полезную сложность.
+Интерфейс — всё необходимое потребителю: данные, ошибки, порядок действий,
+эффекты и ограничения, а не только сигнатуры.
+
+Проверка удаления: если убрать модуль, сложность исчезнет
+или разойдётся по потребителям? Во втором случае он выполняет полезную работу.
+
+## Конкретные приёмы
+
+- Отделяй вычисление решения от I/O, когда это упрощает проверку
+  и не разрывает цельное действие.
+- Передавай время, случайность и внешние зависимости там, где поведение
+  должно быть управляемым. Часто достаточно параметра функции.
+- Проверяй значимое поведение через устойчивый публичный контракт.
+  Не раскрывай внутренние детали только ради теста; адресные внутренние
+  тесты сложного алгоритма допустимы.
+- Скрывай повторяемый протокол за одной операцией, если потребители
+  иначе обязаны одинаково соблюдать сложный порядок действий.
+- Выражай внешние зависимости потребностями потребителя,
+  а не копией интерфейса поставщика.
+
+Примеры:
+
+- Расчёту срока нужен текущий момент: передай now; ClockFactory не обязателен.
+- Несколько потребителей повторяют блокировку, изменение и освобождение:
+  рассмотри одну операцию, владеющую этим протоколом.
+- Две проверки сейчас похожи, но выражают независимые бизнес-правила:
+  совпадение строк не требует общего валидатора.
+
+## Цена абстракции
+
+Создавай границу, когда она концентрирует правило, изолирует внешнюю
+систему, скрывает протокол, обеспечивает нужную проверяемость
+или подтверждённую вариативность.
+
+Одна реализация допустима при наличии такой причины.
+Гипотетического расширения самого по себе недостаточно.
+
+KISS и YAGNI помогают выбирать достаточное решение.
+DRY относится к повторяемому знанию.
+SOLID помогает оценивать ответственность, контракты и зависимости.
+Ни один принцип не требует класса, интерфейса или слоя сам по себе.
+
+Следуй принятому архитектурному стилю. Hexagonal, DDD, CQRS и другие
+подходы применяй по их назначению. Локальный тестовый шов
+не означает переход проекта на новую архитектуру.
+
+## Результат
+
+Передай выбранную конструкцию, существенные контракты, последствия
+и нерешённые вопросы в существующем design/ADR или формате TASK.
+Researcher возвращает FINDINGS/CONFIDENCE/GAPS сообщением; разрешённый автор
+документа пишет только назначенный файл/раздел.
+
+Для нетривиального решения объясни, почему более простой вариант недостаточен.
+Не создавай реализацию вместо дизайна и дополнительные документы ради скилла.
+
+Заверши, когда исполнитель может реализовать решение без угадывания
+существенных границ и гарантий либо точный пробел возвращён постановщику.

package/update-map.json

@@ -1,6 +1,6 @@
 {
-  "version": "2.27.1",
-  "prev": "2.27.0",
+  "version": "2.29.0",
+  "prev": "2.28.0",
   "files": [
     {
       "path": "base/agents/executor-lead.md",
@@ -77,6 +77,11 @@
       "kind": "skill",
       "category": "unchanged"
     },
+    {
+      "path": "base/skills/using-skills/references/agent-language.md",
+      "kind": "skill",
+      "category": "new"
+    },
     {
       "path": "base/skills/using-skills/references/context-and-memory.md",
       "kind": "skill",
@@ -85,7 +90,7 @@
     {
       "path": "base/skills/using-skills/references/contracts.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/using-skills/references/project-rules.md",
@@ -142,6 +147,16 @@
       "kind": "skill",
       "category": "unchanged"
     },
+    {
+      "path": "base/skills/wolf-code-craft/SKILL.md",
+      "kind": "skill",
+      "category": "unchanged"
+    },
+    {
+      "path": "base/skills/wolf-code-simplify/SKILL.md",
+      "kind": "skill",
+      "category": "unchanged"
+    },
     {
       "path": "base/skills/wolf-debug/references/techniques.md",
       "kind": "skill",
@@ -180,7 +195,7 @@
     {
       "path": "base/skills/wolf-feedback/references/complaints.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/wolf-feedback/references/session-diagnosis.md",
@@ -237,6 +252,11 @@
       "kind": "skill",
       "category": "unchanged"
     },
+    {
+      "path": "base/skills/wolf-software-design/SKILL.md",
+      "kind": "skill",
+      "category": "unchanged"
+    },
     {
       "path": "base/skills/wolf-testplan/SKILL.md",
       "kind": "skill",