bots-garden/mini-me · 097fb4d

⑂ 097fb4d

🛟 Updated.

k33g committed 2026-11-13T13:22:03+01:00 Browse files

097fb4d parent: e41fbe6

modified .tickets/milestones.yaml +1 -1 Viewed

@@ -58,5 +58,5 @@ milestones:
58	58	state: closed
59	59	dueOn: 2026-11-15
60	60	- title: v1.0.7
61		- state: open
	61	+ state: closed
62	62	dueOn: 2026-11-14

      state: closed
      dueOn: 2026-11-15
    - title: v1.0.7
--    state: open
++    state: closed
      dueOn: 2026-11-14

modified INSTALL.LINUX.md +1 -1 Viewed

@@ -2,7 +2,7 @@
2	2
3	3	```bash
4	4	# download the binary release in https://rickub.com/bots-garden/mini-me/releases
5		-VERSION=1.0.6
	5	+VERSION=1.0.7
6	6	case "$(uname -m)" in
7	7	x86_64) ARCH=amd64 ;;
8	8	aarch64\|arm64) ARCH=arm64 ;;

  ```bash
  # download the binary release in https://rickub.com/bots-garden/mini-me/releases
--VERSION=1.0.6
++VERSION=1.0.7
  case "$(uname -m)" in
    x86_64)        ARCH=amd64 ;;
    aarch64|arm64) ARCH=arm64 ;;

modified INSTALL.MACOS.md +4 -4 Viewed

@@ -2,7 +2,7 @@
2	2
3	3	Short version:
4	4	```bash
5		-VERSION=1.0.6
	5	+VERSION=1.0.7
6	6	curl -fsSLO "https://rickub.com/bots-garden/mini-me/releases/download/v${VERSION}/mm-${VERSION}-darwin-arm64"
7	7	chmod +x ./mm-${VERSION}-darwin-arm64
8	8	sudo rm -f /usr/local/bin/mm
@@ -14,7 +14,7 @@ From v1.0.5, the macOS binary is signed with a Developer ID and notarized by App
14	14
15	15	```bash
16	16	# download the binary release in https://rickub.com/bots-garden/mini-me/releases
17		-VERSION=1.0.6
	17	+VERSION=1.0.7
18	18	curl -fsSLO "https://rickub.com/bots-garden/mini-me/releases/download/v${VERSION}/mm-${VERSION}-darwin-arm64"
19	19
20	20	# optional: check the download against the release's checksums
@@ -34,8 +34,8 @@ mm --version
34	34	The signature check should print:
35	35
36	36	```
37		-./mm-1.0.6-darwin-arm64: valid on disk
38		-./mm-1.0.6-darwin-arm64: satisfies its Designated Requirement
	37	+./mm-1.0.7-darwin-arm64: valid on disk
	38	+./mm-1.0.7-darwin-arm64: satisfies its Designated Requirement
39	39	Identifier=com.bots-garden.mm
40	40	Authority=Developer ID Application: Philippe Charriere (SNLLBZP9V9)
41	41	TeamIdentifier=SNLLBZP9V9

  Short version:
  ```bash
--VERSION=1.0.6
++VERSION=1.0.7
  curl -fsSLO "https://rickub.com/bots-garden/mini-me/releases/download/v${VERSION}/mm-${VERSION}-darwin-arm64"
  chmod +x ./mm-${VERSION}-darwin-arm64
  sudo rm -f /usr/local/bin/mm
  ```bash
  # download the binary release in https://rickub.com/bots-garden/mini-me/releases
--VERSION=1.0.6
++VERSION=1.0.7
  curl -fsSLO "https://rickub.com/bots-garden/mini-me/releases/download/v${VERSION}/mm-${VERSION}-darwin-arm64"
  # optional: check the download against the release's checksums
  The signature check should print:
  ```
--./mm-1.0.6-darwin-arm64: valid on disk
++./mm-1.0.7-darwin-arm64: valid on disk
--./mm-1.0.6-darwin-arm64: satisfies its Designated Requirement
++./mm-1.0.7-darwin-arm64: satisfies its Designated Requirement
  Identifier=com.bots-garden.mm
  Authority=Developer ID Application: Philippe Charriere (SNLLBZP9V9)
  TeamIdentifier=SNLLBZP9V9

modified INSTALL.WINDOWS.md +1 -1 Viewed

@@ -4,7 +4,7 @@ In PowerShell (no administrator rights needed):
4	4
5	5	```powershell
6	6	# download the binary release in https://rickub.com/bots-garden/mini-me/releases
7		-$Version = "1.0.6"
	7	+$Version = "1.0.7"
8	8	$Arch = if ($env:PROCESSOR_ARCHITECTURE -eq "ARM64") { "arm64" } else { "amd64" }
9	9	$Asset = "mm-$Version-windows-$Arch.exe"
10	10	$Base = "https://rickub.com/bots-garden/mini-me/releases/download/v$Version"

  ```powershell
  # download the binary release in https://rickub.com/bots-garden/mini-me/releases
--$Version = "1.0.6"
++$Version = "1.0.7"
  $Arch = if ($env:PROCESSOR_ARCHITECTURE -eq "ARM64") { "arm64" } else { "amd64" }
  $Asset = "mm-$Version-windows-$Arch.exe"
  $Base = "https://rickub.com/bots-garden/mini-me/releases/download/v$Version"

modified release-notes/README.md +1 -0 Viewed

@@ -4,6 +4,7 @@ One note per tag, in English (`.en.md`) and French (`.fr.md`). Rebuilt on 2026-1
4	4
5	5	\| Version \| Date \| Summary \| \|
6	6	\|---\|---\|---\|---\|
	7	+\| [v1.0.7](v1.0.7.en.md) \| not tagged yet \| A project can keep its agent in a `.mm` folder, which `mm init`, `mm sbxinit` and the new `mm skillcreate` all know, and models such as SmolLM3, whose chat template reads its tools from `xml_tools`, can call mm's tools. \| [FR](v1.0.7.fr.md) \|
7	8	\| [v1.0.6](v1.0.6.en.md) \| not tagged yet \| An ACP client can lend the agent its own functions as tools, and mini-me runs on Kronk, the Go inference server of Ardan Labs. \| [FR](v1.0.6.fr.md) \|
8	9	\| [v1.0.5](v1.0.5.en.md) \| 2026-11-07 \| `mm dockerinit` and `mm sbxinit` write the files to run mini-me in a container or a Docker Sandbox, `mm init` gives the agent its name, two vibe-coding demos (Go and Swift), and a macOS binary signed and notarized by Apple. \| [FR](v1.0.5.fr.md) \|
9	10	\| [v1.0.4](v1.0.4.en.md) \| 2026-11-02 \| A security update: mm now builds with `golang.org/x/net` v0.62.0, which fixes two vulnerabilities in its HTML parser. \| [FR](v1.0.4.fr.md) \|

  | Version | Date | Summary | |
  |---|---|---|---|
