npm - mister-wolf - Versions diffs - 2.27.0 → 2.28.0 - Mend

mister-wolf 2.27.0 → 2.28.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (16) hide show

package/README.md +33 -195
package/README.ru.md +33 -224
package/dist/adapters/fs/session-metrics-log.js +1 -1
package/package.json +4 -3
package/templates/base/agents/worker-researcher.md +6 -2
package/templates/base/skills/requesting-code-review/SKILL.md +6 -1
package/templates/base/skills/using-skills/references/routes-execution.md +1 -0
package/templates/base/skills/using-skills/references/routes-intent.md +1 -0
package/templates/base/skills/using-skills/references/routes-quality.md +6 -0
package/templates/base/skills/wolf-code-craft/SKILL.md +99 -0
package/templates/base/skills/wolf-code-simplify/SKILL.md +79 -0
package/templates/base/skills/wolf-design/SKILL.md +8 -1
package/templates/base/skills/wolf-execute/SKILL.md +5 -0
package/templates/base/skills/wolf-sdd/SKILL.md +9 -1
package/templates/base/skills/wolf-software-design/SKILL.md +96 -0
package/update-map.json +26 -11

package/README.md CHANGED Viewed

@@ -2,227 +2,65 @@
 # Mr. Wolf
-![Mr. Wolf logo](docs/Mr.%20Wolf.png)
+![Mr. Wolf logo](https://raw.githubusercontent.com/chekh/mister-wolf/main/docs/Mr.%20Wolf.png)
-> **Memory is the carrier. Processes are the essence. Agents are the shape. Tools are the hands.**
-> And the hands accumulate: every useful script becomes a permanent project resource.
+> **I solve problems.**
 >
-> **"I solve problems."**
+> A permanent project organization built from temporary AI assistants.
-**Concept version:** 3.3.1 · Status: opencode-first, roadmap v3 Phases A–B implemented.
+Mr. Wolf organizes AI work around your goal. It connects agents, skills, tools, rules and project memory into a process: understand the need, organize delivery, check the result and retain what matters for the next session. Through the Steward, feedback and experience can become controlled changes to how the organization works.
-## What is Wolf
+Wolf is also your point of contact with that organization: explain what you need in ordinary language, discuss meaningful choices, and receive a result you can understand and assess.
-Mr. Wolf is a permanent project organization assembled from temporary AI agents: a coordinator (L0) owns the goal and accepts the result, an executor (L1) supplies context and dispatches, workers (L2) run single tasks in clean sessions. Typed memory, a complaint-driven learning loop and a library of accumulated tools carry the organization from session to session — a new session starts from the project's state, not from zero. Local-first: everything lives in your repo, driven by CLI + MCP. We run our own development through this organization daily. The full picture is in the [concept v3 (RU)](docs/concept/concept.md).
+**[Read the documentation](https://chekh.github.io/mister-wolf/guide/overview)** · [Getting started](https://chekh.github.io/mister-wolf/guide/getting-started) · [What is available today](https://chekh.github.io/mister-wolf/guide/capabilities)
-## Problems Wolf solves
+## Why Wolf
-| #   | Problem                                  | Symptom                                                                        | Wolf response                                                                               |
-| --- | ---------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- |
-| P1  | Context is lost between sessions         | the agent starts from scratch                                                  | typed memory; `wolf call`/`wolf brief` re-inject project state at cold start                |
-| P2  | Experience is not reused                 | recurring tasks are solved from scratch: prose reasoning + new one-off scripts | lessons and the tool library: recurring work starts from what already worked                |
-| P3  | Project documents live apart from agents | no single source of truth                                                      | `.wolf/` — a single source of truth drafted from project documents                          |
-| P4  | Accumulated knowledge becomes noise      | memory grows, value drops                                                      | supersede chains, facets, decay by mileage                                                  |
-| P7  | One agent thinks and checks itself       | confident mistakes survive the session                                         | L0/L1/L2 hierarchy, independent acceptance, Council for ambiguous calls (designed, roadmap) |
-| P8  | The same mistakes repeat                 | corrections live in chat logs, not in the project                              | complaint → playbook mutation → next session behaves differently                            |
-| P9  | Quality degrades over a long process     | context bloat, drifting goals, lost decisions                                  | briefs, checkpoints, typed state continuity                                                 |
+- **Keep the goal in view.** L0 owns the goal and final acceptance; L1 organizes delivery; L2 workers execute bounded tasks. This separation keeps local technical work connected to the intended outcome over a long assignment.
+- **Connect the methods.** A process determines which skills, rules, context and tools apply, what to delegate, when to ask and how to verify. A worker's face and assigned skills supply the specialization its task needs.
+- **Continue across sessions.** Project documents are part of memory, alongside decisions, working state and lessons. Original documents stay canonical in their own files; Wolf records references and relevant context for later work.
+- **Change future behavior through the Steward.** Complaints can lead to versioned playbook changes; mature lessons can be aggregated. Changes retain reasons and history, and face versions support rollback. This is organizational learning, not model-weight training.
+- **Work comfortably with people.** Intent dialogue, clear explanations and timely questions are part of the working method. Internal worker reports are integrated into a useful human-facing answer.
+- **Accumulate capabilities you own.** Useful scripts and methods can become reusable project resources. Local files, CLI and MCP keep project state under your control; model calls still use your configured provider.
-> P5–P6 (capture/reuse failure) are answered by the learning loop and the tool pipeline — see the Learning Loop.
+The [product guide](https://chekh.github.io/mister-wolf/guide/overview) explains how these pieces work together. [Comparison by approach](https://chekh.github.io/mister-wolf/guide/capabilities#how-wolf-relates-to-other-solutions) shows the relationship to agent memory, skill collections, harnesses and multi-agent frameworks, without an invented performance ranking.
-## Installation
+## Start with your project
-> [!WARNING]
-> The package is named **`mister-wolf`** ([on npm](https://www.npmjs.com/package/mister-wolf)) — exactly that. The `mr-wolf` package on npm **belongs to someone else** (a work-queue library): `npm install mr-wolf` installs third-party code and runs its install scripts. Check the name letter by letter before installing.
-Installation is the binary plus one of two explicit paths:
-```bash
-npm install -g mister-wolf   # 1) машина: бинарь wolf (уровень 0)
-```
+Current full organization: **OpenCode-first**. Requirements: Node.js 22 or 24; macOS or Linux with glibc.
 ```bash
-# Путь А — память: минимальный набор
-cd my-project && wolf init   # скелет .wolf/ + AGENTS.md; без платформенных конфигов и базового сета
-wolf bootstrap               # память: стартовое наполнение из документов проекта
-# Путь Б — организация OpenCode: полный базовый набор + MCP
-cd my-project && wolf init --full --platform opencode
+npm install -g mister-wolf
+cd my-project
+wolf init --full --platform opencode
 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, 25 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` (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
-  wolf upgrade --check                                     # needs decision: .opencode/agents/foo.md (mutated)
-  wolf upgrade --show 1                                    # local → base diff, read-only
-  wolf upgrade --resolve 1=protect                         # this file is mine from now on
-  wolf upgrade --check                                     # current · 1 protected (intentional)
-  ```
-  Full workflow, backups and limits: [Upgrading a Project and a Park](docs/site/guide/upgrade.md).
-- **Platforms v1:** opencode, Claude Code. Platform MCP configs are opt-in: `wolf init --platform opencode,claude` (the list replaces the current set); without the flag no platform configs are written.
-- **First run without barriers:** `wolf init` decides nothing for you — a minimal file set by default (`--full` for the complete base set), one interview question in a TTY (Enter to skip), no model pinning (`--model` is opt-in; model lines are omitted and the platform default applies). Re-init on a live project shows the plan and needs a confirmation (`--yes` skips it).
-- **OS/runtime:** macOS and Linux (glibc) on Node 22/24. Alpine/musl is not supported in v1; Windows is best-effort, not claimed. The native dependency better-sqlite3 installs from prebuilds — that is the dependency's own behavior; mister-wolf ships no install scripts of its own.
-- **If installation fails on better-sqlite3 — two different situations:**
-  `prebuild-install ... no prebuilt binary found (musl)` — no prebuilds are published for your platform (Alpine/musl) — **not supported in v1**, use a glibc distribution;
-  `gyp ERR!` / `node-gyp` / a from-source build failed — there is no prebuild for your Node version or it did not download. Install the node-gyp prerequisites (python3, make, a C++ toolchain) and retry `npm rebuild better-sqlite3` — this one is fixable, unlike musl.
-- **Dev path (from a cloned repo):** `npm install && npm run build`, then `alias wolf="node dist/bootstrap/cli.js"`. With a global `mister-wolf` installed at the same time, mind PATH shadowing: which `wolf` runs is decided by the order of directories in your PATH. npm also carries a third-party `wolf` package (Wolfram CLI) — installing both globally conflicts over the binary name and resolves by the same PATH order.
-Connecting an agent is one command: `wolf scaffold agent <name>` creates a thin frame in `.opencode/agents/<name>.md`, a face — the agent's playbook as a versioned memory object — and a relation between them. Playbook delivery into the session is done by the `.opencode/plugins/wolf-router.ts` plugin — see [Integrations](#integrations).
-`bootstrap` finishes by invoking the Steward to fold the startup-memory drafts — protocol: [steward bootstrap (RU)](docs/guide/steward-bootstrap.md).
-## Versioning
-- The single source of truth for the version is `package.json`; the version changes only via `npm version X.Y.Z` (semver, manual).
-- A `v*` tag is the release trigger: CI runs `check`+`e2e` and publishes the package (trusted publishing, provenance).
-- Change history lives in [CHANGELOG.md](CHANGELOG.md); an entry there is mandatory for every release.
+The package name is **`mister-wolf`**; `mr-wolf` is a different package. Restart OpenCode after initialization so its project MCP configuration and default agent load.
-## Architecture
+Then give Wolf an outcome, for example:
-Four layers ([concept §2 (RU)](docs/concept/concept.md)):
+> Help me prepare an onboarding guide for this project. Use the existing documents, identify what a newcomer needs, and produce a concise guide with verified setup steps. Ask me if a missing decision changes the result.
-| Layer         | Contents                                                                                             | State                                     |
-| ------------- | ---------------------------------------------------------------------------------------------------- | ----------------------------------------- |
-| **Memory**    | Single source of truth: decisions, lessons, rules, documents, processes, tools; supersede chains     | mature: CLI + MCP, taxonomy, FTS search   |
-| **Processes** | Working protocols: bootstrap, cold-start, complain channel, checkpoint/wrap-up, knowledge processing | partly in the product, partly in practice |
-| **Agents**    | Thin frames (persona) + playbooks (methodology in memory); delivery into platforms                   | proven by PoCs #1–4                       |
-| **Tools**     | CLI and MCP — the hands that put memory and processes into action                                    | mature                                    |
+Wolf's supplied methods direct it to clarify the goal, organize bounded work, check the result and preserve significant state. The response should explain what was produced, what was checked and what remains unresolved. The exact run depends on your project, model and harness; this is an example request, not a recorded trace.
-The layers are not a stack but a **loop**: agents run processes; processes read and write memory; tools put everything into action; results flow back into memory as new knowledge and new tools.
+[Follow the first session](https://chekh.github.io/mister-wolf/guide/getting-started) for bootstrap expectations, recovery and the optional memory-only setup. You do not need to learn the memory taxonomy to start using the organization.
-Details: [architecture guide (RU)](docs/guide/architecture.md) · [concept v3 (RU)](docs/concept/concept.md).
+## Everyday use and updates
-## Features
-### Memory
-Everything is memory: 8 core types (`rule`, `lesson`, `decision`, `thread`, `complaint`, `tool`, `note`, `face`) plus facets, versions, relations, attribution. A `face` is an agent's playbook as its own versioned type — new versions via `wolf face` (the Steward's mutations leave a structured mutation record), emergency owner rollback via `wolf face breakglass`; structured proposals travel as `wolf propose`.
-```bash
-wolf add --type lesson --title "..." --body "..." --tags "vitest,ci" --confidence medium
-wolf get mem_001 --latest          # до актуального в supersede-цепочке
-wolf list --type decision --stale  # не обновлялись 30 дней
-wolf search "supersede" --type rule --hide-superseded
-wolf supersede mem_001 mem_002     # mem_001 заменён mem_002
-wolf transition mem_002 accepted   # смена статуса жизненного цикла
-wolf relation add mem_001 supports mem_002
-```
-- `wolf taxonomy show|sync` — the effective taxonomy and its regeneration from code.
-- `wolf validate [--fix]` — store integrity, quarantine for broken objects.
-- FTS search over a SQLite index (`wolf rebuild-index` to rebuild).
-- `wolf projects` — all registered projects: activity and memory size; transfer is just git — commit `.wolf/memory/`, the clone carries it.
-### Processes
-Agent working protocols as a product.
+Discuss a task or correction with Wolf in your agent environment. [Working with Wolf](https://chekh.github.io/mister-wolf/guide/working-with-wolf) covers clarification, progress, continuation and feedback. [The Steward](https://chekh.github.io/mister-wolf/guide/feedback) explains how experience can change methods and how you retain control.
 ```bash
-wolf bootstrap                                    # подключение к проекту: скан → черновики правил, document-ref'ы, work-thread
-wolf call                                         # cold-start: активные injections для сессии (--for <topic> — по теме)
-wolf brief                                        # сводка состояния по последнему scan + памяти
-wolf complain --about skill:apprentice --rule "…" --evidence "…" --proposal "…" # жалоба на правило/агента → объект complaint → hot-signal Стюарду
-wolf session checkpoint --thread <id>             # точка свёртки прогресса
-wolf session wrap-up --title "…"                  # session-summary завершения
-wolf solve "битые relation-ссылки" --save         # solve pack для проблемы памяти
-wolf think start --goal "…"                       # последовательность: goal → мысли → решение
+wolf upgrade --check   # inspect CLI and registered-project freshness
+wolf upgrade          # update the package and registered projects
 ```
-- Контур поправок замыкается в памяти: жалоба → триаж → исход (`relation outcome_of`) — **поправил → закрепилось → доставилось → окупилось**.
-### Organization
-Wolf works as a permanent project organization from temporary agents: a **coordinator (L0)** holds the goal and accepts the result, an **executor (L1)** supplies context and dispatches, **workers (L2)** execute single tasks in clean sessions. Roles, the working cycle and the council for ambiguous calls — [Organization & Council](https://chekh.github.io/mister-wolf/guide/organization); the council is designed and on the roadmap, the hierarchy and independent acceptance work today. Corrections flow through the complaint loop: complaint → triage → outcome → playbook mutation → the next session behaves differently.
-### Agents
-- `wolf scaffold agent|skill|command <name>` — a platform frame + a face (the agent's playbook) in memory + a relation, all in one command; `--persona` and `--model` for agents, `--from-playbook <id>` to reuse an existing playbook.
-- Playbook delivery is plugin injection into the system prompt (delivery layer #1): `.opencode/plugins/wolf-router.ts`.
-- **Steward** — the loop's background agent with faces: **Mentor** (methodology, handles complaints), **Librarian** (tools), **Archivist** (knowledge). A new face = a new playbook, not a new agent — since 2.17 a face is a core type: versioned through `wolf face` with a mandatory mutation record per Steward version, migratable from legacy playbook notes (`wolf face migrate`). Since 2.14 the Steward also aggregates mature lessons into single replacements — proposed, then owner-confirmed.
-### Tools
-Tool librarian: a successful script crystallizes into a permanent project resource (search-before-write).
-```bash
-wolf tool register scripts/check.sh --name check --contract-in "нет" --contract-out "exit 0/1"
-wolf tool list --status active
-wolf tool use check          # +1 к usage_count, напоминание контракта
-wolf tool stats              # счётчики + экономика переиспользования из сигнального лога
-wolf tool expose check       # (пере)генерировать .opencode/skills/check/SKILL.md
-wolf tool deprecate check --reason "заменён линтером"
-wolf tool revive check       # deprecated → active
-```
-### Self-learning
-The standalone self-learning pipeline was removed by owner decision — write lessons with `wolf add --type lesson`. The signal log (`.wolf/metrics/session-metrics.jsonl`) remains the source: `wolf tool stats` and `wolf analytics` aggregate it.
-### Effectiveness
-- `wolf analytics` — the single analytics surface: ledgers (memory/tools/rules/agents), memory lifecycle & attribution, campaigns with/without memory + per-memory ROI, coordination, data-quality, console dashboard (`--view dashboard`), experiment readiness; honest metrics (`n/a` + reason, never invented numbers). The former standalone `wolf effectiveness` / `wolf dashboard` / `wolf insights` commands are views of `wolf analytics`.
-- `wolf task-eval --verdict accepted|rejected|partial|inconclusive` — task verdicts: acceptance, coverage, cost per accepted task; `--campaign` groups runs into A/B cohorts.
-- Benchmarks: `scripts/bench/` (b1-repeat-debug, b2-bootstrap, b3-retrospective).
-## Read isolation
-Memory scoped to a linked worktree (`worktree:<id>`) is filtered on exactly one path — the delivery path, `wolf call`, in all modes (default, `--for <topic>`, `--thread <id>`); the MCP channel mirrors the CLI list and a `call` tool there would inherit the same isolation. Every other read — `wolf search`/`get`/`list`/`show`, `brief`, `recap`, `think`/`solve`, `doctor`, relation/analytics paths, `wolf face *` (faces filter by `owner_skill`, not scope) — sees the whole project memory. This composition is a frozen contract (NFR-03): extending it is a requirements change, guarded by a doc-test. Details: [Read Isolation](https://chekh.github.io/mister-wolf/guide/read-isolation).
-## Demos
-Self-checking scenarios: `bash scripts/demo/scenario-N.sh`.
-| #   | Scenario                                                                                                            |
-| --- | ------------------------------------------------------------------------------------------------------------------- |
-| 1   | Connecting Wolf to a new project (self-checking, PASS/FAIL points)                                                  |
-| 2   | The life of a knowledge item: birth, aging (supersede), reading the current one                                     |
-| 3   | A new agent = one command (scaffold: playbook + frame + relation)                                                   |
-| 4   | An owner complaint — a hot-signal into the self-learning loop                                                       |
-| 5   | A script becomes a resource — the Librarian's tool cycle                                                            |
-| 6   | Signal log: repeated tool errors land in session metrics (self-learning pipeline removed)                           |
-| 7   | Loop hygiene: memory integrity, attribution, and noise audit                                                        |
-| 8   | Routing: model from a routing memory object, session wrap-up recorded in memory (**one real LLM call, ~30–60 sec**) |
-## Integrations
-### MCP server
-`wolf mcp` — runs the MCP server (stdio): all memory and processes are available to agents on any MCP-compatible platform. Tool list and configuration: [MCP integration spec (RU)](docs/specs/2026-07-01-mcp-server-integration-design.md).
-### opencode plugins
-- `.opencode/plugins/wolf-router.ts` — injects the current playbook into the system prompt (delivery layer #1); `wolf search` is the fallback.
-- `.opencode/plugins/wolf-session-start.js` — session start context.
-- Agent frames live in `.opencode/agents/` (created by `wolf scaffold`).
-### WOLF_ACTOR
-Mutation attribution: every memory object has an author. Priority: the `--created-by <actor>` flag > the `WOLF_ACTOR` env var > fallback (`user:cli` for CLI commands, `steward:<face>` for the Steward loop).
-## Limitations and roadmap
-- **opencode-first**: multi-platform support is an architectural principle (concept §6.6), but the threads for other platforms come after Levels 1–2 mature.
-- **What Wolf does not do** (concept §10): code editing as a project function · IDE integration · web UI · distributed work · general-purpose orchestration (only protocols proven by practice).
-- Plan: [roadmap-v4 (RU)](docs/dev/roadmap/roadmap-v4.md) — active roadmap; revisions history, decisions and assignments: [ledger](docs/dev/roadmap/roadmap-v4-ledger.md); roadmap history: [v3](docs/dev/roadmap/roadmap-v3.md), [v2](docs/dev/roadmap/roadmap-v2.md).
-## Documentation
+Review local modifications before choosing an update resolution. [Upgrade workflow](https://chekh.github.io/mister-wolf/guide/upgrade) explains diffs, protection and backups.
-- [Concept v3 (RU)](docs/concept/concept.md) — four layers, the activation pipeline, the Steward, USP
-- [Roadmap v4 (RU)](docs/dev/roadmap/roadmap-v4.md) — active roadmap; revisions history, decisions and assignments: [ledger](docs/dev/roadmap/roadmap-v4-ledger.md); roadmap history: [v3](docs/dev/roadmap/roadmap-v3.md), [v2](docs/dev/roadmap/roadmap-v2.md)
-- [User guide (RU)](docs/guide/user-guide.md) — basic commands and workflow
-- [CLI reference (RU)](docs/reference/cli.md) — full command reference
-- [Architecture (RU)](docs/guide/architecture.md) — how the system is built
-- [Documentation index (RU)](docs/README.md)
+## Scope and development
-Feature documentation lives in `docs/dev/` as an artifact pipeline (requirements → design → plan → test-plan): `wolf scaffold artifact` creates the feature folder, `wolf sync` maintains INDEX.md, and `wolf doctor` lints the documents. External skills are onboarded through skill intake: search → review → owner gate → `npx skills add` → registration in Wolf memory.
+Wolf's organizational methods are applicable beyond coding; the shipped set includes research, document work and reports. The current delivery is repository-based and OpenCode-first. MCP access or another platform's configuration does not imply the complete organization is validated there. Council runtime, a user console and durable execution are not current guarantees. See [capabilities and boundaries](https://chekh.github.io/mister-wolf/guide/capabilities). [Read isolation](https://chekh.github.io/mister-wolf/guide/read-isolation) applies to context delivery through `wolf call`; it is not general read access control.
-## Development
+The **website is the canonical user documentation**; its source is `docs/site/`. [Engineering documents](docs/README.md) retain the concept, requirements, designs and roadmap in Git. [Contributing](CONTRIBUTING.md) describes development and documentation checks. No comparative speed, cost or quality improvement is promised without an applicable observation.
-TypeScript (strict, ESM), Node 22, vitest. Verification: `npm run check` (format + lint + test + build); e2e suite: `npm run e2e`. Architecture: ports & adapters — `src/domain` · `src/app/use-cases` · `src/adapters` · `src/ports`.
+MIT · [License](LICENSE) · [Release history](https://chekh.github.io/mister-wolf/changelog/)

package/README.ru.md CHANGED Viewed

@@ -2,256 +2,65 @@
 # Mr. Wolf
-![Mr. Wolf logo](docs/Mr.%20Wolf.png)
+![Mr. Wolf logo](https://raw.githubusercontent.com/chekh/mister-wolf/main/docs/Mr.%20Wolf.png)
-> **Память — носитель. Процессы — суть. Агенты — форма. Инструменты — руки.**
-> И руки накапливаются: каждый полезный скрипт становится постоянным ресурсом проекта.
+> **I solve problems.**
 >
-> **«I solve problems.»**
+> Постоянная проектная организация из временных AI-помощников.
-**Версия концепта:** 3.3.1 · Статус: opencode-first, Фазы A–B roadmap v3 реализованы.
+Mr. Wolf организует работу AI-помощников вокруг вашей цели. Он связывает агентов, скиллы, инструменты, правила и память проекта в процесс: понять потребность, организовать выполнение, проверить результат и сохранить существенное для следующей сессии. Через Стюарда обратная связь и опыт могут превращаться в управляемые изменения способов работы организации.
-## Что такое Wolf
+Wolf — ваша точка общения с этой организацией: объясните потребность обычным языком, обсудите существенные решения и получите результат, который можно понять и оценить.
-Mr. Wolf — постоянная проектная организация, собираемая из временных AI-агентов: координатор (L0) держит цель и принимает результат, исполнитель (L1) поставляет контекст и диспетчирует, воркеры (L2) решают одиночные задачи в чистых сессиях. Типизированная память, жалобный контур обучения и накопленная библиотека инструментов переносят организацию от сессии к сессии — новая сессия стартует из состояния проекта, а не с нуля. Local-first: всё живёт в вашем репозитории, управление — CLI + MCP. Мы гоняем через эту организацию собственную разработку каждый день. Полная картина — в [концепте v3](docs/concept/concept.md).
+**[Документация](https://chekh.github.io/mister-wolf/ru/guide/overview)** · [Начало работы](https://chekh.github.io/mister-wolf/ru/guide/getting-started) · [Что доступно сейчас](https://chekh.github.io/mister-wolf/ru/guide/capabilities)
-## Решаемые проблемы
+## Зачем Wolf
-| №   | Проблема                                    | Проявление                                                                          | Ответ Wolf                                                                                |
-| --- | ------------------------------------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
-| П1  | Контекст теряется между сессиями            | агент начинает с нуля                                                               | типизированная память; `wolf call`/`wolf brief` заново инъецируют состояние               |
-| П2  | Опыт не переиспользуется                    | повторные задачи решаются заново: текстовые рассуждения + новые одноразовые скрипты | уроки и библиотека инструментов: повторная работа стартует от работавшего                 |
-| П3  | Документы проекта живут отдельно от агентов | единая точка правды отсутствует                                                     | `.wolf/` — единая точка правды, наполненная из документов проекта                         |
-| П4  | Накопленное становится шумом                | память растёт, ценность падает                                                      | supersede-цепочки, фасеты, decay по пробегу                                               |
-| П7  | Один агент сам думает и сам себя проверяет  | уверенные ошибки переживают сессию                                                  | иерархия L0/L1/L2, независимая приёмка, консилиум для спорных решений (designed, roadmap) |
-| П8  | Одни и те же ошибки повторяются             | правки живут в чат-логах, а не в проекте                                            | жалоба → мутация playbook'а → следующая сессия работает иначе                             |
-| П9  | Качество деградирует в длинном процессе     | раздувание контекста, дрейф цели, потерянные решения                                | брифы, чекпоинты, типизированная преемственность состояния                                |
+- **Удерживать цель.** L0 отвечает за цель и итоговую приёмку; L1 организует поставку; L2 выполняют ограниченные задачи. Разделение ответственности сохраняет связь частной технической работы с ожидаемым результатом на длинном пути.
+- **Связывать методы.** Процесс определяет применимые скиллы, правила, контекст и инструменты, распределение задач, момент вопроса и способ проверки. Лицо воркера и назначенные скиллы задают нужную специализацию.
+- **Продолжать между сессиями.** Документы проекта — часть памяти наряду с решениями, рабочим состоянием и уроками. Исходные документы остаются каноничными в своих файлах; Wolf сохраняет ссылки и относящийся контекст для дальнейшей работы.
+- **Менять будущее поведение через Стюарда.** Жалобы могут приводить к новым версиям методик; зрелые уроки — обобщаться. Сохраняются причины и история изменений, для версий лиц доступен откат. Это обучение организации, а не обучение весов модели.
+- **Комфортно общаться с человеком.** Содержательное уточнение намерения, ясное объяснение и своевременный вопрос входят в методику работы. Внутренние отчёты воркеров собираются в полезный ответ пользователю.
+- **Накапливать собственные способности.** Полезные скрипты и методы могут становиться ресурсами проекта. Локальные файлы, CLI и MCP сохраняют контроль над состоянием; обращения к модели используют настроенного вами провайдера.
-> П5–П6 (capture/reuse failure) закрывают контур обучения и конвейер инструментов — см. Контур обучения.
+[Обзор продукта](https://chekh.github.io/mister-wolf/ru/guide/overview) объясняет связи компонентов. [Сравнение подходов](https://chekh.github.io/mister-wolf/ru/guide/capabilities#связь-с-другими-решениями) показывает отношение к памяти агентов, наборам скиллов, харнесам и мультиагентным фреймворкам без вымышленного рейтинга эффективности.
-## Установка
+## Начните со своего проекта
-> [!WARNING]
-> Пакет называется **`mister-wolf`** — именно так. Пакет `mr-wolf` в npm **чужой** (work-queue
-> библиотека): `npm install mr-wolf` поставит сторонний код и выполнит его install-скрипты.
-> Проверяй имя буква-в-букву перед установкой.
-Установка — бинарь плюс один из двух явных путей:
-```bash
-npm install -g mister-wolf   # 1) машина: бинарь wolf (уровень 0)
-```
+Полная организация сейчас — **OpenCode-first**. Требования: Node.js 22 или 24; macOS либо Linux с glibc.
 ```bash
-# Путь А — память: минимальный набор
-cd my-project && wolf init   # скелет .wolf/ + AGENTS.md; без платформенных конфигов и базового сета
-wolf bootstrap               # память: стартовое наполнение из документов проекта
-# Путь Б — организация OpenCode: полный базовый набор + MCP
-cd my-project && wolf init --full --platform opencode
+npm install -g mister-wolf
+cd my-project
+wolf init --full --platform opencode
 wolf bootstrap
 ```
-- **Путь А — память:** `wolf init` подключает проект минимально — скелет `.wolf/` и `AGENTS.md`; платформенные конфиги и базовый сет он не пишет. Что печатает чистый запуск: `memory skeleton: ensured`, `base set: AGENTS.md created`, id init-отчёта.
-- **Путь Б — организация 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-фаза
-  (`npm install -g mister-wolf@latest`) и следом проход по всем зарегистрированным проектам
-  (штампованные файлы базового сета и посеянные лица; удаления — только по подтверждению).
-  `--check` — read-only сводка свежести CLI и парка; `--here` — обновить только текущий проект
-  (без npm и реестра); `--yes` — без интерактивного подтверждения, с бэкапом всего, что
-  перезаписывает. Dev/linked-установке откажет честно. `wolf sync` депрекирован →
-  `wolf upgrade --here` (алиас ещё работает и перерендеривает штампованные файлы; его уведомление
-  DEPRECATED всё ещё говорит `removed in 2.20.0` — устаревшая формулировка, команда жива).
-- **Намерения владельца (2.20.0):** когда проходу нужно ваше слово, он называет файл и причину
-  (`mutated` / `conflict`, по путям — без голых счётчиков). `--review` разбирает решения с диффом,
-  `--show <файл|N>` печатает локальный vs эталон, `--resolve <файл|N>=take|keep|protect|pin`
-  применяет решение, `--json` — машинный канал (`wolf.upgrade/1`, а с `--check` — `wolf.upgrade.check/1`). `protect: true` (или
-  `protect: X.Y.Z`) во frontmatter agent/skill/command-файла держит файл навсегда — не
-  перезаписывается, не удаляется и остаётся видимым в `--check`. Локальный конфликт целиком:
-  ```bash
-  wolf upgrade --check                                     # needs decision: .opencode/agents/foo.md (mutated)
-  wolf upgrade --show 1                                    # дифф локальный → эталон, только чтение
-  wolf upgrade --resolve 1=protect                         # этот файл мой с этого момента
-  wolf upgrade --check                                     # current · 1 protected (intentional)
-  ```
-  Полный сценарий, бэкапы и ограничения: [Обновление проекта и парка](docs/site/ru/guide/upgrade.md).
-- **Платформы v1:** opencode, Claude Code. MCP-конфиги платформ — opt-in:
-  `wolf init --platform opencode,claude` (список заменяет текущий набор); без флага платформенные
-  конфиги не пишутся.
-- **Первый запуск без барьеров:** `wolf init` не принимает решений за тебя — минимальный набор
-  файлов по умолчанию (`--full` — полный базовый набор), один вопрос интервью в терминале
-  (Enter — пропустить), никакого пиннинга модели (`--model` — opt-in, строки модели опускаются —
-  действует платформенный дефолт). Повторный init на живом проекте покажет план и потребует
-  подтверждения (`--yes` — без вопросов).
-- **ОС/рантайм:** macOS и Linux (glibc) на Node 22/24. Alpine/musl не поддержан в v1;
-  Windows — best-effort, не заявлена. Нативная зависимость better-sqlite3 ставится из пребилдов —
-  это поведение зависимости, у mister-wolf нет своих install-скриптов.
-- **Если установка падает на better-sqlite3 — две разные ситуации:**
-  `prebuild-install ... no prebuilt binary found (musl)` — для вашей платформы пребилды не
-  выпускаются (Alpine/musl) — **не поддерживается в v1**, используйте glibc-дистрибутив;
-  `gyp ERR!` / `node-gyp` / сборка из исходников упала — пребилда под ваш Node нет или не
-  скачалась, поставь node-gyp prerequisites (python3, make, C++ toolchain) и повтори
-  `npm rebuild better-sqlite3` — это лечится, в отличие от musl.
-- **Dev-путь (из клонированного репо):** `npm install && npm run build`, затем
-  `alias wolf="node dist/bootstrap/cli.js"`. При одновременно установленном глобальном
-  `mister-wolf` помни о PATH-shadowing: какой `wolf` запустится — определяется порядком каталогов
-  в PATH. В npm есть и чужой пакет `wolf` (Wolfram CLI) — глобальная установка обоих конфликтует
-  за имя бинаря, разрешается тем же порядком PATH.
-Подключение агента — одна команда: `wolf scaffold agent <name>` создаёт тонкую рамку в `.opencode/agents/<name>.md`, лицо — playbook агента как версионируемый объект памяти — и relation между ними. Доставку playbook'а в сессию выполняет плагин `.opencode/plugins/wolf-router.ts` — см. [Интеграции](#интеграции).
-`bootstrap` завершается вызовом Стюарда для свёртки черновиков стартовой памяти — протокол: [docs/guide/steward-bootstrap.md](docs/guide/steward-bootstrap.md).
-## Versioning
-- Единственный источник истины версии — `package.json`; версия меняется только командой `npm version X.Y.Z` (semver, вручную).
-- Тег `v*` — релиз-триггер: CI прогоняет `check`+`e2e` и публикует пакет (trusted publishing, provenance).
-- История изменений — [CHANGELOG.md](CHANGELOG.md); запись в него при релизе обязательна.
+Имя пакета — **`mister-wolf`**; `mr-wolf` — другой пакет. После инициализации перезапустите OpenCode, чтобы загрузились проектный MCP-конфиг и агент по умолчанию.
-## Архитектура
+Затем поручите Wolf результат, например:
-Четыре слоя ([концепт §2](docs/concept/concept.md)):
+> Помоги подготовить руководство для новых участников проекта. Используй существующие документы, выясни, что нужно новичку, и подготовь краткое руководство с проверенными шагами запуска. Спроси меня, если недостающее решение влияет на результат.
-| Слой            | Содержание                                                                                        | Состояние                                |
-| --------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------- |
-| **Память**      | Единая точка правды: решения, уроки, правила, документы, процессы, инструменты; supersede-цепочки | зрел: CLI + MCP, таксономия, FTS-поиск   |
-| **Процессы**    | Протоколы работы: bootstrap, cold-start, complain-канал, checkpoint/wrap-up, обработка знаний     | частично в продукте, частично в практике |
-| **Агенты**      | Тонкие рамки (персона) + playbook'и (методика в памяти); доставка в платформы                     | доказано PoC #1–4                        |
-| **Инструменты** | CLI и MCP — руки, приводящие память и процессы в действие                                         | зрел                                     |
+Поставляемые методики предписывают Wolf уточнить цель, организовать ограниченные задачи, проверить результат и сохранить существенное состояние. Ответ должен объяснять, что подготовлено, что проверено и что осталось открытым. Фактический запуск зависит от проекта, модели и харнеса; это пример поручения, а не запись выполненного прогона.
-Слои — не стопка, а **петля**: агенты исполняют процессы; процессы читают и пишут память; инструменты приводят всё в действие; результаты возвращаются в память как новые знания и инструменты.
+[Первый сеанс](https://chekh.github.io/mister-wolf/ru/guide/getting-started) объясняет bootstrap, восстановление и дополнительный режим только памяти. Для начала работы с организацией изучать таксономию памяти не требуется.
-Подробно: [docs/guide/architecture.md](docs/guide/architecture.md) · [концепт v3](docs/concept/concept.md).
+## Повседневная работа и обновление
-## Возможности
-### Память
-Всё есть память: 8 ключевых типов (`rule`, `lesson`, `decision`, `thread`, `complaint`, `tool`, `note`, `face`) плюс фасеты, версии, связи, атрибуция. `face` — playbook агента как отдельный версионируемый тип: новые версии через `wolf face` (мутация Стюарда оставляет структурную запись), аварийный откат владельцем — `wolf face breakglass`; структурированные предложения ходят через `wolf propose`.
-```bash
-wolf add --type lesson --title "..." --body "..." --tags "vitest,ci" --confidence medium
-wolf get mem_001 --latest          # до актуального в supersede-цепочке
-wolf list --type decision --stale  # не обновлялись 30 дней
-wolf search "supersede" --type rule --hide-superseded
-wolf supersede mem_001 mem_002     # mem_001 заменён mem_002
-wolf transition mem_002 accepted   # смена статуса жизненного цикла
-wolf relation add mem_001 supports mem_002
-```
-- `wolf taxonomy show|sync` — эффективная таксономия и её регенерация из кода.
-- `wolf validate [--fix]` — целостность хранилища, карантин битых объектов.
-- FTS-поиск по SQLite-индексу (`wolf rebuild-index` — перестройка).
-- `wolf projects` — все зарегистрированные проекты: активность и размер памяти; перенос — это git: коммитите `.wolf/memory/`, клон переносит.
-### Процессы
-Протоколы работы агентов как продукт.
+Обсуждайте задачу или замечание с Wolf в своей агентной среде. [Работа с Wolf](https://chekh.github.io/mister-wolf/ru/guide/working-with-wolf) описывает уточнение, прогресс, продолжение и обратную связь. [Стюард](https://chekh.github.io/mister-wolf/ru/guide/feedback) — изменение методик по опыту и сохранение вашего контроля.
 ```bash
-wolf bootstrap                                    # подключение к проекту: скан → черновики правил, document-ref'ы, work-thread
-wolf call                                         # cold-start: активные injections для сессии (--for <topic> — по теме)
-wolf brief                                        # сводка состояния по последнему scan + памяти
-wolf complain --about skill:apprentice --rule "…" --evidence "…" --proposal "…" # жалоба на правило/агента → объект complaint → hot-signal Стюарду
-wolf session checkpoint --thread <id>             # точка свёртки прогресса
-wolf session wrap-up --title "…"                  # session-summary завершения
-wolf solve "битые relation-ссылки" --save         # solve pack для проблемы памяти
-wolf think start --goal "…"                       # последовательность: goal → мысли → решение
+wolf upgrade --check   # проверить актуальность CLI и зарегистрированных проектов
+wolf upgrade          # обновить пакет и зарегистрированные проекты
 ```
-- Контур поправок замыкается в памяти: жалоба → триаж → исход (`relation outcome_of`) — **поправил → закрепилось → доставилось → окупилось**.
-### Организация
-Wolf работает как постоянная проектная организация из временных агентов: **координатор (L0)** держит цель и принимает результат, **исполнитель (L1)** поставляет контекст и диспетчирует, **воркеры (L2)** выполняют одиночные задачи в чистых сессиях. Роли, цикл работы и консилиум для спорных решений — [Organization & Council](https://chekh.github.io/mister-wolf/guide/organization); консилиум спроектирован и в roadmap, иерархия и независимая приёмка работают сегодня. Поправки идут через жалобный контур: жалоба → триаж → исход → мутация playbook'а → следующая сессия работает иначе.
-### Агенты
-- `wolf scaffold agent|skill|command <name>` — рамка платформы + лицо (playbook агента) в памяти + relation одной командой; `--persona` и `--model` для агентов, `--from-playbook <id>` — переиспользовать существующий playbook.
-- Доставка playbook'ов — плагин-инжекция в system-промпт (слой доставки №1): `.opencode/plugins/wolf-router.ts`.
-- **Стюард** — фоновый агент контура с лицами: **Наставник** (методики, по жалобам), **Библиотекарь** (инструменты), **Архивариус** (знания). Новое лицо = новый playbook, не новый агент — с 2.17 лицо это core-тип: версионируется через `wolf face` с обязательной записью мутации на каждую версию Стюарда, мигрируется из legacy playbook-заметок (`wolf face migrate`). С 2.14 Стюард также агрегирует зрелые уроки в одну замену — proposed, подтверждение владельцем.
-### Инструменты
-Tool-библиотекарь: удачный скрипт кристаллизуется в постоянный ресурс (search-before-write).
-```bash
-wolf tool register scripts/check.sh --name check --contract-in "нет" --contract-out "exit 0/1"
-wolf tool list --status active
-wolf tool use check          # +1 к usage_count, напоминание контракта
-wolf tool stats              # счётчики + экономика переиспользования из сигнального лога
-wolf tool expose check       # (пере)генерировать .opencode/skills/check/SKILL.md
-wolf tool deprecate check --reason "заменён линтером"
-wolf tool revive check       # deprecated → active
-```
-### Самообучение
-Автономный конвейер самообучения удалён по решению владельца — уроки пишутся через `wolf add --type lesson`. Сигнальный лог (`.wolf/metrics/session-metrics.jsonl`) остался источником: его агрегируют `wolf tool stats` и `wolf analytics`.
-### Эффективность
-- `wolf analytics` — единая аналитическая поверхность: ledger'ы (memory/tools/rules/agents), жизненный цикл памяти и атрибуция, кампании «с памятью/без» + per-memory ROI, координация, data-quality, консольный дашборд (`--view dashboard`), готовность экспериментов; честные метрики (`n/a` + причина, числа не выдумываются). Бывшие автономные `wolf effectiveness` / `wolf dashboard` / `wolf insights` — теперь view'ы `wolf analytics`.
-- `wolf task-eval --verdict accepted|rejected|partial|inconclusive` — вердикты по задачам: acceptance, coverage, стоимость принятой задачи; `--campaign` группирует раны в A/B-когорты.
-- Бенчмарки: `scripts/bench/` (b1-repeat-debug, b2-bootstrap, b3-retrospective).
-## Изоляция чтения
-Память со scope связанной рабочей копии (`worktree:<id>`) фильтруется ровно на одном пути — пути доставки, `wolf call`, во всех режимах (обычный, `--for <тема>`, `--thread <id>`); MCP-канал зеркалит CLI-список, и тул `call` там унаследовал бы ту же изоляцию. Все остальные чтения — `wolf search`/`get`/`list`/`show`, `brief`, `recap`, `think`/`solve`, `doctor`, relation/analytics-пути, `wolf face *` (лица фильтруются по `owner_skill`, не по scope) — видят всю память проекта. Этот состав — замороженный контракт (NFR-03): расширение = изменение требований, охраняется doc-тестом. Подробности: [Изоляция чтения](https://chekh.github.io/mister-wolf/ru/guide/read-isolation).
-## Демо
-Самопроверяющиеся сценарии: `bash scripts/demo/scenario-N.sh`.
-| №   | Сценарий                                                                                                           |
-| --- | ------------------------------------------------------------------------------------------------------------------ |
-| 1   | Подключение Wolf к новому проекту (self-checking, PASS/FAIL-точки)                                                 |
-| 2   | Жизнь знания: рождение, устаревание (supersede), чтение актуального                                                |
-| 3   | Новый агент = одна команда (scaffold: playbook + рамка + связь)                                                    |
-| 4   | Жалоба владельца — hot-signal контура самообучения                                                                 |
-| 5   | Скрипт становится ресурсом — tool-цикл Библиотекаря                                                                |
-| 6   | Сигнальный лог: повторяющиеся тул-ошибки попадают в метрики сессий (конвейер самообучения удалён)                  |
-| 7   | Гигиена контура: целостность памяти, атрибуция, аудит шума                                                         |
-| 8   | Роутинг: модель из routing-объекта памяти, итоги сессии в памяти проекта (**один реальный LLM-вызов, ~30–60 сек**) |
-## Интеграции
-### MCP-сервер
-`wolf mcp` — запуск MCP-сервера (stdio): вся память и процессы доступны агентам любой MCP-совместимой платформы. Список тулов и конфигурация — в [спеке MCP-интеграции](docs/specs/2026-07-01-mcp-server-integration-design.md).
-### opencode-плагины
-- `.opencode/plugins/wolf-router.ts` — инжекция актуального playbook в system-промпт (слой доставки №1); `wolf search` — fallback.
-- `.opencode/plugins/wolf-session-start.js` — стартовый контекст сессии.
-- Рамки агентов — `.opencode/agents/` (создаются `wolf scaffold`).
-### WOLF_ACTOR
-Атрибуция мутаций: каждый объект памяти имеет автора. Приоритет: флаг `--created-by <actor>` > env `WOLF_ACTOR` > fallback (`user:cli` для CLI-команд, `steward:<лицо>` для контура Стюарда).
-## Ограничения и roadmap
-- **opencode-first**: мультиплатформенность — архитектурный принцип (концепт §6.6), но нити других платформ — после зрелости Уровней 1–2.
-- **Что не делает Wolf** (концепт §10): редактирование кода как проектная функция · IDE-интеграция · веб-интерфейс · распределённая работа · оркестрация общего назначения (только протоколы, доказанные практикой).
-- План: [roadmap-v4](docs/dev/roadmap/roadmap-v4.md) — активный роадмап; история: [v3](docs/dev/roadmap/roadmap-v3.md), [v2](docs/dev/roadmap/roadmap-v2.md).
-## Документация
+Перед выбором исхода обновления изучите локальные изменения. [Порядок обновления](https://chekh.github.io/mister-wolf/ru/guide/upgrade) объясняет diff, защиту и резервные копии.
-- [Концепция v3](docs/concept/concept.md) — четыре слоя, конвейер активации, Стюард, УТП
-- [Roadmap v4](docs/dev/roadmap/roadmap-v4.md) — активный роадмап; история: [v3](docs/dev/roadmap/roadmap-v3.md), [v2](docs/dev/roadmap/roadmap-v2.md)
-- [User guide](docs/guide/user-guide.md) — базовые команды и workflow
-- [CLI reference](docs/reference/cli.md) — полный справочник команд
-- [Architecture](docs/guide/architecture.md) — устройство системы
-- [Индекс документации](docs/README.md)
+## Границы и разработка
-Документация фич живёт в `docs/dev/` как конвейер артефактов (requirements → design → plan → test-plan): `wolf scaffold artifact` создаёт папку фичи, `wolf sync` ведёт INDEX.md, `wolf doctor` линтит документы. Внешние скиллы подключаются через skill intake: поиск → ревью → гейт владельца → `npx skills add` → регистрация в памяти Wolf.
+Организационные методы Wolf применимы за пределами программирования; в поставке есть исследования, работа с документами и отчёты. Текущая реализация основана на репозитории и прежде всего OpenCode. Доступ по MCP или конфигурация другой платформы не означают проверенную полную организацию на ней. Исполняемый консилиум, пользовательская консоль и устойчивое выполнение после сбоя пока не гарантируются. См. [возможности и границы](https://chekh.github.io/mister-wolf/ru/guide/capabilities). [Изоляция чтения](https://chekh.github.io/mister-wolf/ru/guide/read-isolation) применяется к доставке через `wolf call`, а не к общему доступу на чтение.
-## Разработка
+**Сайт — единая актуальная пользовательская документация**; исходники — `docs/site/`. [Инженерные документы](docs/README.md) сохраняют концепцию, требования, дизайн и роадмап в Git. [Contributing](CONTRIBUTING.md) описывает разработку и проверки документации. Сравнительный выигрыш в скорости, стоимости или качестве без соответствующего наблюдения не обещается.
-TypeScript (strict, ESM), Node 22, vitest. Верификация: `npm run check` (format + lint + test + build); e2e-набор: `npm run e2e`. Архитектура — ports & adapters: `src/domain` · `src/app/use-cases` · `src/adapters` · `src/ports`.
+MIT · [Лицензия](LICENSE) · [История выпусков](https://chekh.github.io/mister-wolf/ru/changelog/)

package/dist/adapters/fs/session-metrics-log.js CHANGED Viewed

@@ -3,7 +3,7 @@
  * Append-only, derived/rebuildable (инвариант §9), запись детерминированная, без LLM.
  * Формат: OTEL GenAI-совместимые поля по спеке §2.1 (session_id, gen_ai.*, orchestration.*,
  * outcome); gen_ai.modelID — обязательное поле (PoC#4, §21 п.23; null — модель неизвестна).
- * Документация формата: docs/guide/signal-log.md. Спека:
+ * Документация формата: docs/site/guide/telemetry.md. Спека:
  * docs/specs/2026-08-26-self-learning-design.md §2.1, §2.2.
  *
  * Writer-матрица D1 (M20-07, решение Q3): writer'ы — сами CLI-команды (complain,

package/package.json CHANGED Viewed

@@ -1,7 +1,7 @@
 {
   "name": "mister-wolf",
-  "version": "2.27.0",
-  "description": "Local-first project memory for AI coding agents: decisions, lessons, tools and processes that outlive the session",
+  "version": "2.28.0",
+  "description": "A local-first project organization for AI assistants: goal-directed processes, project memory and governed learning",
   "keywords": [
     "ai-agents",
     "mcp",
@@ -42,7 +42,8 @@
     "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/generate-cli-site-page.mjs && node scripts/sync-changelog.mjs && vitepress build docs/site",
-    "docs:preview": "vitepress preview docs/site"
+    "docs:preview": "vitepress preview docs/site",
+    "docs:check": "npm run build && npm run docs:build && node scripts/check-docs-links.mjs"
   },
   "dependencies": {
     "@modelcontextprotocol/server": "^2.0.0",

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

@@ -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 CHANGED Viewed

@@ -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/routes-execution.md CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 ADDED Viewed

@@ -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 ADDED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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-sdd/SKILL.md CHANGED Viewed

@@ -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 ADDED Viewed

@@ -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 CHANGED Viewed

@@ -1,6 +1,6 @@
 {
-  "version": "2.27.0",
-  "prev": "2.26.0",
+  "version": "2.28.0",
+  "prev": "2.27.1",
   "files": [
     {
       "path": "base/agents/executor-lead.md",
@@ -25,7 +25,7 @@
     {
       "path": "base/agents/worker-researcher.md",
       "kind": "agent",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/agents/worker-reviewer.md",
@@ -60,7 +60,7 @@
     {
       "path": "base/skills/requesting-code-review/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/test-driven-development/references/test-quality.md",
@@ -110,17 +110,17 @@
     {
       "path": "base/skills/using-skills/references/routes-execution.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/using-skills/references/routes-intent.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/using-skills/references/routes-quality.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/using-skills/references/routes-state.md",
@@ -142,6 +142,16 @@
       "kind": "skill",
       "category": "unchanged"
     },
+    {
+      "path": "base/skills/wolf-code-craft/SKILL.md",
+      "kind": "skill",
+      "category": "new"
+    },
+    {
+      "path": "base/skills/wolf-code-simplify/SKILL.md",
+      "kind": "skill",
+      "category": "new"
+    },
     {
       "path": "base/skills/wolf-debug/references/techniques.md",
       "kind": "skill",
@@ -155,7 +165,7 @@
     {
       "path": "base/skills/wolf-design/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/wolf-execute/references/technical-helpers.md",
@@ -170,7 +180,7 @@
     {
       "path": "base/skills/wolf-execute/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/wolf-explain/SKILL.md",
@@ -205,7 +215,7 @@
     {
       "path": "base/skills/wolf-git/SKILL.md",
       "kind": "skill",
-      "category": "changed"
+      "category": "unchanged"
     },
     {
       "path": "base/skills/wolf-handoff/SKILL.md",
@@ -230,13 +240,18 @@
     {
       "path": "base/skills/wolf-sdd/SKILL.md",
       "kind": "skill",
-      "category": "unchanged"
+      "category": "changed"
     },
     {
       "path": "base/skills/wolf-skill-intake/SKILL.md",
       "kind": "skill",
       "category": "unchanged"
     },
+    {
+      "path": "base/skills/wolf-software-design/SKILL.md",
+      "kind": "skill",
+      "category": "new"
+    },
     {
       "path": "base/skills/wolf-testplan/SKILL.md",
       "kind": "skill",