mister-wolf 2.21.2 → 2.22.1

package/README.md

@@ -51,10 +51,10 @@ wolf bootstrap
 ```
 
 - **Path A — memory:** `wolf init` connects the project minimally — the `.wolf/` skeleton and `AGENTS.md`; it writes no platform configs and no base set. What a clean run prints: `memory skeleton: ensured`, `base set: AGENTS.md created`, the init-report id.
-- **Path B — OpenCode organization:** `wolf init --full --platform opencode` renders the full base set (6 agent frames, 19 skills, 3 commands, 2 plugins, seeded playbook faces) and writes `opencode.json` (`mcp.servers.wolf`, `default_agent=mr-wolf`, `experimental.subagent_depth=2`). **Restart opencode** after it — the MCP server and the default agent connect at startup. Claude Code will ask you to approve the project-scope MCP server on first start — that is expected.
+- **Path B — OpenCode organization:** `wolf init --full --platform opencode` renders the full base set (6 agent frames, 20 skills, 3 commands, 2 plugins, seeded playbook faces) and writes `opencode.json` (`mcp.servers.wolf`, `default_agent=mr-wolf`, `experimental.subagent_depth=2`). **Restart opencode** after it — the MCP server and the default agent connect at startup. Claude Code will ask you to approve the project-scope MCP server on first start — that is expected.
 
 - **Try it without installing:** `npx mister-wolf init` — try-out mode: creates the `.wolf/` memory skeleton but never writes MCP configs or the base set. Like it? `npm install -g mister-wolf` and run `wolf init` again.
-- **Updating:** `wolf upgrade` — one command updates everything: the npm phase (`npm install -g mister-wolf@latest`) is followed by the update pass over all registered projects (stamped base-set files and seeded faces; deletions only with confirmation). `--check` reports CLI + park freshness without installing; `--here` updates only the current project (no npm, no registry); `--yes` skips the confirmation and backs up whatever it overwrites. Dev/linked installs are refused honestly. `wolf sync` is deprecated → `wolf upgrade --here` (still available in 2.20.0).
+- **Updating:** `wolf upgrade` — one command updates everything: the npm phase (`npm install -g mister-wolf@latest`) is followed by the update pass over all registered projects (stamped base-set files and seeded faces; deletions only with confirmation). `--check` reports CLI + park freshness without installing; `--here` updates only the current project (no npm, no registry); `--yes` skips the confirmation and backs up whatever it overwrites. Dev/linked installs are refused honestly. `wolf sync` is deprecated → `wolf upgrade --here` (the alias still works and re-renders stamped files; its DEPRECATED notice still says `removed in 2.20.0` — stale wording, the command is alive).
 - **Owner intent (2.20.0):** when a pass needs your word, it names the file and the reason (`mutated` / `conflict`, per path — no bare counters). `--review` walks the decisions with a diff, `--show <file|N>` prints local vs base, `--resolve <file|N>=take|keep|protect|pin` applies one, `--json` is the machine channel (`wolf.upgrade/1`, and `wolf.upgrade.check/1` with `--check`). `protect: true` (or `protect: X.Y.Z`) in an agent/skill/command frontmatter holds that file forever — never overwritten, never deleted, still visible in `--check`. A local conflict, start to finish:
 
   ```bash

package/README.ru.md

