mister-wolf 2.32.2 → 3.0.0

package/templates/base/skills/using-git-worktrees/SKILL.md

@@ -1,47 +1,11 @@
 ---
 name: using-git-worktrees
-description: "Применять перед изменениями, когда политика проекта требует отдельной рабочей копии, при параллельной работе с записью, конфликте владения workspace или подготовке изолированной реализации."
+description: "Создание изолированного рабочего дерева для независимой или параллельной работы."
 ---
 
-# Подготовка рабочего пространства
+# Совместимый вход
 
-## Обязательный вход
+Загрузить `wolf-git` один раз и выполнить относящуюся часть.
+Не создавать дополнительный этап или повторный круг проверок.
 
-L0 поручает подготовку L1; L2 получает готовую рабочую копию. До создания проверь existing worktrees, baseline и владельца изменений. Если работа уже изолирована подходящим способом и политика соблюдена, используй её, не создавая вложенный worktree. Изоляция файлов не доказывает изоляцию БД, памяти и внешних действий.
-
-Загрузи полный текст назначенной методики до её выполнения. Обязательные пункты отслеживай в доступном трекере или рабочем брифе; не добавляй новые статусы памяти. Недоступное действие передай ответственному уровню.
-
-
-Git-этапы задачи ведутся по `wolf-git`; baseline и ownership ниже не меняются.
-
-## Владелец
-
-Создание, настройка и git-операции — L1 либо разрешённая исполнительская роль. L2 получает готовые cwd, branch и allowlist. Следуй профилю проекта; local .worktrees/<task> — рекомендуемый fallback, не универсальный запрет других путей.
-
-## Процесс
-
-1. Прочитай AGENTS.md/CI, проверь git status, worktree list, текущую ветку, base branch/SHA и наличие нужной ветки. Зафиксируй чужие незакоммиченные изменения; не убирай их автоматически.
-2. Выбери уникальные branch и абсолютный путь. Для внутреннего каталога проверь ignore. Если нужно изменить .gitignore — делай это в пределах scope и полномочий; коммит не является автоматическим условием setup.
-3. Создай worktree от явно выбранного baseline, не от случайного текущего HEAD. При существующей ветке/пути выясни владельца; не удаляй и не переиспользуй чужую работу.
-4. Установи зависимости согласно lockfile, package manager и CI: frozen/reproducible install, где доступно. Не предполагай npm install или poetry по одному наличию файла. Не меняй lockfile ради setup без причины.
-5. Определи .wolf/: с 2.16.0 linked worktree резолвит общую память main-чекоута; записи по умолчанию `scope: worktree:<name>`, перенос в общую память — `wolf promote`. Владелец записи и порядок интеграции фиксируй в TASK.
-6. Выполни baseline-проверки профиля; сохрани evidence и исходные падения. Детерминированное известное нерелевантное падение допускается при разрешённой политике с явным ограничением; блокирующее или неизвестное передай L1/L0.
-7. Передай TASK: cwd, branch, base_sha, allowlist, setup, checks, memory ownership и baseline limitations.
-
-## Параллельность и cleanup
-
-Отдельные worktree изолируют файлы, но не общую внешнюю БД, процессы, порты и память. Назначь раздельные fixtures/ports и write ownership. Совместимые изменения интегрирует L1 в известном порядке. Память Wolf общая: в linked worktree `wolf` резолвит `.wolf/` в основной чекаут проекта (git common-dir); записи из worktree по умолчанию получают `scope: worktree:<name>` и скрыты из доставки другим рабочим копиям; перенос в общую память — `wolf promote`, а не копирование `.wolf/`.
-
-Путь worktree и имя ветки сохраняй до checkout/cleanup. Уборка — finishing-a-development-branch: после PR рабочая копия сохраняется, пока она нужна для исправлений; грязную или чужую копию не удалять.
-
-## Гейт перехода
-
-Исполнитель получает проверенные cwd, branch, baseline, setup, allowlist, ownership памяти и исходные ограничения проверок. Нельзя передать workspace только по факту создания каталога. Cleanup выполняется отдельно по finishing-a-development-branch и действующему разрешению.
-
-## Не пропускай процесс
-
-| Мысль | Действие |
-| --- | --- |
-| «Создам от текущего HEAD» | Выбери baseline задачи явно. |
-| «Каталог уже есть — удалю» | Выясни владельца и сохранность работы. |
-| «Общая .wolf удобнее» | Общая память уже штатна (git common-dir); записи из worktree — `scope: worktree:<name>`, перенос — `wolf promote`, без ручной синхронизации. |
+Переходная мера: удалить в следующем релизе.

package/templates/base/skills/using-skills/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: using-skills
-description: "Применять L0/L1 при новом запросе, существенном изменении условий или переходе этапа для выбора применимых методик. L2 получает назначенные навыки без обхода каталога."
+description: "Применять L0/L1 при новом запросе, существенном изменении условий или переходе этапа для выбора применимых методик. Исполнитель получает назначенные навыки без обхода каталога."
 ---
 
 # Выбор процесса Wolf
@@ -8,18 +8,16 @@ description: "Применять L0/L1 при новом запросе, сущ
 Перед ответом или действием выбери применимую методику и загрузи полный текст.
 Описание помогает выбрать, но не заменяет методику. Уже доставленный актуальный
 текст повторно не ищи. Если корень доставлен bootstrap, using-skills загружен;
