mini-me v0.9.0

Démarrer un agent sans écrire son fichier, exécuter vos propres outils et hooks en modules WebAssembly dans un bac à sable, et parler à n'importe quel serveur compatible OpenAI.

Nouveautés

`mm init` — un assistant qui écrit l'agent.yaml (#97)

mm init (ou mm --init) pose quelques questions et écrit un agent.yaml commenté : le serveur de modèles, le modèle (choisi dans la liste du serveur lui-même), sa famille, à quoi sert l'agent, quelle machine le fait tourner, s'il faut demander avant chaque commande ou modification de fichier, le nom de l'agent et le fichier. Aucun modèle ne tourne pendant ce temps.
Dans un terminal, il ouvre une fenêtre dans le style de mm -tui : les étapes à gauche, la question au centre avec ce que signifie le choix surligné, et à droite le fichier tel qu'il serait écrit, mis à jour quand la sélection bouge. ↑ ↓ choisissent, Entrée répond, Échap revient en arrière, Tab affiche l'aperçu sur un écran de moins de 100 colonnes, Ctrl-C quitte sans rien écrire.
Chaque valeur dit pourquoi elle a cette valeur, dans un commentaire : ce que le serveur dit du modèle (/api/show de llmman et d'Ollama, /props de llama-server : fenêtre native, échantillonnage du GGUF lui-même, interrupteur de raisonnement du template), puis une table de 14 familles de modèles (Qwen, Qwen Coder, Gemma, Mellum, Mellum Thinking, gpt-oss, OpenAI, MiniCPM, Ornith, Granite Guardian, Menlo, Llama, Mistral, other — chaque entrée avec sa source), puis 9 usages (developer, reviewer, translator, writer, assistant, researcher, docs, json, coordinator), puis les 3 lignes machine du guide des réglages (small, medium, large).
Pour les scripts : chaque question a son option (--provider, --model, --usage, --machine, --name, -o…), --yes prend les valeurs par défaut pour le reste, -o - affiche le fichier au lieu de l'écrire, --line pose les questions ligne par ligne, et --check demande au modèle « Say hello in one line. » avec le nouveau fichier.
Un fichier existant n'est jamais écrasé : mm le dit avant de poser la moindre question. Le fichier écrit est chargé comme mm charge une configuration, donc un fichier qui ne démarrerait pas est signalé tout de suite.

Des outils WebAssembly (#119)

Une entrée tools: peut maintenant nommer un module WebAssembly au lieu d'une commande : wasm: ./tools/search_notes.wasm. mm l'exécute lui-même, avec wazero — aucun processus, rien à installer — dans un bac à sable qui ne voit aucun fichier, aucune variable d'environnement et aucun réseau, sauf les dossiers que l'entrée ouvre : read: [notes] (lecture seule) et write: [out] (lecture-écriture).
Le module est un programme WASI ordinaire (TinyGo : tinygo build -target=wasip1). Il lit les arguments de l'appel en un seul objet JSON sur stdin — vérifiés et typés par mm, valeurs par défaut appliquées — et ce qu'il écrit est le résultat de l'outil ; un code de sortie non nul est un échec.
Même consentement (yolo), même détecteur de boucle, mêmes hooks et même affichage qu'un outil commande, dans toutes les façades.
Mesuré dans un sandbox linux/arm64 : compiler un module TinyGo d'environ 550 Ko a pris 176 à 183 ms, une fois par processus mm ; chaque appel suivant 0,2 à 0,5 ms.

Des hooks WebAssembly (#120, clôt #46)

Une entrée de hook peut aussi nommer un module : wasm: ./hooks/bash_guard.wasm au lieu de command:. Il lit le même JSON et écrit la même réponse qu'un hook script ; matcher, timeout et onError fonctionnent comme avant, et read: / write: ouvrent des dossiers comme pour les outils. De l'environnement, le module ne voit que MM_HOOK_EVENT.
Mesuré avec la garde bash de demos/hooks, à travers le lanceur de hooks de mm : le script Node.js prend une médiane de 65 à 67 ms par appel ; les mêmes règles en module 0,56 à 0,58 ms, après une première exécution de 234 à 248 ms (la compilation).
Un hook qui liste le répertoire de travail ou appelle un serveur (les modèles de garde) reste un script : un module peut ouvrir des dossiers à l'intérieur du répertoire de travail, pas le répertoire lui-même, et n'a pas de réseau.

Un fournisseur pour tout serveur compatible OpenAI (#118)

provider: openai parle à tout serveur qui parle l'API OpenAI — l'API OpenAI elle-même par défaut (https://api.openai.com/v1), ou le baseUrl que vous donnez. La clé vient de OPENAI_API_KEY, jamais du YAML.
Il ne suppose que le protocole : aucun des champs que mm ajoute pour llama.cpp, llmman ou Ollama n'est envoyé. Un tel serveur ne dit pas la taille de sa fenêtre : donnez contextWindow, sinon la compression compte les messages.
Au démarrage, un serveur qui refuse la clé est signalé comme tel (refused the key — export OPENAI_API_KEY…), et non comme un serveur qui ne répond pas.
mm init le propose aussi, et liste ses modèles avec la clé. La vraie API OpenAI n'a pas été essayée pendant le développement.

`mm tui` et `mm acp` (#117)

La fenêtre et le mode éditeur se lancent aussi par un mot, comme mm init : mm tui agent.yaml est mm -tui agent.yaml, mm acp est mm -acp. Toutes les autres options fonctionnent (mm tui -config a.yaml). --tui et --acp fonctionnaient déjà.

Corrigé

Les plans étaient partagés par toutes les conversations d'un éditeur (#108). Chaque session ACP a maintenant ses propres plans ; en mode ligne et dans la fenêtre il n'y a qu'une conversation, comme avant.
/new et /resume gardaient les anciens plans (#109). Une conversation qui change commence maintenant sans plan : /new et /resume en mode ligne et dans la fenêtre, une nouvelle session, session/load et session/resume en ACP (seulement les plans de cette conversation).
La ligne de progression des plans était documentée mais jamais affichée (#110). Après chaque action sur un plan, mm affiche maintenant 📋 [2/3] … : écrite en mode ligne, une notification dans la fenêtre, dans le résultat de l'appel d'outil dans un éditeur. La rendre visible a révélé deux défauts, corrigés avec elle : après update 1 done la ligne montrait encore la tâche 1, et un next ultérieur remettait la tâche terminée en cours.
mm --about ne listait que six outils et deux serveurs de modèles. Il liste maintenant chaque outil intégré — ceux actifs par défaut et ceux que la configuration active — et les serveurs de modèles (Docker Model Runner, llmman, Ollama, llama.cpp, tout autre serveur compatible OpenAI). Un test échoue maintenant si un nouvel outil intégré y manque, et un autre s'il n'a pas de section dans la référence des outils (plan n'en avait pas).

Démos

demos/plans/ (nouvelle) : Planner, sur Qwen3.5 4B avec llmman, construit un petit programme Go en quatre étapes — module, code, test, README — pendant que mm affiche la progression du plan après chaque action.
demos/wasm-tools/ (nouvelle) : un bureau de notes qui n'agit qu'à travers quatre outils WebAssembly — un calcul pur, deux qui ne peuvent que lire notes/, un qui ne peut qu'écrire dans out/. Appelé avec ../agent.yaml, le lecteur de notes ne trouve rien : le fichier est hors de son bac à sable. Qwen3.5 4B sur llmman, une exécution réelle de chaque outil.
demos/wasm-hooks/ (nouvelle) : les hooks de demos/hooks — filtre de secrets, garde bash, journal d'audit — en modules WebAssembly, sans rien à installer à côté de mm. Gemma 4 E4B sur llmman, avec la mesure face aux versions Node.js.
Les modules des deux démos WebAssembly sont fournis, compilés ; ./build.sh les reconstruit avec TinyGo.

Documentation

Nouveaux guides pratiques (EN + FR) :
Nouveau guide : les raccourcis clavier de la fenêtre (EN), groupés par ce que vous faites, avec la fenêtre de mm init.
Réécrit : Gérer des plans et des tâches — ce que montre chaque façade, un exemple mesuré ; la section sur une commande /plans qui n'existe pas a disparu.
Mis à jour : les explications des outils déclarés (une section sur les outils WebAssembly), des hooks (les hooks WebAssembly et ce qui a été mesuré) et des fournisseurs ; les références de la ligne de commande (mm init, mm tui, mm acp), de la configuration, des hooks, des outils (une section plan, les outils WebAssembly) et des commandes slash (/new, /resume et les plans) ; le diagramme des paquets.

Mise à jour

Compiler depuis les sources demande Go 1.27 (#115) : go.mod indique maintenant go 1.27.0 et toolchain go1.27.3. Le kit Go des Docker Sandboxes installe 1.27.3. Les binaires de release ne sont pas concernés.
Aucun changement cassant dans la configuration. Nouvelles clés : provider: openai ; wasm, read et write sur une entrée tools: et sur une entrée de hook. Un agent existant ne reçoit aucun nouvel outil.
Un premier argument init, tui ou acp est maintenant un mot de mode. Un fichier de configuration portant l'un de ces noms doit être donné en ./tui ou avec -config.
Deux messages ont changé : une entrée tools: sans command ni wasm dit maintenant command must name a program, … (or wasm: a module) ; une entrée de hook sans l'un ni l'autre dit command must not be empty (or wasm: a module).
Le binaire est plus gros : le runtime WebAssembly ajoute environ 3,9 Mo (38,97 → 42,87 Mo sur linux/arm64). mm n'utilise toujours pas CGO et se compile pour les mêmes cinq cibles.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72


# mini-me v0.9.0

*[English version](v0.9.0.en.md)*

Démarrer un agent sans écrire son fichier, exécuter vos propres outils et hooks en modules WebAssembly dans un bac à sable, et parler à n'importe quel serveur compatible OpenAI.

## Nouveautés

### `mm init` — un assistant qui écrit l'agent.yaml (#97)

- **`mm init`** (ou `mm --init`) pose quelques questions et écrit un `agent.yaml` commenté : le serveur de modèles, le modèle (choisi dans la liste du serveur lui-même), sa famille, à quoi sert l'agent, quelle machine le fait tourner, s'il faut demander avant chaque commande ou modification de fichier, le nom de l'agent et le fichier. Aucun modèle ne tourne pendant ce temps.
- **Dans un terminal, il ouvre une fenêtre** dans le style de `mm -tui` : les étapes à gauche, la question au centre avec ce que signifie le choix surligné, et à droite le fichier tel qu'il serait écrit, mis à jour quand la sélection bouge. `↑` `↓` choisissent, `Entrée` répond, `Échap` revient en arrière, `Tab` affiche l'aperçu sur un écran de moins de 100 colonnes, `Ctrl-C` quitte sans rien écrire.
- **Chaque valeur dit pourquoi elle a cette valeur**, dans un commentaire : ce que le serveur dit du modèle (`/api/show` de llmman et d'Ollama, `/props` de llama-server : fenêtre native, échantillonnage du GGUF lui-même, interrupteur de raisonnement du template), puis une table de 14 familles de modèles (Qwen, Qwen Coder, Gemma, Mellum, Mellum Thinking, gpt-oss, OpenAI, MiniCPM, Ornith, Granite Guardian, Menlo, Llama, Mistral, other — chaque entrée avec sa source), puis 9 usages (`developer`, `reviewer`, `translator`, `writer`, `assistant`, `researcher`, `docs`, `json`, `coordinator`), puis les 3 lignes machine du guide des réglages (`small`, `medium`, `large`).
- **Pour les scripts** : chaque question a son option (`--provider`, `--model`, `--usage`, `--machine`, `--name`, `-o`…), `--yes` prend les valeurs par défaut pour le reste, `-o -` affiche le fichier au lieu de l'écrire, `--line` pose les questions ligne par ligne, et `--check` demande au modèle « Say hello in one line. » avec le nouveau fichier.
- **Un fichier existant n'est jamais écrasé** : mm le dit avant de poser la moindre question. Le fichier écrit est chargé comme mm charge une configuration, donc un fichier qui ne démarrerait pas est signalé tout de suite.

### Des outils WebAssembly (#119)

- Une entrée `tools:` peut maintenant nommer un **module WebAssembly** au lieu d'une commande : `wasm: ./tools/search_notes.wasm`. mm l'exécute lui-même, avec [wazero](https://wazero.io) — aucun processus, rien à installer — dans un bac à sable qui ne voit **aucun fichier, aucune variable d'environnement et aucun réseau**, sauf les dossiers que l'entrée ouvre : `read: [notes]` (lecture seule) et `write: [out]` (lecture-écriture).
- Le module est un programme WASI ordinaire (TinyGo : `tinygo build -target=wasip1`). Il lit les arguments de l'appel en un seul objet JSON sur stdin — vérifiés et typés par mm, valeurs par défaut appliquées — et ce qu'il écrit est le résultat de l'outil ; un code de sortie non nul est un échec.
- Même consentement (`yolo`), même détecteur de boucle, mêmes hooks et même affichage qu'un outil commande, dans toutes les façades.
- Mesuré dans un sandbox linux/arm64 : compiler un module TinyGo d'environ 550 Ko a pris 176 à 183 ms, une fois par processus mm ; chaque appel suivant 0,2 à 0,5 ms.

### Des hooks WebAssembly (#120, clôt #46)

- Une entrée de hook peut aussi nommer un module : `wasm: ./hooks/bash_guard.wasm` au lieu de `command:`. Il lit le même JSON et écrit la même réponse qu'un hook script ; `matcher`, `timeout` et `onError` fonctionnent comme avant, et `read:` / `write:` ouvrent des dossiers comme pour les outils. De l'environnement, le module ne voit que `MM_HOOK_EVENT`.
- Mesuré avec la garde `bash` de `demos/hooks`, à travers le lanceur de hooks de mm : le script Node.js prend une médiane de 65 à 67 ms par appel ; les mêmes règles en module 0,56 à 0,58 ms, après une première exécution de 234 à 248 ms (la compilation).
- Un hook qui liste le répertoire de travail ou appelle un serveur (les modèles de garde) reste un script : un module peut ouvrir des dossiers à l'intérieur du répertoire de travail, pas le répertoire lui-même, et n'a pas de réseau.

### Un fournisseur pour tout serveur compatible OpenAI (#118)

- **`provider: openai`** parle à tout serveur qui parle l'API OpenAI — l'API OpenAI elle-même par défaut (`https://api.openai.com/v1`), ou le `baseUrl` que vous donnez. La clé vient de `OPENAI_API_KEY`, jamais du YAML.
- Il ne suppose que le protocole : aucun des champs que mm ajoute pour llama.cpp, llmman ou Ollama n'est envoyé. Un tel serveur ne dit pas la taille de sa fenêtre : donnez `contextWindow`, sinon la compression compte les messages.
- Au démarrage, un serveur qui refuse la clé est signalé comme tel (`refused the key — export OPENAI_API_KEY…`), et non comme un serveur qui ne répond pas.
- `mm init` le propose aussi, et liste ses modèles avec la clé. La vraie API OpenAI n'a pas été essayée pendant le développement.

### `mm tui` et `mm acp` (#117)

- La fenêtre et le mode éditeur se lancent aussi par un mot, comme `mm init` : `mm tui agent.yaml` est `mm -tui agent.yaml`, `mm acp` est `mm -acp`. Toutes les autres options fonctionnent (`mm tui -config a.yaml`). `--tui` et `--acp` fonctionnaient déjà.

## Corrigé

- **Les plans étaient partagés par toutes les conversations d'un éditeur** (#108). Chaque session ACP a maintenant ses propres plans ; en mode ligne et dans la fenêtre il n'y a qu'une conversation, comme avant.
- **`/new` et `/resume` gardaient les anciens plans** (#109). Une conversation qui change commence maintenant sans plan : `/new` et `/resume` en mode ligne et dans la fenêtre, une nouvelle session, `session/load` et `session/resume` en ACP (seulement les plans de cette conversation).
- **La ligne de progression des plans était documentée mais jamais affichée** (#110). Après chaque action sur un plan, mm affiche maintenant `📋 [2/3] …` : écrite en mode ligne, une notification dans la fenêtre, dans le résultat de l'appel d'outil dans un éditeur. La rendre visible a révélé deux défauts, corrigés avec elle : après `update 1 done` la ligne montrait encore la tâche 1, et un `next` ultérieur remettait la tâche terminée en cours.
- **`mm --about` ne listait que six outils et deux serveurs de modèles.** Il liste maintenant chaque outil intégré — ceux actifs par défaut et ceux que la configuration active — et les serveurs de modèles (Docker Model Runner, llmman, Ollama, llama.cpp, tout autre serveur compatible OpenAI). Un test échoue maintenant si un nouvel outil intégré y manque, et un autre s'il n'a pas de section dans la référence des outils (`plan` n'en avait pas).

## Démos

- **`demos/plans/`** (nouvelle) : Planner, sur Qwen3.5 4B avec llmman, construit un petit programme Go en quatre étapes — module, code, test, README — pendant que mm affiche la progression du plan après chaque action.
- **`demos/wasm-tools/`** (nouvelle) : un bureau de notes qui n'agit qu'à travers quatre outils WebAssembly — un calcul pur, deux qui ne peuvent que lire `notes/`, un qui ne peut qu'écrire dans `out/`. Appelé avec `../agent.yaml`, le lecteur de notes ne trouve rien : le fichier est hors de son bac à sable. Qwen3.5 4B sur llmman, une exécution réelle de chaque outil.
- **`demos/wasm-hooks/`** (nouvelle) : les hooks de `demos/hooks` — filtre de secrets, garde `bash`, journal d'audit — en modules WebAssembly, sans rien à installer à côté de mm. Gemma 4 E4B sur llmman, avec la mesure face aux versions Node.js.
- Les modules des deux démos WebAssembly sont fournis, compilés ; `./build.sh` les reconstruit avec TinyGo.

## Documentation

- **Nouveaux guides pratiques** (EN + FR) :
  - [Créer un agent avec `mm init`](../docs/fr/how-to/create-an-agent.md)
  - [Utiliser un serveur compatible OpenAI](../docs/fr/how-to/run-with-an-openai-compatible-server.md)
  - [Écrire un outil personnalisé sous forme de module WebAssembly](../docs/fr/how-to/write-a-wasm-tool.md)
  - [Écrire un hook sous forme de module WebAssembly](../docs/fr/how-to/write-a-wasm-hook.md)
- **Nouveau guide** : les [raccourcis clavier de la fenêtre](../guides/raccourcis-clavier-tui.md) ([EN](../guides/tui-keyboard-shortcuts.md)), groupés par ce que vous faites, avec la fenêtre de `mm init`.
- **Réécrit** : [Gérer des plans et des tâches](../docs/fr/how-to/manage-plans-and-tasks.md) — ce que montre chaque façade, un exemple mesuré ; la section sur une commande `/plans` qui n'existe pas a disparu.
- **Mis à jour** : les explications des outils déclarés (une section sur les outils WebAssembly), des hooks (les hooks WebAssembly et ce qui a été mesuré) et des fournisseurs ; les références de la ligne de commande (`mm init`, `mm tui`, `mm acp`), de la configuration, des hooks, des outils (une section `plan`, les outils WebAssembly) et des commandes slash (`/new`, `/resume` et les plans) ; le diagramme des paquets.

## Mise à jour

- **Compiler depuis les sources demande Go 1.27** (#115) : `go.mod` indique maintenant `go 1.27.0` et `toolchain go1.27.3`. Le kit Go des Docker Sandboxes installe 1.27.3. Les binaires de release ne sont pas concernés.
- **Aucun changement cassant dans la configuration.** Nouvelles clés : `provider: openai` ; `wasm`, `read` et `write` sur une entrée `tools:` et sur une entrée de hook. Un agent existant ne reçoit aucun nouvel outil.
- **Un premier argument `init`, `tui` ou `acp` est maintenant un mot de mode.** Un fichier de configuration portant l'un de ces noms doit être donné en `./tui` ou avec `-config`.
- **Deux messages ont changé** : une entrée `tools:` sans `command` ni `wasm` dit maintenant `command must name a program, … (or wasm: a module)` ; une entrée de hook sans l'un ni l'autre dit `command must not be empty (or wasm: a module)`.
- **Le binaire est plus gros** : le runtime WebAssembly ajoute environ 3,9 Mo (38,97 → 42,87 Mo sur linux/arm64). mm n'utilise toujours pas CGO et se compile pour les mêmes cinq cibles.

mini-me v0.9.0

Nouveautés

mm init — un assistant qui écrit l'agent.yaml (#97)

Des outils WebAssembly (#119)

Des hooks WebAssembly (#120, clôt #46)

Un fournisseur pour tout serveur compatible OpenAI (#118)

mm tui et mm acp (#117)

Corrigé

Démos

Documentation

Mise à jour

`mm init` — un assistant qui écrit l'agent.yaml (#97)

`mm tui` et `mm acp` (#117)