@@ -53,7 +53,7 @@ wolf bootstrap
 ```
 
 - **Путь А — память:** `wolf init` подключает проект минимально — скелет `.wolf/` и `AGENTS.md`; платформенные конфиги и базовый сет он не пишет. Что печатает чистый запуск: `memory skeleton: ensured`, `base set: AGENTS.md created`, id init-отчёта.
-- **Путь Б — организация OpenCode:** `wolf init --full --platform opencode` отрисовывает полный базовый набор (6 рамок агентов, 19 скиллов, 3 команды, 2 плагина, посев playbook-лиц) и пишет `opencode.json` (`mcp.servers.wolf`, `default_agent=mr-wolf`, `experimental.subagent_depth=2`). После него **перезапусти opencode** — MCP-сервер и агент по умолчанию подключаются при старте. Claude Code при первом старте попросит approve project-scope MCP-сервер — это штатно.
+- **Путь Б — организация OpenCode:** `wolf init --full --platform opencode` отрисовывает полный базовый набор (6 рамок агентов, 20 скиллов, 3 команды, 2 плагина, посев playbook-лиц) и пишет `opencode.json` (`mcp.servers.wolf`, `default_agent=mr-wolf`, `experimental.subagent_depth=2`). После него **перезапусти opencode** — MCP-сервер и агент по умолчанию подключаются при старте. Claude Code при первом старте попросит approve project-scope MCP-сервер — это штатно.
 
 - **Попробовать без установки:** `npx mister-wolf init` — try-out-режим: создаёт скелет памяти `.wolf/`, но никогда не пишет ни MCP-конфиги, ни базовый сет. Понравилось — `npm install -g mister-wolf` и повтори `wolf init`.
 - **Обновление:** `wolf upgrade` — одна команда обновляет всё: npm-фаза
@@ -62,7 +62,8 @@ wolf bootstrap
   `--check` — read-only сводка свежести CLI и парка; `--here` — обновить только текущий проект
   (без npm и реестра); `--yes` — без интерактивного подтверждения, с бэкапом всего, что
   перезаписывает. Dev/linked-установке откажет честно. `wolf sync` депрекирован →
-  `wolf upgrade --here` (алиас ещё работает в 2.20.0).
+  `wolf upgrade --here` (алиас ещё работает и перерендеривает штампованные файлы; его уведомление
+  DEPRECATED всё ещё говорит `removed in 2.20.0` — устаревшая формулировка, команда жива).
 - **Намерения владельца (2.20.0):** когда проходу нужно ваше слово, он называет файл и причину
   (`mutated` / `conflict`, по путям — без голых счётчиков). `--review` разбирает решения с диффом,
   `--show <файл|N>` печатает локальный vs эталон, `--resolve <файл|N>=take|keep|protect|pin`

package/dist/app/use-cases/gitignore-block.d.ts

@@ -1,6 +1,6 @@
 export declare const GITIGNORE_MARKER = "# wolf-gitignore:v1";
-/** WP4 (спека §7): игнорировать машинно-локальное, коммитить память —
- * формула переноса 2.14 §8.3 («память коммитится — клонирование переносит»). */
+/** WP4 (спека §7): состояние Wolf машинно-локальное — память (.wolf/memory)
+ * не коммитится и на другой машине не восстанавливается. */
 export declare function buildGitignoreBlock(): string;
 export type GitignoreOutcome = 'created' | 'appended' | 'kept';
 export declare function ensureGitignoreBlock(deps: {

package/dist/app/use-cases/gitignore-block.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"gitignore-block.d.ts","sourceRoot":"","sources":["../../../src/app/use-cases/gitignore-block.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,gBAAgB,wBAAwB,CAAC;AAEtD;gFACgF;AAChF,wBAAgB,mBAAmB,IAAI,MAAM,CAU5C;AAED,MAAM,MAAM,gBAAgB,GAAG,SAAS,GAAG,UAAU,GAAG,MAAM,CAAC;AAE/D,wBAAsB,oBAAoB,CACxC,IAAI,EAAE;IACJ,MAAM,EAAE,CAAC,CAAC,EAAE,MAAM,KAAK,OAAO,CAAC,OAAO,CAAC,CAAC;IACxC,QAAQ,EAAE,CAAC,CAAC,EAAE,MAAM,KAAK,OAAO,CAAC,MAAM,GAAG,IAAI,CAAC,CAAC;IAChD,SAAS,EAAE,CAAC,CAAC,EAAE,MAAM,EAAE,CAAC,EAAE,MAAM,KAAK,OAAO,CAAC,IAAI,CAAC,CAAC;CACpD,EACD,OAAO,EAAE,MAAM,GACd,OAAO,CAAC,gBAAgB,CAAC,CAW3B"}
+{"version":3,"file":"gitignore-block.d.ts","sourceRoot":"","sources":["../../../src/app/use-cases/gitignore-block.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,gBAAgB,wBAAwB,CAAC;AAEtD;4DAC4D;AAC5D,wBAAgB,mBAAmB,IAAI,MAAM,CAU5C;AAED,MAAM,MAAM,gBAAgB,GAAG,SAAS,GAAG,UAAU,GAAG,MAAM,CAAC;AAE/D,wBAAsB,oBAAoB,CACxC,IAAI,EAAE;IACJ,MAAM,EAAE,CAAC,CAAC,EAAE,MAAM,KAAK,OAAO,CAAC,OAAO,CAAC,CAAC;IACxC,QAAQ,EAAE,CAAC,CAAC,EAAE,MAAM,KAAK,OAAO,CAAC,MAAM,GAAG,IAAI,CAAC,CAAC;IAChD,SAAS,EAAE,CAAC,CAAC,EAAE,MAAM,EAAE,CAAC,EAAE,MAAM,KAAK,OAAO,CAAC,IAAI,CAAC,CAAC;CACpD,EACD,OAAO,EAAE,MAAM,GACd,OAAO,CAAC,gBAAgB,CAAC,CAW3B"}

package/dist/app/use-cases/gitignore-block.js

@@ -1,11 +1,11 @@
 import { join } from 'path';
 export const GITIGNORE_MARKER = '# wolf-gitignore:v1';
-/** WP4 (спека §7): игнорировать машинно-локальное, коммитить память —
- * формула переноса 2.14 §8.3 («память коммитится — клонирование переносит»). */
+/** WP4 (спека §7): состояние Wolf машинно-локальное — память (.wolf/memory)
+ * не коммитится и на другой машине не восстанавливается. */
 export function buildGitignoreBlock() {
     return [
         GITIGNORE_MARKER,
-        '# wolf: machine-local state; .wolf/memory is portable — commit it',
+        '# wolf: machine-local state; .wolf/memory is NOT committed and is not restored on another machine',
         '.wolf/cache/',
         '.wolf/memory/.lock',
         '.wolf/backup/',

package/dist/app/use-cases/gitignore-block.js.map

@@ -1 +1 @@
-{"version":3,"file":"gitignore-block.js","sourceRoot":"","sources":["../../../src/app/use-cases/gitignore-block.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,IAAI,EAAE,MAAM,MAAM,CAAC;AAE5B,MAAM,CAAC,MAAM,gBAAgB,GAAG,qBAAqB,CAAC;AAEtD;gFACgF;AAChF,MAAM,UAAU,mBAAmB;IACjC,OAAO;QACL,gBAAgB;QAChB,mEAAmE;QACnE,cAAc;QACd,oBAAoB;QACpB,eAAe;QACf,sBAAsB;QACtB,EAAE;KACH,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AACf,CAAC;AAID,MAAM,CAAC,KAAK,UAAU,oBAAoB,CACxC,IAIC,EACD,OAAe;IAEf,MAAM,CAAC,GAAG,IAAI,CAAC,OAAO,EAAE,YAAY,CAAC,CAAC;IACtC,MAAM,OAAO,GAAG,CAAC,MAAM,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,MAAM,IAAI,CAAC,QAAQ,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC;IACvE,IAAI,OAAO,KAAK,IAAI,EAAE,CAAC;QACrB,MAAM,IAAI,CAAC,SAAS,CAAC,CAAC,EAAE,GAAG,mBAAmB,EAAE,IAAI,CAAC,CAAC;QACtD,OAAO,SAAS,CAAC;IACnB,CAAC;IACD,IAAI,OAAO,CAAC,QAAQ,CAAC,gBAAgB,CAAC;QAAE,OAAO,MAAM,CAAC;IACtD,MAAM,GAAG,GAAG,OAAO,CAAC,QAAQ,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,OAAO,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,MAAM,CAAC;IACnF,MAAM,IAAI,CAAC,SAAS,CAAC,CAAC,EAAE,GAAG,OAAO,GAAG,GAAG,GAAG,mBAAmB,EAAE,EAAE,CAAC,CAAC;IACpE,OAAO,UAAU,CAAC;AACpB,CAAC"}
+{"version":3,"file":"gitignore-block.js","sourceRoot":"","sources":["../../../src/app/use-cases/gitignore-block.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,IAAI,EAAE,MAAM,MAAM,CAAC;AAE5B,MAAM,CAAC,MAAM,gBAAgB,GAAG,qBAAqB,CAAC;AAEtD;4DAC4D;AAC5D,MAAM,UAAU,mBAAmB;IACjC,OAAO;QACL,gBAAgB;QAChB,mGAAmG;QACnG,cAAc;QACd,oBAAoB;QACpB,eAAe;QACf,sBAAsB;QACtB,EAAE;KACH,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AACf,CAAC;AAID,MAAM,CAAC,KAAK,UAAU,oBAAoB,CACxC,IAIC,EACD,OAAe;IAEf,MAAM,CAAC,GAAG,IAAI,CAAC,OAAO,EAAE,YAAY,CAAC,CAAC;IACtC,MAAM,OAAO,GAAG,CAAC,MAAM,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,MAAM,IAAI,CAAC,QAAQ,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC;IACvE,IAAI,OAAO,KAAK,IAAI,EAAE,CAAC;QACrB,MAAM,IAAI,CAAC,SAAS,CAAC,CAAC,EAAE,GAAG,mBAAmB,EAAE,IAAI,CAAC,CAAC;QACtD,OAAO,SAAS,CAAC;IACnB,CAAC;IACD,IAAI,OAAO,CAAC,QAAQ,CAAC,gBAAgB,CAAC;QAAE,OAAO,MAAM,CAAC;IACtD,MAAM,GAAG,GAAG,OAAO,CAAC,QAAQ,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,OAAO,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,MAAM,CAAC;IACnF,MAAM,IAAI,CAAC,SAAS,CAAC,CAAC,EAAE,GAAG,OAAO,GAAG,GAAG,GAAG,mBAAmB,EAAE,EAAE,CAAC,CAAC;IACpE,OAAO,UAAU,CAAC;AACpB,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mister-wolf",
-  "version": "2.21.2",
+  "version": "2.22.1",
   "description": "Local-first project memory for AI coding agents: decisions, lessons, tools and processes that outlive the session",
   "keywords": [
     "ai-agents",
@@ -28,7 +28,7 @@
     "update-map.json"
   ],
   "scripts": {
-    "build": "tsc",
+    "build": "rm -rf dist && tsc",
     "dev": "tsc --watch",
     "test": "vitest",
     "test:run": "vitest run",
@@ -41,7 +41,7 @@
     "bench:tokens": "node --disable-warning=ExperimentalWarning scripts/bench-tokens.mjs",
     "check": "node scripts/check-english-surface.mjs && npm run format:check && npm run lint && npm run build && npm run test:run",
     "docs:dev": "vitepress dev docs/site",
-    "docs:build": "node scripts/generate-cli-reference.mjs && node scripts/sync-changelog.mjs && vitepress build docs/site",
+    "docs:build": "node scripts/generate-cli-reference.mjs && node scripts/generate-cli-site-page.mjs && node scripts/sync-changelog.mjs && vitepress build docs/site",
     "docs:preview": "vitepress preview docs/site"
   },
   "dependencies": {

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

@@ -144,6 +144,60 @@ handoff; не маскируй отказ памяти файлом в доку
 - Самообучение: значимые ошибки/удачи воркеров — `wolf add --type
   lesson` (только нетривиальное и воспроизводимое).
 
+### Выбор сеанса: fresh / continue / replace
+
+Правило действует только после решения делегировать. Малая связанная работа остаётся
+у L1 и не создаёт обязательного L2/исследователя; требуемую независимую приёмку
+выполняет другой уполномоченный участник, self-review независимой приёмкой не является.
+Ядро и профиль поручения — по канону using-skills.
+
+- **fresh** — новый самостоятельный принимаемый результат → новый L2 и отобранный под
+  него TASK.
+- **continue** — тот же ещё не принятый результат → прежний L2: уточнение, следующий
+  связанный этап, дополнительное evidence, ограниченное исправление по приёмке.
+- **replace** — та же задача, прежнее исполнение больше не подходит → новый L2 через
+  handoff (порядок ниже).
+
+Инварианты:
+
+1. `task_id` — идентификатор задачи, не id сеанса; совпадение имён параметров инструмента
+   не делает их равными.
+2. `continue` не расширяет scope: новые самостоятельные требования не добавляются под
+   видом исправления, несвязанная задача не дробится после каждого шага.
+3. `DONE` не закрывает задачу: после ACCEPTED прежний L2 не становится свободным слотом
+   под следующую задачу.
+4. Правило не создаёт исследователя или агента на файл: малая связанная работа остаётся
+   у L1, независимая приёмка — у другого уполномоченного участника.
+5. Первичное независимое review получает проверяемые материалы, нормы и evidence, но не
+   историю родителя, не чужие findings и не ожидаемый verdict; повторная проверка
+   исправлений своих замечаний тем же reviewer допустима.
+6. При замене model/variant resume не доказывает смену модели; неподдержанная в resume
+   смена → новый исполнитель.
+7. Новый id сеанса не доказывает чистую изоляцию: если host наследует историю родителя,
+   независимость не закрыта — результат остаётся `INCONCLUSIVE` либо ограниченным;
+   честный отчёт о возможностях host ≠ успешная независимая приёмка.
+8. Незавершённая приёмка при замене не обнуляется: известный результат и открытые
+   замечания передаются через handoff. Учёт фактических расходов — A1.1/E2; без связей
+   результат помечается «неизвестно с покрытием», не нулём.
+
+### Порядок replace
+
+Четыре различимых шага; `1` и `4` — не одно действие.
+
+1. **stop-writing** — прекратить новые изменения и подтвердить завершение пишущих
+   инструментов прежнего исполнителя.
+2. **preserve** — уполномоченный владелец/L1 сохраняет известный результат и handoff,
+   выполняет требуемую публикацию. L2 без права коммита отдаёт checkpoint L1; L1
+   фиксирует его после прекращения записи.
+3. **hand-over** — получатель проверяет доступность результата и принимает ownership;
+   при неопределённости передача той же ветки не завершена.
+4. **close** — прежняя сессия закрывается после сохранения нужного контекста.
+
+Инварианты порядка: таймаут, молчание и истёкший бюджет не доказывают остановку записи;
+read-only review не требует нового worktree; task identity, evidence, права и действующая
+политика model/variant сохраняются; незавершённая приёмка и известный результат не
+обнуляются.
+
 ## Библиотека регулярных средств
 
 Перед повторяющейся процедурой или обходом известного трения проверь готовое

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

@@ -200,12 +200,62 @@ FULL — несколько компонентов, новые контракт
 
 ## Контракты передачи
 
+### Ядро TASK
+
+Ядро обязательно для любого поручения; каждый пункт — проверяемое предписание,
+а не перечисление через запятую. Профиль (ниже) добавляет к ядру, не заменяет его.
+
+- `task_id` — идентификатор подзадачи, отличный от id сеанса; по нему сверяются отчёт
+  и evidence.
+- Цель/ожидаемый результат — что должно быть на выходе, одной проверяемой формулировкой.
+- AC — приёмочные критерии, по каждому из которых можно сказать «подтверждено» или нет.
+- Scope и полномочия — что входит в работу, что запрещено (запись, спавн, коммиты),
+  где вести рабочие материалы.
+- Входы и назначенная методика — какие нормы и файлы читать и каким процессом
+  исполнять; недостающий обязательный вход запрашивается, не додумывается.
+- Проверка — точные команды или процедуры и ожидаемый результат; запускает исполнитель.
+- Конечный бюджет и stop/return — лимит работы и условия немедленного возврата L1.
+- Ожидаемый RESULT — форма отчёта по роли, включая допустимые статусы и вердикты.
+
+Инварианты ядра: применимое ядерное поле нельзя опустить; неизвестный обязательный
+вход явно запрашивается (`NEEDS_CONTEXT`), не заполняется заглушкой. Опускание
+неприменимого профильного поля — не дефект поручения.
+
+### Профили поручения
+
+Профиль `implement | review | research` добавляет поля к ядру. Неприменимое поле
+опускается, а не заполняется заглушкой; поручение без такого поля корректно.
+
+- `implement` добавляет: repo/workspace, `base_sha`, allowlist записи, разрешённые
+  области чтения, зависимости, ссылки на design/test-plan. Из ядра не опускает ничего.
+  RESULT: `DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED`.
+- `review` добавляет: revision проверяемого артефакта, назначенную линзу, норму
+  и evidence-набор. Не требует `base_sha`, allowlist записи, worktree.
+  RESULT: `SUMMARY/VERDICT/FINDINGS/SCOPE/LIMITS/EVIDENCE`; вердикты
+  `APPROVED | CHANGES_REQUIRED | INCONCLUSIVE`.
+- `research` добавляет: проверяемый вопрос, критерий ответа, revision документа или
+  источника, границы поиска и условие остановки. Не требует `base_sha`, allowlist записи.
+  RESULT: `FINDINGS/CONFIDENCE/GAPS` с разделением источника, факта, вывода и гипотезы.
+
+Формат передачи по умолчанию — сообщение; точные разрешённые выходные файлы, если они
+нужны, и место временной работы вне документации указывает L1. Ответственность
+за общий план и покрытие остаётся у L1.
+
+### Словарь контрактов
+
+Термины определены статически; определения не описывают поведение механизмов
+и не ссылаются на команды или поля, которых нет. Ниже таблицы — действующие формы
+`RESULT`/`EVIDENCE`/`ACCEPTANCE`: они подробны, таблица даёт только смысл термина.
+
+| Термин | Значение |
+| --- | --- |
+| TASK | Поручение исполнителю: ядро из восьми элементов плюс поля применимого профиля. |
+| RESULT | Отчёт исполнителя по форме своей роли: статус или вердикт, изменения, границы. |
+| EVIDENCE | Подтверждение claim/AC: команда или процедура, cwd, revision, exit, результат. |
+| ACCEPTANCE | Сверка каждого AC с evidence и итоговый verdict приёмки у L0. |
+| SCOPE | Границы задачи: что входит и что запрещено. В отчёте worker-reviewer `SCOPE` — покрытие ревью, не границы задачи. |
+| LIMITS/GAPS | Что не проверено, где нет данных или остался риск; отсутствие данных не равно нулю или успеху. |
 
-TASK: task_id, цель, AC/REQ, base_sha, cwd/worktree, allowlist записи, разрешённые области чтения, зависимости, ссылки на design/test-plan, проверки, ограничения, ожидаемый отчёт. Для L2: один конечный результат,
-способ/границы допустимого поиска, конечный лимит и точный триггер возврата L1;
-формат передачи (по умолчанию сообщение), точные разрешённые выходные файлы,
-если нужны, и место временной работы вне документации;
-ответственность за общий план и покрытие остаётся у L1.
 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.

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

@@ -14,7 +14,7 @@ description: "Применять перед сменой сессии или и
 
 ## Выбор действия
 
-Различай: продолжение той же роли в новой сессии, замена исполнителя и новая подзадача. L0 передаёт цель преемнику L0 либо поручает L1 поставку; L1 заменяет L2/исполнительскую сессию; L2 возвращает checkpoint и запрос L1. L2 не спавнит преемника. Указание tool.task не гарантирует сброс контекста родителя — проверь возможности платформы.
+Различай: продолжение той же роли в новой сессии, замена исполнителя и новая подзадача. L0 передаёт цель преемнику L0 либо поручает L1 поставку; L1 заменяет L2/исполнительскую сессию (порядок замены и выбор сеанса — по канону executor-lead); L2 возвращает checkpoint и запрос L1. L2 не спавнит преемника. Указание tool.task не гарантирует сброс контекста родителя — проверь возможности платформы.
 
 ## Snapshot
 
@@ -40,7 +40,7 @@ Snapshot не становится проектным документом ав
 
 1. Зафиксируй snapshot revision и место. При недоступной записи L2 передаёт его L1, не обходит permissions.
 2. Действующим механизмом останови или отзови право записи старого исполнителя; проверь незавершённые инструменты/процессы. При неизвестном исходе сначала выясни состояние.
-3. L1/L0 передаёт преемнику TASK, snapshot и доступные источники. Если технической блокировки нет, установи протокольного единственного владельца и явно обозначь ограничение.
+3. L1/L0 передаёт преемнику TASK (по канону ядра и профилю поручения в using-skills), snapshot и доступные источники. Если технической блокировки нет, установи протокольного единственного владельца и явно обозначь ограничение.
 4. Преемник подтверждает цель, revision, dirty-state и следующий шаг; сверяет память/план с фактом. Несовпадение → NEEDS_CONTEXT, не слепое продолжение.
 5. Только после подтверждения отметь передачу завершённой и сообщи ответственному уровню ID/статус.
 

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

@@ -20,7 +20,7 @@ description: "Применять перед декомпозицией утве
 
 1. Проверь версии входов. Отнеси каждый REQ/NFR к задаче и проверке; зафиксируй пробелы до исполнения.
 2. Раздели работу по результатам и ответственности. Размер задачи определяется независимой проверкой и доступным контекстом, а не обязательными 2–5 минутами.
-3. Для каждой задачи заполни TASK из using-skills: цель, AC, baseline, ссылки на контракт, allowlist, зависимости, проверки, ограничение scope и ожидаемый RESULT. Разреши читать затронутый код и потребителей; отсутствие истории сессии не означает запрета чтения.
+3. Для каждой задачи заполни TASK из using-skills по канону ядра и профилю поручения; перечень полей не дублируй, сошлись на канон. Разреши читать затронутый код и потребителей; отсутствие истории сессии не означает запрета чтения.
 4. Укажи достаточно точные действия и символы, не полный код реализации. Примеры допустимы для неоднозначного контракта, но не дублируют design. Не предписывай точный код теста вместо проверяемого свойства.
 5. Построй зависимости. Параллельность разреши только для независимых outputs, изолированной записи и определённого владельца интеграции. Общие контракты и миграции сериализуй.
 6. Для выходов TASK укажи сообщение либо точный файл/раздел; временную область назначь вне документации. Дополнительному документу этапа задай назначение, читателя и владельца прямо в plan, без отдельного реестра. Добавь отдельную интеграционную задачу: порядок объединения, проверка взаимодействий, полный гейт и правила разрешения конфликтов. Укажи промежуточные чекпоинты для длительной работы.

package/templates/base/skills/wolf-release-docs/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: wolf-release-docs
+description: "Применять при подготовке любой новой версии Wolf к выпуску, обновлении README или сайта для релиза, проверке готовности документации перед публикацией, а также после изменения состава выпуска или поведения документируемой возможности."
+---
+
+# Документация Wolf перед выпуском
+
+## Обязательный вход и ответственность
+
+Загрузи этот скилл до планирования и редактирования документации выпуска. Применяй к major/minor/patch: объём зависит от изменений, но проверка актуальности и полезности обязательна. Обычный feature-PR без подготовки выпуска не требует полного релизного прохода; изменённое поведение всё равно документируется в своей задаче. После изменения состава выпуска перепроверь затронутые страницы и примеры.
+
+L0 задаёт цель выпуска и принимает пакет документации; сам не пишет файлы и не запускает проверки. L1 ведёт план, назначает авторов и независимое ревью, интегрирует изменения. L2 получает конкретные страницы, источники, allowlist и критерии. Общие README, концепт и навигация имеют одного владельца записи. Скилл не разрешает публикацию npm, тег, деплой, коммит или изменение утверждённой концепции сверх действующего поручения.
+
+Цель — актуальная, связная и всё более полезная документация. Читатель понимает назначение Wolf, пользу возможностей, устройство, действия, ограничения и способ проверить результат. Число страниц, строк и новых методов не является мерой качества. Исправление устаревшего текста, ясная схема и удачный пример могут быть лучше нового раздела.
+
+## Основания и карта покрытия
+
+1. Зафиксируй текущий и целевой полный X.Y.Z, предыдущую базу выпуска, проверяемый SHA/dirty-state, состав изменений, утверждённые решения и известные ограничения. Сверь diff, код, тесты, CLI help и артефакты приёмки. CHANGELOG и отчёт автора — указатели, а не доказательства поведения. Не редактируй под неподтверждённый номер версии; соблюдай maintainer-only правила версионирования проекта.
+2. Прочитай AGENTS.md, CONTRIBUTING.md, docs/README.md и правила языков/генерации. На каждом выпуске сделай сквозной обзор опорных страниц, даже если release diff их не затрагивает. Остальные страницы проверяй по влиянию изменений, ссылкам и накопленным пробелам — не перечитывай весь архив вместо полезной работы.
+3. Создай в существующем плане или отчёте карту: возможность/утверждение → адресат → страницы → источник поведения/статуса → пример → проверка → действие автора. Отметь новые, изменённые, сохранённые и устаревшие утверждения. Путь назначения и неизменённые страницы должны иметь основание, не формальное «проверено всё».
+
+| Опорная поверхность | Что проверить и развить |
+| --- | --- |
+| README.md / README.ru.md | Что такое Wolf, для кого, пользу, рабочий пример, установку/обновление, ограничения, ссылки. Обновляй пару согласованно |
+| Главная docs/site | Обещания, статусы, первая команда, ожидание результата, версия, ссылки. Найди реальные компоненты главной, не предполагай один index.md |
+| getting-started / configuration / mcp | Память против полного агентского набора, платформенные флаги, prerequisites, первый диалог, ожидаемый результат и восстановление |
+| organization / memory / delivery / feedback / base-set | Роли, потоки, типы, версии лиц, скиллы, обучение и ограничения; связь возможностей в целый сценарий |
+| CLI/API и docs/reference/cli.md | Точные команды, поля, дефолты, ошибки; справочник дополняется сценариями в руководстве |
+| docs/concept/{concept,maturity,evidence,coverage}.md | Канон, объяснение принципов, фактическая зрелость, сила доказательств и смысловое покрытие |
+| artifact-pipeline / troubleshooting / upgrade | Шаблоны документов, реальные маршруты, совместимость, миграции, типичные проблемы и безопасные действия |
+| CHANGELOG / release notes / docs/dev | Пользовательский эффект, миграции, открытые риски и итоговый статус. Журнал событий сохраняй; финальная сводка отражает факт |
+
+Используй реальные существующие пути и EN/RU пары. Служебный отчёт не заменяет пользовательское руководство, а README не становится копией подробного справочника.
+
+## Сбалансированное развитие содержания
+
+4. Проверь четыре опоры Wolf: постоянная организация, непрерывность состояния, накопленные способности и управляемое обучение. Новая команда должна быть объяснена в связи с одной или несколькими опорами. Не развивай только CLI, пока роль Стюарда, границы памяти или путь пользователя остаются непонятными.
+5. Выбери существенные пробелы читателя: вопросы пользователя, повторные пояснения, жалобы, недокументированные ограничения, оборванный сценарий или противоречие страниц. Если таких данных нет, проверь сценарий нового пользователя и обновление существующего проекта; не выдумывай статистику обращений. Закрой выбранные пробелы в этом проходе, сохрани остальные с приоритетом в существующем backlog.
+6. Для каждой новой или существенно изменённой возможности обеспечь объяснение достаточной глубины: какую проблему решает; кому и когда нужна; как связана с остальным Wolf; как пользоваться; какой результат увидеть; чего она не гарантирует; как продолжить при ошибке. Распределяй материал между страницами, не повторяй полный набор на каждой.
+7. Добавь воспроизводимый основной пример и существенный пограничный/ошибочный сценарий там, где поведение неочевидно. Для нового workflow покажи путь целиком, а не только вызов нового API. Для небольшой локальной правки можно актуализировать существующий пример вместо добавления нового. Поведение, настройки и результаты в примере должны соответствовать версии.
+8. Углубляй объяснение концепции через связи, инварианты, причины выбора и реальные случаи. Уточнение формулировки или пример, сохраняющие утверждённый смысл, — обычная редактура. Изменение целей, ролей, полномочий, гарантий или самой модели — продуктовая правка: оформи CR и нужное согласование через L0. Не переписывай канон вслед за каждым implementation detail; текущая зрелость живёт в maturity/evidence.
+
+Перед завершением каждого выпуска сравни понимание читателя до/после: какой сценарий теперь можно пройти, какой термин или причинная связь стали яснее, какой пробел закрыт. Для срочного hotfix актуальность и инструкции обновления обязательны; несвязанный большой учебный материал можно отложить с конкретным основанием. Не задерживай исправление аварии ради искусственного объёма документации. Для выпуска без содержательных пробелов явно зафиксируй проверку и результат — не добавляй воду ради нормы прироста.
+
+## Образец полезного объяснения
+
+Слабый вариант: «Добавлены face new, restore, breakglass».
+
+Содержательный материал объясняет: поведение агента хранится отдельным версионируемым лицом; причина и границы мутации видны в истории; владельцу доступен откат. Затем показывает разрешённое изменение, просмотр версии, границу её применения и сценарий восстановления. Отдельно уточняет: история версий сама по себе не доказывает улучшение поведения. Команды и поля бери из текущего CLI; этот пример — структура объяснения, не обещание всех гарантий конкретной версии.
+
+Другой пример: если init минимальный по умолчанию, недостаточно записать «появился --full». Покажи отдельно подключение памяти и развёртывание организации агентов, укажи платформу, результат первого запуска и следующий шаг. Проверь одинаковый смысл в README, главной и getting-started.
+
+## Примеры и точность
+
+9. У полноценного примера есть цель, исходное состояние, prerequisites/версия/роль, команды или шаги, наблюдаемый результат и важное ограничение. При необходимости добавь следующий шаг и безопасный cleanup. Используй осмысленную сквозную задачу; заменители вроде <id> поясни и покажи, откуда брать значение.
+10. Запускай подходящие примеры в изолированной фикстуре нужной версии; у linked worktree проверь общий memory root — он не гарантирует изоляцию памяти. Не изменяй live-проект, секреты, публикации и внешние сервисы ради документации. Опасные или недоступные внешние действия описывай с условиями и явным статусом проверки. Ожидаемый иллюстративный вывод пометь как ожидаемый; не выдавай его за фактический trace.
+11. Не превращай fallback в основной успешный сценарий. Отделяй загрузку инструкции от её применения, сохранение от доставки/обработки, PR от merge/публикации, lock от транзакции, локальные тесты от реального поведения модели. Нормативное правило в скилле не доказывает enforcement в коде. «Работает», «спроектировано», «экспериментально» и «подтверждён эффект» имеют разные основания.
+12. Проверь дефолты и отсутствующие флаги, области памяти, actor/permissions, процессы/сессии, повторные вызовы, partial failure и совместимость. Проблема кода не исправляется красивым обещанием: передай дефект через wolf-debug/действующий процесс, ослабь утверждение до подтверждённого уровня. Не расширяй реализацию скрыто в задаче документации.
+
+## Редактура и структура
+
+Пиши языком адресата: сначала смысл и полезное действие, затем устройство и детали. Объясняй термин до дальнейшего использования, сохраняй точные имена команд/полей. Применяй принципы wolf-explain к пользовательским пояснениям; не переноси в руководство внутренний отчёт RESULT/EVIDENCE.
+
+Разделяй начало работы, руководство по задачам, объяснение принципов и точный справочник. Ссылки соединяют уровни. Пример команды не заменяет объяснения причин; абстрактная концепция не заменяет инструкции. Для взаимодействующих частей используй компактную схему, когда она точнее прозы; она отражает реализованную или явно отмеченную проектную модель.
+
+Убирай дубли, устаревшие инструкции и служебный сленг, но сохраняй полезные объяснения и причины ограничений. Не вырезай длинный пример только ради краткости. Новый раздел нужен для реальной задачи читателя, а не для каждого нового файла. Оглавления и навигация должны помогать найти следующий ответ; проверь ссылки между страницами.
+
+## Генерация и согласование языков
+
+13. Не правь вручную generated-справочник и зеркала CHANGELOG. В Wolf scripts/generate-cli-reference.mjs строит CLI reference из собранного реестра; scripts/sync-changelog.mjs обновляет страницы истории; npm run docs:build вызывает их и VitePress. Сначала убедись, что dist относится к проверяемому коду: наличия старого dist недостаточно. Проверь текущие scripts и marker-правила, если они изменились.
+14. Согласуй README EN/RU и смысловые пары страниц сайта: команды, дефолты, статусы и ограничения должны совпадать. Соблюдай язык product-facing документов и локализованных страниц. Не требуй буквального одинакового объёма перевода, но не оставляй одну аудиторию без новой существенной инструкции. Генератор может намеренно сохранять английский CHANGELOG на русском сайте — не создавай ручной расходящийся перевод без решения.
+
+## Проверка и независимое ревью
+
+15. Выполни релевантные проверки профиля проекта: форматирование, ссылки/навигация, примеры, generated consistency, сборка документации и предусмотренные release checks. Сборка сайта подтверждает сборку, но не смысл. Само создание HTML не означает деплой; содержимое опубликованного сайта проверяется после отдельно разрешённого деплоя.
+16. Независимому reviewer передай документы, diff, версию, основания утверждений, карту покрытия и сырые результаты примеров. Назначь два мандата: фактическое соответствие продукту и полезность для читателя. Для малой задачи один независимый reviewer может выполнить оба явно; не нужен отдельный агент для каждой страницы. При отсутствии независимого канала обозначь ограничение, не имитируй второй голос.
+17. Ревьюер проходит глазами нового пользователя и обновляющегося владельца: может ли начать без догадок, понять пользу, выполнить сценарий, распознать результат и восстановиться. Он также проверяет, что объяснение концепции не изменило утверждённый смысл. Находки обрабатывай через receiving-code-review; после правок перепроверь затронутые примеры/пары страниц. Вердикт привязан к версии.
+
+## Гейт готовности документации
+
+Нельзя объявить документацию готовой к публикации, пока существенные противоречия в установке, дефолтах, гарантиях, статусах и примерах остаются необработанными. Блокирующую находку исправь либо вынеси владельцу явный ограниченный исход; не скрывай её в общем APPROVED. Неблокирующий долг имеет источник и приоритет.
+
+Подготовь в существующем release-отчёте пакет:
+
+- полный номер и SHA/dirty-state; состав просмотренных поверхностей и изменений;
+- карта возможностей/утверждений и путей документации с основаниями;
+- полезное развитие: закрытые пробелы читателя, примеры и уточнения, а не число строк;
+- результаты проверок и статус непроверенных примеров;
+- согласование EN/RU, generated-страниц, навигации и версии;
+- независимые мандаты/вердикт, найденные ограничения, долг и решения владельца;
+- готовность исходников/сборки отдельно от готовности опубликованного сайта.
+
+Для финального утверждения применяй verification-before-completion. Передай пакет L0; выполняй только уже разрешённые дальнейшие действия. Публикацию этот скилл не запускает. При невозможности проверки укажи точное ограничение вместо «всё актуально».
+
+## Не подменяй развитие документации
+
+| Мысль | Действие |
+| --- | --- |
+| «Достаточно перечислить новый API в CHANGELOG» | Объясни задачу, пользу, место в системе и рабочий сценарий |
+| «README не менялся в diff» | Проверь его обещания и путь нового пользователя |
+| «Сайт собрался, значит документация верна» | Проверь поведение примеров и смысл утверждений |
+| «Больше текста означает лучше» | Закрой конкретный пробел; удали дубли и воду |
+| «Концепцию можно дописать любым новым обещанием» | Различай пояснение канона и изменение продуктовой модели |
+| «Перевод и примеры сделаем после релиза» | Существенные пользовательские пути входят в готовность выпуска |
+| «Старый вывод похож на новый» | Сопоставь версию, условия и актуальные результаты |
+| «Для patch документация не нужна» | Проверь влияющие инструкции и ограничения; выбирай соразмерный объём |
+| «Напишу, что исправлено, пока код не подтверждён» | Верни дефект исполнителю и укажи реальное состояние |

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

@@ -14,9 +14,9 @@ worker-reviewer. L2 не получает полномочий диспетче
 эту организационную методику в каждый worker-TASK. При явно назначенной иной
 специализированной методике доставь её полный текст, не самодельное сокращение.
 
-TASK: цель владельца одной строкой → вклад подзадачи → проверяемый результат,
-baseline/revision/digest/cwd, норма и относящиеся политики, источники, границы,
-полный мандат/AC, инструменты/контракты, RESULT/evidence, бюджет и стоп-условие.
+TASK собирается по канону ядра и профилю review в using-skills, без пересказа
+перечня полей. Собственная рамка роли: цель владельца одной строкой, вклад
+подзадачи и проверяемый результат — по ним оценивается покрытие.
 Обязательные нормативные фрагменты передай без потери исключений и приоритета;
 сохрани точные ссылки для дочитывания, не подменяй норму пересказом. Историю
 родителя, чужие находки и ожидаемый вердикт в независимый первый проход не передавай.

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

@@ -18,7 +18,7 @@ description: "Применять при исполнении утверждён
 
 ## Цикл задачи
 
-1. Разрежь работу до конечных мандатов L2; архитектуру, стратегию поиска и зависимости определяет L1. Назначь владельца проверки общих связей. Выбери независимые ready-задачи, запусти параллельно в бюджете и с изоляцией; собери каждому TASK из using-skills. Передай ссылки и минимальный достаточный контекст, проверенные контракты и expected RESULT. L2 разрешено читать нужные файлы и потребителей; история родительской сессии не наследуется.
+1. Разрежь работу до конечных мандатов L2; архитектуру, стратегию поиска и зависимости определяет L1. Назначь владельца проверки общих связей. Выбери независимые ready-задачи, запусти параллельно в бюджете и с изоляцией; собери каждому TASK из using-skills по канону ядра. Выбор сеанса L2 — по канону executor-lead. Передай ссылки и минимальный достаточный контекст, проверенные контракты и expected RESULT. L2 разрешено читать нужные файлы и потребителей; история родительской сессии не наследуется.
 2. Доставь полную методику действия L2 и активный playbook, относящиеся нормы и TASK/RESULT/EVIDENCE; не весь процесс L1/ACCEPTANCE. Для регулярного шага/трения L1 проверяет tool-библиотеку и передаёт подходящий контракт. L2 не выбирает организацию и не спавнит.
 3. Принимай RESULT по готовности: DONE → diff/evidence; DONE_WITH_CONCERNS → риск до ревью; NEEDS_CONTEXT → точный вход; BLOCKED → решение L1, готовое средство или разбиение. Следующий вызов получает решённый вопрос, короткий остаток и новый конечный лимит. Один эксперт — при точном пробеле; дорогой консилиум — только по критериям рамки L1. Изменение цели → L0. Дефект правила → жалобный триаж/Стюард. Не возвращай L2 прежнее «разберись» и не запускай идентичный провал.
 4. Проверь allowlist и новые файлы, включая untracked: RESULT L2 не требует отдельного документа. Частные отчёты/скрипты в docs/dev нарушают состав папки; L1 встраивает полезные выводы в основные документы. Не удаляй чужое/прежнее автоматически. Проверь отсутствие посторонних изменений. Воркер не коммитит; L1 фиксирует результат разрешённым git-действием после проверок, включая авторизованность самого коммита.

package/templates/opencode/plugins/wolf-session-start.js

@@ -77,6 +77,8 @@ function governanceBody() {
 const WORKER_BODY = `## using-skills: пассивный режим воркера (L2)
 
 - Работаешь ровно одну подзадачу: читаешь назначенные скиллы, каталог сам не перебираешь.