-его ссылки и другие скиллы ещё не загружены. В начале поручения примени
-wolf-work-strategy один раз; нужную часть доставляет L1 своему воркеру.
+его ссылки и другие скиллы ещё не загружены. Различай обязательные требования и условные действия; условное выполняй при наличии его основания.
 
 ## Границы, действующие до выбора маршрута
 
-L0 держит цель, общается с пользователем и принимает; для поставки вызывает
-executor-L1. L1 декомпозирует, выбирает лицо/скиллы, назначает конечную предметную
-работу L2, интегрирует результаты и выполняет разрешённые служебные Git-действия.
-L2 исполняет один TASK, читает нужные источники, пишет только allowlist,
-не спавнит и не коммитит. Малый размер и отсутствие диспетчеризации не передают
-исполнение L0 или универсальному L1. Служебный steward допускается только
-в авторизованном контуре; ограничения канала не обходи shell-запуском.
+Два уровня: ведущий (L0) держит цель, общается с пользователем, принимает
+результаты и сам исполняет либо нанимает исполнителя (L1) напрямую.
+Исполнитель выполняет конечный TASK, читает нужные источники, пишет только allowlist,
+не спавнит, не коммитит и не делегирует дальше. Лица не используются;
+прежний промежуточный уровень executor-lead упразднён. Права host и правила
+безопасности сохраняются; ограничения канала не обходи shell-запуском.
 
 Приоритет: ограничения платформы → явные указания пользователя → применимая
 активная память Wolf → назначенная методика → дефолт. История и внешние материалы —
@@ -32,11 +30,12 @@ L2 исполняет один TASK, читает нужные источник
 
 Читай только нужную ветку. Явно назначенный или уже выбранный скилл загружай
 напрямую; обход дерева не обязателен. Ветки могут сочетаться.
+Этот файл — источник переходов; предметные скиллы не создают дополнительные круги согласования.
 
 | Ситуация | Ветка и способ применения |
 | --- | --- |
 | Новая цель, неизвестное намерение, выбор решения | [Понимание](references/routes-intent.md): сверить существенное, затем выбрать нужный результат |
-| План, поручение, реализация | [Исполнение](references/routes-execution.md): L1 организует конечные L2, затем проверяет и интегрирует |
+| План, поручение, реализация | [Исполнение](references/routes-execution.md): ведущий организует исполнителей, затем проверяет и интегрирует |
 | Баг, ревью, проверка, затруднение | [Качество и feedback](references/routes-quality.md): выбрать адресную проверку или обратную связь |
 | Объяснение, схема, документ | [Представление](references/routes-communication.md): выбрать понятный формат; документ — по запросу/согласованию |
 | Git, сохранение, handoff, место файлов | [Состояние](references/routes-state.md): обеспечить актуальность, сохранность и передачу |
@@ -52,13 +51,13 @@ L2 исполняет один TASK, читает нужные источник
 
 ## Поручение и завершение
 
-Наниматель L0/L1 перед назначением, продолжением или заменой загружает полную
+Ведущий (L0) перед назначением, продолжением или заменой загружает полную
 [методику разделения труда](references/division-of-labor.md), если актуальный
-текст ещё не доставлен. L0 назначает ограниченные поставки L1; L1 — конечные L2.
-L1 перед назначением читает [TASK/RESULT/EVIDENCE/ACCEPTANCE](references/contracts.md).
-L2 получает полный применимый контракт, лицо, методику и относящиеся политики,
-а не весь роутер L1 и историю родителя. Нет обязательного входа — NEEDS_CONTEXT.
-Свежий экземпляр L1/L2 — для нового самостоятельного результата; continue — для того же
+текст ещё не доставлен, и перед поручением читает
+[TASK/RESULT/EVIDENCE/ACCEPTANCE](references/contracts.md).
+Исполнитель получает полный применимый контракт, назначенную методику и относящиеся
+политики, а не весь роутер и историю родителя. Нет обязательного входа — NEEDS_CONTEXT.
+Свежий экземпляр исполнителя — для нового самостоятельного результата; continue — для того же
 непринятого; replace — через handoff. После приёмки ненужный экземпляр закрывается
 после сохранения результата и остановки записи, без прощальной церемонии.
 
@@ -66,7 +65,7 @@ execution задаёт реальные model/variant, execute|solve, бюдже
 Плотность density standard|draft — отдельная ось: отсутствие поля — standard;
 draft сокращает служебную запись, сохраняя основания, проверки и права.
 Существенная неопределённость требует адресной проверки или вопроса, а не
-необоснованного краткого ответа. L2 без лимита возвращается не позднее 8
+необоснованного краткого ответа. Исполнитель без заданного лимита возвращается не позднее 8
 обращений; два шага без продвижения — возврат раньше. DONE не равно ACCEPTED.
 
 Для сохранения/восстановления загрузи [адресную память](references/context-and-memory.md),

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

@@ -32,7 +32,7 @@
   ревью, не приёмка.
 - **DONE ≠ ACCEPTED** — разные высказывания разных уровней: DONE сообщает
   готовность к ревью; ACCEPTED — решение назначенного принимающего по
