rickub
bots-garden/mini-mepublic Fork
⑂ 460cf23
Branches
feature/agents-file feature/ask-agent-hooks feature/ask-cli feature/declared-tools feature/display-called-hooks feature/fetch-build-in feature/genkit-v1.13.1 feature/github-mcp-in-sbx feature/go-1.27.3 feature/hooks feature/improve-init feature/interactive-prompt feature/last-question feature/llmman-provider feature/log-errors feature/lsp-builtin feature/mcp-gateway-session feature/mcp-support feature/memory-search feature/mini-mes feature/mm-init feature/open-terminal feature/prompt-flag feature/response-request feature/resume-acp feature/sbx-template-kit feature/search-in-doc feature/selectors feature/skill-discovery feature/structured-output feature/system-one feature/talk-to-another-mm feature/tasks-builtin feature/try-again feature/unload-model feature/wasm-custom-tools feature/yolo feature/zed-skill-selector fix/generation-timeout fix/plan-mode fix/too-long-completion fix/tool-order fix/word-wrap improve-mem-usage main thinking
Tags
v0.0.0 v0.0.1 v0.0.2 v0.0.3 v0.0.4 v0.1.0 v0.1.1 v0.1.2 v0.1.3 v0.1.4 v0.1.5 v0.1.6 v0.1.7 v0.1.8 v0.1.9 v0.2.0 v0.2.1 v0.2.2 v0.2.3 v0.2.4 v0.2.5 v0.2.6 v0.3.0 v0.4.0 v0.5.0 v0.6.0 v0.7.0 v0.8.0 v0.9.0 v1.0.0 View all branches → View all tags →
Commits
⬇ Clone ▾
git clone https://git.rickub.com/bots-garden/mini-me.git
git clone ssh://git@rickub.com/bots-garden/mini-me.git

Host key fingerprint (ed25519): SHA256:iycHnxEyq0Q7uyVpB7JlznP0G7JrTPXLYRcAU5CSLhc — verify it before your first connect.

Download ZIP

📦 Mini Me

