mister-wolf 2.26.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/cli/cli-entry.d.ts.map +1 -1
- package/dist/adapters/cli/cli-entry.js +11 -0
- package/dist/adapters/cli/cli-entry.js.map +1 -1
- package/dist/adapters/cli/commands/git-inspect.d.ts +7 -0
- package/dist/adapters/cli/commands/git-inspect.d.ts.map +1 -0
- package/dist/adapters/cli/commands/git-inspect.js +20 -0
- package/dist/adapters/cli/commands/git-inspect.js.map +1 -0
- package/dist/adapters/fs/session-metrics-log.js +1 -1
- package/dist/app/use-cases/git-inspect.d.ts +105 -0
- package/dist/app/use-cases/git-inspect.d.ts.map +1 -0
- package/dist/app/use-cases/git-inspect.js +359 -0
- package/dist/app/use-cases/git-inspect.js.map +1 -0
- package/package.json +4 -3
- package/templates/base/skills/wolf-git/SKILL.md +3 -1
- package/update-map.json +7 -7
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/)
|