| @@ -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.1` | The template image. You never name it yourself: each kit pulls it. | | 28 | +| `k33g/mm-sandbox:0.1.3` | The template image. You never name it yourself: each kit pulls it. | |
| 29 | -| `k33g/mm-tui:0.1.1` | The window-mode kit, for `sbx run`. | | 29 | +| `k33g/mm-tui:0.1.3` | The window-mode kit, for `sbx run`. | |
| 30 | -| `k33g/mm-acp:0.1.1` | The editor kit, for `sbx create` + `sbx exec -i … mm -acp`. | | 30 | +| `k33g/mm-acp:0.1.3` | 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 | ```bash | 36 | ```bash |
| 37 | -sbx kit inspect k33g/mm-tui:0.1.1 | 37 | +sbx kit inspect k33g/mm-tui:0.1.3 |
| 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 | ```bash | 42 | ```bash |
| 43 | cd /path/to/your/project | 43 | cd /path/to/your/project |
| 44 | -sbx run k33g/mm-tui:0.1.1 . -- agent.dmr.yaml | 44 | +sbx run k33g/mm-tui:0.1.3 . -- 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 | ```bash | 49 | ```bash |
| 50 | -sbx run k33g/mm-tui:0.1.1 . --kit-arg config=agent.dmr.yaml | 50 | +sbx run k33g/mm-tui:0.1.3 . --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 | ```bash | 57 | ```bash |
| 58 | cd /path/to/your/project | 58 | cd /path/to/your/project |
| 59 | -sbx create --name mm-acp k33g/mm-acp:0.1.1 . --kit-arg config=agent.dmr.yaml | 59 | +sbx create --name mm-acp k33g/mm-acp:0.1.3 . --kit-arg config=agent.dmr.yaml |
| 60 | | 60 | |
| 61 | -#sbx create k33g/mm-acp:0.1.0 . --name sbx-mm-acp | 61 | +#sbx create k33g/mm-acp:0.1.3 . --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`: |
| @@ -96,7 +96,7 @@ From the repository root: |
| 96 | | 96 | |
| 97 | ```bash | 97 | ```bash |
| 98 | ./docker-sbx/build.sh # TAG from release.env: v0.1.1 → k33g/mm-sandbox:0.1.1 | 98 | ./docker-sbx/build.sh # TAG from release.env: v0.1.1 → k33g/mm-sandbox:0.1.1 |
| 99 | -./docker-sbx/build.sh v0.0.3 # → k33g/mm-sandbox:0.0.3 | 99 | +./docker-sbx/build.sh v0.1.3 # → k33g/mm-sandbox:0.1.3 |
| 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.1`. 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.1`. 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`. |
| @@ -186,14 +186,14 @@ Publishing is done by hand, from a laptop with Docker Desktop (buildx and the `s |
| 186 | export DOCKER_HANDLE=k33g # the Docker Hub account, also the image owner | 186 | export DOCKER_HANDLE=k33g # the Docker Hub account, also the image owner |
| 187 | export DOCKER_PAT=dckr_pat_… # an access token with read/write scope | 187 | export DOCKER_PAT=dckr_pat_… # an access token with read/write scope |
| 188 | ./docker-sbx/publish.sh # TAG from release.env: v0.0.3 → k33g/mm-sandbox:0.0.3, k33g/mm-tui:0.0.3, k33g/mm-acp:0.0.3 | 188 | ./docker-sbx/publish.sh # TAG from release.env: v0.0.3 → k33g/mm-sandbox:0.0.3, k33g/mm-tui:0.0.3, k33g/mm-acp:0.0.3 |
| 189 | -./docker-sbx/publish.sh v0.0.4 # another tag | 189 | +./docker-sbx/publish.sh v0.1.3 # another tag |
| 190 | ``` | 190 | ``` |
| 191 | | 191 | |
| 192 | With the two variables set, the script logs in with them and logs out at the end; with neither, it reuses the `docker login` you already have. It is two steps you can also run alone: | 192 | With the two variables set, the script logs in with them and logs out at the end; with neither, it reuses the `docker login` you already have. It is two steps you can also run alone: |
| 193 | | 193 | |
| 194 | ```bash | 194 | ```bash |
| 195 | -PUSH=1 ./docker-sbx/build.sh v0.0.3 # buildx multi-arch, pushed; proof: `imagetools inspect` lists both platforms | 195 | +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.0.3 # sbx kit validate + sbx kit push, for each kit | 196 | +./docker-sbx/push-kits.sh v0.1.3 # 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. |