k33g committed 2026-09-25T17:34:18+02:00 Browse files
460cf23 parent: aa53c8e
modified INSTALL.MACOS.md +1 -1
@@ -2,7 +2,7 @@
22
33 ```bash
44 # download the binary release in https://rickub.com/bots-garden/mini-me/releases
5-VERSION=0.1.6
5+VERSION=0.1.7
66 curl -fsSLO "https://rickub.com/bots-garden/mini-me/releases/download/v${VERSION}/mm-${VERSION}-darwin-arm64"
77 chmod +x ./mm-${VERSION}-darwin-arm64
88 xattr -cr ./mm-${VERSION}-darwin-arm64
@@ -2,7 +2,7 @@
2 2
3 ```bash3 ```bash
4 # download the binary release in https://rickub.com/bots-garden/mini-me/releases4 # download the binary release in https://rickub.com/bots-garden/mini-me/releases
5-VERSION=0.1.65+VERSION=0.1.7
6 curl -fsSLO "https://rickub.com/bots-garden/mini-me/releases/download/v${VERSION}/mm-${VERSION}-darwin-arm64"6 curl -fsSLO "https://rickub.com/bots-garden/mini-me/releases/download/v${VERSION}/mm-${VERSION}-darwin-arm64"
7 chmod +x ./mm-${VERSION}-darwin-arm647 chmod +x ./mm-${VERSION}-darwin-arm64
8 xattr -cr ./mm-${VERSION}-darwin-arm648 xattr -cr ./mm-${VERSION}-darwin-arm64
modified demo/MCP-GITHUB-SBX.en.md +3 -3
@@ -30,7 +30,7 @@ api.github.com
3030
3131 ## Prerequisites
3232
33-- `mm` **0.1.6 or later**. Earlier versions do not open an MCP session, so the
33+- `mm` **0.1.7 or later**. Earlier versions do not open an MCP session, so the
3434 gateway rejects everything with
3535 `method "tools/list" is invalid during session initialization`.
3636 - A GitHub token. Here it is in the shell variable `GITHUB_OAUTH_TOKEN`. A
@@ -92,7 +92,7 @@ The script path must be **absolute**, hence `$PWD`.
9292 ```bash
9393 cd demo
9494 sbx rm mm-mcp-github 2>/dev/null
95-sbx run --name mm-mcp-github --static-mcp github-mm k33g/mm-tui:0.1.6 . -- agent.dmr.sbx.yaml
95+sbx run --name mm-mcp-github --static-mcp github-mm k33g/mm-tui:0.1.7 . -- agent.dmr.sbx.yaml
9696 ```
9797
9898 Two rules to remember:
@@ -156,7 +156,7 @@ enabled give 44 tools.
156156 | `set up MCP gateway: … all 1 backend connections failed` | The script exited before answering. | Read the log below. |
157157 | Log: `github-mcp: no token` | No token in the keychain. | Step 1. |
158158 | Banner without any `sbx-gateway_*` | The sandbox was created without `--static-mcp`, or the flag is after `--`. | Step 4: `sbx rm`, then start again. |
159-| `method "tools/list" is invalid during session initialization` | `mm` is older than 0.1.6. | Update the image or the kit. |
159+| `method "tools/list" is invalid during session initialization` | `mm` is older than 0.1.7. | Update the image or the kit. |
160160 | Tools `search_users`, `push_files`, no `get_me` | The archived `github` server is still in use. | Step 3: `sbx mcp rm github`. |
161161 | `Not Found` on every call | The model invented the repository. | Name `owner/repo` in the request. |
162162
@@ -30,7 +30,7 @@ api.github.com
30 30
31 ## Prerequisites31 ## Prerequisites
32 32
33-- `mm` **0.1.6 or later**. Earlier versions do not open an MCP session, so the33+- `mm` **0.1.7 or later**. Earlier versions do not open an MCP session, so the
34 gateway rejects everything with34 gateway rejects everything with
35 `method "tools/list" is invalid during session initialization`.35 `method "tools/list" is invalid during session initialization`.
36 - A GitHub token. Here it is in the shell variable `GITHUB_OAUTH_TOKEN`. A36 - A GitHub token. Here it is in the shell variable `GITHUB_OAUTH_TOKEN`. A
@@ -92,7 +92,7 @@ The script path must be **absolute**, hence `$PWD`.
92 ```bash92 ```bash
93 cd demo93 cd demo
94 sbx rm mm-mcp-github 2>/dev/null94 sbx rm mm-mcp-github 2>/dev/null
95-sbx run --name mm-mcp-github --static-mcp github-mm k33g/mm-tui:0.1.6 . -- agent.dmr.sbx.yaml95+sbx run --name mm-mcp-github --static-mcp github-mm k33g/mm-tui:0.1.7 . -- agent.dmr.sbx.yaml
96 ```96 ```
97 97
98 Two rules to remember:98 Two rules to remember:
@@ -156,7 +156,7 @@ enabled give 44 tools.
156 | `set up MCP gateway: … all 1 backend connections failed` | The script exited before answering. | Read the log below. |156 | `set up MCP gateway: … all 1 backend connections failed` | The script exited before answering. | Read the log below. |
157 | Log: `github-mcp: no token` | No token in the keychain. | Step 1. |157 | Log: `github-mcp: no token` | No token in the keychain. | Step 1. |
158 | Banner without any `sbx-gateway_*` | The sandbox was created without `--static-mcp`, or the flag is after `--`. | Step 4: `sbx rm`, then start again. |158 | Banner without any `sbx-gateway_*` | The sandbox was created without `--static-mcp`, or the flag is after `--`. | Step 4: `sbx rm`, then start again. |
159-| `method "tools/list" is invalid during session initialization` | `mm` is older than 0.1.6. | Update the image or the kit. |159+| `method "tools/list" is invalid during session initialization` | `mm` is older than 0.1.7. | Update the image or the kit. |
160 | Tools `search_users`, `push_files`, no `get_me` | The archived `github` server is still in use. | Step 3: `sbx mcp rm github`. |160 | Tools `search_users`, `push_files`, no `get_me` | The archived `github` server is still in use. | Step 3: `sbx mcp rm github`. |
161 | `Not Found` on every call | The model invented the repository. | Name `owner/repo` in the request. |161 | `Not Found` on every call | The model invented the repository. | Name `owner/repo` in the request. |
162 162
modified demo/MCP-GITHUB-SBX.md +3 -3
@@ -30,7 +30,7 @@ api.github.com
3030
3131 ## Prérequis
3232
33-- `mm` en version **0.1.6 ou plus**. Les versions antérieures n'ouvrent pas de
33+- `mm` en version **0.1.7 ou plus**. Les versions antérieures n'ouvrent pas de
3434 session MCP. La passerelle refuse alors tout avec
3535 `method "tools/list" is invalid during session initialization`.
3636 - Un jeton GitHub. Ici, il est dans la variable `GITHUB_OAUTH_TOKEN` du shell. Un
@@ -92,7 +92,7 @@ Le chemin du script doit être **absolu**, d'où `$PWD`.
9292 ```bash
9393 cd demo
9494 sbx rm mm-mcp-github 2>/dev/null
95-sbx run --name mm-mcp-github --static-mcp github-mm k33g/mm-tui:0.1.6 . -- agent.dmr.sbx.yaml
95+sbx run --name mm-mcp-github --static-mcp github-mm k33g/mm-tui:0.1.7 . -- agent.dmr.sbx.yaml
9696 ```
9797
9898 Deux règles à retenir :
@@ -156,7 +156,7 @@ d'outils en écriture donnent 44 outils.
156156 | `set up MCP gateway: … all 1 backend connections failed` | Le script s'est arrêté avant de répondre. | Lis le journal ci-dessous. |
157157 | Journal : `github-mcp: no token` | Pas de jeton dans le trousseau. | Étape 1. |
158158 | Bannière sans aucun `sbx-gateway_*` | La sandbox a été créée sans `--static-mcp`, ou l'option est après `--`. | Étape 4 : `sbx rm`, puis relancer. |
159-| `method "tools/list" is invalid during session initialization` | `mm` est antérieur à 0.1.6. | Mettre à jour l'image ou le kit. |
159+| `method "tools/list" is invalid during session initialization` | `mm` est antérieur à 0.1.7. | Mettre à jour l'image ou le kit. |
160160 | Outils `search_users`, `push_files`, sans `get_me` | Le serveur archivé `github` est encore utilisé. | Étape 3 : `sbx mcp rm github`. |
161161 | `Not Found` sur chaque appel | Le modèle a inventé le dépôt. | Nommer `propriétaire/dépôt` dans la demande. |
162162
@@ -30,7 +30,7 @@ api.github.com
30 30
31 ## Prérequis31 ## Prérequis
32 32
33-- `mm` en version **0.1.6 ou plus**. Les versions antérieures n'ouvrent pas de33+- `mm` en version **0.1.7 ou plus**. Les versions antérieures n'ouvrent pas de
34 session MCP. La passerelle refuse alors tout avec34 session MCP. La passerelle refuse alors tout avec
35 `method "tools/list" is invalid during session initialization`.35 `method "tools/list" is invalid during session initialization`.
36 - Un jeton GitHub. Ici, il est dans la variable `GITHUB_OAUTH_TOKEN` du shell. Un36 - Un jeton GitHub. Ici, il est dans la variable `GITHUB_OAUTH_TOKEN` du shell. Un
@@ -92,7 +92,7 @@ Le chemin du script doit être **absolu**, d'où `$PWD`.
92 ```bash92 ```bash
93 cd demo93 cd demo
94 sbx rm mm-mcp-github 2>/dev/null94 sbx rm mm-mcp-github 2>/dev/null
95-sbx run --name mm-mcp-github --static-mcp github-mm k33g/mm-tui:0.1.6 . -- agent.dmr.sbx.yaml95+sbx run --name mm-mcp-github --static-mcp github-mm k33g/mm-tui:0.1.7 . -- agent.dmr.sbx.yaml
96 ```96 ```
97 97
98 Deux règles à retenir :98 Deux règles à retenir :
@@ -156,7 +156,7 @@ d'outils en écriture donnent 44 outils.
156 | `set up MCP gateway: … all 1 backend connections failed` | Le script s'est arrêté avant de répondre. | Lis le journal ci-dessous. |156 | `set up MCP gateway: … all 1 backend connections failed` | Le script s'est arrêté avant de répondre. | Lis le journal ci-dessous. |
157 | Journal : `github-mcp: no token` | Pas de jeton dans le trousseau. | Étape 1. |157 | Journal : `github-mcp: no token` | Pas de jeton dans le trousseau. | Étape 1. |
158 | Bannière sans aucun `sbx-gateway_*` | La sandbox a été créée sans `--static-mcp`, ou l'option est après `--`. | Étape 4 : `sbx rm`, puis relancer. |158 | Bannière sans aucun `sbx-gateway_*` | La sandbox a été créée sans `--static-mcp`, ou l'option est après `--`. | Étape 4 : `sbx rm`, puis relancer. |
159-| `method "tools/list" is invalid during session initialization` | `mm` est antérieur à 0.1.6. | Mettre à jour l'image ou le kit. |159+| `method "tools/list" is invalid during session initialization` | `mm` est antérieur à 0.1.7. | Mettre à jour l'image ou le kit. |
160 | Outils `search_users`, `push_files`, sans `get_me` | Le serveur archivé `github` est encore utilisé. | Étape 3 : `sbx mcp rm github`. |160 | Outils `search_users`, `push_files`, sans `get_me` | Le serveur archivé `github` est encore utilisé. | Étape 3 : `sbx mcp rm github`. |
161 | `Not Found` sur chaque appel | Le modèle a inventé le dépôt. | Nommer `propriétaire/dépôt` dans la demande. |161 | `Not Found` sur chaque appel | Le modèle a inventé le dépôt. | Nommer `propriétaire/dépôt` dans la demande. |
162 162
modified docker-sbx/README.md +16 -16
@@ -25,29 +25,29 @@ Every release publishes the image and the two kits to Docker Hub at mm's version
2525
2626 | On Docker Hub | What it is |
2727 |---|---|
28-| `k33g/mm-sandbox:0.1.6` | The template image. You never name it yourself: each kit pulls it. |
29-| `k33g/mm-tui:0.1.6` | The window-mode kit, for `sbx run`. |
30-| `k33g/mm-acp:0.1.6` | The editor kit, for `sbx create` + `sbx exec -i … mm -acp`. |
28+| `k33g/mm-sandbox:0.1.7` | The template image. You never name it yourself: each kit pulls it. |
29+| `k33g/mm-tui:0.1.7` | The window-mode kit, for `sbx run`. |
30+| `k33g/mm-acp:0.1.7` | The editor kit, for `sbx create` + `sbx exec -i … mm -acp`. |
3131
3232 Nothing to build, no `--pull never`, and no setting to change: Docker Hub is an allowed kit source out of the box (`sbx settings get kit.allowedSources` shows `docker.io/`), and a reference with a `/` but no registry host is read as `docker.io/…`. Only Docker Desktop with the `sbx` command, and a model server on your machine, are needed.
3333
3434 **Look before you run.** `sbx kit inspect` reads the kit from the Hub without creating anything: its image, its entry point, its arguments and their defaults, the ports it allows.
3535
3636 ```bash
37-sbx kit inspect k33g/mm-tui:0.1.6
37+sbx kit inspect k33g/mm-tui:0.1.7
3838 ```
3939
4040 **Window mode.** From the project you want mm to work on:
4141
4242 ```bash
4343 cd /path/to/your/project
44-sbx run k33g/mm-tui:0.1.6 . -- agent.dmr.yaml
44+sbx run k33g/mm-tui:0.1.7 . -- agent.dmr.yaml
4545 ```
4646
4747 The first run pulls the kit and the image, creates the sandbox `mm-tui-<directory>`, mounts the current directory as its workspace and opens `mm -tui agent.dmr.yaml` in it. What follows `--` is mm's own command line, so `-- -config other.yaml` works too. Without anything after `--`, mm reads the kit's `config` argument, then `./agent.yaml` in the workspace:
4848
4949 ```bash
50-sbx run k33g/mm-tui:0.1.6 . --kit-arg config=agent.dmr.yaml
50+sbx run k33g/mm-tui:0.1.7 . --kit-arg config=agent.dmr.yaml
5151 ```
5252
5353 Later, `sbx run --name mm-tui-<directory>` re-attaches to that sandbox; `sbx ls` lists them.
@@ -56,9 +56,9 @@ Later, `sbx run --name mm-tui-<directory>` re-attaches to that sandbox; `sbx ls`
5656
5757 ```bash
5858 cd /path/to/your/project
59-sbx create --name mm-acp k33g/mm-acp:0.1.6 . --kit-arg config=agent.dmr.yaml
59+sbx create --name mm-acp k33g/mm-acp:0.1.7 . --kit-arg config=agent.dmr.yaml
6060
61-#sbx create k33g/mm-acp:0.1.6 . --name sbx-mm-acp
61+#sbx create k33g/mm-acp:0.1.7 . --name sbx-mm-acp
6262 ```
6363
6464 then register it in the editor — in Zed's `settings.json`:
@@ -82,9 +82,9 @@ The editor starts `mm -acp` inside the sandbox for every conversation; `sbx exec
8282 | `--kit-arg` | Default | Effect |
8383 |---|---|---|
8484 | `config=<path>` | empty | The file mm reads (its `AGENT_CONFIG`): relative to the workspace, or absolute inside the sandbox. Empty: `./agent.yaml`, then the built-in defaults. |
85-| `tag=<version>` | the kit's own version (`0.1.6`) | Which `k33g/mm-sandbox:<version>` image to use. Normally left alone: a kit and its image share a version. |
85+| `tag=<version>` | the kit's own version (`0.1.7`) | Which `k33g/mm-sandbox:<version>` image to use. Normally left alone: a kit and its image share a version. |
8686
87-**Other versions.** Replace `0.1.6` with the release you want, in the kit reference only — the kit brings the matching image. A kit can also be pinned by digest, `k33g/mm-tui@sha256:…`, the digest being what `sbx kit inspect` or the Hub page shows.
87+**Other versions.** Replace `0.1.7` with the release you want, in the kit reference only — the kit brings the matching image. A kit can also be pinned by digest, `k33g/mm-tui@sha256:…`, the digest being what `sbx kit inspect` or the Hub page shows.
8888
8989 **If sbx refuses the source.** A message like `its source is not in your allowlist` means `kit.allowedSources` was narrowed on this machine; `sbx settings set kit.allowedSources '["docker.io/"]'` restores the default, or add `docker.io/k33g/` to your list.
9090
@@ -95,11 +95,11 @@ Sections 1–3 are the same flow with a template and kits built locally, for a w
9595 From the repository root:
9696
9797 ```bash
98-./docker-sbx/build.sh # TAG from release.env: v0.1.6 → k33g/mm-sandbox:0.1.6
98+./docker-sbx/build.sh # TAG from release.env: v0.1.7 → k33g/mm-sandbox:0.1.7
9999 ./docker-sbx/build.sh v0.1.5 # → k33g/mm-sandbox:0.1.5
100100 ```
101101
102-The image tag is mm's tag without the `v`, the same rule as the release assets, and the script rewrites the kits' default `tag` argument to the version it built, so the kits always name the image just built. The image lands in the local Docker image store: every `sbx run` / `sbx create` below carries `--pull never` until you `docker push k33g/mm-sandbox:0.1.6`. If `sbx` runs on another machine, `EXPORT=1 ./docker-sbx/build.sh` also writes `tmp/mm-sandbox-<version>.tar`; load it there with `sbx template load`.
102+The image tag is mm's tag without the `v`, the same rule as the release assets, and the script rewrites the kits' default `tag` argument to the version it built, so the kits always name the image just built. The image lands in the local Docker image store: every `sbx run` / `sbx create` below carries `--pull never` until you `docker push k33g/mm-sandbox:0.1.7`. If `sbx` runs on another machine, `EXPORT=1 ./docker-sbx/build.sh` also writes `tmp/mm-sandbox-<version>.tar`; load it there with `sbx template load`.
103103
104104 ## 2. Window mode in the terminal — kit `mm-tui`
105105
@@ -114,7 +114,7 @@ What follows `--` reaches `mm` as its own arguments, so this runs `mm -tui agent
114114 | `--kit-arg` | Default | Effect |
115115 |---|---|---|
116116 | `config=<path>` | empty | The file `mm` reads when nothing follows `--` (its `AGENT_CONFIG`). Relative to the workspace, or absolute. Empty: `./agent.yaml`, then the built-in defaults. |
117-| `tag=<version>` | the version last built (`0.1.6`) | Which `k33g/mm-sandbox:<version>` image to use. |
117+| `tag=<version>` | the version last built (`0.1.7`) | Which `k33g/mm-sandbox:<version>` image to use. |
118118
119119 `sbx run --name <name>` re-attaches to a sandbox that already exists. Sessions, when enabled in the YAML, are written under the workspace's `.mm/sessions`, which is your host directory.
120120
@@ -127,7 +127,7 @@ cd /path/to/your/project
127127 sbx create --pull never --name mm-acp ./docker-sbx/kits/mm-acp . \
128128 --kit-arg config=agent.dmr.yaml
129129
130-# once the image is pushed (docker push k33g/mm-sandbox:0.1.6), --pull never is not needed:
130+# once the image is pushed (docker push k33g/mm-sandbox:0.1.7), --pull never is not needed:
131131 sbx create --name mm-acp ./docker-sbx/kits/mm-acp . \
132132 --kit-arg config=agent.dmr.yaml
133133 ```
@@ -185,7 +185,7 @@ Publishing is done by hand, from a laptop with Docker Desktop (buildx and the `s
185185 ```bash
186186 export DOCKER_HANDLE=k33g # the Docker Hub account, also the image owner
187187 export DOCKER_PAT=dckr_pat_… # an access token with read/write scope
188-./docker-sbx/publish.sh # TAG from release.env: v0.1.6 → k33g/mm-sandbox:0.1.6, k33g/mm-tui:0.1.6, k33g/mm-acp:0.1.6
188+./docker-sbx/publish.sh # TAG from release.env: v0.1.7 → k33g/mm-sandbox:0.1.7, k33g/mm-tui:0.1.7, k33g/mm-acp:0.1.7
189189 ./docker-sbx/publish.sh v0.1.5 # another tag
190190 ```
191191
@@ -193,7 +193,7 @@ With the two variables set, the script logs in with them and logs out at the end
193193
194194 ```bash
195195 PUSH=1 ./docker-sbx/build.sh v0.2.3 # buildx multi-arch, pushed; proof: `imagetools inspect` lists both platforms
196-./docker-sbx/push-kits.sh v0.1.6 # sbx kit validate + sbx kit push, for each kit
196+./docker-sbx/push-kits.sh v0.1.7 # sbx kit validate + sbx kit push, for each kit
197197 ```
198198
199199 Both call `sync-kits.sh` first, so the published kits always name the image just pushed, and the kits' `spec.yaml` end up saying the new version — commit them. `sbx kit push` talks to the registry directly and authenticates from the Docker credential store; no sandbox daemon is involved. `IMAGE_OWNER=<handle>` publishes under another account. Nothing in CI publishes to the Hub: the Release workflow only builds the binaries.
@@ -25,29 +25,29 @@ Every release publishes the image and the two kits to Docker Hub at mm's version
25 25
26 | On Docker Hub | What it is |26 | On Docker Hub | What it is |
27 |---|---|27 |---|---|
28-| `k33g/mm-sandbox:0.1.6` | The template image. You never name it yourself: each kit pulls it. |28+| `k33g/mm-sandbox:0.1.7` | The template image. You never name it yourself: each kit pulls it. |
29-| `k33g/mm-tui:0.1.6` | The window-mode kit, for `sbx run`. |29+| `k33g/mm-tui:0.1.7` | The window-mode kit, for `sbx run`. |
30-| `k33g/mm-acp:0.1.6` | The editor kit, for `sbx create` + `sbx exec -i … mm -acp`. |30+| `k33g/mm-acp:0.1.7` | The editor kit, for `sbx create` + `sbx exec -i … mm -acp`. |
31 31
32 Nothing to build, no `--pull never`, and no setting to change: Docker Hub is an allowed kit source out of the box (`sbx settings get kit.allowedSources` shows `docker.io/`), and a reference with a `/` but no registry host is read as `docker.io/…`. Only Docker Desktop with the `sbx` command, and a model server on your machine, are needed.32 Nothing to build, no `--pull never`, and no setting to change: Docker Hub is an allowed kit source out of the box (`sbx settings get kit.allowedSources` shows `docker.io/`), and a reference with a `/` but no registry host is read as `docker.io/…`. Only Docker Desktop with the `sbx` command, and a model server on your machine, are needed.
33 33
34 **Look before you run.** `sbx kit inspect` reads the kit from the Hub without creating anything: its image, its entry point, its arguments and their defaults, the ports it allows.34 **Look before you run.** `sbx kit inspect` reads the kit from the Hub without creating anything: its image, its entry point, its arguments and their defaults, the ports it allows.
35 35
36 ```bash36 ```bash
37-sbx kit inspect k33g/mm-tui:0.1.637+sbx kit inspect k33g/mm-tui:0.1.7
38 ```38 ```
39 39
40 **Window mode.** From the project you want mm to work on:40 **Window mode.** From the project you want mm to work on:
41 41
42 ```bash42 ```bash
43 cd /path/to/your/project43 cd /path/to/your/project
44-sbx run k33g/mm-tui:0.1.6 . -- agent.dmr.yaml44+sbx run k33g/mm-tui:0.1.7 . -- agent.dmr.yaml
45 ```45 ```
46 46
47 The first run pulls the kit and the image, creates the sandbox `mm-tui-<directory>`, mounts the current directory as its workspace and opens `mm -tui agent.dmr.yaml` in it. What follows `--` is mm's own command line, so `-- -config other.yaml` works too. Without anything after `--`, mm reads the kit's `config` argument, then `./agent.yaml` in the workspace:47 The first run pulls the kit and the image, creates the sandbox `mm-tui-<directory>`, mounts the current directory as its workspace and opens `mm -tui agent.dmr.yaml` in it. What follows `--` is mm's own command line, so `-- -config other.yaml` works too. Without anything after `--`, mm reads the kit's `config` argument, then `./agent.yaml` in the workspace:
48 48
49 ```bash49 ```bash
50-sbx run k33g/mm-tui:0.1.6 . --kit-arg config=agent.dmr.yaml50+sbx run k33g/mm-tui:0.1.7 . --kit-arg config=agent.dmr.yaml
51 ```51 ```
52 52
53 Later, `sbx run --name mm-tui-<directory>` re-attaches to that sandbox; `sbx ls` lists them.53 Later, `sbx run --name mm-tui-<directory>` re-attaches to that sandbox; `sbx ls` lists them.
@@ -56,9 +56,9 @@ Later, `sbx run --name mm-tui-<directory>` re-attaches to that sandbox; `sbx ls`
56 56
57 ```bash57 ```bash
58 cd /path/to/your/project58 cd /path/to/your/project
59-sbx create --name mm-acp k33g/mm-acp:0.1.6 . --kit-arg config=agent.dmr.yaml59+sbx create --name mm-acp k33g/mm-acp:0.1.7 . --kit-arg config=agent.dmr.yaml
60 60
61-#sbx create k33g/mm-acp:0.1.6 . --name sbx-mm-acp61+#sbx create k33g/mm-acp:0.1.7 . --name sbx-mm-acp
62 ```62 ```
63 63
64 then register it in the editor — in Zed's `settings.json`:64 then register it in the editor — in Zed's `settings.json`:
@@ -82,9 +82,9 @@ The editor starts `mm -acp` inside the sandbox for every conversation; `sbx exec
82 | `--kit-arg` | Default | Effect |82 | `--kit-arg` | Default | Effect |
83 |---|---|---|83 |---|---|---|
84 | `config=<path>` | empty | The file mm reads (its `AGENT_CONFIG`): relative to the workspace, or absolute inside the sandbox. Empty: `./agent.yaml`, then the built-in defaults. |84 | `config=<path>` | empty | The file mm reads (its `AGENT_CONFIG`): relative to the workspace, or absolute inside the sandbox. Empty: `./agent.yaml`, then the built-in defaults. |
85-| `tag=<version>` | the kit's own version (`0.1.6`) | Which `k33g/mm-sandbox:<version>` image to use. Normally left alone: a kit and its image share a version. |85+| `tag=<version>` | the kit's own version (`0.1.7`) | Which `k33g/mm-sandbox:<version>` image to use. Normally left alone: a kit and its image share a version. |
86 86
87-**Other versions.** Replace `0.1.6` with the release you want, in the kit reference only — the kit brings the matching image. A kit can also be pinned by digest, `k33g/mm-tui@sha256:…`, the digest being what `sbx kit inspect` or the Hub page shows.87+**Other versions.** Replace `0.1.7` with the release you want, in the kit reference only — the kit brings the matching image. A kit can also be pinned by digest, `k33g/mm-tui@sha256:…`, the digest being what `sbx kit inspect` or the Hub page shows.
88 88
89 **If sbx refuses the source.** A message like `its source is not in your allowlist` means `kit.allowedSources` was narrowed on this machine; `sbx settings set kit.allowedSources '["docker.io/"]'` restores the default, or add `docker.io/k33g/` to your list.89 **If sbx refuses the source.** A message like `its source is not in your allowlist` means `kit.allowedSources` was narrowed on this machine; `sbx settings set kit.allowedSources '["docker.io/"]'` restores the default, or add `docker.io/k33g/` to your list.
90 90
@@ -95,11 +95,11 @@ Sections 1–3 are the same flow with a template and kits built locally, for a w
95 From the repository root:95 From the repository root:
96 96
97 ```bash97 ```bash
98-./docker-sbx/build.sh # TAG from release.env: v0.1.6 → k33g/mm-sandbox:0.1.698+./docker-sbx/build.sh # TAG from release.env: v0.1.7 → k33g/mm-sandbox:0.1.7
99 ./docker-sbx/build.sh v0.1.5 # → k33g/mm-sandbox:0.1.599 ./docker-sbx/build.sh v0.1.5 # → k33g/mm-sandbox:0.1.5
100 ```100 ```
101 101
102-The image tag is mm's tag without the `v`, the same rule as the release assets, and the script rewrites the kits' default `tag` argument to the version it built, so the kits always name the image just built. The image lands in the local Docker image store: every `sbx run` / `sbx create` below carries `--pull never` until you `docker push k33g/mm-sandbox:0.1.6`. If `sbx` runs on another machine, `EXPORT=1 ./docker-sbx/build.sh` also writes `tmp/mm-sandbox-<version>.tar`; load it there with `sbx template load`.102+The image tag is mm's tag without the `v`, the same rule as the release assets, and the script rewrites the kits' default `tag` argument to the version it built, so the kits always name the image just built. The image lands in the local Docker image store: every `sbx run` / `sbx create` below carries `--pull never` until you `docker push k33g/mm-sandbox:0.1.7`. If `sbx` runs on another machine, `EXPORT=1 ./docker-sbx/build.sh` also writes `tmp/mm-sandbox-<version>.tar`; load it there with `sbx template load`.
103 103
104 ## 2. Window mode in the terminal — kit `mm-tui`104 ## 2. Window mode in the terminal — kit `mm-tui`
105 105
@@ -114,7 +114,7 @@ What follows `--` reaches `mm` as its own arguments, so this runs `mm -tui agent
114 | `--kit-arg` | Default | Effect |114 | `--kit-arg` | Default | Effect |
115 |---|---|---|115 |---|---|---|
116 | `config=<path>` | empty | The file `mm` reads when nothing follows `--` (its `AGENT_CONFIG`). Relative to the workspace, or absolute. Empty: `./agent.yaml`, then the built-in defaults. |116 | `config=<path>` | empty | The file `mm` reads when nothing follows `--` (its `AGENT_CONFIG`). Relative to the workspace, or absolute. Empty: `./agent.yaml`, then the built-in defaults. |
117-| `tag=<version>` | the version last built (`0.1.6`) | Which `k33g/mm-sandbox:<version>` image to use. |117+| `tag=<version>` | the version last built (`0.1.7`) | Which `k33g/mm-sandbox:<version>` image to use. |
118 118
119 `sbx run --name <name>` re-attaches to a sandbox that already exists. Sessions, when enabled in the YAML, are written under the workspace's `.mm/sessions`, which is your host directory.119 `sbx run --name <name>` re-attaches to a sandbox that already exists. Sessions, when enabled in the YAML, are written under the workspace's `.mm/sessions`, which is your host directory.
120 120
@@ -127,7 +127,7 @@ cd /path/to/your/project
127 sbx create --pull never --name mm-acp ./docker-sbx/kits/mm-acp . \127 sbx create --pull never --name mm-acp ./docker-sbx/kits/mm-acp . \
128 --kit-arg config=agent.dmr.yaml128 --kit-arg config=agent.dmr.yaml
129 129
130-# once the image is pushed (docker push k33g/mm-sandbox:0.1.6), --pull never is not needed:130+# once the image is pushed (docker push k33g/mm-sandbox:0.1.7), --pull never is not needed:
131 sbx create --name mm-acp ./docker-sbx/kits/mm-acp . \131 sbx create --name mm-acp ./docker-sbx/kits/mm-acp . \
132 --kit-arg config=agent.dmr.yaml132 --kit-arg config=agent.dmr.yaml
133 ```133 ```
@@ -185,7 +185,7 @@ Publishing is done by hand, from a laptop with Docker Desktop (buildx and the `s
185 ```bash185 ```bash
186 export DOCKER_HANDLE=k33g # the Docker Hub account, also the image owner186 export DOCKER_HANDLE=k33g # the Docker Hub account, also the image owner
187 export DOCKER_PAT=dckr_pat_… # an access token with read/write scope187 export DOCKER_PAT=dckr_pat_… # an access token with read/write scope
188-./docker-sbx/publish.sh # TAG from release.env: v0.1.6 → k33g/mm-sandbox:0.1.6, k33g/mm-tui:0.1.6, k33g/mm-acp:0.1.6188+./docker-sbx/publish.sh # TAG from release.env: v0.1.7 → k33g/mm-sandbox:0.1.7, k33g/mm-tui:0.1.7, k33g/mm-acp:0.1.7
189 ./docker-sbx/publish.sh v0.1.5 # another tag189 ./docker-sbx/publish.sh v0.1.5 # another tag
190 ```190 ```
191 191
@@ -193,7 +193,7 @@ With the two variables set, the script logs in with them and logs out at the end
193 193
194 ```bash194 ```bash
195 PUSH=1 ./docker-sbx/build.sh v0.2.3 # buildx multi-arch, pushed; proof: `imagetools inspect` lists both platforms195 PUSH=1 ./docker-sbx/build.sh v0.2.3 # buildx multi-arch, pushed; proof: `imagetools inspect` lists both platforms
196-./docker-sbx/push-kits.sh v0.1.6 # sbx kit validate + sbx kit push, for each kit196+./docker-sbx/push-kits.sh v0.1.7 # sbx kit validate + sbx kit push, for each kit
197 ```197 ```
198 198
199 Both call `sync-kits.sh` first, so the published kits always name the image just pushed, and the kits' `spec.yaml` end up saying the new version — commit them. `sbx kit push` talks to the registry directly and authenticates from the Docker credential store; no sandbox daemon is involved. `IMAGE_OWNER=<handle>` publishes under another account. Nothing in CI publishes to the Hub: the Release workflow only builds the binaries.199 Both call `sync-kits.sh` first, so the published kits always name the image just pushed, and the kits' `spec.yaml` end up saying the new version — commit them. `sbx kit push` talks to the registry directly and authenticates from the Docker credential store; no sandbox daemon is involved. `IMAGE_OWNER=<handle>` publishes under another account. Nothing in CI publishes to the Hub: the Release workflow only builds the binaries.
modified docker-sbx/USE.MM.SBX-WITH.TURBO.EDITORS.md +1 -1
@@ -2,7 +2,7 @@
22
33 Start `sbx` in your project directory:
44 ```bash
5-sbx create k33g/mm-acp:0.1.6 . --name turbo-acp --kit-arg config=.turbo-go/agent.mm-dmr-gemma.yaml
5+sbx create k33g/mm-acp:0.1.7 . --name turbo-acp --kit-arg config=.turbo-go/agent.mm-dmr-gemma.yaml
66 ```
77
88 `acp.toml`:
@@ -2,7 +2,7 @@
2 2
3 Start `sbx` in your project directory:3 Start `sbx` in your project directory:
4 ```bash4 ```bash
5-sbx create k33g/mm-acp:0.1.6 . --name turbo-acp --kit-arg config=.turbo-go/agent.mm-dmr-gemma.yaml5+sbx create k33g/mm-acp:0.1.7 . --name turbo-acp --kit-arg config=.turbo-go/agent.mm-dmr-gemma.yaml
6 ```6 ```
7 7
8 `acp.toml`:8 `acp.toml`:
modified docker-sbx/USE.MM.SBX-WITH.ZED.EDITOR.md +1 -1
@@ -2,7 +2,7 @@
22
33 Start `sbx` in your project directory:
44 ```bash
5-sbx create k33g/mm-acp:0.1.6 . --name zed-acp --kit-arg config=agent.dmr.yaml
5+sbx create k33g/mm-acp:0.1.7 . --name zed-acp --kit-arg config=agent.dmr.yaml
66 ```
77
88 Zed settings:
@@ -2,7 +2,7 @@
2 2
3 Start `sbx` in your project directory:3 Start `sbx` in your project directory:
4 ```bash4 ```bash
5-sbx create k33g/mm-acp:0.1.6 . --name zed-acp --kit-arg config=agent.dmr.yaml5+sbx create k33g/mm-acp:0.1.7 . --name zed-acp --kit-arg config=agent.dmr.yaml
6 ```6 ```
7 7
8 Zed settings:8 Zed settings:
modified docs/en/how-to/navigate-code-with-lsp.md +1 -1
@@ -71,7 +71,7 @@ This guide shows how to give `mm` a language server, so the model can ask the co
7171
7272 ```text
7373 [warning: lsp server ghost (no-such-lsp-server) not found on the PATH — skipped]
74- mm v0.1.6 | config: agent.lsp.yaml | provider: dmr | model: … | ctx: unknown | tools: bash, read_skill, read_file, write_file, edit_file, lsp | skills: 4
74+ mm v0.1.7 | config: agent.lsp.yaml | provider: dmr | model: … | ctx: unknown | tools: bash, read_skill, read_file, write_file, edit_file, lsp | skills: 4
7575 ```
7676
7777 `lsp` in the `tools:` column means at least one server was found. Servers start on their first use, not here.
@@ -71,7 +71,7 @@ This guide shows how to give `mm` a language server, so the model can ask the co
71 71
72 ```text72 ```text
73 [warning: lsp server ghost (no-such-lsp-server) not found on the PATH — skipped]73 [warning: lsp server ghost (no-such-lsp-server) not found on the PATH — skipped]
74- mm v0.1.6 | config: agent.lsp.yaml | provider: dmr | model: … | ctx: unknown | tools: bash, read_skill, read_file, write_file, edit_file, lsp | skills: 474+ mm v0.1.7 | config: agent.lsp.yaml | provider: dmr | model: … | ctx: unknown | tools: bash, read_skill, read_file, write_file, edit_file, lsp | skills: 4
75 ```75 ```
76 76
77 `lsp` in the `tools:` column means at least one server was found. Servers start on their first use, not here.77 `lsp` in the `tools:` column means at least one server was found. Servers start on their first use, not here.
modified docs/en/how-to/run-in-a-docker-sandbox.md +9 -9
@@ -14,20 +14,20 @@ Everything lives under [`docker-sbx/`](../../../docker-sbx/README.md) in the rep
1414
1515 ## Use the published kits
1616
17-Every release publishes the image and both kits to Docker Hub at mm's version — `k33g/mm-sandbox:0.1.6`, `k33g/mm-tui:0.1.6`, `k33g/mm-acp:0.1.6` — so the shortest path needs no build at all. Docker Hub is an allowed kit source by default (`sbx settings get kit.allowedSources` shows `docker.io/`), and a reference with a `/` but no registry host is read as `docker.io/…`:
17+Every release publishes the image and both kits to Docker Hub at mm's version — `k33g/mm-sandbox:0.1.7`, `k33g/mm-tui:0.1.7`, `k33g/mm-acp:0.1.7` — so the shortest path needs no build at all. Docker Hub is an allowed kit source by default (`sbx settings get kit.allowedSources` shows `docker.io/`), and a reference with a `/` but no registry host is read as `docker.io/…`:
1818
1919 ```bash
2020 cd /path/to/your/project
21-sbx run k33g/mm-tui:0.1.6 . -- agent.dmr.yaml
21+sbx run k33g/mm-tui:0.1.7 . -- agent.dmr.yaml
2222 ```
2323
2424 for the window mode, and for an editor:
2525
2626 ```bash
27-sbx create --name mm-acp k33g/mm-acp:0.1.6 . --kit-arg config=agent.dmr.yaml
27+sbx create --name mm-acp k33g/mm-acp:0.1.7 . --kit-arg config=agent.dmr.yaml
2828 ```
2929
30-then the editor registration of step 3 below. No `--pull never`: the kit names `k33g/mm-sandbox:0.1.6` and sbx pulls it. `sbx kit inspect k33g/mm-tui:0.1.6` shows what a kit declares before you run it. The steps that follow build the same thing locally, for a work-in-progress mm.
30+then the editor registration of step 3 below. No `--pull never`: the kit names `k33g/mm-sandbox:0.1.7` and sbx pulls it. `sbx kit inspect k33g/mm-tui:0.1.7` shows what a kit declares before you run it. The steps that follow build the same thing locally, for a work-in-progress mm.
3131
3232 ## Steps
3333
@@ -39,9 +39,9 @@ From the repository root:
3939 ./docker-sbx/build.sh
4040 ```
4141
42-This reads mm's tag from `release.env` (`v0.1.6`) and builds `k33g/mm-sandbox:0.1.6`: the image tag is the version without the `v`, like the release assets, and `mm` inside is stamped with the tag — `mm --version` is run in the image as proof. The script then rewrites the kits' default `tag` argument to `0.1.6`, so the kits and the image move together. `./docker-sbx/build.sh v0.1.5` builds another version; an earlier image stays reachable with `--kit-arg tag=0.1.4`.
42+This reads mm's tag from `release.env` (`v0.1.7`) and builds `k33g/mm-sandbox:0.1.7`: the image tag is the version without the `v`, like the release assets, and `mm` inside is stamped with the tag — `mm --version` is run in the image as proof. The script then rewrites the kits' default `tag` argument to `0.1.7`, so the kits and the image move together. `./docker-sbx/build.sh v0.1.5` builds another version; an earlier image stays reachable with `--kit-arg tag=0.1.4`.
4343
44-The image is in your local Docker image store: every `sbx run` or `sbx create` on these kits takes `--pull never` until the image is pushed (`docker push k33g/mm-sandbox:0.1.6`), or `sbx` tries to pull it and fails. If `sbx` runs on another machine, `EXPORT=1 ./docker-sbx/build.sh` also writes `tmp/mm-sandbox-0.1.6.tar`, to load there with `sbx template load`.
44+The image is in your local Docker image store: every `sbx run` or `sbx create` on these kits takes `--pull never` until the image is pushed (`docker push k33g/mm-sandbox:0.1.7`), or `sbx` tries to pull it and fails. If `sbx` runs on another machine, `EXPORT=1 ./docker-sbx/build.sh` also writes `tmp/mm-sandbox-0.1.7.tar`, to load there with `sbx template load`.
4545
4646 ### 2. Window mode in the terminal (kit `mm-tui`)
4747
@@ -62,7 +62,7 @@ sbx run --pull never ./docker-sbx/kits/mm-tui . --kit-arg config=agent.dmr.yaml
6262 | `--kit-arg` | Default | Effect |
6363 |---|---|---|
6464 | `config=<path>` | empty | The configuration file, as `mm`'s `AGENT_CONFIG`: relative to the workspace, or absolute inside the sandbox. |
65-| `tag=<version>` | the version last built (`0.1.6`) | Which `k33g/mm-sandbox:<version>` image the sandbox is made from. |
65+| `tag=<version>` | the version last built (`0.1.7`) | Which `k33g/mm-sandbox:<version>` image the sandbox is made from. |
6666
6767 The sandbox keeps its name (`mm-tui-<directory>` unless you pass `--name`); `sbx run --name <name>` re-attaches to it later. Inside, the window is the one described in [Use the window mode](use-the-window-mode.md). Sessions, when `sessions.enabled` is on, are written under the workspace's `.mm/sessions` — that is your host directory, so they survive the sandbox.
6868
@@ -118,10 +118,10 @@ Publishing is a manual step, from a machine with Docker Desktop (buildx and the
118118 ```bash
119119 export DOCKER_HANDLE=k33g # the Docker Hub account, also the image owner
120120 export DOCKER_PAT=dckr_pat_… # an access token with read/write scope
121-./docker-sbx/publish.sh # TAG from release.env: v0.1.6 → k33g/mm-sandbox:0.1.6, k33g/mm-tui:0.1.6, k33g/mm-acp:0.1.6
121+./docker-sbx/publish.sh # TAG from release.env: v0.1.7 → k33g/mm-sandbox:0.1.7, k33g/mm-tui:0.1.7, k33g/mm-acp:0.1.7
122122 ```
123123
124-With both variables set, the script logs in with them and logs out when it is done; with neither, it reuses your existing `docker login`. Its two halves run alone as `PUSH=1 ./docker-sbx/build.sh v0.1.6` (image) and `./docker-sbx/push-kits.sh v0.1.6` (kits, `SBX=/path/to/sbx` if the CLI is not on the PATH). Both call `sync-kits.sh` first, which rewrites the kits' `version`, default `tag` and image owner, so a published kit always names the image pushed with it — commit the two `spec.yaml` afterwards. `sbx kit push` talks to the registry directly and authenticates from the Docker credential store, no sandbox daemon involved. `IMAGE_OWNER=<handle>` publishes under another account.
124+With both variables set, the script logs in with them and logs out when it is done; with neither, it reuses your existing `docker login`. Its two halves run alone as `PUSH=1 ./docker-sbx/build.sh v0.1.7` (image) and `./docker-sbx/push-kits.sh v0.1.7` (kits, `SBX=/path/to/sbx` if the CLI is not on the PATH). Both call `sync-kits.sh` first, which rewrites the kits' `version`, default `tag` and image owner, so a published kit always names the image pushed with it — commit the two `spec.yaml` afterwards. `sbx kit push` talks to the registry directly and authenticates from the Docker credential store, no sandbox daemon involved. `IMAGE_OWNER=<handle>` publishes under another account.
125125
126126 ## MCP servers through the sbx gateway (GitHub as the example)
127127
@@ -14,20 +14,20 @@ Everything lives under [`docker-sbx/`](../../../docker-sbx/README.md) in the rep
14 14
15 ## Use the published kits15 ## Use the published kits
16 16
17-Every release publishes the image and both kits to Docker Hub at mm's version — `k33g/mm-sandbox:0.1.6`, `k33g/mm-tui:0.1.6`, `k33g/mm-acp:0.1.6` — so the shortest path needs no build at all. Docker Hub is an allowed kit source by default (`sbx settings get kit.allowedSources` shows `docker.io/`), and a reference with a `/` but no registry host is read as `docker.io/…`:17+Every release publishes the image and both kits to Docker Hub at mm's version — `k33g/mm-sandbox:0.1.7`, `k33g/mm-tui:0.1.7`, `k33g/mm-acp:0.1.7` — so the shortest path needs no build at all. Docker Hub is an allowed kit source by default (`sbx settings get kit.allowedSources` shows `docker.io/`), and a reference with a `/` but no registry host is read as `docker.io/…`:
18 18
19 ```bash19 ```bash
20 cd /path/to/your/project20 cd /path/to/your/project
21-sbx run k33g/mm-tui:0.1.6 . -- agent.dmr.yaml21+sbx run k33g/mm-tui:0.1.7 . -- agent.dmr.yaml
22 ```22 ```
23 23
24 for the window mode, and for an editor:24 for the window mode, and for an editor:
25 25
26 ```bash26 ```bash
27-sbx create --name mm-acp k33g/mm-acp:0.1.6 . --kit-arg config=agent.dmr.yaml27+sbx create --name mm-acp k33g/mm-acp:0.1.7 . --kit-arg config=agent.dmr.yaml
28 ```28 ```
29 29
30-then the editor registration of step 3 below. No `--pull never`: the kit names `k33g/mm-sandbox:0.1.6` and sbx pulls it. `sbx kit inspect k33g/mm-tui:0.1.6` shows what a kit declares before you run it. The steps that follow build the same thing locally, for a work-in-progress mm.30+then the editor registration of step 3 below. No `--pull never`: the kit names `k33g/mm-sandbox:0.1.7` and sbx pulls it. `sbx kit inspect k33g/mm-tui:0.1.7` shows what a kit declares before you run it. The steps that follow build the same thing locally, for a work-in-progress mm.
31 31
32 ## Steps32 ## Steps
33 33
@@ -39,9 +39,9 @@ From the repository root:
39 ./docker-sbx/build.sh39 ./docker-sbx/build.sh
40 ```40 ```
41 41
42-This reads mm's tag from `release.env` (`v0.1.6`) and builds `k33g/mm-sandbox:0.1.6`: the image tag is the version without the `v`, like the release assets, and `mm` inside is stamped with the tag — `mm --version` is run in the image as proof. The script then rewrites the kits' default `tag` argument to `0.1.6`, so the kits and the image move together. `./docker-sbx/build.sh v0.1.5` builds another version; an earlier image stays reachable with `--kit-arg tag=0.1.4`.42+This reads mm's tag from `release.env` (`v0.1.7`) and builds `k33g/mm-sandbox:0.1.7`: the image tag is the version without the `v`, like the release assets, and `mm` inside is stamped with the tag — `mm --version` is run in the image as proof. The script then rewrites the kits' default `tag` argument to `0.1.7`, so the kits and the image move together. `./docker-sbx/build.sh v0.1.5` builds another version; an earlier image stays reachable with `--kit-arg tag=0.1.4`.
43 43
44-The image is in your local Docker image store: every `sbx run` or `sbx create` on these kits takes `--pull never` until the image is pushed (`docker push k33g/mm-sandbox:0.1.6`), or `sbx` tries to pull it and fails. If `sbx` runs on another machine, `EXPORT=1 ./docker-sbx/build.sh` also writes `tmp/mm-sandbox-0.1.6.tar`, to load there with `sbx template load`.44+The image is in your local Docker image store: every `sbx run` or `sbx create` on these kits takes `--pull never` until the image is pushed (`docker push k33g/mm-sandbox:0.1.7`), or `sbx` tries to pull it and fails. If `sbx` runs on another machine, `EXPORT=1 ./docker-sbx/build.sh` also writes `tmp/mm-sandbox-0.1.7.tar`, to load there with `sbx template load`.
45 45
46 ### 2. Window mode in the terminal (kit `mm-tui`)46 ### 2. Window mode in the terminal (kit `mm-tui`)
47 47
@@ -62,7 +62,7 @@ sbx run --pull never ./docker-sbx/kits/mm-tui . --kit-arg config=agent.dmr.yaml
62 | `--kit-arg` | Default | Effect |62 | `--kit-arg` | Default | Effect |
63 |---|---|---|63 |---|---|---|
64 | `config=<path>` | empty | The configuration file, as `mm`'s `AGENT_CONFIG`: relative to the workspace, or absolute inside the sandbox. |64 | `config=<path>` | empty | The configuration file, as `mm`'s `AGENT_CONFIG`: relative to the workspace, or absolute inside the sandbox. |
65-| `tag=<version>` | the version last built (`0.1.6`) | Which `k33g/mm-sandbox:<version>` image the sandbox is made from. |65+| `tag=<version>` | the version last built (`0.1.7`) | Which `k33g/mm-sandbox:<version>` image the sandbox is made from. |
66 66
67 The sandbox keeps its name (`mm-tui-<directory>` unless you pass `--name`); `sbx run --name <name>` re-attaches to it later. Inside, the window is the one described in [Use the window mode](use-the-window-mode.md). Sessions, when `sessions.enabled` is on, are written under the workspace's `.mm/sessions` — that is your host directory, so they survive the sandbox.67 The sandbox keeps its name (`mm-tui-<directory>` unless you pass `--name`); `sbx run --name <name>` re-attaches to it later. Inside, the window is the one described in [Use the window mode](use-the-window-mode.md). Sessions, when `sessions.enabled` is on, are written under the workspace's `.mm/sessions` — that is your host directory, so they survive the sandbox.
68 68
@@ -118,10 +118,10 @@ Publishing is a manual step, from a machine with Docker Desktop (buildx and the
118 ```bash118 ```bash
119 export DOCKER_HANDLE=k33g # the Docker Hub account, also the image owner119 export DOCKER_HANDLE=k33g # the Docker Hub account, also the image owner
120 export DOCKER_PAT=dckr_pat_… # an access token with read/write scope120 export DOCKER_PAT=dckr_pat_… # an access token with read/write scope
121-./docker-sbx/publish.sh # TAG from release.env: v0.1.6 → k33g/mm-sandbox:0.1.6, k33g/mm-tui:0.1.6, k33g/mm-acp:0.1.6121+./docker-sbx/publish.sh # TAG from release.env: v0.1.7 → k33g/mm-sandbox:0.1.7, k33g/mm-tui:0.1.7, k33g/mm-acp:0.1.7
122 ```122 ```
123 123
124-With both variables set, the script logs in with them and logs out when it is done; with neither, it reuses your existing `docker login`. Its two halves run alone as `PUSH=1 ./docker-sbx/build.sh v0.1.6` (image) and `./docker-sbx/push-kits.sh v0.1.6` (kits, `SBX=/path/to/sbx` if the CLI is not on the PATH). Both call `sync-kits.sh` first, which rewrites the kits' `version`, default `tag` and image owner, so a published kit always names the image pushed with it — commit the two `spec.yaml` afterwards. `sbx kit push` talks to the registry directly and authenticates from the Docker credential store, no sandbox daemon involved. `IMAGE_OWNER=<handle>` publishes under another account.124+With both variables set, the script logs in with them and logs out when it is done; with neither, it reuses your existing `docker login`. Its two halves run alone as `PUSH=1 ./docker-sbx/build.sh v0.1.7` (image) and `./docker-sbx/push-kits.sh v0.1.7` (kits, `SBX=/path/to/sbx` if the CLI is not on the PATH). Both call `sync-kits.sh` first, which rewrites the kits' `version`, default `tag` and image owner, so a published kit always names the image pushed with it — commit the two `spec.yaml` afterwards. `sbx kit push` talks to the registry directly and authenticates from the Docker credential store, no sandbox daemon involved. `IMAGE_OWNER=<handle>` publishes under another account.
125 125
126 ## MCP servers through the sbx gateway (GitHub as the example)126 ## MCP servers through the sbx gateway (GitHub as the example)
127 127
modified docs/en/how-to/use-from-an-editor.md +1 -1
@@ -47,7 +47,7 @@ This guide shows how to host `mm` inside an editor that speaks the Agent Client
4747 | mm -acp -config /absolute/path/to/agent.yaml 2>/dev/null | head -1
4848 ```
4949
50- The answer carries `"agentInfo":{"name":"bob","title":"Bob (bash-first agent)","version":"v0.1.6"}` with the default settings.
50+ The answer carries `"agentInfo":{"name":"bob","title":"Bob (bash-first agent)","version":"v0.1.7"}` with the default settings.
5151
5252 ## See also
5353
@@ -47,7 +47,7 @@ This guide shows how to host `mm` inside an editor that speaks the Agent Client
47 | mm -acp -config /absolute/path/to/agent.yaml 2>/dev/null | head -147 | mm -acp -config /absolute/path/to/agent.yaml 2>/dev/null | head -1
48 ```48 ```
49 49
50- The answer carries `"agentInfo":{"name":"bob","title":"Bob (bash-first agent)","version":"v0.1.6"}` with the default settings.50+ The answer carries `"agentInfo":{"name":"bob","title":"Bob (bash-first agent)","version":"v0.1.7"}` with the default settings.
51 51
52 ## See also52 ## See also
53 53
modified docs/en/reference/acp.md +1 -1
@@ -19,7 +19,7 @@
1919 | `agentCapabilities` | `loadSession: true` when `sessions.enabled` is set, absent (false) otherwise. Everything else absent (false): no image or audio prompts, no HTTP MCP. |
2020 | `agentInfo.name` | `acp.name` of the configuration, `bob` by default. |
2121 | `agentInfo.title` | `acp.title` of the configuration, `Bob (bash-first agent)` by default; absent when empty. |
22-| `agentInfo.version` | The binary's version, the same string as `mm --version` (for example `v0.1.6`). |
22+| `agentInfo.version` | The binary's version, the same string as `mm --version` (for example `v0.1.7`). |
2323 | `authMethods` | `[]` |
2424
2525 ## Methods
@@ -19,7 +19,7 @@
19 | `agentCapabilities` | `loadSession: true` when `sessions.enabled` is set, absent (false) otherwise. Everything else absent (false): no image or audio prompts, no HTTP MCP. |19 | `agentCapabilities` | `loadSession: true` when `sessions.enabled` is set, absent (false) otherwise. Everything else absent (false): no image or audio prompts, no HTTP MCP. |
20 | `agentInfo.name` | `acp.name` of the configuration, `bob` by default. |20 | `agentInfo.name` | `acp.name` of the configuration, `bob` by default. |
21 | `agentInfo.title` | `acp.title` of the configuration, `Bob (bash-first agent)` by default; absent when empty. |21 | `agentInfo.title` | `acp.title` of the configuration, `Bob (bash-first agent)` by default; absent when empty. |
22-| `agentInfo.version` | The binary's version, the same string as `mm --version` (for example `v0.1.6`). |22+| `agentInfo.version` | The binary's version, the same string as `mm --version` (for example `v0.1.7`). |
23 | `authMethods` | `[]` |23 | `authMethods` | `[]` |
24 24
25 ## Methods25 ## Methods
modified docs/en/reference/cli.md +4 -4
@@ -24,14 +24,14 @@ mm [-config <path>] [-acp] [-tui] [-prompt <text>|-p <text>] [--version] [--abou
2424 `mm --version` (or `-version`) prints one line and exits, before the configuration file is looked for — so it answers in any directory, with no model server running:
2525
2626 ```
27-mm v0.1.6 (go1.26.5, darwin/arm64)
27+mm v0.1.7 (go1.26.5, darwin/arm64)
2828 ```
2929
30-`mm --about` prints the same version inside a short description of the program. The version also opens the start-up banner (`mm v0.1.6 | config: …`), which the window mode keeps as the conversation's first line, and sits in the window's status bar before the counters.
30+`mm --about` prints the same version inside a short description of the program. The version also opens the start-up banner (`mm v0.1.7 | config: …`), which the window mode keeps as the conversation's first line, and sits in the window's status bar before the counters.
3131
3232 | Where it comes from | What you see |
3333 |---|---|
34-| A release binary, stamped at build time by `02-build-releases.sh` | The tag: `v0.1.6` |
34+| A release binary, stamped at build time by `02-build-releases.sh` | The tag: `v0.1.7` |
3535 | `go install`ed from a tagged version | That tag |
3636 | Built by hand from a working tree (`go build`, `./install.sh`) | The short commit, `9073268`, with `+dirty` when the tree had uncommitted changes |
3737 | Built with `-buildvcs=false` | `unknown` |
@@ -73,7 +73,7 @@ Printed on stdout in terminal mode, on stderr in ACP mode. Dimmed when stdout is
7373
7474 ```
7575 [warning: llamacpp: nothing answers at http://127.0.0.1:8080/v1 — start it: llama-server -m <model.gguf> --jinja --port 8080]
76-mm v0.1.6 | config: agent.llamacpp.yaml | provider: llamacpp | model: jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
76+mm v0.1.7 | config: agent.llamacpp.yaml | provider: llamacpp | model: jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
7777 ```
7878
7979 ## ACP mode specifics
@@ -24,14 +24,14 @@ mm [-config <path>] [-acp] [-tui] [-prompt <text>|-p <text>] [--version] [--abou
24 `mm --version` (or `-version`) prints one line and exits, before the configuration file is looked for — so it answers in any directory, with no model server running:24 `mm --version` (or `-version`) prints one line and exits, before the configuration file is looked for — so it answers in any directory, with no model server running:
25 25
26 ```26 ```
27-mm v0.1.6 (go1.26.5, darwin/arm64)27+mm v0.1.7 (go1.26.5, darwin/arm64)
28 ```28 ```
29 29
30-`mm --about` prints the same version inside a short description of the program. The version also opens the start-up banner (`mm v0.1.6 | config: …`), which the window mode keeps as the conversation's first line, and sits in the window's status bar before the counters.30+`mm --about` prints the same version inside a short description of the program. The version also opens the start-up banner (`mm v0.1.7 | config: …`), which the window mode keeps as the conversation's first line, and sits in the window's status bar before the counters.
31 31
32 | Where it comes from | What you see |32 | Where it comes from | What you see |
33 |---|---|33 |---|---|
34-| A release binary, stamped at build time by `02-build-releases.sh` | The tag: `v0.1.6` |34+| A release binary, stamped at build time by `02-build-releases.sh` | The tag: `v0.1.7` |
35 | `go install`ed from a tagged version | That tag |35 | `go install`ed from a tagged version | That tag |
36 | Built by hand from a working tree (`go build`, `./install.sh`) | The short commit, `9073268`, with `+dirty` when the tree had uncommitted changes |36 | Built by hand from a working tree (`go build`, `./install.sh`) | The short commit, `9073268`, with `+dirty` when the tree had uncommitted changes |
37 | Built with `-buildvcs=false` | `unknown` |37 | Built with `-buildvcs=false` | `unknown` |
@@ -73,7 +73,7 @@ Printed on stdout in terminal mode, on stderr in ACP mode. Dimmed when stdout is
73 73
74 ```74 ```
75 [warning: llamacpp: nothing answers at http://127.0.0.1:8080/v1 — start it: llama-server -m <model.gguf> --jinja --port 8080]75 [warning: llamacpp: nothing answers at http://127.0.0.1:8080/v1 — start it: llama-server -m <model.gguf> --jinja --port 8080]
76-mm v0.1.6 | config: agent.llamacpp.yaml | provider: llamacpp | model: jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 076+mm v0.1.7 | config: agent.llamacpp.yaml | provider: llamacpp | model: jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
77 ```77 ```
78 78
79 ## ACP mode specifics79 ## ACP mode specifics
modified docs/en/tutorials/getting-started.md +1 -1
@@ -32,7 +32,7 @@ Type:
3232 You should see a banner like this one (the model name is the one from `agent.yaml`):
3333
3434 ```
35-mm v0.1.6 | config: agent.yaml | provider: dmr | model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
35+mm v0.1.7 | config: agent.yaml | provider: dmr | model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
3636 Agent ready. Commands: "/quit" to exit, "/abort" to stop current generation, "/compact" to compress the history, "/new" to start a new session, "/sessions" and "/resume" for stored sessions, "/help" to list them.
3737 Shortcut: Ctrl+C to abort generation, or Ctrl+C at prompt to quit.
3838
@@ -32,7 +32,7 @@ Type:
32 You should see a banner like this one (the model name is the one from `agent.yaml`):32 You should see a banner like this one (the model name is the one from `agent.yaml`):
33 33
34 ```34 ```
35-mm v0.1.6 | config: agent.yaml | provider: dmr | model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 035+mm v0.1.7 | config: agent.yaml | provider: dmr | model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
36 Agent ready. Commands: "/quit" to exit, "/abort" to stop current generation, "/compact" to compress the history, "/new" to start a new session, "/sessions" and "/resume" for stored sessions, "/help" to list them.36 Agent ready. Commands: "/quit" to exit, "/abort" to stop current generation, "/compact" to compress the history, "/new" to start a new session, "/sessions" and "/resume" for stored sessions, "/help" to list them.
37 Shortcut: Ctrl+C to abort generation, or Ctrl+C at prompt to quit.37 Shortcut: Ctrl+C to abort generation, or Ctrl+C at prompt to quit.
38 38
modified docs/en/tutorials/mcp-getting-started.md +1 -1
@@ -32,7 +32,7 @@ Type:
3232 You should see a banner like this one (the model name is the one from `agent.yaml`):
3333
3434 ```
35-mm v0.1.6 | config: agent.yaml | provider: dmr | model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
35+mm v0.1.7 | config: agent.yaml | provider: dmr | model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
3636 Agent ready. Commands: "/quit" to exit, "/abort" to stop current generation, "/compact" to compress the history, "/new" to start a new session, "/sessions" and "/resume" for stored sessions, "/help" to list them.
3737 Shortcut: Ctrl+C to abort generation, or Ctrl+C at prompt to quit.
3838
@@ -32,7 +32,7 @@ Type:
32 You should see a banner like this one (the model name is the one from `agent.yaml`):32 You should see a banner like this one (the model name is the one from `agent.yaml`):
33 33
34 ```34 ```
35-mm v0.1.6 | config: agent.yaml | provider: dmr | model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 035+mm v0.1.7 | config: agent.yaml | provider: dmr | model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
36 Agent ready. Commands: "/quit" to exit, "/abort" to stop current generation, "/compact" to compress the history, "/new" to start a new session, "/sessions" and "/resume" for stored sessions, "/help" to list them.36 Agent ready. Commands: "/quit" to exit, "/abort" to stop current generation, "/compact" to compress the history, "/new" to start a new session, "/sessions" and "/resume" for stored sessions, "/help" to list them.
37 Shortcut: Ctrl+C to abort generation, or Ctrl+C at prompt to quit.37 Shortcut: Ctrl+C to abort generation, or Ctrl+C at prompt to quit.
38 38
modified docs/fr/how-to/navigate-code-with-lsp.md +1 -1
@@ -71,7 +71,7 @@ Ce guide montre comment donner un serveur de langage à `mm`, pour que le modèl
7171
7272 ```text
7373 [warning: lsp server ghost (no-such-lsp-server) not found on the PATH — skipped]
74- mm v0.1.6 | config: agent.lsp.yaml | provider: dmr | model: … | ctx: unknown | tools: bash, read_skill, read_file, write_file, edit_file, lsp | skills: 4
74+ mm v0.1.7 | config: agent.lsp.yaml | provider: dmr | model: … | ctx: unknown | tools: bash, read_skill, read_file, write_file, edit_file, lsp | skills: 4
7575 ```
7676
7777 `lsp` dans la colonne `tools:` signifie qu'au moins un serveur a été trouvé. Les serveurs démarrent à leur premier usage, pas ici.
@@ -71,7 +71,7 @@ Ce guide montre comment donner un serveur de langage à `mm`, pour que le modèl
71 71
72 ```text72 ```text
73 [warning: lsp server ghost (no-such-lsp-server) not found on the PATH — skipped]73 [warning: lsp server ghost (no-such-lsp-server) not found on the PATH — skipped]
74- mm v0.1.6 | config: agent.lsp.yaml | provider: dmr | model: … | ctx: unknown | tools: bash, read_skill, read_file, write_file, edit_file, lsp | skills: 474+ mm v0.1.7 | config: agent.lsp.yaml | provider: dmr | model: … | ctx: unknown | tools: bash, read_skill, read_file, write_file, edit_file, lsp | skills: 4
75 ```75 ```
76 76
77 `lsp` dans la colonne `tools:` signifie qu'au moins un serveur a été trouvé. Les serveurs démarrent à leur premier usage, pas ici.77 `lsp` dans la colonne `tools:` signifie qu'au moins un serveur a été trouvé. Les serveurs démarrent à leur premier usage, pas ici.
modified docs/fr/how-to/run-in-a-docker-sandbox.md +9 -9
@@ -14,20 +14,20 @@ Tout est sous [`docker-sbx/`](../../../docker-sbx/README.md) dans le dépôt :
1414
1515 ## Utiliser les kits publiés
1616
17-Chaque release publie l'image et les deux kits sur Docker Hub à la version de mm — `k33g/mm-sandbox:0.1.6`, `k33g/mm-tui:0.1.6`, `k33g/mm-acp:0.1.6` — le chemin le plus court ne demande donc aucune construction. Docker Hub est une source de kits autorisée par défaut (`sbx settings get kit.allowedSources` montre `docker.io/`), et une référence avec un `/` mais sans hôte de registre est lue comme `docker.io/…` :
17+Chaque release publie l'image et les deux kits sur Docker Hub à la version de mm — `k33g/mm-sandbox:0.1.7`, `k33g/mm-tui:0.1.7`, `k33g/mm-acp:0.1.7` — le chemin le plus court ne demande donc aucune construction. Docker Hub est une source de kits autorisée par défaut (`sbx settings get kit.allowedSources` montre `docker.io/`), et une référence avec un `/` mais sans hôte de registre est lue comme `docker.io/…` :
1818
1919 ```bash
2020 cd /chemin/de/votre/projet
21-sbx run k33g/mm-tui:0.1.6 . -- agent.dmr.yaml
21+sbx run k33g/mm-tui:0.1.7 . -- agent.dmr.yaml
2222 ```
2323
2424 pour le mode fenêtre, et pour un éditeur :
2525
2626 ```bash
27-sbx create --name mm-acp k33g/mm-acp:0.1.6 . --kit-arg config=agent.dmr.yaml
27+sbx create --name mm-acp k33g/mm-acp:0.1.7 . --kit-arg config=agent.dmr.yaml
2828 ```
2929
30-puis la déclaration dans l'éditeur de l'étape 3 ci-dessous. Pas de `--pull never` : le kit nomme `k33g/mm-sandbox:0.1.6` et sbx la télécharge. `sbx kit inspect k33g/mm-tui:0.1.6` montre ce qu'un kit déclare avant de le lancer. Les étapes qui suivent construisent la même chose en local, pour un mm en cours de travail.
30+puis la déclaration dans l'éditeur de l'étape 3 ci-dessous. Pas de `--pull never` : le kit nomme `k33g/mm-sandbox:0.1.7` et sbx la télécharge. `sbx kit inspect k33g/mm-tui:0.1.7` montre ce qu'un kit déclare avant de le lancer. Les étapes qui suivent construisent la même chose en local, pour un mm en cours de travail.
3131
3232 ## Étapes
3333
@@ -39,9 +39,9 @@ Depuis la racine du dépôt :
3939 ./docker-sbx/build.sh
4040 ```
4141
42-Cela lit le tag de mm dans `release.env` (`v0.1.6`) et construit `k33g/mm-sandbox:0.1.6` : le tag de l'image est la version sans le `v`, comme les binaires de release, et le `mm` à l'intérieur est estampillé avec le tag — `mm --version` est exécuté dans l'image comme preuve. Le script réécrit ensuite la valeur par défaut de l'argument `tag` des kits à `0.1.6`, pour que kits et image avancent ensemble. `./docker-sbx/build.sh v0.1.5` construit une autre version ; une image antérieure reste joignable avec `--kit-arg tag=0.1.4`.
42+Cela lit le tag de mm dans `release.env` (`v0.1.7`) et construit `k33g/mm-sandbox:0.1.7` : le tag de l'image est la version sans le `v`, comme les binaires de release, et le `mm` à l'intérieur est estampillé avec le tag — `mm --version` est exécuté dans l'image comme preuve. Le script réécrit ensuite la valeur par défaut de l'argument `tag` des kits à `0.1.7`, pour que kits et image avancent ensemble. `./docker-sbx/build.sh v0.1.5` construit une autre version ; une image antérieure reste joignable avec `--kit-arg tag=0.1.4`.
4343
44-L'image est dans votre store d'images Docker local : chaque `sbx run` ou `sbx create` sur ces kits prend `--pull never` tant qu'elle n'est pas poussée (`docker push k33g/mm-sandbox:0.1.6`), sinon `sbx` tente de la télécharger et échoue. Si `sbx` tourne sur une autre machine, `EXPORT=1 ./docker-sbx/build.sh` écrit aussi `tmp/mm-sandbox-0.1.6.tar`, à charger là-bas avec `sbx template load`.
44+L'image est dans votre store d'images Docker local : chaque `sbx run` ou `sbx create` sur ces kits prend `--pull never` tant qu'elle n'est pas poussée (`docker push k33g/mm-sandbox:0.1.7`), sinon `sbx` tente de la télécharger et échoue. Si `sbx` tourne sur une autre machine, `EXPORT=1 ./docker-sbx/build.sh` écrit aussi `tmp/mm-sandbox-0.1.7.tar`, à charger là-bas avec `sbx template load`.
4545
4646 ### 2. Mode fenêtre dans le terminal (kit `mm-tui`)
4747
@@ -62,7 +62,7 @@ sbx run --pull never ./docker-sbx/kits/mm-tui . --kit-arg config=agent.dmr.yaml
6262 | `--kit-arg` | Défaut | Effet |
6363 |---|---|---|
6464 | `config=<chemin>` | vide | Le fichier de configuration, comme `AGENT_CONFIG` de `mm` : relatif à l'espace de travail, ou absolu dans le sandbox. |
65-| `tag=<version>` | la dernière version construite (`0.1.6`) | L'image `k33g/mm-sandbox:<version>` dont le sandbox est fait. |
65+| `tag=<version>` | la dernière version construite (`0.1.7`) | L'image `k33g/mm-sandbox:<version>` dont le sandbox est fait. |
6666
6767 Le sandbox garde son nom (`mm-tui-<répertoire>` sauf `--name`) ; `sbx run --name <nom>` s'y rattache plus tard. À l'intérieur, la fenêtre est celle décrite dans [Utiliser le mode fenêtre](use-the-window-mode.md). Les sessions, quand `sessions.enabled` est actif, sont écrites sous `.mm/sessions` dans l'espace de travail — c'est votre répertoire hôte, elles survivent donc au sandbox.
6868
@@ -118,10 +118,10 @@ La publication est une étape manuelle, depuis une machine avec Docker Desktop (
118118 ```bash
119119 export DOCKER_HANDLE=k33g # le compte Docker Hub, aussi propriétaire de l'image
120120 export DOCKER_PAT=dckr_pat_… # un jeton d'accès en lecture/écriture
121-./docker-sbx/publish.sh # TAG depuis release.env : v0.1.6 → k33g/mm-sandbox:0.1.6, k33g/mm-tui:0.1.6, k33g/mm-acp:0.1.6
121+./docker-sbx/publish.sh # TAG depuis release.env : v0.1.7 → k33g/mm-sandbox:0.1.7, k33g/mm-tui:0.1.7, k33g/mm-acp:0.1.7
122122 ```
123123
124-Avec les deux variables, le script se connecte avec elles et se déconnecte à la fin ; sans elles, il réutilise votre `docker login` existant. Ses deux moitiés se lancent seules : `PUSH=1 ./docker-sbx/build.sh v0.1.6` (l'image) et `./docker-sbx/push-kits.sh v0.1.6` (les kits, `SBX=/chemin/vers/sbx` si la CLI n'est pas sur le PATH). Les deux appellent d'abord `sync-kits.sh`, qui réécrit `version`, le `tag` par défaut et le propriétaire de l'image des kits, de sorte qu'un kit publié nomme toujours l'image poussée avec lui — commitez ensuite les deux `spec.yaml`. `sbx kit push` parle directement au registre et s'authentifie depuis le magasin d'identifiants Docker, sans démon sandbox. `IMAGE_OWNER=<compte>` publie sous un autre compte.
124+Avec les deux variables, le script se connecte avec elles et se déconnecte à la fin ; sans elles, il réutilise votre `docker login` existant. Ses deux moitiés se lancent seules : `PUSH=1 ./docker-sbx/build.sh v0.1.7` (l'image) et `./docker-sbx/push-kits.sh v0.1.7` (les kits, `SBX=/chemin/vers/sbx` si la CLI n'est pas sur le PATH). Les deux appellent d'abord `sync-kits.sh`, qui réécrit `version`, le `tag` par défaut et le propriétaire de l'image des kits, de sorte qu'un kit publié nomme toujours l'image poussée avec lui — commitez ensuite les deux `spec.yaml`. `sbx kit push` parle directement au registre et s'authentifie depuis le magasin d'identifiants Docker, sans démon sandbox. `IMAGE_OWNER=<compte>` publie sous un autre compte.
125125
126126 ## Serveurs MCP via la passerelle sbx (exemple : GitHub)
127127
@@ -14,20 +14,20 @@ Tout est sous [`docker-sbx/`](../../../docker-sbx/README.md) dans le dépôt :
14 14
15 ## Utiliser les kits publiés15 ## Utiliser les kits publiés
16 16
17-Chaque release publie l'image et les deux kits sur Docker Hub à la version de mm — `k33g/mm-sandbox:0.1.6`, `k33g/mm-tui:0.1.6`, `k33g/mm-acp:0.1.6` — le chemin le plus court ne demande donc aucune construction. Docker Hub est une source de kits autorisée par défaut (`sbx settings get kit.allowedSources` montre `docker.io/`), et une référence avec un `/` mais sans hôte de registre est lue comme `docker.io/…` :17+Chaque release publie l'image et les deux kits sur Docker Hub à la version de mm — `k33g/mm-sandbox:0.1.7`, `k33g/mm-tui:0.1.7`, `k33g/mm-acp:0.1.7` — le chemin le plus court ne demande donc aucune construction. Docker Hub est une source de kits autorisée par défaut (`sbx settings get kit.allowedSources` montre `docker.io/`), et une référence avec un `/` mais sans hôte de registre est lue comme `docker.io/…` :
18 18
19 ```bash19 ```bash
20 cd /chemin/de/votre/projet20 cd /chemin/de/votre/projet
21-sbx run k33g/mm-tui:0.1.6 . -- agent.dmr.yaml21+sbx run k33g/mm-tui:0.1.7 . -- agent.dmr.yaml
22 ```22 ```
23 23
24 pour le mode fenêtre, et pour un éditeur :24 pour le mode fenêtre, et pour un éditeur :
25 25
26 ```bash26 ```bash
27-sbx create --name mm-acp k33g/mm-acp:0.1.6 . --kit-arg config=agent.dmr.yaml27+sbx create --name mm-acp k33g/mm-acp:0.1.7 . --kit-arg config=agent.dmr.yaml
28 ```28 ```
29 29
30-puis la déclaration dans l'éditeur de l'étape 3 ci-dessous. Pas de `--pull never` : le kit nomme `k33g/mm-sandbox:0.1.6` et sbx la télécharge. `sbx kit inspect k33g/mm-tui:0.1.6` montre ce qu'un kit déclare avant de le lancer. Les étapes qui suivent construisent la même chose en local, pour un mm en cours de travail.30+puis la déclaration dans l'éditeur de l'étape 3 ci-dessous. Pas de `--pull never` : le kit nomme `k33g/mm-sandbox:0.1.7` et sbx la télécharge. `sbx kit inspect k33g/mm-tui:0.1.7` montre ce qu'un kit déclare avant de le lancer. Les étapes qui suivent construisent la même chose en local, pour un mm en cours de travail.
31 31
32 ## Étapes32 ## Étapes
33 33
@@ -39,9 +39,9 @@ Depuis la racine du dépôt :
39 ./docker-sbx/build.sh39 ./docker-sbx/build.sh
40 ```40 ```
41 41
42-Cela lit le tag de mm dans `release.env` (`v0.1.6`) et construit `k33g/mm-sandbox:0.1.6` : le tag de l'image est la version sans le `v`, comme les binaires de release, et le `mm` à l'intérieur est estampillé avec le tag — `mm --version` est exécuté dans l'image comme preuve. Le script réécrit ensuite la valeur par défaut de l'argument `tag` des kits à `0.1.6`, pour que kits et image avancent ensemble. `./docker-sbx/build.sh v0.1.5` construit une autre version ; une image antérieure reste joignable avec `--kit-arg tag=0.1.4`.42+Cela lit le tag de mm dans `release.env` (`v0.1.7`) et construit `k33g/mm-sandbox:0.1.7` : le tag de l'image est la version sans le `v`, comme les binaires de release, et le `mm` à l'intérieur est estampillé avec le tag — `mm --version` est exécuté dans l'image comme preuve. Le script réécrit ensuite la valeur par défaut de l'argument `tag` des kits à `0.1.7`, pour que kits et image avancent ensemble. `./docker-sbx/build.sh v0.1.5` construit une autre version ; une image antérieure reste joignable avec `--kit-arg tag=0.1.4`.
43 43
44-L'image est dans votre store d'images Docker local : chaque `sbx run` ou `sbx create` sur ces kits prend `--pull never` tant qu'elle n'est pas poussée (`docker push k33g/mm-sandbox:0.1.6`), sinon `sbx` tente de la télécharger et échoue. Si `sbx` tourne sur une autre machine, `EXPORT=1 ./docker-sbx/build.sh` écrit aussi `tmp/mm-sandbox-0.1.6.tar`, à charger là-bas avec `sbx template load`.44+L'image est dans votre store d'images Docker local : chaque `sbx run` ou `sbx create` sur ces kits prend `--pull never` tant qu'elle n'est pas poussée (`docker push k33g/mm-sandbox:0.1.7`), sinon `sbx` tente de la télécharger et échoue. Si `sbx` tourne sur une autre machine, `EXPORT=1 ./docker-sbx/build.sh` écrit aussi `tmp/mm-sandbox-0.1.7.tar`, à charger là-bas avec `sbx template load`.
45 45
46 ### 2. Mode fenêtre dans le terminal (kit `mm-tui`)46 ### 2. Mode fenêtre dans le terminal (kit `mm-tui`)
47 47
@@ -62,7 +62,7 @@ sbx run --pull never ./docker-sbx/kits/mm-tui . --kit-arg config=agent.dmr.yaml
62 | `--kit-arg` | Défaut | Effet |62 | `--kit-arg` | Défaut | Effet |
63 |---|---|---|63 |---|---|---|
64 | `config=<chemin>` | vide | Le fichier de configuration, comme `AGENT_CONFIG` de `mm` : relatif à l'espace de travail, ou absolu dans le sandbox. |64 | `config=<chemin>` | vide | Le fichier de configuration, comme `AGENT_CONFIG` de `mm` : relatif à l'espace de travail, ou absolu dans le sandbox. |
65-| `tag=<version>` | la dernière version construite (`0.1.6`) | L'image `k33g/mm-sandbox:<version>` dont le sandbox est fait. |65+| `tag=<version>` | la dernière version construite (`0.1.7`) | L'image `k33g/mm-sandbox:<version>` dont le sandbox est fait. |
66 66
67 Le sandbox garde son nom (`mm-tui-<répertoire>` sauf `--name`) ; `sbx run --name <nom>` s'y rattache plus tard. À l'intérieur, la fenêtre est celle décrite dans [Utiliser le mode fenêtre](use-the-window-mode.md). Les sessions, quand `sessions.enabled` est actif, sont écrites sous `.mm/sessions` dans l'espace de travail — c'est votre répertoire hôte, elles survivent donc au sandbox.67 Le sandbox garde son nom (`mm-tui-<répertoire>` sauf `--name`) ; `sbx run --name <nom>` s'y rattache plus tard. À l'intérieur, la fenêtre est celle décrite dans [Utiliser le mode fenêtre](use-the-window-mode.md). Les sessions, quand `sessions.enabled` est actif, sont écrites sous `.mm/sessions` dans l'espace de travail — c'est votre répertoire hôte, elles survivent donc au sandbox.
68 68
@@ -118,10 +118,10 @@ La publication est une étape manuelle, depuis une machine avec Docker Desktop (
118 ```bash118 ```bash
119 export DOCKER_HANDLE=k33g # le compte Docker Hub, aussi propriétaire de l'image119 export DOCKER_HANDLE=k33g # le compte Docker Hub, aussi propriétaire de l'image
120 export DOCKER_PAT=dckr_pat_… # un jeton d'accès en lecture/écriture120 export DOCKER_PAT=dckr_pat_… # un jeton d'accès en lecture/écriture
121-./docker-sbx/publish.sh # TAG depuis release.env : v0.1.6 → k33g/mm-sandbox:0.1.6, k33g/mm-tui:0.1.6, k33g/mm-acp:0.1.6121+./docker-sbx/publish.sh # TAG depuis release.env : v0.1.7 → k33g/mm-sandbox:0.1.7, k33g/mm-tui:0.1.7, k33g/mm-acp:0.1.7
122 ```122 ```
123 123
124-Avec les deux variables, le script se connecte avec elles et se déconnecte à la fin ; sans elles, il réutilise votre `docker login` existant. Ses deux moitiés se lancent seules : `PUSH=1 ./docker-sbx/build.sh v0.1.6` (l'image) et `./docker-sbx/push-kits.sh v0.1.6` (les kits, `SBX=/chemin/vers/sbx` si la CLI n'est pas sur le PATH). Les deux appellent d'abord `sync-kits.sh`, qui réécrit `version`, le `tag` par défaut et le propriétaire de l'image des kits, de sorte qu'un kit publié nomme toujours l'image poussée avec lui — commitez ensuite les deux `spec.yaml`. `sbx kit push` parle directement au registre et s'authentifie depuis le magasin d'identifiants Docker, sans démon sandbox. `IMAGE_OWNER=<compte>` publie sous un autre compte.124+Avec les deux variables, le script se connecte avec elles et se déconnecte à la fin ; sans elles, il réutilise votre `docker login` existant. Ses deux moitiés se lancent seules : `PUSH=1 ./docker-sbx/build.sh v0.1.7` (l'image) et `./docker-sbx/push-kits.sh v0.1.7` (les kits, `SBX=/chemin/vers/sbx` si la CLI n'est pas sur le PATH). Les deux appellent d'abord `sync-kits.sh`, qui réécrit `version`, le `tag` par défaut et le propriétaire de l'image des kits, de sorte qu'un kit publié nomme toujours l'image poussée avec lui — commitez ensuite les deux `spec.yaml`. `sbx kit push` parle directement au registre et s'authentifie depuis le magasin d'identifiants Docker, sans démon sandbox. `IMAGE_OWNER=<compte>` publie sous un autre compte.
125 125
126 ## Serveurs MCP via la passerelle sbx (exemple : GitHub)126 ## Serveurs MCP via la passerelle sbx (exemple : GitHub)
127 127
modified docs/fr/how-to/use-from-an-editor.md +1 -1
@@ -47,7 +47,7 @@ Ce guide montre comment héberger `mm` dans un éditeur qui parle l'Agent Client
4747 | mm -acp -config /chemin/absolu/vers/agent.yaml 2>/dev/null | head -1
4848 ```
4949
50- Avec les réglages par défaut, la réponse contient `"agentInfo":{"name":"bob","title":"Bob (bash-first agent)","version":"v0.1.6"}`.
50+ Avec les réglages par défaut, la réponse contient `"agentInfo":{"name":"bob","title":"Bob (bash-first agent)","version":"v0.1.7"}`.
5151
5252 ## Voir aussi
5353
@@ -47,7 +47,7 @@ Ce guide montre comment héberger `mm` dans un éditeur qui parle l'Agent Client
47 | mm -acp -config /chemin/absolu/vers/agent.yaml 2>/dev/null | head -147 | mm -acp -config /chemin/absolu/vers/agent.yaml 2>/dev/null | head -1
48 ```48 ```
49 49
50- Avec les réglages par défaut, la réponse contient `"agentInfo":{"name":"bob","title":"Bob (bash-first agent)","version":"v0.1.6"}`.50+ Avec les réglages par défaut, la réponse contient `"agentInfo":{"name":"bob","title":"Bob (bash-first agent)","version":"v0.1.7"}`.
51 51
52 ## Voir aussi52 ## Voir aussi
53 53
modified docs/fr/reference/acp.md +1 -1
@@ -19,7 +19,7 @@
1919 | `agentCapabilities` | `loadSession: true` quand `sessions.enabled` est activé, absente (false) sinon. Tout le reste absent (false) : pas de prompts image ou audio, pas de MCP HTTP. |
2020 | `agentInfo.name` | `acp.name` de la configuration, `bob` par défaut. |
2121 | `agentInfo.title` | `acp.title` de la configuration, `Bob (bash-first agent)` par défaut ; absent quand vide. |
22-| `agentInfo.version` | La version du binaire, la même chaîne que `mm --version` (par exemple `v0.1.6`). |
22+| `agentInfo.version` | La version du binaire, la même chaîne que `mm --version` (par exemple `v0.1.7`). |
2323 | `authMethods` | `[]` |
2424
2525 ## Méthodes
@@ -19,7 +19,7 @@
19 | `agentCapabilities` | `loadSession: true` quand `sessions.enabled` est activé, absente (false) sinon. Tout le reste absent (false) : pas de prompts image ou audio, pas de MCP HTTP. |19 | `agentCapabilities` | `loadSession: true` quand `sessions.enabled` est activé, absente (false) sinon. Tout le reste absent (false) : pas de prompts image ou audio, pas de MCP HTTP. |
20 | `agentInfo.name` | `acp.name` de la configuration, `bob` par défaut. |20 | `agentInfo.name` | `acp.name` de la configuration, `bob` par défaut. |
21 | `agentInfo.title` | `acp.title` de la configuration, `Bob (bash-first agent)` par défaut ; absent quand vide. |21 | `agentInfo.title` | `acp.title` de la configuration, `Bob (bash-first agent)` par défaut ; absent quand vide. |
22-| `agentInfo.version` | La version du binaire, la même chaîne que `mm --version` (par exemple `v0.1.6`). |22+| `agentInfo.version` | La version du binaire, la même chaîne que `mm --version` (par exemple `v0.1.7`). |
23 | `authMethods` | `[]` |23 | `authMethods` | `[]` |
24 24
25 ## Méthodes25 ## Méthodes
modified docs/fr/reference/cli.md +4 -4
@@ -24,14 +24,14 @@ mm [-config <chemin>] [-acp] [-tui] [-prompt <texte>|-p <texte>] [--version] [--
2424 `mm --version` (ou `-version`) affiche une ligne puis quitte, avant même de chercher le fichier de configuration — la réponse arrive donc depuis n'importe quel répertoire, sans serveur de modèle démarré :
2525
2626 ```
27-mm v0.1.6 (go1.26.5, darwin/arm64)
27+mm v0.1.7 (go1.26.5, darwin/arm64)
2828 ```
2929
30-`mm --about` affiche la même version à l'intérieur d'une courte description du programme. La version ouvre aussi la bannière de démarrage (`mm v0.1.6 | config: …`), que le mode fenêtre conserve comme première ligne de la conversation, et figure dans la barre d'état de la fenêtre avant les compteurs.
30+`mm --about` affiche la même version à l'intérieur d'une courte description du programme. La version ouvre aussi la bannière de démarrage (`mm v0.1.7 | config: …`), que le mode fenêtre conserve comme première ligne de la conversation, et figure dans la barre d'état de la fenêtre avant les compteurs.
3131
3232 | D'où elle vient | Ce que vous voyez |
3333 |---|---|
34-| Un binaire de release, estampillé à la construction par `02-build-releases.sh` | Le tag : `v0.1.6` |
34+| Un binaire de release, estampillé à la construction par `02-build-releases.sh` | Le tag : `v0.1.7` |
3535 | Installé par `go install` depuis une version taguée | Ce tag |
3636 | Construit à la main depuis un arbre de travail (`go build`, `./install.sh`) | Le commit court, `9073268`, suivi de `+dirty` si l'arbre avait des modifications non validées |
3737 | Construit avec `-buildvcs=false` | `unknown` |
@@ -73,7 +73,7 @@ Affichée sur stdout en mode terminal, sur stderr en mode ACP. Grisée quand std
7373
7474 ```
7575 [warning: llamacpp: nothing answers at http://127.0.0.1:8080/v1 — start it: llama-server -m <model.gguf> --jinja --port 8080]
76-mm v0.1.6 | config: agent.llamacpp.yaml | provider: llamacpp | model: jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
76+mm v0.1.7 | config: agent.llamacpp.yaml | provider: llamacpp | model: jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
7777 ```
7878
7979 ## Spécificités du mode ACP
@@ -24,14 +24,14 @@ mm [-config <chemin>] [-acp] [-tui] [-prompt <texte>|-p <texte>] [--version] [--
24 `mm --version` (ou `-version`) affiche une ligne puis quitte, avant même de chercher le fichier de configuration — la réponse arrive donc depuis n'importe quel répertoire, sans serveur de modèle démarré :24 `mm --version` (ou `-version`) affiche une ligne puis quitte, avant même de chercher le fichier de configuration — la réponse arrive donc depuis n'importe quel répertoire, sans serveur de modèle démarré :
25 25
26 ```26 ```
27-mm v0.1.6 (go1.26.5, darwin/arm64)27+mm v0.1.7 (go1.26.5, darwin/arm64)
28 ```28 ```
29 29
30-`mm --about` affiche la même version à l'intérieur d'une courte description du programme. La version ouvre aussi la bannière de démarrage (`mm v0.1.6 | config: …`), que le mode fenêtre conserve comme première ligne de la conversation, et figure dans la barre d'état de la fenêtre avant les compteurs.30+`mm --about` affiche la même version à l'intérieur d'une courte description du programme. La version ouvre aussi la bannière de démarrage (`mm v0.1.7 | config: …`), que le mode fenêtre conserve comme première ligne de la conversation, et figure dans la barre d'état de la fenêtre avant les compteurs.
31 31
32 | D'où elle vient | Ce que vous voyez |32 | D'où elle vient | Ce que vous voyez |
33 |---|---|33 |---|---|
34-| Un binaire de release, estampillé à la construction par `02-build-releases.sh` | Le tag : `v0.1.6` |34+| Un binaire de release, estampillé à la construction par `02-build-releases.sh` | Le tag : `v0.1.7` |
35 | Installé par `go install` depuis une version taguée | Ce tag |35 | Installé par `go install` depuis une version taguée | Ce tag |
36 | Construit à la main depuis un arbre de travail (`go build`, `./install.sh`) | Le commit court, `9073268`, suivi de `+dirty` si l'arbre avait des modifications non validées |36 | Construit à la main depuis un arbre de travail (`go build`, `./install.sh`) | Le commit court, `9073268`, suivi de `+dirty` si l'arbre avait des modifications non validées |
37 | Construit avec `-buildvcs=false` | `unknown` |37 | Construit avec `-buildvcs=false` | `unknown` |
@@ -73,7 +73,7 @@ Affichée sur stdout en mode terminal, sur stderr en mode ACP. Grisée quand std
73 73
74 ```74 ```
75 [warning: llamacpp: nothing answers at http://127.0.0.1:8080/v1 — start it: llama-server -m <model.gguf> --jinja --port 8080]75 [warning: llamacpp: nothing answers at http://127.0.0.1:8080/v1 — start it: llama-server -m <model.gguf> --jinja --port 8080]
76-mm v0.1.6 | config: agent.llamacpp.yaml | provider: llamacpp | model: jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 076+mm v0.1.7 | config: agent.llamacpp.yaml | provider: llamacpp | model: jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
77 ```77 ```
78 78
79 ## Spécificités du mode ACP79 ## Spécificités du mode ACP
modified docs/fr/tutorials/getting-started.md +1 -1
@@ -32,7 +32,7 @@ Tapez :
3232 Vous devez voir une bannière comme celle-ci (le nom du modèle est celui d'`agent.yaml`) :
3333
3434 ```
35-mm v0.1.6 | config: agent.yaml | provider: dmr | model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
35+mm v0.1.7 | config: agent.yaml | provider: dmr | model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
3636 Agent ready. Commands: "/quit" to exit, "/abort" to stop current generation, "/compact" to compress the history, "/new" to start a new session, "/sessions" and "/resume" for stored sessions, "/help" to list them.
3737 Shortcut: Ctrl+C to abort generation, or Ctrl+C at prompt to quit.
3838
@@ -32,7 +32,7 @@ Tapez :
32 Vous devez voir une bannière comme celle-ci (le nom du modèle est celui d'`agent.yaml`) :32 Vous devez voir une bannière comme celle-ci (le nom du modèle est celui d'`agent.yaml`) :
33 33
34 ```34 ```
35-mm v0.1.6 | config: agent.yaml | provider: dmr | model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 035+mm v0.1.7 | config: agent.yaml | provider: dmr | model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M | ctx: unknown | tools: bash, read_file, write_file, edit_file | skills: 0
36 Agent ready. Commands: "/quit" to exit, "/abort" to stop current generation, "/compact" to compress the history, "/new" to start a new session, "/sessions" and "/resume" for stored sessions, "/help" to list them.36 Agent ready. Commands: "/quit" to exit, "/abort" to stop current generation, "/compact" to compress the history, "/new" to start a new session, "/sessions" and "/resume" for stored sessions, "/help" to list them.
37 Shortcut: Ctrl+C to abort generation, or Ctrl+C at prompt to quit.37 Shortcut: Ctrl+C to abort generation, or Ctrl+C at prompt to quit.
38 38