+- Методика и ядро поручения доставлены в самом поручении: бери их по ссылке
+  на канон, копию каталога скиллов и ядра не переноси.
 - Методики загружай до исполнения. Блокер и недостающие входы передай L1;
   не начинай продуктовый discovery и новый тред вместо назначенной задачи.
 - Не спавнишь агентов и не коммитишь.

package/update-map.json

@@ -1,6 +1,6 @@
 {
-  "version": "2.21.2",
-  "prev": "2.21.1",
+  "version": "2.22.1",
+  "prev": "2.22.0",
   "files": [
     {
       "path": "base/agents/executor-lead.md",
@@ -117,6 +117,11 @@
       "kind": "skill",
       "category": "unchanged"
     },
+    {
+      "path": "base/skills/wolf-release-docs/SKILL.md",
+      "kind": "skill",
+      "category": "new"
+    },
     {
       "path": "base/skills/wolf-review/SKILL.md",
       "kind": "skill",

package/templates/.wolf/router.log

@@ -1 +0,0 @@
-2026-10-30T13:59:40.930Z agent-id=v2-router-probe-xyz playbook=hit name=fallback variant=fallback source=default resolution=error face_id=- version=- hash=- session=opc-4fe037e6-1e4b-499e-9655-3f38c55686c8 injected=yes ms=0 bytes=1274