mister-wolf 2.27.0 → 2.27.1
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.
- 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/update-map.json +3 -3
package/README.md
CHANGED
|
@@ -2,227 +2,65 @@
|
|
|
2
2
|
|
|
3
3
|
# Mr. Wolf
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
|
|
6
6
|
|
|
7
|
-
> **
|
|
8
|
-
> And the hands accumulate: every useful script becomes a permanent project resource.
|
|
7
|
+
> **I solve problems.**
|
|
9
8
|
>
|
|
10
|
-
>
|
|
9
|
+
> A permanent project organization built from temporary AI assistants.
|
|
11
10
|
|
|
12
|
-
|
|
11
|
+
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.
|
|
13
12
|
|
|
14
|
-
|
|
13
|
+
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.
|
|
15
14
|
|
|
16
|
-
|
|
15
|
+
**[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)
|
|
17
16
|
|
|
18
|
-
##
|
|
17
|
+
## Why Wolf
|
|
19
18
|
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
| P7 | One agent thinks and checks itself | confident mistakes survive the session | L0/L1/L2 hierarchy, independent acceptance, Council for ambiguous calls (designed, roadmap) |
|
|
27
|
-
| P8 | The same mistakes repeat | corrections live in chat logs, not in the project | complaint → playbook mutation → next session behaves differently |
|
|
28
|
-
| P9 | Quality degrades over a long process | context bloat, drifting goals, lost decisions | briefs, checkpoints, typed state continuity |
|
|
19
|
+
- **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.
|
|
20
|
+
- **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.
|
|
21
|
+
- **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.
|
|
22
|
+
- **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.
|
|
23
|
+
- **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.
|
|
24
|
+
- **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.
|
|
29
25
|
|
|
30
|
-
|
|
26
|
+
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.
|
|
31
27
|
|
|
32
|
-
##
|
|
28
|
+
## Start with your project
|
|
33
29
|
|
|
34
|
-
|
|
35
|
-
> 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.
|
|
36
|
-
|
|
37
|
-
Installation is the binary plus one of two explicit paths:
|
|
38
|
-
|
|
39
|
-
```bash
|
|
40
|
-
npm install -g mister-wolf # 1) машина: бинарь wolf (уровень 0)
|
|
41
|
-
```
|
|
30
|
+
Current full organization: **OpenCode-first**. Requirements: Node.js 22 or 24; macOS or Linux with glibc.
|
|
42
31
|
|
|
43
32
|
```bash
|
|
44
|
-
|
|
45
|
-
cd my-project
|
|
46
|
-
wolf
|
|
47
|
-
|
|
48
|
-
# Путь Б — организация OpenCode: полный базовый набор + MCP
|
|
49
|
-
cd my-project && wolf init --full --platform opencode
|
|
33
|
+
npm install -g mister-wolf
|
|
34
|
+
cd my-project
|
|
35
|
+
wolf init --full --platform opencode
|
|
50
36
|
wolf bootstrap
|
|
51
37
|
```
|
|
52
38
|
|
|
53
|
-
|
|
54
|
-
- **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.
|
|
55
|
-
|
|
56
|
-
- **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.
|
|
57
|
-
- **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).
|
|
58
|
-
- **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:
|
|
59
|
-
|
|
60
|
-
```bash
|
|
61
|
-
wolf upgrade --check # needs decision: .opencode/agents/foo.md (mutated)
|
|
62
|
-
wolf upgrade --show 1 # local → base diff, read-only
|
|
63
|
-
wolf upgrade --resolve 1=protect # this file is mine from now on
|
|
64
|
-
wolf upgrade --check # current · 1 protected (intentional)
|
|
65
|
-
```
|
|
66
|
-
|
|
67
|
-
Full workflow, backups and limits: [Upgrading a Project and a Park](docs/site/guide/upgrade.md).
|
|
68
|
-
|
|
69
|
-
- **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.
|
|
70
|
-
- **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).
|
|
71
|
-
- **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.
|
|
72
|
-
- **If installation fails on better-sqlite3 — two different situations:**
|
|
73
|
-
`prebuild-install ... no prebuilt binary found (musl)` — no prebuilds are published for your platform (Alpine/musl) — **not supported in v1**, use a glibc distribution;
|
|
74
|
-
`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.
|
|
75
|
-
- **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.
|
|
76
|
-
|
|
77
|
-
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).
|
|
78
|
-
|
|
79
|
-
`bootstrap` finishes by invoking the Steward to fold the startup-memory drafts — protocol: [steward bootstrap (RU)](docs/guide/steward-bootstrap.md).
|
|
80
|
-
|
|
81
|
-
## Versioning
|
|
82
|
-
|
|
83
|
-
- The single source of truth for the version is `package.json`; the version changes only via `npm version X.Y.Z` (semver, manual).
|
|
84
|
-
- A `v*` tag is the release trigger: CI runs `check`+`e2e` and publishes the package (trusted publishing, provenance).
|
|
85
|
-
- Change history lives in [CHANGELOG.md](CHANGELOG.md); an entry there is mandatory for every release.
|
|
39
|
+
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.
|
|
86
40
|
|
|
87
|
-
|
|
41
|
+
Then give Wolf an outcome, for example:
|
|
88
42
|
|
|
89
|
-
|
|
43
|
+
> 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.
|
|
90
44
|
|
|
91
|
-
|
|
92
|
-
| ------------- | ---------------------------------------------------------------------------------------------------- | ----------------------------------------- |
|
|
93
|
-
| **Memory** | Single source of truth: decisions, lessons, rules, documents, processes, tools; supersede chains | mature: CLI + MCP, taxonomy, FTS search |
|
|
94
|
-
| **Processes** | Working protocols: bootstrap, cold-start, complain channel, checkpoint/wrap-up, knowledge processing | partly in the product, partly in practice |
|
|
95
|
-
| **Agents** | Thin frames (persona) + playbooks (methodology in memory); delivery into platforms | proven by PoCs #1–4 |
|
|
96
|
-
| **Tools** | CLI and MCP — the hands that put memory and processes into action | mature |
|
|
45
|
+
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.
|
|
97
46
|
|
|
98
|
-
|
|
47
|
+
[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.
|
|
99
48
|
|
|
100
|
-
|
|
49
|
+
## Everyday use and updates
|
|
101
50
|
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
### Memory
|
|
105
|
-
|
|
106
|
-
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`.
|
|
107
|
-
|
|
108
|
-
```bash
|
|
109
|
-
wolf add --type lesson --title "..." --body "..." --tags "vitest,ci" --confidence medium
|
|
110
|
-
wolf get mem_001 --latest # до актуального в supersede-цепочке
|
|
111
|
-
wolf list --type decision --stale # не обновлялись 30 дней
|
|
112
|
-
wolf search "supersede" --type rule --hide-superseded
|
|
113
|
-
wolf supersede mem_001 mem_002 # mem_001 заменён mem_002
|
|
114
|
-
wolf transition mem_002 accepted # смена статуса жизненного цикла
|
|
115
|
-
wolf relation add mem_001 supports mem_002
|
|
116
|
-
```
|
|
117
|
-
|
|
118
|
-
- `wolf taxonomy show|sync` — the effective taxonomy and its regeneration from code.
|
|
119
|
-
- `wolf validate [--fix]` — store integrity, quarantine for broken objects.
|
|
120
|
-
- FTS search over a SQLite index (`wolf rebuild-index` to rebuild).
|
|
121
|
-
- `wolf projects` — all registered projects: activity and memory size; transfer is just git — commit `.wolf/memory/`, the clone carries it.
|
|
122
|
-
|
|
123
|
-
### Processes
|
|
124
|
-
|
|
125
|
-
Agent working protocols as a product.
|
|
51
|
+
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.
|
|
126
52
|
|
|
127
53
|
```bash
|
|
128
|
-
wolf
|
|
129
|
-
wolf
|
|
130
|
-
wolf brief # сводка состояния по последнему scan + памяти
|
|
131
|
-
wolf complain --about skill:apprentice --rule "…" --evidence "…" --proposal "…" # жалоба на правило/агента → объект complaint → hot-signal Стюарду
|
|
132
|
-
wolf session checkpoint --thread <id> # точка свёртки прогресса
|
|
133
|
-
wolf session wrap-up --title "…" # session-summary завершения
|
|
134
|
-
wolf solve "битые relation-ссылки" --save # solve pack для проблемы памяти
|
|
135
|
-
wolf think start --goal "…" # последовательность: goal → мысли → решение
|
|
54
|
+
wolf upgrade --check # inspect CLI and registered-project freshness
|
|
55
|
+
wolf upgrade # update the package and registered projects
|
|
136
56
|
```
|
|
137
57
|
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
### Organization
|
|
141
|
-
|
|
142
|
-
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.
|
|
143
|
-
|
|
144
|
-
### Agents
|
|
145
|
-
|
|
146
|
-
- `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.
|
|
147
|
-
- Playbook delivery is plugin injection into the system prompt (delivery layer #1): `.opencode/plugins/wolf-router.ts`.
|
|
148
|
-
- **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.
|
|
149
|
-
|
|
150
|
-
### Tools
|
|
151
|
-
|
|
152
|
-
Tool librarian: a successful script crystallizes into a permanent project resource (search-before-write).
|
|
153
|
-
|
|
154
|
-
```bash
|
|
155
|
-
wolf tool register scripts/check.sh --name check --contract-in "нет" --contract-out "exit 0/1"
|
|
156
|
-
wolf tool list --status active
|
|
157
|
-
wolf tool use check # +1 к usage_count, напоминание контракта
|
|
158
|
-
wolf tool stats # счётчики + экономика переиспользования из сигнального лога
|
|
159
|
-
wolf tool expose check # (пере)генерировать .opencode/skills/check/SKILL.md
|
|
160
|
-
wolf tool deprecate check --reason "заменён линтером"
|
|
161
|
-
wolf tool revive check # deprecated → active
|
|
162
|
-
```
|
|
163
|
-
|
|
164
|
-
### Self-learning
|
|
165
|
-
|
|
166
|
-
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.
|
|
167
|
-
|
|
168
|
-
### Effectiveness
|
|
169
|
-
|
|
170
|
-
- `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`.
|
|
171
|
-
- `wolf task-eval --verdict accepted|rejected|partial|inconclusive` — task verdicts: acceptance, coverage, cost per accepted task; `--campaign` groups runs into A/B cohorts.
|
|
172
|
-
- Benchmarks: `scripts/bench/` (b1-repeat-debug, b2-bootstrap, b3-retrospective).
|
|
173
|
-
|
|
174
|
-
## Read isolation
|
|
175
|
-
|
|
176
|
-
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).
|
|
177
|
-
|
|
178
|
-
## Demos
|
|
179
|
-
|
|
180
|
-
Self-checking scenarios: `bash scripts/demo/scenario-N.sh`.
|
|
181
|
-
|
|
182
|
-
| # | Scenario |
|
|
183
|
-
| --- | ------------------------------------------------------------------------------------------------------------------- |
|
|
184
|
-
| 1 | Connecting Wolf to a new project (self-checking, PASS/FAIL points) |
|
|
185
|
-
| 2 | The life of a knowledge item: birth, aging (supersede), reading the current one |
|
|
186
|
-
| 3 | A new agent = one command (scaffold: playbook + frame + relation) |
|
|
187
|
-
| 4 | An owner complaint — a hot-signal into the self-learning loop |
|
|
188
|
-
| 5 | A script becomes a resource — the Librarian's tool cycle |
|
|
189
|
-
| 6 | Signal log: repeated tool errors land in session metrics (self-learning pipeline removed) |
|
|
190
|
-
| 7 | Loop hygiene: memory integrity, attribution, and noise audit |
|
|
191
|
-
| 8 | Routing: model from a routing memory object, session wrap-up recorded in memory (**one real LLM call, ~30–60 sec**) |
|
|
192
|
-
|
|
193
|
-
## Integrations
|
|
194
|
-
|
|
195
|
-
### MCP server
|
|
196
|
-
|
|
197
|
-
`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).
|
|
198
|
-
|
|
199
|
-
### opencode plugins
|
|
200
|
-
|
|
201
|
-
- `.opencode/plugins/wolf-router.ts` — injects the current playbook into the system prompt (delivery layer #1); `wolf search` is the fallback.
|
|
202
|
-
- `.opencode/plugins/wolf-session-start.js` — session start context.
|
|
203
|
-
- Agent frames live in `.opencode/agents/` (created by `wolf scaffold`).
|
|
204
|
-
|
|
205
|
-
### WOLF_ACTOR
|
|
206
|
-
|
|
207
|
-
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).
|
|
208
|
-
|
|
209
|
-
## Limitations and roadmap
|
|
210
|
-
|
|
211
|
-
- **opencode-first**: multi-platform support is an architectural principle (concept §6.6), but the threads for other platforms come after Levels 1–2 mature.
|
|
212
|
-
- **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).
|
|
213
|
-
- 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).
|
|
214
|
-
|
|
215
|
-
## Documentation
|
|
58
|
+
Review local modifications before choosing an update resolution. [Upgrade workflow](https://chekh.github.io/mister-wolf/guide/upgrade) explains diffs, protection and backups.
|
|
216
59
|
|
|
217
|
-
|
|
218
|
-
- [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)
|
|
219
|
-
- [User guide (RU)](docs/guide/user-guide.md) — basic commands and workflow
|
|
220
|
-
- [CLI reference (RU)](docs/reference/cli.md) — full command reference
|
|
221
|
-
- [Architecture (RU)](docs/guide/architecture.md) — how the system is built
|
|
222
|
-
- [Documentation index (RU)](docs/README.md)
|
|
60
|
+
## Scope and development
|
|
223
61
|
|
|
224
|
-
|
|
62
|
+
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.
|
|
225
63
|
|
|
226
|
-
|
|
64
|
+
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.
|
|
227
65
|
|
|
228
|
-
|
|
66
|
+
MIT · [License](LICENSE) · [Release history](https://chekh.github.io/mister-wolf/changelog/)
|
package/README.ru.md
CHANGED
|
@@ -2,256 +2,65 @@
|
|
|
2
2
|
|
|
3
3
|
# Mr. Wolf
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
|
|
6
6
|
|
|
7
|
-
>
|
|
8
|
-
> И руки накапливаются: каждый полезный скрипт становится постоянным ресурсом проекта.
|
|
7
|
+
> **I solve problems.**
|
|
9
8
|
>
|
|
10
|
-
>
|
|
9
|
+
> Постоянная проектная организация из временных AI-помощников.
|
|
11
10
|
|
|
12
|
-
|
|
11
|
+
Mr. Wolf организует работу AI-помощников вокруг вашей цели. Он связывает агентов, скиллы, инструменты, правила и память проекта в процесс: понять потребность, организовать выполнение, проверить результат и сохранить существенное для следующей сессии. Через Стюарда обратная связь и опыт могут превращаться в управляемые изменения способов работы организации.
|
|
13
12
|
|
|
14
|
-
|
|
13
|
+
Wolf — ваша точка общения с этой организацией: объясните потребность обычным языком, обсудите существенные решения и получите результат, который можно понять и оценить.
|
|
15
14
|
|
|
16
|
-
|
|
15
|
+
**[Документация](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)
|
|
17
16
|
|
|
18
|
-
##
|
|
17
|
+
## Зачем Wolf
|
|
19
18
|
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
| П7 | Один агент сам думает и сам себя проверяет | уверенные ошибки переживают сессию | иерархия L0/L1/L2, независимая приёмка, консилиум для спорных решений (designed, roadmap) |
|
|
27
|
-
| П8 | Одни и те же ошибки повторяются | правки живут в чат-логах, а не в проекте | жалоба → мутация playbook'а → следующая сессия работает иначе |
|
|
28
|
-
| П9 | Качество деградирует в длинном процессе | раздувание контекста, дрейф цели, потерянные решения | брифы, чекпоинты, типизированная преемственность состояния |
|
|
19
|
+
- **Удерживать цель.** L0 отвечает за цель и итоговую приёмку; L1 организует поставку; L2 выполняют ограниченные задачи. Разделение ответственности сохраняет связь частной технической работы с ожидаемым результатом на длинном пути.
|
|
20
|
+
- **Связывать методы.** Процесс определяет применимые скиллы, правила, контекст и инструменты, распределение задач, момент вопроса и способ проверки. Лицо воркера и назначенные скиллы задают нужную специализацию.
|
|
21
|
+
- **Продолжать между сессиями.** Документы проекта — часть памяти наряду с решениями, рабочим состоянием и уроками. Исходные документы остаются каноничными в своих файлах; Wolf сохраняет ссылки и относящийся контекст для дальнейшей работы.
|
|
22
|
+
- **Менять будущее поведение через Стюарда.** Жалобы могут приводить к новым версиям методик; зрелые уроки — обобщаться. Сохраняются причины и история изменений, для версий лиц доступен откат. Это обучение организации, а не обучение весов модели.
|
|
23
|
+
- **Комфортно общаться с человеком.** Содержательное уточнение намерения, ясное объяснение и своевременный вопрос входят в методику работы. Внутренние отчёты воркеров собираются в полезный ответ пользователю.
|
|
24
|
+
- **Накапливать собственные способности.** Полезные скрипты и методы могут становиться ресурсами проекта. Локальные файлы, CLI и MCP сохраняют контроль над состоянием; обращения к модели используют настроенного вами провайдера.
|
|
29
25
|
|
|
30
|
-
|
|
26
|
+
[Обзор продукта](https://chekh.github.io/mister-wolf/ru/guide/overview) объясняет связи компонентов. [Сравнение подходов](https://chekh.github.io/mister-wolf/ru/guide/capabilities#связь-с-другими-решениями) показывает отношение к памяти агентов, наборам скиллов, харнесам и мультиагентным фреймворкам без вымышленного рейтинга эффективности.
|
|
31
27
|
|
|
32
|
-
##
|
|
28
|
+
## Начните со своего проекта
|
|
33
29
|
|
|
34
|
-
|
|
35
|
-
> Пакет называется **`mister-wolf`** — именно так. Пакет `mr-wolf` в npm **чужой** (work-queue
|
|
36
|
-
> библиотека): `npm install mr-wolf` поставит сторонний код и выполнит его install-скрипты.
|
|
37
|
-
> Проверяй имя буква-в-букву перед установкой.
|
|
38
|
-
|
|
39
|
-
Установка — бинарь плюс один из двух явных путей:
|
|
40
|
-
|
|
41
|
-
```bash
|
|
42
|
-
npm install -g mister-wolf # 1) машина: бинарь wolf (уровень 0)
|
|
43
|
-
```
|
|
30
|
+
Полная организация сейчас — **OpenCode-first**. Требования: Node.js 22 или 24; macOS либо Linux с glibc.
|
|
44
31
|
|
|
45
32
|
```bash
|
|
46
|
-
|
|
47
|
-
cd my-project
|
|
48
|
-
wolf
|
|
49
|
-
|
|
50
|
-
# Путь Б — организация OpenCode: полный базовый набор + MCP
|
|
51
|
-
cd my-project && wolf init --full --platform opencode
|
|
33
|
+
npm install -g mister-wolf
|
|
34
|
+
cd my-project
|
|
35
|
+
wolf init --full --platform opencode
|
|
52
36
|
wolf bootstrap
|
|
53
37
|
```
|
|
54
38
|
|
|
55
|
-
|
|
56
|
-
- **Путь Б — организация 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-сервер — это штатно.
|
|
57
|
-
|
|
58
|
-
- **Попробовать без установки:** `npx mister-wolf init` — try-out-режим: создаёт скелет памяти `.wolf/`, но никогда не пишет ни MCP-конфиги, ни базовый сет. Понравилось — `npm install -g mister-wolf` и повтори `wolf init`.
|
|
59
|
-
- **Обновление:** `wolf upgrade` — одна команда обновляет всё: npm-фаза
|
|
60
|
-
(`npm install -g mister-wolf@latest`) и следом проход по всем зарегистрированным проектам
|
|
61
|
-
(штампованные файлы базового сета и посеянные лица; удаления — только по подтверждению).
|
|
62
|
-
`--check` — read-only сводка свежести CLI и парка; `--here` — обновить только текущий проект
|
|
63
|
-
(без npm и реестра); `--yes` — без интерактивного подтверждения, с бэкапом всего, что
|
|
64
|
-
перезаписывает. Dev/linked-установке откажет честно. `wolf sync` депрекирован →
|
|
65
|
-
`wolf upgrade --here` (алиас ещё работает и перерендеривает штампованные файлы; его уведомление
|
|
66
|
-
DEPRECATED всё ещё говорит `removed in 2.20.0` — устаревшая формулировка, команда жива).
|
|
67
|
-
- **Намерения владельца (2.20.0):** когда проходу нужно ваше слово, он называет файл и причину
|
|
68
|
-
(`mutated` / `conflict`, по путям — без голых счётчиков). `--review` разбирает решения с диффом,
|
|
69
|
-
`--show <файл|N>` печатает локальный vs эталон, `--resolve <файл|N>=take|keep|protect|pin`
|
|
70
|
-
применяет решение, `--json` — машинный канал (`wolf.upgrade/1`, а с `--check` — `wolf.upgrade.check/1`). `protect: true` (или
|
|
71
|
-
`protect: X.Y.Z`) во frontmatter agent/skill/command-файла держит файл навсегда — не
|
|
72
|
-
перезаписывается, не удаляется и остаётся видимым в `--check`. Локальный конфликт целиком:
|
|
73
|
-
|
|
74
|
-
```bash
|
|
75
|
-
wolf upgrade --check # needs decision: .opencode/agents/foo.md (mutated)
|
|
76
|
-
wolf upgrade --show 1 # дифф локальный → эталон, только чтение
|
|
77
|
-
wolf upgrade --resolve 1=protect # этот файл мой с этого момента
|
|
78
|
-
wolf upgrade --check # current · 1 protected (intentional)
|
|
79
|
-
```
|
|
80
|
-
|
|
81
|
-
Полный сценарий, бэкапы и ограничения: [Обновление проекта и парка](docs/site/ru/guide/upgrade.md).
|
|
82
|
-
|
|
83
|
-
- **Платформы v1:** opencode, Claude Code. MCP-конфиги платформ — opt-in:
|
|
84
|
-
`wolf init --platform opencode,claude` (список заменяет текущий набор); без флага платформенные
|
|
85
|
-
конфиги не пишутся.
|
|
86
|
-
- **Первый запуск без барьеров:** `wolf init` не принимает решений за тебя — минимальный набор
|
|
87
|
-
файлов по умолчанию (`--full` — полный базовый набор), один вопрос интервью в терминале
|
|
88
|
-
(Enter — пропустить), никакого пиннинга модели (`--model` — opt-in, строки модели опускаются —
|
|
89
|
-
действует платформенный дефолт). Повторный init на живом проекте покажет план и потребует
|
|
90
|
-
подтверждения (`--yes` — без вопросов).
|
|
91
|
-
- **ОС/рантайм:** macOS и Linux (glibc) на Node 22/24. Alpine/musl не поддержан в v1;
|
|
92
|
-
Windows — best-effort, не заявлена. Нативная зависимость better-sqlite3 ставится из пребилдов —
|
|
93
|
-
это поведение зависимости, у mister-wolf нет своих install-скриптов.
|
|
94
|
-
- **Если установка падает на better-sqlite3 — две разные ситуации:**
|
|
95
|
-
`prebuild-install ... no prebuilt binary found (musl)` — для вашей платформы пребилды не
|
|
96
|
-
выпускаются (Alpine/musl) — **не поддерживается в v1**, используйте glibc-дистрибутив;
|
|
97
|
-
`gyp ERR!` / `node-gyp` / сборка из исходников упала — пребилда под ваш Node нет или не
|
|
98
|
-
скачалась, поставь node-gyp prerequisites (python3, make, C++ toolchain) и повтори
|
|
99
|
-
`npm rebuild better-sqlite3` — это лечится, в отличие от musl.
|
|
100
|
-
- **Dev-путь (из клонированного репо):** `npm install && npm run build`, затем
|
|
101
|
-
`alias wolf="node dist/bootstrap/cli.js"`. При одновременно установленном глобальном
|
|
102
|
-
`mister-wolf` помни о PATH-shadowing: какой `wolf` запустится — определяется порядком каталогов
|
|
103
|
-
в PATH. В npm есть и чужой пакет `wolf` (Wolfram CLI) — глобальная установка обоих конфликтует
|
|
104
|
-
за имя бинаря, разрешается тем же порядком PATH.
|
|
105
|
-
|
|
106
|
-
Подключение агента — одна команда: `wolf scaffold agent <name>` создаёт тонкую рамку в `.opencode/agents/<name>.md`, лицо — playbook агента как версионируемый объект памяти — и relation между ними. Доставку playbook'а в сессию выполняет плагин `.opencode/plugins/wolf-router.ts` — см. [Интеграции](#интеграции).
|
|
107
|
-
|
|
108
|
-
`bootstrap` завершается вызовом Стюарда для свёртки черновиков стартовой памяти — протокол: [docs/guide/steward-bootstrap.md](docs/guide/steward-bootstrap.md).
|
|
109
|
-
|
|
110
|
-
## Versioning
|
|
111
|
-
|
|
112
|
-
- Единственный источник истины версии — `package.json`; версия меняется только командой `npm version X.Y.Z` (semver, вручную).
|
|
113
|
-
- Тег `v*` — релиз-триггер: CI прогоняет `check`+`e2e` и публикует пакет (trusted publishing, provenance).
|
|
114
|
-
- История изменений — [CHANGELOG.md](CHANGELOG.md); запись в него при релизе обязательна.
|
|
39
|
+
Имя пакета — **`mister-wolf`**; `mr-wolf` — другой пакет. После инициализации перезапустите OpenCode, чтобы загрузились проектный MCP-конфиг и агент по умолчанию.
|
|
115
40
|
|
|
116
|
-
|
|
41
|
+
Затем поручите Wolf результат, например:
|
|
117
42
|
|
|
118
|
-
|
|
43
|
+
> Помоги подготовить руководство для новых участников проекта. Используй существующие документы, выясни, что нужно новичку, и подготовь краткое руководство с проверенными шагами запуска. Спроси меня, если недостающее решение влияет на результат.
|
|
119
44
|
|
|
120
|
-
|
|
121
|
-
| --------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------- |
|
|
122
|
-
| **Память** | Единая точка правды: решения, уроки, правила, документы, процессы, инструменты; supersede-цепочки | зрел: CLI + MCP, таксономия, FTS-поиск |
|
|
123
|
-
| **Процессы** | Протоколы работы: bootstrap, cold-start, complain-канал, checkpoint/wrap-up, обработка знаний | частично в продукте, частично в практике |
|
|
124
|
-
| **Агенты** | Тонкие рамки (персона) + playbook'и (методика в памяти); доставка в платформы | доказано PoC #1–4 |
|
|
125
|
-
| **Инструменты** | CLI и MCP — руки, приводящие память и процессы в действие | зрел |
|
|
45
|
+
Поставляемые методики предписывают Wolf уточнить цель, организовать ограниченные задачи, проверить результат и сохранить существенное состояние. Ответ должен объяснять, что подготовлено, что проверено и что осталось открытым. Фактический запуск зависит от проекта, модели и харнеса; это пример поручения, а не запись выполненного прогона.
|
|
126
46
|
|
|
127
|
-
|
|
47
|
+
[Первый сеанс](https://chekh.github.io/mister-wolf/ru/guide/getting-started) объясняет bootstrap, восстановление и дополнительный режим только памяти. Для начала работы с организацией изучать таксономию памяти не требуется.
|
|
128
48
|
|
|
129
|
-
|
|
49
|
+
## Повседневная работа и обновление
|
|
130
50
|
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
### Память
|
|
134
|
-
|
|
135
|
-
Всё есть память: 8 ключевых типов (`rule`, `lesson`, `decision`, `thread`, `complaint`, `tool`, `note`, `face`) плюс фасеты, версии, связи, атрибуция. `face` — playbook агента как отдельный версионируемый тип: новые версии через `wolf face` (мутация Стюарда оставляет структурную запись), аварийный откат владельцем — `wolf face breakglass`; структурированные предложения ходят через `wolf propose`.
|
|
136
|
-
|
|
137
|
-
```bash
|
|
138
|
-
wolf add --type lesson --title "..." --body "..." --tags "vitest,ci" --confidence medium
|
|
139
|
-
wolf get mem_001 --latest # до актуального в supersede-цепочке
|
|
140
|
-
wolf list --type decision --stale # не обновлялись 30 дней
|
|
141
|
-
wolf search "supersede" --type rule --hide-superseded
|
|
142
|
-
wolf supersede mem_001 mem_002 # mem_001 заменён mem_002
|
|
143
|
-
wolf transition mem_002 accepted # смена статуса жизненного цикла
|
|
144
|
-
wolf relation add mem_001 supports mem_002
|
|
145
|
-
```
|
|
146
|
-
|
|
147
|
-
- `wolf taxonomy show|sync` — эффективная таксономия и её регенерация из кода.
|
|
148
|
-
- `wolf validate [--fix]` — целостность хранилища, карантин битых объектов.
|
|
149
|
-
- FTS-поиск по SQLite-индексу (`wolf rebuild-index` — перестройка).
|
|
150
|
-
- `wolf projects` — все зарегистрированные проекты: активность и размер памяти; перенос — это git: коммитите `.wolf/memory/`, клон переносит.
|
|
151
|
-
|
|
152
|
-
### Процессы
|
|
153
|
-
|
|
154
|
-
Протоколы работы агентов как продукт.
|
|
51
|
+
Обсуждайте задачу или замечание с Wolf в своей агентной среде. [Работа с Wolf](https://chekh.github.io/mister-wolf/ru/guide/working-with-wolf) описывает уточнение, прогресс, продолжение и обратную связь. [Стюард](https://chekh.github.io/mister-wolf/ru/guide/feedback) — изменение методик по опыту и сохранение вашего контроля.
|
|
155
52
|
|
|
156
53
|
```bash
|
|
157
|
-
wolf
|
|
158
|
-
wolf
|
|
159
|
-
wolf brief # сводка состояния по последнему scan + памяти
|
|
160
|
-
wolf complain --about skill:apprentice --rule "…" --evidence "…" --proposal "…" # жалоба на правило/агента → объект complaint → hot-signal Стюарду
|
|
161
|
-
wolf session checkpoint --thread <id> # точка свёртки прогресса
|
|
162
|
-
wolf session wrap-up --title "…" # session-summary завершения
|
|
163
|
-
wolf solve "битые relation-ссылки" --save # solve pack для проблемы памяти
|
|
164
|
-
wolf think start --goal "…" # последовательность: goal → мысли → решение
|
|
54
|
+
wolf upgrade --check # проверить актуальность CLI и зарегистрированных проектов
|
|
55
|
+
wolf upgrade # обновить пакет и зарегистрированные проекты
|
|
165
56
|
```
|
|
166
57
|
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
### Организация
|
|
170
|
-
|
|
171
|
-
Wolf работает как постоянная проектная организация из временных агентов: **координатор (L0)** держит цель и принимает результат, **исполнитель (L1)** поставляет контекст и диспетчирует, **воркеры (L2)** выполняют одиночные задачи в чистых сессиях. Роли, цикл работы и консилиум для спорных решений — [Organization & Council](https://chekh.github.io/mister-wolf/guide/organization); консилиум спроектирован и в roadmap, иерархия и независимая приёмка работают сегодня. Поправки идут через жалобный контур: жалоба → триаж → исход → мутация playbook'а → следующая сессия работает иначе.
|
|
172
|
-
|
|
173
|
-
### Агенты
|
|
174
|
-
|
|
175
|
-
- `wolf scaffold agent|skill|command <name>` — рамка платформы + лицо (playbook агента) в памяти + relation одной командой; `--persona` и `--model` для агентов, `--from-playbook <id>` — переиспользовать существующий playbook.
|
|
176
|
-
- Доставка playbook'ов — плагин-инжекция в system-промпт (слой доставки №1): `.opencode/plugins/wolf-router.ts`.
|
|
177
|
-
- **Стюард** — фоновый агент контура с лицами: **Наставник** (методики, по жалобам), **Библиотекарь** (инструменты), **Архивариус** (знания). Новое лицо = новый playbook, не новый агент — с 2.17 лицо это core-тип: версионируется через `wolf face` с обязательной записью мутации на каждую версию Стюарда, мигрируется из legacy playbook-заметок (`wolf face migrate`). С 2.14 Стюард также агрегирует зрелые уроки в одну замену — proposed, подтверждение владельцем.
|
|
178
|
-
|
|
179
|
-
### Инструменты
|
|
180
|
-
|
|
181
|
-
Tool-библиотекарь: удачный скрипт кристаллизуется в постоянный ресурс (search-before-write).
|
|
182
|
-
|
|
183
|
-
```bash
|
|
184
|
-
wolf tool register scripts/check.sh --name check --contract-in "нет" --contract-out "exit 0/1"
|
|
185
|
-
wolf tool list --status active
|
|
186
|
-
wolf tool use check # +1 к usage_count, напоминание контракта
|
|
187
|
-
wolf tool stats # счётчики + экономика переиспользования из сигнального лога
|
|
188
|
-
wolf tool expose check # (пере)генерировать .opencode/skills/check/SKILL.md
|
|
189
|
-
wolf tool deprecate check --reason "заменён линтером"
|
|
190
|
-
wolf tool revive check # deprecated → active
|
|
191
|
-
```
|
|
192
|
-
|
|
193
|
-
### Самообучение
|
|
194
|
-
|
|
195
|
-
Автономный конвейер самообучения удалён по решению владельца — уроки пишутся через `wolf add --type lesson`. Сигнальный лог (`.wolf/metrics/session-metrics.jsonl`) остался источником: его агрегируют `wolf tool stats` и `wolf analytics`.
|
|
196
|
-
|
|
197
|
-
### Эффективность
|
|
198
|
-
|
|
199
|
-
- `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`.
|
|
200
|
-
- `wolf task-eval --verdict accepted|rejected|partial|inconclusive` — вердикты по задачам: acceptance, coverage, стоимость принятой задачи; `--campaign` группирует раны в A/B-когорты.
|
|
201
|
-
- Бенчмарки: `scripts/bench/` (b1-repeat-debug, b2-bootstrap, b3-retrospective).
|
|
202
|
-
|
|
203
|
-
## Изоляция чтения
|
|
204
|
-
|
|
205
|
-
Память со 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).
|
|
206
|
-
|
|
207
|
-
## Демо
|
|
208
|
-
|
|
209
|
-
Самопроверяющиеся сценарии: `bash scripts/demo/scenario-N.sh`.
|
|
210
|
-
|
|
211
|
-
| № | Сценарий |
|
|
212
|
-
| --- | ------------------------------------------------------------------------------------------------------------------ |
|
|
213
|
-
| 1 | Подключение Wolf к новому проекту (self-checking, PASS/FAIL-точки) |
|
|
214
|
-
| 2 | Жизнь знания: рождение, устаревание (supersede), чтение актуального |
|
|
215
|
-
| 3 | Новый агент = одна команда (scaffold: playbook + рамка + связь) |
|
|
216
|
-
| 4 | Жалоба владельца — hot-signal контура самообучения |
|
|
217
|
-
| 5 | Скрипт становится ресурсом — tool-цикл Библиотекаря |
|
|
218
|
-
| 6 | Сигнальный лог: повторяющиеся тул-ошибки попадают в метрики сессий (конвейер самообучения удалён) |
|
|
219
|
-
| 7 | Гигиена контура: целостность памяти, атрибуция, аудит шума |
|
|
220
|
-
| 8 | Роутинг: модель из routing-объекта памяти, итоги сессии в памяти проекта (**один реальный LLM-вызов, ~30–60 сек**) |
|
|
221
|
-
|
|
222
|
-
## Интеграции
|
|
223
|
-
|
|
224
|
-
### MCP-сервер
|
|
225
|
-
|
|
226
|
-
`wolf mcp` — запуск MCP-сервера (stdio): вся память и процессы доступны агентам любой MCP-совместимой платформы. Список тулов и конфигурация — в [спеке MCP-интеграции](docs/specs/2026-07-01-mcp-server-integration-design.md).
|
|
227
|
-
|
|
228
|
-
### opencode-плагины
|
|
229
|
-
|
|
230
|
-
- `.opencode/plugins/wolf-router.ts` — инжекция актуального playbook в system-промпт (слой доставки №1); `wolf search` — fallback.
|
|
231
|
-
- `.opencode/plugins/wolf-session-start.js` — стартовый контекст сессии.
|
|
232
|
-
- Рамки агентов — `.opencode/agents/` (создаются `wolf scaffold`).
|
|
233
|
-
|
|
234
|
-
### WOLF_ACTOR
|
|
235
|
-
|
|
236
|
-
Атрибуция мутаций: каждый объект памяти имеет автора. Приоритет: флаг `--created-by <actor>` > env `WOLF_ACTOR` > fallback (`user:cli` для CLI-команд, `steward:<лицо>` для контура Стюарда).
|
|
237
|
-
|
|
238
|
-
## Ограничения и roadmap
|
|
239
|
-
|
|
240
|
-
- **opencode-first**: мультиплатформенность — архитектурный принцип (концепт §6.6), но нити других платформ — после зрелости Уровней 1–2.
|
|
241
|
-
- **Что не делает Wolf** (концепт §10): редактирование кода как проектная функция · IDE-интеграция · веб-интерфейс · распределённая работа · оркестрация общего назначения (только протоколы, доказанные практикой).
|
|
242
|
-
- План: [roadmap-v4](docs/dev/roadmap/roadmap-v4.md) — активный роадмап; история: [v3](docs/dev/roadmap/roadmap-v3.md), [v2](docs/dev/roadmap/roadmap-v2.md).
|
|
243
|
-
|
|
244
|
-
## Документация
|
|
58
|
+
Перед выбором исхода обновления изучите локальные изменения. [Порядок обновления](https://chekh.github.io/mister-wolf/ru/guide/upgrade) объясняет diff, защиту и резервные копии.
|
|
245
59
|
|
|
246
|
-
|
|
247
|
-
- [Roadmap v4](docs/dev/roadmap/roadmap-v4.md) — активный роадмап; история: [v3](docs/dev/roadmap/roadmap-v3.md), [v2](docs/dev/roadmap/roadmap-v2.md)
|
|
248
|
-
- [User guide](docs/guide/user-guide.md) — базовые команды и workflow
|
|
249
|
-
- [CLI reference](docs/reference/cli.md) — полный справочник команд
|
|
250
|
-
- [Architecture](docs/guide/architecture.md) — устройство системы
|
|
251
|
-
- [Индекс документации](docs/README.md)
|
|
60
|
+
## Границы и разработка
|
|
252
61
|
|
|
253
|
-
|
|
62
|
+
Организационные методы Wolf применимы за пределами программирования; в поставке есть исследования, работа с документами и отчёты. Текущая реализация основана на репозитории и прежде всего OpenCode. Доступ по MCP или конфигурация другой платформы не означают проверенную полную организацию на ней. Исполняемый консилиум, пользовательская консоль и устойчивое выполнение после сбоя пока не гарантируются. См. [возможности и границы](https://chekh.github.io/mister-wolf/ru/guide/capabilities). [Изоляция чтения](https://chekh.github.io/mister-wolf/ru/guide/read-isolation) применяется к доставке через `wolf call`, а не к общему доступу на чтение.
|
|
254
63
|
|
|
255
|
-
|
|
64
|
+
**Сайт — единая актуальная пользовательская документация**; исходники — `docs/site/`. [Инженерные документы](docs/README.md) сохраняют концепцию, требования, дизайн и роадмап в Git. [Contributing](CONTRIBUTING.md) описывает разработку и проверки документации. Сравнительный выигрыш в скорости, стоимости или качестве без соответствующего наблюдения не обещается.
|
|
256
65
|
|
|
257
|
-
|
|
66
|
+
MIT · [Лицензия](LICENSE) · [История выпусков](https://chekh.github.io/mister-wolf/ru/changelog/)
|
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
* Append-only, derived/rebuildable (инвариант §9), запись детерминированная, без LLM.
|
|
4
4
|
* Формат: OTEL GenAI-совместимые поля по спеке §2.1 (session_id, gen_ai.*, orchestration.*,
|
|
5
5
|
* outcome); gen_ai.modelID — обязательное поле (PoC#4, §21 п.23; null — модель неизвестна).
|
|
6
|
-
* Документация формата: docs/guide/
|
|
6
|
+
* Документация формата: docs/site/guide/telemetry.md. Спека:
|
|
7
7
|
* docs/specs/2026-08-26-self-learning-design.md §2.1, §2.2.
|
|
8
8
|
*
|
|
9
9
|
* Writer-матрица D1 (M20-07, решение Q3): writer'ы — сами CLI-команды (complain,
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "mister-wolf",
|
|
3
|
-
"version": "2.27.
|
|
4
|
-
"description": "
|
|
3
|
+
"version": "2.27.1",
|
|
4
|
+
"description": "A local-first project organization for AI assistants: goal-directed processes, project memory and governed learning",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"ai-agents",
|
|
7
7
|
"mcp",
|
|
@@ -42,7 +42,8 @@
|
|
|
42
42
|
"check": "node scripts/check-english-surface.mjs && npm run format:check && npm run lint && npm run build && npm run test:run",
|
|
43
43
|
"docs:dev": "vitepress dev docs/site",
|
|
44
44
|
"docs:build": "node scripts/generate-cli-reference.mjs && node scripts/generate-cli-site-page.mjs && node scripts/sync-changelog.mjs && vitepress build docs/site",
|
|
45
|
-
"docs:preview": "vitepress preview docs/site"
|
|
45
|
+
"docs:preview": "vitepress preview docs/site",
|
|
46
|
+
"docs:check": "npm run build && npm run docs:build && node scripts/check-docs-links.mjs"
|
|
46
47
|
},
|
|
47
48
|
"dependencies": {
|
|
48
49
|
"@modelcontextprotocol/server": "^2.0.0",
|
package/update-map.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
|
-
"version": "2.27.
|
|
3
|
-
"prev": "2.
|
|
2
|
+
"version": "2.27.1",
|
|
3
|
+
"prev": "2.27.0",
|
|
4
4
|
"files": [
|
|
5
5
|
{
|
|
6
6
|
"path": "base/agents/executor-lead.md",
|
|
@@ -205,7 +205,7 @@
|
|
|
205
205
|
{
|
|
206
206
|
"path": "base/skills/wolf-git/SKILL.md",
|
|
207
207
|
"kind": "skill",
|
|
208
|
-
"category": "
|
|
208
|
+
"category": "unchanged"
|
|
209
209
|
},
|
|
210
210
|
{
|
|
211
211
|
"path": "base/skills/wolf-handoff/SKILL.md",
|