++| [v1.0.7](v1.0.7.en.md) | not tagged yet | A project can keep its agent in a `.mm` folder, which `mm init`, `mm sbxinit` and the new `mm skillcreate` all know, and models such as SmolLM3, whose chat template reads its tools from `xml_tools`, can call mm's tools. | [FR](v1.0.7.fr.md) |
  | [v1.0.6](v1.0.6.en.md) | not tagged yet | An ACP client can lend the agent its own functions as tools, and mini-me runs on Kronk, the Go inference server of Ardan Labs. | [FR](v1.0.6.fr.md) |
  | [v1.0.5](v1.0.5.en.md) | 2026-11-07 | `mm dockerinit` and `mm sbxinit` write the files to run mini-me in a container or a Docker Sandbox, `mm init` gives the agent its name, two vibe-coding demos (Go and Swift), and a macOS binary signed and notarized by Apple. | [FR](v1.0.5.fr.md) |
  | [v1.0.4](v1.0.4.en.md) | 2026-11-02 | A security update: mm now builds with `golang.org/x/net` v0.62.0, which fixes two vulnerabilities in its HTML parser. | [FR](v1.0.4.fr.md) |

added release-notes/v1.0.7.en.md +106 -0 Viewed

new file mode 100644
@@ -0,0 +1,106 @@
	1	+# mini-me v1.0.7
	2	+
	3	+[Version française](v1.0.7.fr.md)
	4	+
	5	+A project can keep its agent in a `.mm` folder, which `mm init`, `mm sbxinit` and the new `mm skillcreate` all know, and models such as SmolLM3, whose chat template reads its tools from `xml_tools`, can call mm's tools.
	6	+
	7	+## New
	8	+
	9	+### The `.mm` project folder (#204)
	10	+
	11	+`mm` and `mm tui` started with no config file now look for `./agent.yaml`, then for `./.mm/agent.yaml`. When both exist, `./agent.yaml` wins. A file named with `-config` or `AGENT_CONFIG` still comes first.
	12	+
	13	+The relative paths of a config file directly inside a `.mm` folder are read from the project root, the parent of `.mm`, not from `.mm` itself. This holds whatever way the file was named, and in ACP mode too. A `.mm/agent.yaml` therefore writes `skillsDir: .mm/skills`, as you would type it from the root where mm runs. It covers `mmConfigs`, the hooks and their `MM_CONFIG_DIR`, `tools[].wasm`, the deciders of `skillRouting` and `toolRouting`, and `skillsDir` in ACP mode, where it used to give `.mm/.mm/skills`. `skillsDir` in a terminal, `sessions.dir` and `agentsMd.path` follow the working directory, as before.
	14	+
	15	+See [How to keep a project's mini-me files in a `.mm` folder](../docs/en/how-to/keep-the-config-in-a-mm-folder.md).
	16	+
	17	+### `mm init`: Project layout, sessions and skills (#205)
	18	+
	19	+The wizard has three new yes/no questions, all `no` by default.
	20	+
	21	+- Keep everything in a `.mm` folder? It is asked first. With `yes`, mm creates `.mm/`, writes `.mm/agent.yaml` with its paths from the project root, and ends with `Next: mm (or mm tui)`. A file chosen outside `.mm/` is refused.
	22	+- Save the conversations? With `yes`, the file gets a `sessions` section (`enabled: true`, `dir: .mm/sessions`). With `no`, it gets none, and sessions stay off as before.
	23	+- Use skills? With `yes`, the file gets `skillsDir: skills`, or `.mm/skills` with the Project layout, and the folder is created.
	24	+
	25	+The flags are `--project`, `--sessions` and `--skills`, each `yes` or `no`. `-o -` prints the file and creates nothing. Without the new flags, the file mm init writes is the same as in v1.0.6, byte for byte.
	26	+
	27	+See [How to create an agent with `mm init`](../docs/en/how-to/create-an-agent.md).
	28	+
	29	+### `mm skillcreate`, a wizard for skills (#206)
	30	+
	31	+`mm skillcreate` asks for a skill and writes it as `<skillsDir>/<name>/SKILL.md`, where the agent's config file says its skills are. It finds that file as mm does, `.mm/agent.yaml` included. Without a config, or with `skillsDir: no-skills`, the skill goes to `.mm/skills` when a `.mm` folder exists, else to `skills`, and mm says which `skillsDir` to set.
	32	+
	33	+- The name is written lower case, with dashes: `Vulcan Salute` gives `vulcan-salute`, for the front matter's `name` and for the folder.
	34	+- The level-1 title is the name as you typed it. A name typed already normalised is turned back into words: `vulcan-salute` gives `# Vulcan Salute`. A `## What to do` section follows, then the text.
	35	+- The keywords are optional. Beyond 8, mm warns that only the first 8 reach the catalogue.
	36	+- The text is always the last question. In the line mode it ends with Ctrl-D. In the window, Enter adds a line and Ctrl-D answers. The window is the one of `mm init`, with the `SKILL.md` as it would be written on the right.
	37	+- An existing skill is never replaced without your answer. The question comes right after the name.
	38	+- After writing, mm reads the skill back with its own loader and says `✅ mm reads it`.
	39	+
	40	+The flags are `--name`, `--description`, `--keywords`, `--body`, `--body-file`, `-config`, `--yes` and `--line`. `-o -` prints the skill and creates nothing.
	41	+
	42	+Not tried: the window in a real terminal. It is covered by tests on a simulated screen only.
	43	+
	44	+See [How to add a skill](../docs/en/how-to/add-a-skill.md).
	45	+
	46	+### Tools for models whose template reads `xml_tools` (#207)
	47	+
	48	+SmolLM3's card says it calls tools, but through mm it never did. Its chat template reads the tools from an `xml_tools` variable and never from the OpenAI API's `tools`, which is what mm sends. Given `xml_tools`, the model writes its call as `<tool_call>…</tool_call>` text, which llama-server does not turn into a tool call.
	49	+
	50	+`toolFormat: xml_tools` in the agent file fixes both sides. mm sends the tools in `chat_template_kwargs.xml_tools`, writes earlier calls back into the history as `<tool_call>` text, and turns the `<tool_call>` blocks of the answer into tool calls, streamed or not. A block whose JSON is broken or cut is handed back to the model, as for any other model. `toolFormat: openai`, the default, changes nothing for other models.
	51	+
	52	+Measured on llmman with SmolLM3-3B Q4_K_M:
	53	+- with reasoning on, it repeats its call after the tool's answer instead of answering (3 runs out of 3);
	54	+- with reasoning off, it answers (6 out of 6);
	55	+- SmolLM3-3B-128K was tried on a one-step request (3 runs); longer tasks were not tried with it.
	56	+
	57	+Tasks of several steps stay fragile at 3B: the model sometimes takes a tool's output for something the user said. Wrapping that output in `<tool_response>` tags made no measured difference.
	58	+
	59	+See [How to give tools to a model whose template reads `xml_tools`](../docs/en/how-to/use-a-model-that-reads-xml-tools.md).
	60	+
	61	+### SmolLM3 in `mm init`
	62	+
	63	+A new `smollm3` family covers `unsloth/SmolLM3-3B-GGUF` and `SmolLM3-3B-128K-GGUF`.
	64	+
	65	+- Sampling: temperature 0.6 and top_p 0.95, from the model card and its `generation_config.json`.
	66	+- Tools: the family writes `toolFormat: xml_tools` for a usage with tools.
	67	+- Reasoning: it is written off whatever the usage, with a note at the end of the file that gives the measurement above.
	68	+
	69	+A file written by `mm init --usage developer --project yes` for SmolLM3-3B ran `bash` in 3 runs out of 3. Both models pass `mm init --check` with the `translator` usage.
	70	+
	71	+### `mm sbxinit` and the `.mm` folder (#208)
	72	+
	73	+`mm sbxinit` now also looks for `.mm/agent.yaml`, after `agent.yaml`, and names the sandbox after its `acp.name`. For a `.mm` project it writes a `sbxenv.yaml` that keeps the agent's settings out of its own reach.
	74	+
	75	+- `.mm/` is mounted read-only over the workspace.
	76	+- The folders mm writes in are mounted writable again, read from the agent file: `sessions.dir` when the sessions are on, and `trace.dir` when the trace is on.
	77	+- `AGENT_CONFIG` names the agent file through a `PROJECT_DIR` argument, so it does not depend on the mm version the kit ships. It was not tried from an editor (ACP) in a sandbox.
	78	+- Every path is relative to the folder of `sbxenv.yaml`, so the file can be committed.
	79	+- Every `sbx env` command takes `--env-arg PROJECT_DIR="$PWD"`.
	80	+
	81	+The nested mounts were checked in a Docker Sandbox: the sessions are written from the sandbox while `.mm` is read-only.
	82	+
	83	+See [How to run mini-me in a Docker Sandbox](../docs/en/how-to/run-in-a-docker-sandbox.md).
	84	+
	85	+## Demos
	86	+
	87	+- [`demos/smollm3-demo/`](../demos/smollm3-demo/.mm/agent.yaml): an agent written by `mm init` for SmolLM3-3B in a `.mm` folder, with `toolFormat: xml_tools` and reasoning off.
	88	+
	89	+## Documentation
	90	+
	91	+- New:
	92	+ - [How to keep a project's mini-me files in a `.mm` folder](../docs/en/how-to/keep-the-config-in-a-mm-folder.md);
	93	+ - [How to give tools to a model whose template reads `xml_tools`](../docs/en/how-to/use-a-model-that-reads-xml-tools.md).
	94	+- Updated:
	95	+ - the CLI reference, with configuration file resolution, the base directory of relative paths, the flags of `mm init` and `mm sbxinit`, and `mm skillcreate`;
	96	+ - the configuration reference (`toolFormat`) and the hooks reference (`MM_CONFIG_DIR`);
	97	+ - the guides to creating an agent, adding a skill, using mini-me from an editor, guarding the agent with hooks, and running in a Docker Sandbox;
	98	+ - the `mm init` explanation. The sample window of [How to create an agent](../docs/en/how-to/create-an-agent.md) is now taken from the real window.
	99	+
	100	+## Upgrading
	101	+
	102	+- Agent files do not change, with one exception, below. Replace the binary: see the install guides for [macOS](../INSTALL.MACOS.md), [Linux](../INSTALL.LINUX.md) and [Windows](../INSTALL.WINDOWS.md).
	103	+- A config file directly inside a `.mm` folder: its relative paths now start at the project root, and `MM_CONFIG_DIR` is the project root. A hook written `$MM_CONFIG_DIR/hooks/…` for a `.mm/agent.yaml` becomes `$MM_CONFIG_DIR/.mm/hooks/…`. To run the same file with an older mm too, for example the one a sandbox kit ships, write `${MM_CONFIG_DIR%/.mm}/.mm/hooks/…`, which gives the project root with any version.
	104	+- New key: `toolFormat` (`openai` by default, or `xml_tools`). Any other value stops the load with `toolFormat must be openai or xml_tools`.
	105	+- New command: `mm skillcreate` (also `--skillcreate`). New `mm init` flags: `--project`, `--sessions` and `--skills`.
	106	+- Changed messages. The interrupt messages start with `🔴` followed by two spaces instead of `🛑 `: for example `🔴 Generation aborted.`, `🔴 Interrupted (Ctrl+C).` and `🔴 Ask aborted — nothing kept.`

++# mini-me v1.0.7
++
++*[Version française](v1.0.7.fr.md)*
++
++A project can keep its agent in a `.mm` folder, which `mm init`, `mm sbxinit` and the new `mm skillcreate` all know, and models such as SmolLM3, whose chat template reads its tools from `xml_tools`, can call mm's tools.
++
++## New
++
++### The `.mm` project folder (#204)
++
++`mm` and `mm tui` started with no config file now look for `./agent.yaml`, then for `./.mm/agent.yaml`. When both exist, `./agent.yaml` wins. A file named with `-config` or `AGENT_CONFIG` still comes first.
++
++The relative paths of a config file directly inside a `.mm` folder are read from the project root, the parent of `.mm`, not from `.mm` itself. This holds whatever way the file was named, and in ACP mode too. A `.mm/agent.yaml` therefore writes `skillsDir: .mm/skills`, as you would type it from the root where mm runs. It covers `mmConfigs`, the hooks and their `MM_CONFIG_DIR`, `tools[].wasm`, the deciders of `skillRouting` and `toolRouting`, and `skillsDir` in ACP mode, where it used to give `.mm/.mm/skills`. `skillsDir` in a terminal, `sessions.dir` and `agentsMd.path` follow the working directory, as before.
++
++See [How to keep a project's mini-me files in a `.mm` folder](../docs/en/how-to/keep-the-config-in-a-mm-folder.md).
++
++### `mm init`: Project layout, sessions and skills (#205)
++
++The wizard has three new yes/no questions, all `no` by default.
++
++- **Keep everything in a `.mm` folder?** It is asked first. With `yes`, mm creates `.mm/`, writes `.mm/agent.yaml` with its paths from the project root, and ends with `Next: mm (or mm tui)`. A file chosen outside `.mm/` is refused.
++- **Save the conversations?** With `yes`, the file gets a `sessions` section (`enabled: true`, `dir: .mm/sessions`). With `no`, it gets none, and sessions stay off as before.
++- **Use skills?** With `yes`, the file gets `skillsDir: skills`, or `.mm/skills` with the Project layout, and the folder is created.
++
++The flags are `--project`, `--sessions` and `--skills`, each `yes` or `no`. `-o -` prints the file and creates nothing. Without the new flags, the file mm init writes is the same as in v1.0.6, byte for byte.
++
++See [How to create an agent with `mm init`](../docs/en/how-to/create-an-agent.md).
++
++### `mm skillcreate`, a wizard for skills (#206)
++
++`mm skillcreate` asks for a skill and writes it as `<skillsDir>/<name>/SKILL.md`, where the agent's config file says its skills are. It finds that file as mm does, `.mm/agent.yaml` included. Without a config, or with `skillsDir: no-skills`, the skill goes to `.mm/skills` when a `.mm` folder exists, else to `skills`, and mm says which `skillsDir` to set.
++
++- **The name** is written lower case, with dashes: `Vulcan Salute` gives `vulcan-salute`, for the front matter's `name` and for the folder.
++- **The level-1 title** is the name as you typed it. A name typed already normalised is turned back into words: `vulcan-salute` gives `# Vulcan Salute`. A `## What to do` section follows, then the text.
++- **The keywords** are optional. Beyond 8, mm warns that only the first 8 reach the catalogue.
++- **The text** is always the last question. In the line mode it ends with Ctrl-D. In the window, Enter adds a line and Ctrl-D answers. The window is the one of `mm init`, with the `SKILL.md` as it would be written on the right.
++- **An existing skill** is never replaced without your answer. The question comes right after the name.
++- **After writing**, mm reads the skill back with its own loader and says `✅ mm reads it`.
++
++The flags are `--name`, `--description`, `--keywords`, `--body`, `--body-file`, `-config`, `--yes` and `--line`. `-o -` prints the skill and creates nothing.
++
++**Not tried**: the window in a real terminal. It is covered by tests on a simulated screen only.
++
++See [How to add a skill](../docs/en/how-to/add-a-skill.md).
++
++### Tools for models whose template reads `xml_tools` (#207)
++
++SmolLM3's card says it calls tools, but through mm it never did. Its chat template reads the tools from an `xml_tools` variable and never from the OpenAI API's `tools`, which is what mm sends. Given `xml_tools`, the model writes its call as `<tool_call>…</tool_call>` text, which llama-server does not turn into a tool call.
++
++`toolFormat: xml_tools` in the agent file fixes both sides. mm sends the tools in `chat_template_kwargs.xml_tools`, writes earlier calls back into the history as `<tool_call>` text, and turns the `<tool_call>` blocks of the answer into tool calls, streamed or not. A block whose JSON is broken or cut is handed back to the model, as for any other model. `toolFormat: openai`, the default, changes nothing for other models.
++
++Measured on llmman with SmolLM3-3B Q4_K_M:
++- with reasoning on, it repeats its call after the tool's answer instead of answering (3 runs out of 3);
++- with reasoning off, it answers (6 out of 6);
++- SmolLM3-3B-128K was tried on a one-step request (3 runs); longer tasks were not tried with it.
++
++Tasks of several steps stay fragile at 3B: the model sometimes takes a tool's output for something the user said. Wrapping that output in `<tool_response>` tags made no measured difference.
++
++See [How to give tools to a model whose template reads `xml_tools`](../docs/en/how-to/use-a-model-that-reads-xml-tools.md).
++
++### SmolLM3 in `mm init`
++
++A new `smollm3` family covers `unsloth/SmolLM3-3B-GGUF` and `SmolLM3-3B-128K-GGUF`.
++
++- **Sampling**: temperature 0.6 and top_p 0.95, from the model card and its `generation_config.json`.
++- **Tools**: the family writes `toolFormat: xml_tools` for a usage with tools.
++- **Reasoning**: it is written off whatever the usage, with a note at the end of the file that gives the measurement above.
++
++A file written by `mm init --usage developer --project yes` for SmolLM3-3B ran `bash` in 3 runs out of 3. Both models pass `mm init --check` with the `translator` usage.
++
++### `mm sbxinit` and the `.mm` folder (#208)
++
++`mm sbxinit` now also looks for `.mm/agent.yaml`, after `agent.yaml`, and names the sandbox after its `acp.name`. For a `.mm` project it writes a `sbxenv.yaml` that keeps the agent's settings out of its own reach.
++
++- `.mm/` is mounted read-only over the workspace.
++- The folders mm writes in are mounted writable again, read from the agent file: `sessions.dir` when the sessions are on, and `trace.dir` when the trace is on.
++- `AGENT_CONFIG` names the agent file through a `PROJECT_DIR` argument, so it does not depend on the mm version the kit ships. It was not tried from an editor (ACP) in a sandbox.
++- Every path is relative to the folder of `sbxenv.yaml`, so the file can be committed.
++- Every `sbx env` command takes `--env-arg PROJECT_DIR="$PWD"`.
++
++The nested mounts were checked in a Docker Sandbox: the sessions are written from the sandbox while `.mm` is read-only.
++
++See [How to run mini-me in a Docker Sandbox](../docs/en/how-to/run-in-a-docker-sandbox.md).
++
++## Demos
++
++- [`demos/smollm3-demo/`](../demos/smollm3-demo/.mm/agent.yaml): an agent written by `mm init` for SmolLM3-3B in a `.mm` folder, with `toolFormat: xml_tools` and reasoning off.
++
++## Documentation
++
++- New:
++  - [How to keep a project's mini-me files in a `.mm` folder](../docs/en/how-to/keep-the-config-in-a-mm-folder.md);
++  - [How to give tools to a model whose template reads `xml_tools`](../docs/en/how-to/use-a-model-that-reads-xml-tools.md).
++- Updated:
++  - the CLI reference, with configuration file resolution, the base directory of relative paths, the flags of `mm init` and `mm sbxinit`, and `mm skillcreate`;
++  - the configuration reference (`toolFormat`) and the hooks reference (`MM_CONFIG_DIR`);
++  - the guides to creating an agent, adding a skill, using mini-me from an editor, guarding the agent with hooks, and running in a Docker Sandbox;
++  - the `mm init` explanation. The sample window of [How to create an agent](../docs/en/how-to/create-an-agent.md) is now taken from the real window.
++
++## Upgrading
++
++- **Agent files do not change**, with one exception, below. Replace the binary: see the install guides for [macOS](../INSTALL.MACOS.md), [Linux](../INSTALL.LINUX.md) and [Windows](../INSTALL.WINDOWS.md).
++- **A config file directly inside a `.mm` folder**: its relative paths now start at the project root, and `MM_CONFIG_DIR` is the project root. A hook written `$MM_CONFIG_DIR/hooks/…` for a `.mm/agent.yaml` becomes `$MM_CONFIG_DIR/.mm/hooks/…`. To run the same file with an older mm too, for example the one a sandbox kit ships, write `${MM_CONFIG_DIR%/.mm}/.mm/hooks/…`, which gives the project root with any version.
++- New key: `toolFormat` (`openai` by default, or `xml_tools`). Any other value stops the load with `toolFormat must be openai or xml_tools`.
++- New command: `mm skillcreate` (also `--skillcreate`). New `mm init` flags: `--project`, `--sessions` and `--skills`.
++- **Changed messages.** The interrupt messages start with `🔴` followed by two spaces instead of `🛑 `: for example `🔴  Generation aborted.`, `🔴  Interrupted (Ctrl+C).` and `🔴  Ask aborted — nothing kept.`

added release-notes/v1.0.7.fr.md +106 -0 Viewed

new file mode 100644
@@ -0,0 +1,106 @@
	1	+# mini-me v1.0.7
	2	+
	3	+[English version](v1.0.7.en.md)
	4	+
	5	+Un projet peut ranger son agent dans un dossier `.mm`, que `mm init`, `mm sbxinit` et le nouveau `mm skillcreate` connaissent tous, et des modèles comme SmolLM3, dont le chat template lit ses outils dans `xml_tools`, peuvent appeler les outils de mm.
	6	+
	7	+## Nouveautés
	8	+
	9	+### Le dossier de projet `.mm` (#204)
	10	+
	11	+`mm` et `mm tui` lancés sans fichier de configuration cherchent maintenant `./agent.yaml`, puis `./.mm/agent.yaml`. Quand les deux existent, `./agent.yaml` l'emporte. Un fichier donné par `-config` ou `AGENT_CONFIG` passe toujours en premier.
	12	+
	13	+Les chemins relatifs d'un fichier de configuration placé directement dans un dossier `.mm` partent de la racine du projet, le parent de `.mm`, et non de `.mm` lui-même. C'est vrai quelle que soit la façon dont le fichier a été désigné, et aussi en mode ACP. Un `.mm/agent.yaml` écrit donc `skillsDir: .mm/skills`, comme on le taperait depuis la racine où mm tourne. Cela concerne `mmConfigs`, les hooks et leur `MM_CONFIG_DIR`, `tools[].wasm`, les deciders de `skillRouting` et `toolRouting`, et `skillsDir` en mode ACP, qui donnait jusqu'ici `.mm/.mm/skills`. `skillsDir` dans un terminal, `sessions.dir` et `agentsMd.path` suivent le répertoire de travail, comme avant.
	14	+
	15	+Voir [Comment ranger les fichiers mini-me d'un projet dans un dossier `.mm`](../docs/fr/how-to/keep-the-config-in-a-mm-folder.md).
	16	+
	17	+### `mm init` : disposition Project, sessions et skills (#205)
	18	+
	19	+L'assistant a trois nouvelles questions oui/non, toutes à `no` par défaut.
	20	+
	21	+- Tout ranger dans un dossier `.mm` ? C'est la première question. Avec `yes`, mm crée `.mm/`, écrit `.mm/agent.yaml` avec des chemins depuis la racine du projet, et finit par `Next: mm (or mm tui)`. Un fichier choisi hors de `.mm/` est refusé.
	22	+- Enregistrer les conversations ? Avec `yes`, le fichier reçoit une section `sessions` (`enabled: true`, `dir: .mm/sessions`). Avec `no`, il n'en reçoit aucune, et les sessions restent désactivées comme avant.
	23	+- Utiliser des skills ? Avec `yes`, le fichier reçoit `skillsDir: skills`, ou `.mm/skills` avec la disposition Project, et le dossier est créé.
	24	+
	25	+Les options sont `--project`, `--sessions` et `--skills`, chacune à `yes` ou `no`. `-o -` affiche le fichier et ne crée rien. Sans les nouvelles options, le fichier qu'écrit mm init est identique, octet pour octet, à celui de la v1.0.6.
	26	+
	27	+Voir [Créer un agent avec `mm init`](../docs/fr/how-to/create-an-agent.md).
	28	+
	29	+### `mm skillcreate`, un assistant pour les skills (#206)
	30	+
	31	+`mm skillcreate` demande un skill et l'écrit dans `<skillsDir>/<nom>/SKILL.md`, là où le fichier de configuration de l'agent dit que sont ses skills. Il trouve ce fichier comme mm, `.mm/agent.yaml` compris. Sans configuration, ou avec `skillsDir: no-skills`, le skill va dans `.mm/skills` si un dossier `.mm` existe, sinon dans `skills`, et mm indique quel `skillsDir` régler.
	32	+
	33	+- Le nom est écrit en minuscules, avec des tirets : `Vulcan Salute` donne `vulcan-salute`, pour le `name` de l'en-tête et pour le dossier.
	34	+- Le titre de niveau 1 est le nom tel que vous l'avez tapé. Un nom tapé déjà normalisé redevient des mots : `vulcan-salute` donne `# Vulcan Salute`. Une section `## What to do` suit, puis le texte.
	35	+- Les mots-clés sont facultatifs. Au-delà de 8, mm prévient que seuls les 8 premiers arrivent au catalogue.
	36	+- Le texte est toujours la dernière question. En mode ligne, il se termine par Ctrl-D. Dans la fenêtre, Entrée ajoute une ligne et Ctrl-D valide. La fenêtre est celle de `mm init`, avec à droite le `SKILL.md` tel qu'il serait écrit.
	37	+- Un skill existant n'est jamais remplacé sans votre réponse. La question vient juste après le nom.
	38	+- Après l'écriture, mm relit le skill avec son propre chargeur et affiche `✅ mm reads it`.
	39	+
	40	+Les options sont `--name`, `--description`, `--keywords`, `--body`, `--body-file`, `-config`, `--yes` et `--line`. `-o -` affiche le skill et ne crée rien.
	41	+
	42	+Pas essayé : la fenêtre dans un vrai terminal. Seuls des tests sur un écran simulé la couvrent.
	43	+
	44	+Voir [Comment ajouter un skill](../docs/fr/how-to/add-a-skill.md).
	45	+
	46	+### Des outils pour les modèles dont le template lit `xml_tools` (#207)
	47	+
	48	+La fiche de SmolLM3 dit qu'il sait appeler des outils, mais à travers mm il ne le faisait jamais. Son chat template lit les outils dans une variable `xml_tools`, jamais dans le champ `tools` de l'API OpenAI, celui qu'envoie mm. Quand on lui donne `xml_tools`, le modèle écrit son appel en texte, `<tool_call>…</tool_call>`, que llama-server ne transforme pas en appel d'outil.
	49	+
	50	+`toolFormat: xml_tools` dans le fichier de l'agent règle les deux côtés. mm envoie les outils dans `chat_template_kwargs.xml_tools`, réécrit les appels précédents dans l'historique en texte `<tool_call>`, et transforme les blocs `<tool_call>` de la réponse en appels d'outils, en streaming ou non. Un bloc dont le JSON est cassé ou coupé est rendu au modèle, comme pour tout autre modèle. `toolFormat: openai`, la valeur par défaut, ne change rien pour les autres modèles.
	51	+
	52	+Mesuré sur llmman avec SmolLM3-3B Q4_K_M :
	53	+- avec le raisonnement activé, il répète son appel après la réponse de l'outil au lieu de répondre (3 essais sur 3) ;
	54	+- sans raisonnement, il répond (6 sur 6) ;
	55	+- SmolLM3-3B-128K a été essayé sur une demande en une étape (3 essais) ; les tâches plus longues n'ont pas été essayées avec lui.
	56	+
	57	+Les tâches en plusieurs étapes restent fragiles avec un 3B : le modèle prend parfois la sortie d'un outil pour une phrase de l'utilisateur. Entourer cette sortie de balises `<tool_response>` n'a rien changé de mesurable.
	58	+
	59	+Voir [Comment donner des outils à un modèle dont le template lit `xml_tools`](../docs/fr/how-to/use-a-model-that-reads-xml-tools.md).
	60	+
	61	+### SmolLM3 dans `mm init`
	62	+
	63	+Une nouvelle famille `smollm3` couvre `unsloth/SmolLM3-3B-GGUF` et `SmolLM3-3B-128K-GGUF`.
	64	+
	65	+- Échantillonnage : température 0.6 et top_p 0.95, d'après la fiche du modèle et son `generation_config.json`.
	66	+- Outils : la famille écrit `toolFormat: xml_tools` pour un usage avec outils.
	67	+- Raisonnement : il est écrit désactivé quel que soit l'usage, avec en fin de fichier une note qui donne la mesure ci-dessus.
	68	+
	69	+Un fichier écrit par `mm init --usage developer --project yes` pour SmolLM3-3B a lancé `bash` dans 3 essais sur 3. Les deux modèles passent `mm init --check` avec l'usage `translator`.
	70	+
	71	+### `mm sbxinit` et le dossier `.mm` (#208)
	72	+
	73	+`mm sbxinit` cherche maintenant aussi `.mm/agent.yaml`, après `agent.yaml`, et nomme la sandbox d'après son `acp.name`. Pour un projet `.mm`, il écrit un `sbxenv.yaml` qui met les réglages de l'agent hors de sa portée.
	74	+
	75	+- `.mm/` est monté en lecture seule par-dessus le workspace.
	76	+- Les dossiers où mm écrit sont de nouveau montés en écriture, d'après le fichier d'agent : `sessions.dir` quand les sessions sont activées, et `trace.dir` quand la trace l'est.
	77	+- `AGENT_CONFIG` désigne le fichier d'agent via un argument `PROJECT_DIR`, ce qui ne dépend pas de la version de mm qu'embarque le kit. Ce n'a pas été essayé depuis un éditeur (ACP) dans une sandbox.
	78	+- Tous les chemins sont relatifs au dossier de `sbxenv.yaml` : le fichier peut être commité.
	79	+- Chaque commande `sbx env` prend `--env-arg PROJECT_DIR="$PWD"`.
	80	+
	81	+Les montages imbriqués ont été vérifiés dans un Docker Sandbox : les sessions s'écrivent depuis la sandbox alors que `.mm` est en lecture seule.
	82	+
	83	+Voir [Comment faire tourner mini-me dans un Docker Sandbox](../docs/fr/how-to/run-in-a-docker-sandbox.md).
	84	+
	85	+## Démos
	86	+
	87	+- [`demos/smollm3-demo/`](../demos/smollm3-demo/.mm/agent.yaml) : un agent écrit par `mm init` pour SmolLM3-3B dans un dossier `.mm`, avec `toolFormat: xml_tools` et le raisonnement désactivé.
	88	+
	89	+## Documentation
	90	+
	91	+- Nouveau :
	92	+ - [Comment ranger les fichiers mini-me d'un projet dans un dossier `.mm`](../docs/fr/how-to/keep-the-config-in-a-mm-folder.md) ;
	93	+ - [Comment donner des outils à un modèle dont le template lit `xml_tools`](../docs/fr/how-to/use-a-model-that-reads-xml-tools.md).
	94	+- Mis à jour :
	95	+ - la référence CLI, avec la résolution du fichier de configuration, le répertoire de base des chemins relatifs, les options de `mm init` et `mm sbxinit`, et `mm skillcreate` ;
	96	+ - la référence de la configuration (`toolFormat`) et celle des hooks (`MM_CONFIG_DIR`) ;
	97	+ - les guides pour créer un agent, ajouter un skill, utiliser mini-me depuis un éditeur, encadrer l'agent avec des hooks, et le faire tourner dans un Docker Sandbox ;
	98	+ - l'explication de `mm init`. La fenêtre d'exemple de [Créer un agent](../docs/fr/how-to/create-an-agent.md) est maintenant tirée de la vraie fenêtre.
	99	+
	100	+## Mise à jour
	101	+
	102	+- Les fichiers d'agent ne changent pas, à une exception près, ci-dessous. Remplacez le binaire : voir les guides d'installation pour [macOS](../INSTALL.MACOS.md), [Linux](../INSTALL.LINUX.md) et [Windows](../INSTALL.WINDOWS.md).
	103	+- Un fichier de configuration placé directement dans un dossier `.mm` : ses chemins relatifs partent maintenant de la racine du projet, et `MM_CONFIG_DIR` vaut la racine du projet. Un hook écrit `$MM_CONFIG_DIR/hooks/…` pour un `.mm/agent.yaml` devient `$MM_CONFIG_DIR/.mm/hooks/…`. Pour faire tourner le même fichier avec un mm plus ancien aussi, par exemple celui d'un kit de sandbox, écrivez `${MM_CONFIG_DIR%/.mm}/.mm/hooks/…`, qui donne la racine du projet avec n'importe quelle version.
	104	+- Nouvelle clé : `toolFormat` (`openai` par défaut, ou `xml_tools`). Toute autre valeur arrête le chargement avec `toolFormat must be openai or xml_tools`.
	105	+- Nouvelle commande : `mm skillcreate` (aussi `--skillcreate`). Nouvelles options de `mm init` : `--project`, `--sessions` et `--skills`.
	106	+- Messages modifiés. Les messages d'interruption commencent par `🔴` suivi de deux espaces au lieu de `🛑 `, par exemple `🔴 Generation aborted.`, `🔴 Interrupted (Ctrl+C).` et `🔴 Ask aborted — nothing kept.`

++# mini-me v1.0.7
++
++*[English version](v1.0.7.en.md)*
++
++Un projet peut ranger son agent dans un dossier `.mm`, que `mm init`, `mm sbxinit` et le nouveau `mm skillcreate` connaissent tous, et des modèles comme SmolLM3, dont le chat template lit ses outils dans `xml_tools`, peuvent appeler les outils de mm.
++
++## Nouveautés
++
++### Le dossier de projet `.mm` (#204)
++
++`mm` et `mm tui` lancés sans fichier de configuration cherchent maintenant `./agent.yaml`, puis `./.mm/agent.yaml`. Quand les deux existent, `./agent.yaml` l'emporte. Un fichier donné par `-config` ou `AGENT_CONFIG` passe toujours en premier.
++
++Les chemins relatifs d'un fichier de configuration placé directement dans un dossier `.mm` partent de la racine du projet, le parent de `.mm`, et non de `.mm` lui-même. C'est vrai quelle que soit la façon dont le fichier a été désigné, et aussi en mode ACP. Un `.mm/agent.yaml` écrit donc `skillsDir: .mm/skills`, comme on le taperait depuis la racine où mm tourne. Cela concerne `mmConfigs`, les hooks et leur `MM_CONFIG_DIR`, `tools[].wasm`, les deciders de `skillRouting` et `toolRouting`, et `skillsDir` en mode ACP, qui donnait jusqu'ici `.mm/.mm/skills`. `skillsDir` dans un terminal, `sessions.dir` et `agentsMd.path` suivent le répertoire de travail, comme avant.
++
++Voir [Comment ranger les fichiers mini-me d'un projet dans un dossier `.mm`](../docs/fr/how-to/keep-the-config-in-a-mm-folder.md).
++
++### `mm init` : disposition Project, sessions et skills (#205)
++
++L'assistant a trois nouvelles questions oui/non, toutes à `no` par défaut.
++
++- **Tout ranger dans un dossier `.mm` ?** C'est la première question. Avec `yes`, mm crée `.mm/`, écrit `.mm/agent.yaml` avec des chemins depuis la racine du projet, et finit par `Next: mm (or mm tui)`. Un fichier choisi hors de `.mm/` est refusé.
++- **Enregistrer les conversations ?** Avec `yes`, le fichier reçoit une section `sessions` (`enabled: true`, `dir: .mm/sessions`). Avec `no`, il n'en reçoit aucune, et les sessions restent désactivées comme avant.
++- **Utiliser des skills ?** Avec `yes`, le fichier reçoit `skillsDir: skills`, ou `.mm/skills` avec la disposition Project, et le dossier est créé.
++
++Les options sont `--project`, `--sessions` et `--skills`, chacune à `yes` ou `no`. `-o -` affiche le fichier et ne crée rien. Sans les nouvelles options, le fichier qu'écrit mm init est identique, octet pour octet, à celui de la v1.0.6.
++
++Voir [Créer un agent avec `mm init`](../docs/fr/how-to/create-an-agent.md).
++
++### `mm skillcreate`, un assistant pour les skills (#206)
++
++`mm skillcreate` demande un skill et l'écrit dans `<skillsDir>/<nom>/SKILL.md`, là où le fichier de configuration de l'agent dit que sont ses skills. Il trouve ce fichier comme mm, `.mm/agent.yaml` compris. Sans configuration, ou avec `skillsDir: no-skills`, le skill va dans `.mm/skills` si un dossier `.mm` existe, sinon dans `skills`, et mm indique quel `skillsDir` régler.
++
++- **Le nom** est écrit en minuscules, avec des tirets : `Vulcan Salute` donne `vulcan-salute`, pour le `name` de l'en-tête et pour le dossier.
++- **Le titre de niveau 1** est le nom tel que vous l'avez tapé. Un nom tapé déjà normalisé redevient des mots : `vulcan-salute` donne `# Vulcan Salute`. Une section `## What to do` suit, puis le texte.
++- **Les mots-clés** sont facultatifs. Au-delà de 8, mm prévient que seuls les 8 premiers arrivent au catalogue.
++- **Le texte** est toujours la dernière question. En mode ligne, il se termine par Ctrl-D. Dans la fenêtre, Entrée ajoute une ligne et Ctrl-D valide. La fenêtre est celle de `mm init`, avec à droite le `SKILL.md` tel qu'il serait écrit.
++- **Un skill existant** n'est jamais remplacé sans votre réponse. La question vient juste après le nom.
++- **Après l'écriture**, mm relit le skill avec son propre chargeur et affiche `✅ mm reads it`.
++
++Les options sont `--name`, `--description`, `--keywords`, `--body`, `--body-file`, `-config`, `--yes` et `--line`. `-o -` affiche le skill et ne crée rien.
++
++**Pas essayé** : la fenêtre dans un vrai terminal. Seuls des tests sur un écran simulé la couvrent.
++
++Voir [Comment ajouter un skill](../docs/fr/how-to/add-a-skill.md).
++
++### Des outils pour les modèles dont le template lit `xml_tools` (#207)
++
++La fiche de SmolLM3 dit qu'il sait appeler des outils, mais à travers mm il ne le faisait jamais. Son chat template lit les outils dans une variable `xml_tools`, jamais dans le champ `tools` de l'API OpenAI, celui qu'envoie mm. Quand on lui donne `xml_tools`, le modèle écrit son appel en texte, `<tool_call>…</tool_call>`, que llama-server ne transforme pas en appel d'outil.
++
++`toolFormat: xml_tools` dans le fichier de l'agent règle les deux côtés. mm envoie les outils dans `chat_template_kwargs.xml_tools`, réécrit les appels précédents dans l'historique en texte `<tool_call>`, et transforme les blocs `<tool_call>` de la réponse en appels d'outils, en streaming ou non. Un bloc dont le JSON est cassé ou coupé est rendu au modèle, comme pour tout autre modèle. `toolFormat: openai`, la valeur par défaut, ne change rien pour les autres modèles.
++
++Mesuré sur llmman avec SmolLM3-3B Q4_K_M :
++- avec le raisonnement activé, il répète son appel après la réponse de l'outil au lieu de répondre (3 essais sur 3) ;
++- sans raisonnement, il répond (6 sur 6) ;
++- SmolLM3-3B-128K a été essayé sur une demande en une étape (3 essais) ; les tâches plus longues n'ont pas été essayées avec lui.
++
++Les tâches en plusieurs étapes restent fragiles avec un 3B : le modèle prend parfois la sortie d'un outil pour une phrase de l'utilisateur. Entourer cette sortie de balises `<tool_response>` n'a rien changé de mesurable.
++
++Voir [Comment donner des outils à un modèle dont le template lit `xml_tools`](../docs/fr/how-to/use-a-model-that-reads-xml-tools.md).
++
++### SmolLM3 dans `mm init`
++
++Une nouvelle famille `smollm3` couvre `unsloth/SmolLM3-3B-GGUF` et `SmolLM3-3B-128K-GGUF`.
++
++- **Échantillonnage** : température 0.6 et top_p 0.95, d'après la fiche du modèle et son `generation_config.json`.
++- **Outils** : la famille écrit `toolFormat: xml_tools` pour un usage avec outils.
++- **Raisonnement** : il est écrit désactivé quel que soit l'usage, avec en fin de fichier une note qui donne la mesure ci-dessus.
++
++Un fichier écrit par `mm init --usage developer --project yes` pour SmolLM3-3B a lancé `bash` dans 3 essais sur 3. Les deux modèles passent `mm init --check` avec l'usage `translator`.
++
++### `mm sbxinit` et le dossier `.mm` (#208)
++
++`mm sbxinit` cherche maintenant aussi `.mm/agent.yaml`, après `agent.yaml`, et nomme la sandbox d'après son `acp.name`. Pour un projet `.mm`, il écrit un `sbxenv.yaml` qui met les réglages de l'agent hors de sa portée.
++
++- `.mm/` est monté en lecture seule par-dessus le workspace.
++- Les dossiers où mm écrit sont de nouveau montés en écriture, d'après le fichier d'agent : `sessions.dir` quand les sessions sont activées, et `trace.dir` quand la trace l'est.
++- `AGENT_CONFIG` désigne le fichier d'agent via un argument `PROJECT_DIR`, ce qui ne dépend pas de la version de mm qu'embarque le kit. Ce n'a pas été essayé depuis un éditeur (ACP) dans une sandbox.
++- Tous les chemins sont relatifs au dossier de `sbxenv.yaml` : le fichier peut être commité.
++- Chaque commande `sbx env` prend `--env-arg PROJECT_DIR="$PWD"`.
++
++Les montages imbriqués ont été vérifiés dans un Docker Sandbox : les sessions s'écrivent depuis la sandbox alors que `.mm` est en lecture seule.
++
++Voir [Comment faire tourner mini-me dans un Docker Sandbox](../docs/fr/how-to/run-in-a-docker-sandbox.md).
++
++## Démos
++
++- [`demos/smollm3-demo/`](../demos/smollm3-demo/.mm/agent.yaml) : un agent écrit par `mm init` pour SmolLM3-3B dans un dossier `.mm`, avec `toolFormat: xml_tools` et le raisonnement désactivé.
++
++## Documentation
++
++- Nouveau :
++  - [Comment ranger les fichiers mini-me d'un projet dans un dossier `.mm`](../docs/fr/how-to/keep-the-config-in-a-mm-folder.md) ;
++  - [Comment donner des outils à un modèle dont le template lit `xml_tools`](../docs/fr/how-to/use-a-model-that-reads-xml-tools.md).
++- Mis à jour :
++  - la référence CLI, avec la résolution du fichier de configuration, le répertoire de base des chemins relatifs, les options de `mm init` et `mm sbxinit`, et `mm skillcreate` ;
++  - la référence de la configuration (`toolFormat`) et celle des hooks (`MM_CONFIG_DIR`) ;
++  - les guides pour créer un agent, ajouter un skill, utiliser mini-me depuis un éditeur, encadrer l'agent avec des hooks, et le faire tourner dans un Docker Sandbox ;
++  - l'explication de `mm init`. La fenêtre d'exemple de [Créer un agent](../docs/fr/how-to/create-an-agent.md) est maintenant tirée de la vraie fenêtre.
++
++## Mise à jour
++
++- **Les fichiers d'agent ne changent pas**, à une exception près, ci-dessous. Remplacez le binaire : voir les guides d'installation pour [macOS](../INSTALL.MACOS.md), [Linux](../INSTALL.LINUX.md) et [Windows](../INSTALL.WINDOWS.md).
++- **Un fichier de configuration placé directement dans un dossier `.mm`** : ses chemins relatifs partent maintenant de la racine du projet, et `MM_CONFIG_DIR` vaut la racine du projet. Un hook écrit `$MM_CONFIG_DIR/hooks/…` pour un `.mm/agent.yaml` devient `$MM_CONFIG_DIR/.mm/hooks/…`. Pour faire tourner le même fichier avec un mm plus ancien aussi, par exemple celui d'un kit de sandbox, écrivez `${MM_CONFIG_DIR%/.mm}/.mm/hooks/…`, qui donne la racine du projet avec n'importe quelle version.
++- Nouvelle clé : `toolFormat` (`openai` par défaut, ou `xml_tools`). Toute autre valeur arrête le chargement avec `toolFormat must be openai or xml_tools`.
++- Nouvelle commande : `mm skillcreate` (aussi `--skillcreate`). Nouvelles options de `mm init` : `--project`, `--sessions` et `--skills`.
++- **Messages modifiés.** Les messages d'interruption commencent par `🔴` suivi de deux espaces au lieu de `🛑 `, par exemple `🔴  Generation aborted.`, `🔴  Interrupted (Ctrl+C).` et `🔴  Ask aborted — nothing kept.`