-  результатам приёмки (L1 принимает результат L2 в пределах полномочий;
+  результатам приёмки (ведущий принимает результат исполнителя в пределах полномочий;
   владелец — там, где предусмотрено его решение).
 - **EVIDENCE** — подтверждение утверждения/критерия: команда или процедура,
   cwd, revision, exit/статус, результат. Состав — contracts.md.
@@ -66,7 +66,7 @@
 Основание подтверждается EVIDENCE, допущение принято условно, неизвестное
 передаётся в LIMITS/GAPS. Согласие нескольких экспертов не делает допущение фактом.
 Условия пересмотра указывают, какие данные изменят позицию. Предложенная проверка
-не разрешает запуск; L1 отдельно назначает её в пределах полномочий.
+не разрешает запуск; ведущий отдельно назначает её в пределах полномочий.
 Профили RESULT expert/synthesis и поля v2 нормативно определены в contracts.md.
 `ready | insufficient_evidence` обозначает исход синтеза, не новые статусы памяти.
 

package/templates/base/skills/using-skills/references/context-and-memory.md

@@ -4,40 +4,42 @@
 
 ## Контекст по ответственности
 
-L0 хранит весь контекст цели/критериев и принимает; L1 руководит ограниченной
-поставкой, решениями, параллельными ready-задачами и интеграцией; L2 быстро
-исполняет один конечный мандат и возвращается. Ответственность не передаётся
-вниз вместе со сложностью; сложную работу L1 разрезает до назначений L2. TASK связывает цель владельца одной
-строкой, вклад подзадачи и результат. Методики организации/приёмки L0/L1 не
-назначай L2 по умолчанию. Воркер получает полную методику своего действия,
+Ведущий (L0) хранит весь контекст цели/критериев и принимает; он же руководит ограниченной
+поставкой, решениями, параллельными ready-задачами и интеграцией либо назначает
+исполнителя (L1): тот быстро исполняет один конечный мандат и возвращается.
+Ответственность не передаётся вниз вместе со сложностью; сложную работу ведущий
+разрезает до конечных TASK исполнителей. TASK связывает цель владельца одной
+строкой, вклад подзадачи и результат. Методики организации/приёмки не
+назначай исполнителю по умолчанию. Лица/face/playbook-доставка не используются;
+назначенная методика доставляется в поручении. Исполнитель получает полную методику своего действия,
 относящиеся нормы/исключения, TASK/RESULT/EVIDENCE и нужные инструменты;
 ACCEPTANCE и весь контекст проекта оставь ответственному уровню. Автоматически
 доставленный полный текст повторно не копируй. Обязательную норму не сжимай
 до утраты смысла; дай точный источник и возможность дочитать зависимость.
 
 Отдельное исследование требует вопроса, связи с критерием/решением/риском
-и условия остановки. Не ищи «что ещё улучшить» вне поручения. L2 передаёт
-неожиданную сложность/вопрос о полномочиях L1, не выбирает дальнейший поиск.
-Сначала решение L1/контекст/готовое средство, затем при необходимости один
-адресный worker-expert. Консилиум — по wolf-council при существенном выборе,
+и условия остановки. Не ищи «что ещё улучшить» вне поручения. Исполнитель передаёт
+неожиданную сложность/вопрос о полномочиях нанимателю, не выбирает дальнейший поиск.
+Сначала решение нанимателя/контекст/готовое средство, затем при необходимости один
+адресный wolf-expert. Консилиум — по wolf-council при существенном выборе,
 содержательном противоречии или прямом запросе; без обязательного тупика.
 Независимость и ограниченные права проверяются до запуска. Дефект правила
-W1–W4 идёт через триаж Стюарду. Совет/мутация не меняют цель и права.
+W1–W4 идёт через wolf-feedback. Совет/мутация не меняют цель и права.
 
 
 Цель/thread может объединять несколько последовательных или параллельных
-поручений L1. Поручение обозначает принимаемый результат, сессия — экземпляр
+поручений. Поручение обозначает принимаемый результат, сессия — экземпляр
 исполнителя; совпадение thread не обосновывает continue. Выбор — по
 [разделению труда](division-of-labor.md). Общий подробный план ведёт назначенный
-L1; остальные передают ему изменения/статусы. L0 хранит краткую карту назначений,
+планировщик; остальные передают ему изменения/статусы. Ведущий хранит краткую карту назначений,
 зависимости и вердикты, не весь контекст планирования. Смена владельца записи
 требует передачи, не одновременного редактирования.
 
 ## Рабочая память между агентами и сессиями
 
-Короткий RESULT L2 — сообщение. Сохраняй в Wolf только состояние/результат,
+Короткий RESULT — сообщение. Сохраняй в Wolf только состояние/результат,
 нужные следующему агенту, контрольной точке или приёмке; не каждый шаг/вывод тула.
-Владелец записи L0/L1, один на задачу. L2 без прав записи передаёт ему содержимое.
+Владелец записи — ведущий, один на задачу. Исполнитель без прав записи передаёт ему содержимое.
 Память — основной маршрут обмена; рабочий файл вне docs — fallback при её
 недоступности либо для patch/бинарных данных. Записи создаются штатными командами,
 не ручными файлами в .wolf; скрипт хранится как файл/tool, не как простыня note.
@@ -46,7 +48,7 @@ L1; остальные передают ему изменения/статусы
 - note + history: RESULT, checkpoint, сводка проверок/ревью и принятый handoff.
 - note + metric: измерения, когда они действительно нужны для сравнения.
 - thread: многошаговая цель; blocked/waiting_answer — реальная зависимость/вопрос
-  треда, не обязательный статус из-за возврата любого L2.
+  треда, не обязательный статус из-за возврата любого исполнителя.
 - decision: фактически выбранный уполномоченным уровнем вариант. Частный выбор
   команды/гипотеза остаются в рабочей note, не создают проектного решения.
 - lesson: доказанный переносимый урок с границами применимости и триггером.
@@ -55,7 +57,7 @@ L1; остальные передают ему изменения/статусы
 
 Для рабочих note явно сохраняй memory_class=working, truth_role=proposed_knowledge,
 lifetime=short_term, review_state=proposed, status=active. Для строго одноразового
-контекста допустим lifetime=session. review_state здесь не поручение Стюарду:
+контекста допустим lifetime=session. review_state здесь не поручение автоматическому триажу (обработка Стюардом временно отключена):
 это рабочая запись, а не предложенный урок/правило. history-note с accepted может
 попасть в общий brief; не делай частный результат принятой общей памятью.
 Эти поля не обеспечивают TTL, приватность или гарантированное скрытие из поиска.
@@ -65,22 +67,22 @@ lifetime=short_term, review_state=proposed, status=active. Для строго
 evidence, вопрос/следующий шаг. tags — для адресного поиска. Свяжи note с реальным
 thread через related_to; передай получателю точные ID и краткий релевантный фрагмент,
 не весь brief/архив. Не добавляй несуществующие поля task_id/expires_at/thread к note
-через --set. Учитывай scope ворктрии; прямое get/brief не является изоляцией доступа.
+через --set. Учитывай scope worktree; прямое get/brief не является изоляцией доступа.
 Пример поддержанного пути (ID/тело — реальные, не буквальные плейсхолдеры):
 
 ```bash
 wolf add --type note --facet history --title "TASK: контрольная точка" \
   --body "task/thread, revision, результат, evidence, остаток" \
-  --tags "working-state" --created-by agent:executor-lead \
+  --tags "working-state" --created-by agent:wolf-developer \
   --set memory_class=working --set truth_role=proposed_knowledge \
   --set lifetime=short_term --set review_state=proposed --set status=active
 wolf relation add <note-id> related_to <thread-id>
 ```
 
-После подтверждённой передачи/завершения L1 архивирует только свои/закреплённые
+После подтверждённой передачи/завершения владелец архивирует только свои/закреплённые
 ненужные рабочие note текущей задачи, не чужое состояние или требуемый аудит,
 сохраняя ссылки и требуемый приёмочный след; lifetime сам ничего не удаляет.
 Смысловая замена checkpoint — новая note + supersede, не дубли копий для каждого
 исполнителя. Урок/жалоба выделяются отдельно только при наличии их оснований;
 новая карточка ссылается на исходное evidence, исходная note не переименовывается
-в lesson/complaint. Стюард не превращает рабочий архив в очередь агрегации.
+в lesson/complaint. Рабочий архив не превращается в очередь агрегации; автоматическая обработка Стюардом временно отключена.

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

@@ -1,6 +1,6 @@
 # Поручение и доказательства
 
-Загружает L1 перед составлением TASK; L2 получает применимые нормы в поручении.
+Загружает ведущий перед составлением TASK; исполнитель получает применимые нормы в поручении.
 
 execution в TASK задаёт model/variant/mode и бюджет существующим способом
 запуска, не новой конфигурационной схемой. Иерархия ролей не шкала reasoning.
@@ -8,22 +8,22 @@ execution в TASK задаёт model/variant/mode и бюджет существ
 доступный режим; не повышай его сам и не считай просьбу в тексте подтверждением
 фактической настройки. У каждого вызова конечный лимит; без него — возврат
 не позднее 8 инструментальных обращений (дефолт пилота). Два шага без продвижения
-для L2 означают возврат L1, смену способа выбирает L1. Новый вывод, контрпример и обнаруженная ошибка
+означают возврат нанимателю; смену способа выбирает он. Новый вывод, контрпример и обнаруженная ошибка
 прежней проверки — основания пересмотра, даже если исходные данные те же.
 
 Плотность density standard|draft — отдельная ось того же блока execution,
 отличная от execute|solve, FULL/LITE/FIX, роли, model и variant: выбирает
-L1 или пользователь, отсутствие поля — standard, не новая конфигурационная схема.
+наниматель или пользователь, отсутствие поля — standard, не новая конфигурационная схема.
 В draft исполнитель сокращает видимую служебную запись — повторные пересказы,
 дублирующие сводки, действия без конкретного основания, — сохраняя основания
 решений; существенная неопределённость расширяет адресное исследование/проверку
-или даёт запрос L1, а не короткий необоснованный ответ. Обязательные проверки,
+или даёт запрос нанимателю, а не короткий необоснованный ответ. Обязательные проверки,
 права, независимость приёмки и безопасность не отменяются; FULL/LITE/FIX и
 execute/solve не зависят от плотности. RESULT фиксирует фактическую плотность;
 приёмка сверяет наблюдаемые действия, evidence и результат, а не ярлык draft.
 
 Инструментальный сбой не автоматически продуктовый баг и не запускает полный
-wolf-debug: один осмысленный обход в scope, затем FRICTION/ограничение и L1.
+wolf-debug: один осмысленный обход в scope, затем FRICTION/ограничение и возврат нанимателю.
 Повторный запуск чтения/проверки обосновывается изменёнными входами, новым
 свидетельством или конкретным обязательным непокрытым критерием.
 
@@ -51,7 +51,7 @@ wolf-debug: один осмысленный обход в scope, затем FRIC
   `D-id`, что решили (одной строкой), почему/что отвергнуто, основание/источник.
   Одна строка на решение; не история обсуждения. Отсутствует — влияющих решений нет.
 - Проверка — точные команды или процедуры и ожидаемый результат; запускает исполнитель.
-- Конечный бюджет и stop/return — лимит работы и условия немедленного возврата L1.
+- Конечный бюджет и stop/return — лимит работы и условия немедленного возврата нанимателю.
 - Ожидаемый RESULT — форма отчёта по роли, включая допустимые статусы и вердикты.
 
 Инварианты ядра: применимое ядерное поле нельзя опустить; неизвестный обязательный
@@ -90,7 +90,7 @@ wolf-debug: один осмысленный обход в scope, затем FRIC
   Нет обязательного входа — `NEEDS_CONTEXT`. Входы полны, но позиции нет —
   завершённая экспертиза с текстовым исходом «недостаточно оснований» и `LIMITS`,
   без выдуманных claims. Это не новый status enum и не валидное opinion с claims=[].
-  L1 сохраняет такой ответ как отсутствие сформированной позиции в синтезе.
+  Организатор сохраняет такой ответ как отсутствие сформированной позиции в синтезе.
 
 ### Профиль синтеза RESULT
 
@@ -107,8 +107,8 @@ Accepted_claims — основания, выбранные для рекомен
 их обязательные слоты не меняются; полную процедуру организатора задаёт wolf-council.
 
 Формат передачи по умолчанию — сообщение; точные разрешённые выходные файлы, если они
-нужны, и место временной работы вне документации указывает L1. Ответственность
-за общий план и покрытие остаётся у L1.
+нужны, и место временной работы вне документации указывает наниматель. Ответственность
+за общий план и покрытие остаётся у него.
 
 ### Словарь контрактов
 
@@ -121,14 +121,14 @@ Accepted_claims — основания, выбранные для рекомен
 | TASK | Поручение исполнителю: ядро из десяти элементов плюс поля применимого профиля. |
 | RESULT | Отчёт исполнителя по форме своей роли: статус или вердикт, изменения, границы. |
 | EVIDENCE | Подтверждение claim/AC: команда или процедура, cwd, revision, exit, результат. |
-| ACCEPTANCE | Сверка каждого AC с evidence и итоговый verdict приёмки у L0. |
-| SCOPE | Границы задачи: что входит и что запрещено. В отчёте worker-reviewer `SCOPE` — покрытие ревью, не границы задачи. |
+| ACCEPTANCE | Сверка каждого AC с evidence и итоговый verdict приёмки у ведущего. |
+| SCOPE | Границы задачи: что входит и что запрещено. В отчёте wolf-reviewer `SCOPE` — покрытие ревью, не границы задачи. |
 | LIMITS/GAPS | Что не проверено, где нет данных или остался риск; отсутствие данных не равно нулю или успеху. |
 
 RESULT: task_id, DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED, изменения, проверки и evidence, отклонения, оставшиеся риски. DONE означает готовность к ревью, а не приёмку.
 EVIDENCE: claim/AC, command или процедура, cwd, revision, dirty-state digest при наличии, существенное окружение, время, exit/status, результат и ссылка на имеющееся подтверждение (лог, вывод инструмента, CI-артефакт). Отдельный файл лога не обязателен. Не выдумывай отсутствующие поля.
-ACCEPTANCE: по каждому AC подтверждение/не подтверждено, актуальные evidence, независимое ревью, ограничения; финальный verdict L0: ACCEPTED | PARTIAL | REJECTED | INCONCLUSIVE.
+ACCEPTANCE: по каждому AC подтверждение/не подтверждено, актуальные evidence, независимое ревью, ограничения; финальный verdict ведущего: ACCEPTED | PARTIAL | REJECTED | INCONCLUSIVE.
 
-Контракты веди сообщениями и адресными note Wolf; файловый fallback — по правилам рабочей памяти выше. Не добавляй команды или типы Wolf без отдельной реализации. Следы жалоб и вердиктов сохраняй разрешённым каналом; при недоступной записи передай L1.
+Контракты веди сообщениями и адресными note Wolf; файловый fallback — по правилам рабочей памяти выше. Не добавляй команды или типы Wolf без отдельной реализации. Следы жалоб и вердиктов сохраняй разрешённым каналом; при недоступной записи передай нанимателю.
 
 Термины и правила употребления внутреннего языка агентов — см. agent-language.md; формы сообщений (слоты) остаются нормативными здесь.

package/templates/base/skills/using-skills/references/division-of-labor.md

@@ -1,16 +1,16 @@
 # Разделение труда и границы поручений
 
-Загружает наниматель L0/L1 перед назначением, продолжением или заменой подчинённого.
+Загружает ведущий (L0) перед назначением, продолжением или заменой подчинённого.
 Доставленный актуальный текст повторно не ищи. Методика выбирает границы работы и
 экземпляр исполнителя; действующие планирование, проверки, независимое ревью и
-приёмка сохраняются. Права задаёт рамка: L0 назначает L1, L1 — L2; L1 не нанимает
-других L1, L2 никого не спавнит.
+приёмка сохраняются. Права задаёт рамка: ведущий (L0) сам исполняет или назначает исполнителя (L1);
+исполнитель никого не нанимает и не спавнит.
 
 ## Ограниченное поручение
 
 Нанимай на законченный по смыслу, самостоятельно принимаемый результат с явными
-критериями, входами, scope, полномочиями и бюджетом. L1 организует ограниченную
-поставку через L2; L2 выполняет конечную часть. Общие цель, thread, тема, лицо и
+критериями, входами, scope, полномочиями и бюджетом. Ведущий организует ограниченную
+поставку сам или через исполнителя; исполнитель выполняет конечную часть. Общие цель, thread, тема и
 пользовательская сессия не задают срок жизни экземпляра. Несколько связанных
 действий, проверок и исправлений могут составлять одну поставку; не создавай
 агента на файл, команду или формальный этап. Не объединяй самостоятельные
@@ -20,7 +20,7 @@
 
 | Выбор | Основание |
 | --- | --- |
-| fresh | Новый самостоятельно принимаемый результат → новый экземпляр и отобранный TASK. Это действует и для последовательной работы одного L1. |
+| fresh | Новый самостоятельно принимаемый результат → новый экземпляр и отобранный TASK. Это действует и для последовательной работы одного нанимателя. |
 | continue | Тот же непринятый результат → прежний экземпляр: ответ на вопрос, разблокировка, предусмотренная часть поставки или исправление замечаний. |
 | replace | То же поручение, но исполнитель недоступен либо контекст непригоден → новый экземпляр через wolf-handoff. |
 
@@ -32,28 +32,36 @@
 Недоступный fresh/close или наследование истории host'ом укажи как ограничение;
 не выдавай новую метку за сброс контекста и не обходи permissions.
 
+Новая самостоятельная часть работы, принятое прежнее поручение, новый scope/AC/решение,
+новое исследование, отсутствие продвижения → новый экземпляр исполнителя.
+Повторный вызов только для локальной коррекции последнего непринятого результата, если
+одновременно прежняя цель/AC/решения неизменны, работа конкретна и ограничена,
+исследование не требуется, продвижение было и сохранённый контекст даёт названное преимущество.
+После одного корректирующего возврата следующий проход всегда свежему экземпляру.
+В TASK фиксируй REUSE-основание и счётчик. «Автор», «знает проект», «удобнее» — не основания.
+
 ## Подготовка и назначение
 
 Оценка и планирование — существующие виды работы, а не четыре обязательных
 вызова перед каждым назначением. Используй уже достаточные входы и принятый план.
-Если распределение общей цели между несколькими L1 требует предметной работы,
-L0 поручает L1 подготовить план по wolf-plan. Планирующий L1 организует нужную
-помощь L2 и возвращает готовые ограниченные брифы L1, зависимости/условия запуска,
-предложения по параллельности, общий бюджет и владельца интеграции. L0 принимает
+Если распределение общей цели между несколькими исполнителями требует предметной работы,
+ведущий поручает подготовить план по wolf-plan. Планирующий исполнитель организует нужную
+помощь и возвращает готовые ограниченные брифы, зависимости/условия запуска,
+предложения по параллельности, общий бюджет и владельца интеграции. Ведущий принимает
 план по цели/полномочиям и выполняет назначения, не дописывает техническую
 декомпозицию сам. Пробел возвращает автору плана. План — отдельный результат,
 если именно планирование было поручено; его приёмка не разрешает реализацию.
-Малая понятная поставка не требует отдельного планировщика: L1 планирует свой
-мандат и назначает L2 в его пределах. Планирование не расширяет права на найм.
+Малая понятная поставка не требует отдельного планировщика: ведущий планирует свой
+мандат и назначает исполнителей в его пределах. Планирование не расширяет права на найм.
 
 Готовые независимые поручения запускай параллельно в пределах общего бюджета
 и возможностей host. Границы записи/общих ресурсов, dependencies и порядок
 интеграции должны быть известны; блокер останавливает зависимых, не остальных.
-При нескольких L1 каждый владеет своей поставкой; техническую интеграцию
-организует назначенный L1, итоговый verdict сохраняет L0/владелец. Общие plan,
+При нескольких поставках каждая принадлежит своему исполнителю; техническую интеграцию
+организует назначенный интегратор, итоговый verdict сохраняет владелец. Общие plan,
 память и иные изменяемые артефакты имеют одного назначенного писателя; изменение
-владельца проходит handoff. L0 получает краткие статусы и ссылки на версии,
-а не весь контекст планирования; подробный план ведёт назначенный L1.
+владельца проходит handoff. Владелец получает краткие статусы и ссылки на версии,
+а не весь контекст планирования; подробный план ведёт назначенный планировщик.
 
 ## Коммуникация и завершение
 
@@ -61,7 +69,7 @@ L0 поручает L1 подготовить план по wolf-plan. План
 оценки, плана или поставки выражай целью/результатом/scope существующего TASK;
 новых типов сообщений, профилей, обязательных слотов и статусов нет. Ссылки на
 поручение и входы адресные, по ID с версией; описательное обсуждение остаётся
-свободным. Сохраняй формы RESULT роли: L1 REPORT/STATUS/CRITERIA, L2 — по профилю.
+свободным. Сохраняй формы RESULT роли: организатор REPORT/STATUS/CRITERIA, исполнитель — по профилю.
 Готовность отчёта не означает приёмку, приёмка плана не означает исполнение.
 Непокрытое формой — «вне контракта» по R6; доказанное языковое затруднение —
 LANGUAGE-предмет через wolf-feedback, не самостоятельное изменение языка.

package/templates/base/skills/using-skills/references/project-rules.md

@@ -1,6 +1,6 @@
 # Документы и устройство работы проекта
 
-Загружает L0/L1 при выборе места, режима и документного профиля.
+Загружает ведущий или исполнитель при выборе места, режима и документного профиля.
 
 ## Состав документации этапа
 
@@ -13,22 +13,22 @@ pre-requirements.md — первый документ: намерение, ра
 Это отдельный документ, а не раздел «Журнал изменений (CR)» в requirements.md: журнал
 описывает изменения самих требований. Поток изменения: замечание → change-request →
 pre-requirements/requirements → design → test-plan → plan.
-Выводы подзадач L1 встраивает в нужный документ: решения — в ADR design.md,
+Выводы подзадач ведущий встраивает в нужный документ: решения — в ADR design.md,
 состояние/проверки — в plan.md/test-plan.md; значимую память ведёт штатным каналом.
-L2 по умолчанию возвращает RESULT/findings/review сообщением. Право создать файл
+Исполнитель по умолчанию возвращает RESULT/findings/review сообщением. Право создать файл
 должно содержать точный путь и назначение; разрешения на каталог недостаточно.
 Явное задание обновить основной документ допустимо в назначенном разделе.
 Итог разговора по wolf-brainstorm — pre-requirements.md в папке той же цели: это
 штатный первый документ пакета, но сам по себе он не запускает пакет и не означает
-утверждённые требования.
+утверждённые требования. Один факт имеет каноническое место; в других документах — ссылка и нужный контекст.
 
 Дополнения — единичные самостоятельные документы с пользой после этапа, например
-необходимый migration-guide или итоговое исследование. L1 до создания указывает
+необходимый migration-guide или итоговое исследование. Ведущий до создания указывает
 в существующем plan/брифе путь, читателя/назначение, причину отдельного документа
 и владельца актуальности. Сначала проверь, достаточно ли существующего раздела.
 Новый файл не требуется на каждый TASK/раунд. Ресурс документа, например схема,
 допустим при явной необходимости и точном пути в TASK. Согласованные состав и форматы
-сохраняй; меняющий scope вопрос передай L0. Отдельный реестр файлов не создавай.
+сохраняй; меняющий scope вопрос верни ведущему. Отдельный реестр файлов не создавай.
 
 Частные report-*, decisions-*, checkpoint, черновики, логи и исполняемые скрипты
 в docs/dev не размещай, в том числе в подпапке tmp/reports. Рабочие файлы — только
@@ -38,18 +38,38 @@ L2 по умолчанию возвращает RESULT/findings/review сооб
 состояние в доступном долговечном месте вне документации. Одна ссылка на tmp
 не является сохранённым evidence. Не удаляй чужие/прежние файлы автоматически.
 
+### Читаемость проектных документов
+
+Пиши для читателя, которому нужно понять, проверить, утвердить или выполнить
+описанное. Сначала обозначь назначение или результат, затем раскрой условия
+и основания. Принятую схему документа сохраняй.
+
+Самостоятельные части разделяй настоящими блоками Markdown: пустыми строками,
+абзацами, подзаголовками и списками. Один перенос строки новым абзацем не
+считать. Длинный пункт списка не заменяет структуру.
+
+CR, ADR и длинные задачи делай доступными для навигации по исходным ID и
+названиям. Независимые критерии приёмки и варианты отделяй друг от друга;
+числа, условия, исключения, статусы и основания сохраняй. Не вводи новые
+ID, обязательные секции и графику ради оформления.
+
+При назначенном редакционном проходе передай готовую версию исполнителю с
+wolf-document-readability. Не загружай полный навык писателя ради каждого
+частного ответа и не добавляй параллельную финальную редактуру. Передача
+писателю не освобождает автора от точности содержания.
+
 
 ## Новая цель и рабочий тред
 
 При запросе на реальную разработку или изменение продукта L0 сверяет существующие треды и цель. Продолжение той же цели сохраняет тред. Для новой самостоятельной цели без подходящего треда создай его поддержанным механизмом памяти, например wolf thread add с title и goal; запомни фактический ID. Не создавай тред на каждое уточнение, приветствие или вопрос о текущем состоянии.
 
-Передай L1 ID треда, цель, известные ограничения и назначенную методику. L1 фиксирует FULL/LITE/FIX до выбора документного профиля. До согласованного перехода к формализации не создавай requirements.md и downstream-шаблоны. По выбору пользователя допустим итог pre-requirements.md в папке той же цели по wolf-brainstorm; он не означает утверждение требований.
+Передай исполнителю ID треда, цель, известные ограничения и назначенную методику. Режим FULL/LITE/FIX фиксирует ведущий или наниматель до выбора документного профиля. До согласованного перехода к формализации не создавай requirements.md и downstream-шаблоны. По выбору пользователя допустим итог pre-requirements.md в папке той же цели по wolf-brainstorm; он не означает утверждение требований.
 
 В FULL исполнитель использует wolf scaffold artifact <slug>; команда создаёт пакет в docs/dev/<date>-<slug>/ в объявленном порядке (pre-requirements → requirements → change-request → design → test-plan → plan). Если папка уже есть (например, из brainstorm), команда делает top-up: добавляет только недостающие документы и не перезаписывает существующие. FIX — профиль --fix (requirements.md + plan.md), когда он подходит задаче; LITE — достаточный бриф. Ссылки на документы и принятые решения связывай с тредом существующим поддержанным способом, не придумывай поля схемы. Если инструменты памяти недоступны, обозначь ограничение и передай запись исполнителю; разговор можно продолжить, нельзя утверждать, что тред создан.
 
 
 ## Масштаб и профиль проекта
 
-FULL — несколько компонентов, новые контракты, миграции или существенные риски. LITE — локальное обратимое изменение без новых контрактов. FIX — подтверждённый дефект с воспроизведением и проверкой. Режим фиксирует L1. Соблюдай протокол ошибки масштаба: если в LITE/FIX обнаружились новые контракты, второй компонент или неочевидная причина — останови затронутое исполнение и передай L1 для пересмотра; режим меняет только L1. Сам не расширяй scope. Одобренную работу повторно не согласовывай без изменения существенных условий.
+FULL — несколько компонентов, новые контракты, миграции или существенные риски. LITE — локальное обратимое изменение без новых контрактов. FIX — подтверждённый дефект с воспроизведением и проверкой. Режим фиксирует ведущий или наниматель. Соблюдай протокол ошибки масштаба: если в LITE/FIX обнаружились новые контракты, второй компонент или неочевидная причина — останови затронутое исполнение и верни ведущему для пересмотра; режим меняет только ведущий или наниматель. Сам не расширяй scope. Одобренную работу повторно не согласовывай без изменения существенных условий.
 
 Из AGENTS.md, конфигурации, lockfile и CI определи base branch, package manager, setup, targeted/full checks, worktree policy и права на commit/push/merge. Не предполагай npm, Vitest или main. При конфликте проверь фактический CI и запроси только недостающее решение. Не создавай новую конфигурационную схему автоматически.

package/templates/base/skills/using-skills/references/project-tools.md

@@ -1,13 +1,13 @@
 # Средства проекта и карточки Wolf
 
-Загружает L1 при создании/сохранении/обновлении инструмента; L2 получает
+Загружает ведущий или исполнитель при создании/сохранении/обновлении инструмента; получает
 относящиеся нормы и точный контракт, а не весь каталог.
 
 ## Размещение и регистрация
 
 Используй принятый постоянный каталог вспомогательных средств проекта.
-Если его нет, L1 выбирает и создаёт подходящее место; при существенной
-неоднозначности L0 уточняет у пользователя. Путь фиксируется в памяти и не
+Если его нет, ведущий выбирает и создаёт подходящее место; при существенной
+неоднозначности ведущий уточняет у пользователя. Путь фиксируется в памяти и не
 согласуется заново. Каталог отделим от функциональности продукта; зависимости
 обслуживающих процедур явны. Компоненты продукта остаются в его структуре.
 
@@ -28,8 +28,8 @@ tmp допустим для одноразовой пробы. Скрипт, н
 Одной ссылки на tmp недостаточно. Разовая команда без дальнейшей ценности
 не требует упаковки или карточки.
 
-Если скрипты создавались, L2 возвращает кратко назначение/путь/проверку/нужность.
-L1 обеспечивает сохранность и регистрацию до приёмки; Git diff не видит все
+Если скрипты создавались, исполнитель возвращает кратко назначение/путь/проверку/нужность.
+Ведущий обеспечивает сохранность и регистрацию до приёмки; Git diff не видит все
 созданные в tmp средства. Оформление уже разрешённого средства — часть завершения,
 не новое согласование. Существенное расширение автоматизации — решение владельца.
 

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

@@ -5,9 +5,9 @@
 | Создание/изменение методики | writing-skills: сценарий, канон и проверка поведения | Проверенная методика и откат |
 | Подключение внешнего пакета | wolf-skill-intake: проверить источник/revision и scope | Проверенная доступная методика |
 | Повторяемая техническая операция | [Библиотека проекта](project-tools.md): найти аналог, создать при необходимости | Инструмент и карточка |
-| Дефект действующего правила | wolf-feedback: W1–W4, complaint, действующий триаж | Основание коррекции Стюардом |
+| Дефект действующего правила | wolf-feedback: W1–W4, complaint, действующий триаж | Основание коррекции методики |
 
-Новая помощь собирается L1 из L2, подходящего лица, скиллов и доступных средств.
+Ведущий собирает помощь из исполнителей, скиллов и доступных средств.
 Скрипт обслуживает повторяемую механику, не является обязательной формой
 помощника. Рабочие записи не становятся автоматически уроками или жалобами.
-Локальная мутация Стюарда не становится глобальным шаблоном без своей проверки.
+Локальное изменение методики по решению владельца не становится глобальным шаблоном без своей проверки.