overmind-mcp 3.7.0 → 3.8.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +20 -4
- package/dist/bin/overmind-bridge.js +1 -1
- package/dist/bin/overmind-bridge.js.map +1 -1
- package/dist/bin/overmind-client.js +2 -2
- package/dist/bin/overmind-client.js.map +1 -1
- package/dist/bridge/BridgeProxy.d.ts +8 -0
- package/dist/bridge/BridgeProxy.d.ts.map +1 -1
- package/dist/bridge/BridgeProxy.js +20 -0
- package/dist/bridge/BridgeProxy.js.map +1 -1
- package/dist/bridge/OverBridgeService.d.ts +4 -1
- package/dist/bridge/OverBridgeService.d.ts.map +1 -1
- package/dist/bridge/OverBridgeService.js +25 -3
- package/dist/bridge/OverBridgeService.js.map +1 -1
- package/dist/bridge/types.d.ts +3 -1
- package/dist/bridge/types.d.ts.map +1 -1
- package/dist/bridge/types.js +2 -1
- package/dist/bridge/types.js.map +1 -1
- package/dist/server.d.ts.map +1 -1
- package/dist/server.js +8 -0
- package/dist/server.js.map +1 -1
- package/dist/services/AgentManager.d.ts.map +1 -1
- package/dist/services/AgentManager.js +23 -1
- package/dist/services/AgentManager.js.map +1 -1
- package/dist/services/HermesGatewayRunner.d.ts.map +1 -1
- package/dist/services/HermesGatewayRunner.js +77 -9
- package/dist/services/HermesGatewayRunner.js.map +1 -1
- package/dist/services/HermesPoolClient.js.map +1 -1
- package/dist/services/HermesProfileManager.d.ts.map +1 -1
- package/dist/services/HermesProfileManager.js +3 -2
- package/dist/services/HermesProfileManager.js.map +1 -1
- package/dist/tools/a2a_hub.d.ts.map +1 -1
- package/dist/tools/a2a_hub.js +21 -13
- package/dist/tools/a2a_hub.js.map +1 -1
- package/dist/tools/get_metrics.d.ts +22 -0
- package/dist/tools/get_metrics.d.ts.map +1 -0
- package/dist/tools/get_metrics.js +101 -0
- package/dist/tools/get_metrics.js.map +1 -0
- package/docs/MIGRATION_V4_WRAPPER.md +544 -0
- package/package.json +1 -1
|
@@ -0,0 +1,544 @@
|
|
|
1
|
+
# Migration Overmind v4.0 — Wrapper Multi-Agent Persistant
|
|
2
|
+
|
|
3
|
+
> **Statut** : Plan de migration détaillé (4 phases)
|
|
4
|
+
> **Date** : 2026-07-10
|
|
5
|
+
> **Source** : v3.7.0 → v4.0.0
|
|
6
|
+
> **Pré-requis** : v3.7.0 publié (✅ en cours de pipeline)
|
|
7
|
+
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
## 🎯 Vision : pourquoi pivoter
|
|
11
|
+
|
|
12
|
+
### Le problème actuel (v3.7.0)
|
|
13
|
+
|
|
14
|
+
OverMind est positionné "orchestrateur universel" mais il fait 2 choses contradictoires :
|
|
15
|
+
|
|
16
|
+
1. **Wrapper multi-runner** (utile) — spawn Claude/Hermes/Kilo/Gemini, gère profils
|
|
17
|
+
2. **Couche d'orchestration centrale** (redondante avec Hermes) — dispatcher, kanban adapter, scenarios
|
|
18
|
+
|
|
19
|
+
La couche (2) réinvente des choses qu'Hermes fait **nativement** depuis la v0.13+ :
|
|
20
|
+
- Kanban natif (`hermes kanban`)
|
|
21
|
+
- Dispatcher (loop gateway 60s tick)
|
|
22
|
+
- Pool credentials avec rotation round-robin
|
|
23
|
+
- Sessions persistantes par profile
|
|
24
|
+
|
|
25
|
+
**Résultat** : 2 sources de vérité pour les mêmes concepts, dette technique, divergence de comportement.
|
|
26
|
+
|
|
27
|
+
### La cible (v4.0)
|
|
28
|
+
|
|
29
|
+
**OverMind = factory à agents persistants. Point.**
|
|
30
|
+
|
|
31
|
+
```
|
|
32
|
+
┌─────────────────────────────────────────────────────────────┐
|
|
33
|
+
│ OVERMIND v4.0 WRAPPER │
|
|
34
|
+
│ │
|
|
35
|
+
│ 1 process FastMCP sur :3099 — pure factory │
|
|
36
|
+
│ │
|
|
37
|
+
│ In: create_agent(name, prompt, model) │
|
|
38
|
+
│ Out: profil Hermes autonome + mémoire + state + skills │
|
|
39
|
+
│ │
|
|
40
|
+
│ Puis l'agent vit sa vie via: │
|
|
41
|
+
│ • run_agent (invoke direct) │
|
|
42
|
+
│ • a2a_hub (HTTP peer-to-peer) │
|
|
43
|
+
│ • bridge par-agent (1 port = 1 agent, peer-to-peer) │
|
|
44
|
+
└─────────────────────────────────────────────────────────────┘
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
**Ce qui disparaît d'Overmind** (laissé à Hermes, sauf Kanban qui devient optionnel) :
|
|
48
|
+
- ❌ Kanban central → **`kanban_hub` MCP thin wrapper OPTIONNEL** (défaut OFF, opt-in via `OVERMIND_KANBAN_ENABLED=1`)
|
|
49
|
+
- ❌ Dispatcher → gateway loop natif
|
|
50
|
+
- ❌ ScenarioLoader → kanban pipeline natif (uniquement si Kanban activé)
|
|
51
|
+
- ❌ YOLO_CONFIG retry/circuit → dispatcher natif
|
|
52
|
+
- ❌ pgvector memory central → `memory.provider: postgres` dans chaque profil
|
|
53
|
+
|
|
54
|
+
**Ce qui reste d'Overmind** (son vrai rôle) :
|
|
55
|
+
- ✅ `create_agent` — thin wrapper sur `hermes profile create`
|
|
56
|
+
- ✅ `list_agents` / `delete_agent` / `update_agent_config` / `get_agent_configs`
|
|
57
|
+
- ✅ `run_agent` / `run_agents_parallel` — multi-runner (Claude, Kilo, etc.)
|
|
58
|
+
- ✅ `a2a_hub` — inter-agent HTTP (déjà peer-to-peer)
|
|
59
|
+
- ✅ `agent_control` — process lifecycle
|
|
60
|
+
- ✅ `memory_search` / `memory_store` — fallback pour les anciens clients
|
|
61
|
+
- 🔶 `kanban_hub` — **OPTIONNEL** (désactivé par défaut), uniquement si Kanban est dans le scope utilisateur
|
|
62
|
+
|
|
63
|
+
---
|
|
64
|
+
|
|
65
|
+
## 📐 Architecture cible
|
|
66
|
+
|
|
67
|
+
```
|
|
68
|
+
┌────────────────────────────────────────────────────────────────┐
|
|
69
|
+
│ v3.7.0 (actuel) — Orchestrateur central │
|
|
70
|
+
│ │
|
|
71
|
+
│ Client → MCP:3099 (Overmind) → orchestration/dispatcher │
|
|
72
|
+
│ → KanbanAdapter │
|
|
73
|
+
│ → ScenarioLoader │
|
|
74
|
+
│ → HermesRunner spawn │
|
|
75
|
+
└────────────────────────────────────────────────────────────────┘
|
|
76
|
+
↓ REFACTOR ↓
|
|
77
|
+
┌────────────────────────────────────────────────────────────────┐
|
|
78
|
+
│ v4.0 (cible) — Wrapper factory │
|
|
79
|
+
│ │
|
|
80
|
+
│ Client → MCP:3099 (Overmind factory) │
|
|
81
|
+
│ ├─ create_agent(name) → hermes profile create │
|
|
82
|
+
│ ├─ run_agent(name) → HTTP :8642 + X-Hermes-Profile │
|
|
83
|
+
│ ├─ a2a_hub → HTTP peer-to-peer │
|
|
84
|
+
│ └─ kanban_hub → hermes kanban CLI [OPTIONNEL] │
|
|
85
|
+
│ │
|
|
86
|
+
│ Hermes Gateway (:8642, multi-profile) │
|
|
87
|
+
│ Hermes Pool (credentials natifs, rotation auto) │
|
|
88
|
+
└────────────────────────────────────────────────────────────────┘
|
|
89
|
+
|
|
90
|
+
> **Kanban est optionnel** : `kanban_hub` n'est exposé que si `OVERMIND_KANBAN_ENABLED=1`.
|
|
91
|
+
> Défaut = OFF pour rester minimaliste. Les utilisateurs qui n'en ont pas besoin
|
|
92
|
+
> ne tirent jamais la dépendance `hermes kanban` et n'ont pas la surface d'attaque.
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
### Différence conceptuelle clé
|
|
96
|
+
|
|
97
|
+
| Aspect | v3.7.0 orchestrateur | v4.0 wrapper |
|
|
98
|
+
|--------|----------------------|--------------|
|
|
99
|
+
| **Source of truth agents** | Overmind registry + db | Profils Hermes natifs (`~/.hermes/profiles/<name>/`) |
|
|
100
|
+
| **Source of truth state** | PostgreSQL central | `state.db` par profile (SQLite Hermes) |
|
|
101
|
+
| **Source of truth memory** | pgvector central | `memory.provider: postgres` par profile OU pgvector partagé en fallback |
|
|
102
|
+
| **Source of truth credentials** | `.env` par profile | Pool Hermes natif (`hermes auth add`) |
|
|
103
|
+
| **Source of truth workflows** | ScenarioLoader.json | Kanban Hermes |
|
|
104
|
+
| **Communication inter-agent** | Bridge central → RPC | HTTP peer-to-peer via bridge par-agent |
|
|
105
|
+
| **Échelle** | Limitée par le central | N agents, 1 process chacun, linéaire |
|
|
106
|
+
|
|
107
|
+
---
|
|
108
|
+
|
|
109
|
+
## 🗺️ Phases d'implémentation
|
|
110
|
+
|
|
111
|
+
### **Phase 1a — Audit & nettoyage minimal (semaine 1)** ⚡ OBLIGATOIRE
|
|
112
|
+
|
|
113
|
+
**Objectif** : supprimer le bloc `dispatcher + YOLO_CONFIG` (le seul vrai code d'orchestration custom). **Garde `KanbanAdapter.ts` et `ScenarioLoader.ts` intacts** pour ne rien casser aux utilisateurs Kanban existants.
|
|
114
|
+
|
|
115
|
+
#### 1a.1 Suppressions (SEULEMENT le couple dispatcher/YOLO)
|
|
116
|
+
|
|
117
|
+
| Fichier | LOC | Remplacé par | Risque |
|
|
118
|
+
|---------|-----|-------------|--------|
|
|
119
|
+
| `src/lib/orchestration/dispatcher.ts` | 283 | Gateway loop Hermes | Faible — seul `index.ts` + `run_agents_parallel.ts` |
|
|
120
|
+
| `YOLO_CONFIG` (inline) | ~50 | retry/circuit-breaker Hermes | Aucun — config isolée |
|
|
121
|
+
|
|
122
|
+
**Garde-fous** :
|
|
123
|
+
- `src/services/KanbanAdapter.ts` ← **CONSERVÉ** (utilisé si Kanban activé)
|
|
124
|
+
- `src/bridge/ScenarioLoader.ts` ← **CONSERVÉ** (utilisé si Kanban activé)
|
|
125
|
+
|
|
126
|
+
#### 1a.2 Étapes concrètes
|
|
127
|
+
|
|
128
|
+
```bash
|
|
129
|
+
# 1. Backup l'état actuel
|
|
130
|
+
git checkout -b chore/v4-phase1a-cleanup
|
|
131
|
+
git tag v3.7.0-baseline
|
|
132
|
+
|
|
133
|
+
# 2. Supprimer seulement dispatcher.ts et YOLO_CONFIG
|
|
134
|
+
rm src/lib/orchestration/dispatcher.ts
|
|
135
|
+
rmdir src/lib/orchestration
|
|
136
|
+
# Fix imports dans src/index.ts, src/tools/run_agents_parallel.ts
|
|
137
|
+
grep -r "YOLO" src/ # doit retourner 0 résultat
|
|
138
|
+
|
|
139
|
+
# 3. Build + tests
|
|
140
|
+
pnpm run rebuild && pnpm run test && pnpm run lint
|
|
141
|
+
|
|
142
|
+
# 4. Merge
|
|
143
|
+
git checkout main
|
|
144
|
+
git merge --no-ff chore/v4-phase1a-cleanup
|
|
145
|
+
git tag v4.0.0-phase1a
|
|
146
|
+
```
|
|
147
|
+
|
|
148
|
+
#### 1a.3 Critères de succès Phase 1a
|
|
149
|
+
|
|
150
|
+
| Métrique | Avant | Après |
|
|
151
|
+
|----------|-------|-------|
|
|
152
|
+
| Services files | 17 | 17 (inchangé — 0 suppression) |
|
|
153
|
+
| LOC total src/ | ~12,500 | ~12,200 (-300) |
|
|
154
|
+
| Concept "dispatcher" présent | 1 fichier | 0 |
|
|
155
|
+
| Tests passent | 68 | 68 |
|
|
156
|
+
|
|
157
|
+
---
|
|
158
|
+
|
|
159
|
+
### **Phase 1b — Suppression Kanban historique (semaine 1+) — OPTIONNEL**
|
|
160
|
+
|
|
161
|
+
> **Statut** : À faire **UNIQUEMENT** si on confirme via télémétrie/usage
|
|
162
|
+
> que personne n'utilise Kanban via Overmind (peu probable — Nexus l'utilise).
|
|
163
|
+
> Si Kanban est utilisé par ≥1 user → **sauter cette phase**, garder le code legacy.
|
|
164
|
+
|
|
165
|
+
**Pré-requis avant suppression** :
|
|
166
|
+
- ✅ Phase 2 livrée (`kanban_hub` MCP tool disponible)
|
|
167
|
+
- ✅ Au moins 1 release avec Kanban en opt-in sans régression
|
|
168
|
+
- ✅ Communication utilisateurs (CHANGELOG deprecation notice, 1 release de grâce)
|
|
169
|
+
|
|
170
|
+
Si OK pour suppression, déplacer `KanbanAdapter.ts` + `ScenarioLoader.ts` derrière le flag `OVERMIND_KANBAN_ENABLED=1` (déjà ce que fait Phase 2), puis supprimer après 1 release.
|
|
171
|
+
|
|
172
|
+
#### 1b.1 Suppressions conditionnelles
|
|
173
|
+
|
|
174
|
+
| Fichier | LOC | Remplacé par | Risque |
|
|
175
|
+
|---------|-----|-------------|--------|
|
|
176
|
+
| `src/services/KanbanAdapter.ts` | 420 | `tools/kanban_hub.ts` opt-in (Phase 2) | Moyen — utilisé par `index.ts`, `ScenarioLoader.ts` |
|
|
177
|
+
| `src/bridge/ScenarioLoader.ts` | 508 | `hermes kanban pipeline` | Moyen — utilisé par `overmind-bridge.ts` |
|
|
178
|
+
|
|
179
|
+
---
|
|
180
|
+
|
|
181
|
+
### **Phase 2 — Support Kanban OPTIONNEL (opt-in) (semaine 2)**
|
|
182
|
+
|
|
183
|
+
> **Statut** : À faire UNIQUEMENT si des utilisateurs demandent Kanban.
|
|
184
|
+
> Si personne ne l'utilise, sauter cette phase. Les autres phases (1, 3, 4) ne
|
|
185
|
+
> dépendent pas de Kanban.
|
|
186
|
+
|
|
187
|
+
**Opt-in** : `OVERMIND_KANBAN_ENABLED=1` dans `.env` (ou flag CLI `--with-kanban`).
|
|
188
|
+
|
|
189
|
+
**Objectif** : remplacer `KanbanAdapter` par 1 outil MCP unifié, conforme au pattern `a2a_hub` / `agent_control`. Uniquement chargé si activé.
|
|
190
|
+
|
|
191
|
+
#### 2.1 Spécification de l'outil
|
|
192
|
+
|
|
193
|
+
```typescript
|
|
194
|
+
// src/tools/kanban_hub.ts
|
|
195
|
+
import { z } from 'zod';
|
|
196
|
+
|
|
197
|
+
export const kanbanHubTool = {
|
|
198
|
+
name: 'kanban_hub',
|
|
199
|
+
description: `Hermes Kanban — manage tasks, boards and pipelines.
|
|
200
|
+
Actions: init, create, list, show, update, complete, block, unblock,
|
|
201
|
+
comment, assign, link, dispatch, stats, archive, boards, watch.`,
|
|
202
|
+
inputSchema: z.object({
|
|
203
|
+
action: z.enum([
|
|
204
|
+
'init', 'create', 'list', 'show', 'update', 'complete',
|
|
205
|
+
'block', 'unblock', 'comment', 'assign', 'link',
|
|
206
|
+
'dispatch', 'stats', 'archive', 'boards', 'watch',
|
|
207
|
+
]),
|
|
208
|
+
// Champs communs
|
|
209
|
+
board: z.string().optional(), // board name (multi-board)
|
|
210
|
+
taskId: z.string().optional(), // t_abc123
|
|
211
|
+
// Champs spécifiques par action
|
|
212
|
+
title: z.string().optional(),
|
|
213
|
+
body: z.string().optional(),
|
|
214
|
+
assignee: z.string().optional(),
|
|
215
|
+
parents: z.array(z.string()).optional(),
|
|
216
|
+
reason: z.string().optional(),
|
|
217
|
+
status: z.enum(['pending', 'running', 'blocked', 'done', 'archived']).optional(),
|
|
218
|
+
agentName: z.string().optional(),
|
|
219
|
+
due: z.string().optional(),
|
|
220
|
+
tags: z.array(z.string()).optional(),
|
|
221
|
+
}),
|
|
222
|
+
handler: async (args) => {
|
|
223
|
+
// Wraps `hermes kanban <subcommand>` CLI
|
|
224
|
+
return await HermesKanbanClient.execute(args);
|
|
225
|
+
},
|
|
226
|
+
};
|
|
227
|
+
```
|
|
228
|
+
|
|
229
|
+
#### 2.2 Implémentation — `HermesKanbanClient`
|
|
230
|
+
|
|
231
|
+
```typescript
|
|
232
|
+
// src/services/HermesKanbanClient.ts
|
|
233
|
+
export class HermesKanbanClient {
|
|
234
|
+
static async execute(args: KanbanArgs): Promise<KanbanResult> {
|
|
235
|
+
const cmd = this.buildCommand(args);
|
|
236
|
+
const { stdout, stderr } = await execAsync(cmd);
|
|
237
|
+
return this.parseOutput(args.action, stdout, stderr);
|
|
238
|
+
}
|
|
239
|
+
|
|
240
|
+
static buildCommand(args: KanbanArgs): string {
|
|
241
|
+
const sub = `${args.board ? `--board "${args.board}" ` : ''}${args.action}`;
|
|
242
|
+
const flags = this.buildFlags(args);
|
|
243
|
+
return `hermes kanban ${sub} ${flags}`.trim();
|
|
244
|
+
}
|
|
245
|
+
|
|
246
|
+
static parseOutput(action: string, stdout: string, stderr: string): KanbanResult {
|
|
247
|
+
// Parse le format tabulaire d'`hermes kanban list/show`, JSON pour le reste
|
|
248
|
+
return { success: !stderr, action, data: this.parseStructured(action, stdout) };
|
|
249
|
+
}
|
|
250
|
+
}
|
|
251
|
+
```
|
|
252
|
+
|
|
253
|
+
#### 2.3 Migration des callers
|
|
254
|
+
|
|
255
|
+
| Caller actuel | Devient |
|
|
256
|
+
|--------------|---------|
|
|
257
|
+
| `index.ts` export de `kanbanAdapter` | Export de `HermesKanbanClient` |
|
|
258
|
+
| Appels directs `kanban.create(...)` | `kanban_hub({ action: 'create', ... })` |
|
|
259
|
+
| `ScenarioLoader.load(path)` | `kanban_hub({ action: 'load', path })` (futur) |
|
|
260
|
+
|
|
261
|
+
#### 2.4 Tests
|
|
262
|
+
|
|
263
|
+
- [ ] `kanban_hub({ action: 'list' })` retourne les tâches
|
|
264
|
+
- [ ] `kanban_hub({ action: 'create', title, assignee })` crée une tâche
|
|
265
|
+
- [ ] Erreurs explicites si `hermes kanban` CLI échoue
|
|
266
|
+
- [ ] Format de sortie cohérent avec les autres tools `*_hub`
|
|
267
|
+
|
|
268
|
+
#### 2.5 Critères de succès Phase 2
|
|
269
|
+
|
|
270
|
+
- [ ] `KanbanAdapter.ts` supprimé
|
|
271
|
+
- [ ] `tools/kanban_hub.ts` créé avec 16 actions
|
|
272
|
+
- [ ] Tests passent 68 → 75+
|
|
273
|
+
- [ ] `tools/list` montre 15 outils au lieu de 14 (+1 kanban_hub)
|
|
274
|
+
|
|
275
|
+
---
|
|
276
|
+
|
|
277
|
+
### **Phase 3 — Decentralized bridges + multi-profile gateway (semaine 3-4)**
|
|
278
|
+
|
|
279
|
+
**Objectif** : passer d'un `OverBridgeServer` centralisé à un bridge par agent (déjà documenté dans `overmind-bridge-guide.md` mais pas encore implémenté).
|
|
280
|
+
|
|
281
|
+
#### 3.1 État cible
|
|
282
|
+
|
|
283
|
+
```
|
|
284
|
+
Agent 1 = profil Hermes "alpha"
|
|
285
|
+
├─ hermes gateway --profile alpha --port 8742 (1 instance par agent)
|
|
286
|
+
└─ overmind-bridge --agent alpha --port 3101
|
|
287
|
+
|
|
288
|
+
Agent 2 = profil Hermes "beta"
|
|
289
|
+
├─ hermes gateway --profile beta --port 8743
|
|
290
|
+
└─ overmind-bridge --agent beta --port 3102
|
|
291
|
+
```
|
|
292
|
+
|
|
293
|
+
**OU** (variante multiplexing) : 1 seul gateway, routing par `X-Hermes-Profile` :
|
|
294
|
+
```
|
|
295
|
+
1 gateway process :8642
|
|
296
|
+
├─ profile alpha → sessions alpha
|
|
297
|
+
└─ profile beta → sessions beta
|
|
298
|
+
|
|
299
|
+
overmind-bridge par-agent (3101, 3102)
|
|
300
|
+
→ POST http://127.0.0.1:8642/v1/chat/completions
|
|
301
|
+
+ header `X-Hermes-Profile: alpha`
|
|
302
|
+
```
|
|
303
|
+
|
|
304
|
+
#### 3.2 Work items
|
|
305
|
+
|
|
306
|
+
| Item | Effort | Dépendance |
|
|
307
|
+
|------|--------|-----------|
|
|
308
|
+
| `HermesGatewayManager.spawn(profile)` auto-start | 2h | Phase 1 ✅ |
|
|
309
|
+
| `HermesGatewayRunner` accepte `profile` option | 1h | — |
|
|
310
|
+
| Template `overmind-bridge-<agent>.ts` (peer-to-peer sans central) | 4h | Phase 1 ✅ |
|
|
311
|
+
| Suppression de `OverBridgeServer` (central) | 8h | Smoke test E2E réussi d'abord |
|
|
312
|
+
| `BridgeProxy` discovery service (trouve les peers par registry) | 3h | — |
|
|
313
|
+
| Refactor `a2a_hub` pour parler aux bridge ports (3101+) et plus au central | 4h | Découverte du peer |
|
|
314
|
+
|
|
315
|
+
#### 3.3 Stratégie d'exécution (crucial — éviter le Big Bang)
|
|
316
|
+
|
|
317
|
+
**Étape 1 — drapeau de feature**
|
|
318
|
+
```typescript
|
|
319
|
+
// src/lib/config.ts
|
|
320
|
+
process.env.OVERMIND_BRIDGE_MODE = 'centralized' | 'decentralized' | 'hybrid';
|
|
321
|
+
```
|
|
322
|
+
|
|
323
|
+
**Étape 2 — les deux modes coexistent**
|
|
324
|
+
- Mode A (`centralized`) : code actuel, default
|
|
325
|
+
- Mode B (`decentralized`) : nouveau, opt-in via env var
|
|
326
|
+
- Mode C (`hybrid`) : A pour les anciens agents, B pour les nouveaux
|
|
327
|
+
|
|
328
|
+
**Étape 3 — bascule progressive**
|
|
329
|
+
1. Déployer en `hybrid`
|
|
330
|
+
2. Migrer les 8 agents existants (Nexus Master, Trader, Healer, etc.) un par un
|
|
331
|
+
3. Quand tous sont migrés → flag = `decentralized` par défaut
|
|
332
|
+
4. Supprimer le code `centralized` (Phase 3 finale)
|
|
333
|
+
|
|
334
|
+
#### 3.4 Critères de succès Phase 3
|
|
335
|
+
|
|
336
|
+
- [ ] 1 bridge isolé par agent (8 agents = 8 bridges sur 3101-3108)
|
|
337
|
+
- [ ] A2A fonctionne entre bridges (peer-to-peer HTTP direct)
|
|
338
|
+
- [ ] Aucun agent ne dépend du `OverBridgeServer` central
|
|
339
|
+
- [ ] `OverBridgeServer` peut être supprimé sans casser les tests
|
|
340
|
+
- [ ] `pnpm run test` reste vert
|
|
341
|
+
|
|
342
|
+
---
|
|
343
|
+
|
|
344
|
+
### **Phase 4 — Mémoire par-profile (semaine 4-5)**
|
|
345
|
+
|
|
346
|
+
**Objectif** : chaque agent utilise son propre memory provider, au lieu du pgvector central.
|
|
347
|
+
|
|
348
|
+
#### 4.1 Le problème actuel
|
|
349
|
+
|
|
350
|
+
`PostgresMemoryProvider` est utilisé par :
|
|
351
|
+
- `tools/memory_search.ts` (MCP tool)
|
|
352
|
+
- `tools/memory_store.ts` (MCP tool)
|
|
353
|
+
- Auto-injecté à chaque agent via `mcp_servers: { memory: { url: :3099/mcp } }`
|
|
354
|
+
|
|
355
|
+
**Conséquence** : tous les agents partagent la même DB pgvector. Pas d'isolation mémoire entre agents. C'est exactement ce que le wrapper multi-agent persistant doit éviter.
|
|
356
|
+
|
|
357
|
+
#### 4.2 Solution
|
|
358
|
+
|
|
359
|
+
Hermes supporte `memory.provider` dans `config.yaml` (natif depuis v0.15+) :
|
|
360
|
+
```yaml
|
|
361
|
+
# config.yaml du profil
|
|
362
|
+
memory:
|
|
363
|
+
provider: postgres
|
|
364
|
+
postgres:
|
|
365
|
+
url: postgresql://user:pass@localhost/memory_<profile_name>
|
|
366
|
+
```
|
|
367
|
+
|
|
368
|
+
Chaque agent a sa **propre DB**, nommée d'après le profil.
|
|
369
|
+
|
|
370
|
+
#### 4.3 Étapes
|
|
371
|
+
|
|
372
|
+
```typescript
|
|
373
|
+
// src/services/HermesProfileManager.ts — ajout méthode
|
|
374
|
+
static async setMemoryProvider(
|
|
375
|
+
name: string,
|
|
376
|
+
opts: { provider: 'postgres' | 'sqlite' | 'file'; url?: string } = { provider: 'sqlite' },
|
|
377
|
+
): Promise<void> {
|
|
378
|
+
// 1. Si postgres, créer DB dédiée
|
|
379
|
+
if (opts.provider === 'postgres' && !opts.url) {
|
|
380
|
+
const dbName = `overmind_memory_${name}`;
|
|
381
|
+
await PostgresAdmin.createDatabase(dbName);
|
|
382
|
+
opts.url = `postgresql://${process.env.PG_USER}:${process.env.PG_PASS}@localhost/${dbName}`;
|
|
383
|
+
}
|
|
384
|
+
|
|
385
|
+
// 2. hermes -p <name> config set memory.provider <provider>
|
|
386
|
+
await execAsync(`hermes -p "${name}" config set memory.provider "${opts.provider}"`);
|
|
387
|
+
if (opts.url) {
|
|
388
|
+
await execAsync(`hermes -p "${name}" config set memory.postgres.url "${opts.url}"`);
|
|
389
|
+
}
|
|
390
|
+
}
|
|
391
|
+
```
|
|
392
|
+
|
|
393
|
+
#### 4.4 Compatibilité ascendante
|
|
394
|
+
|
|
395
|
+
`memory_search` / `memory_store` MCP tools restent mais deviennent **passerelles** :
|
|
396
|
+
- Si l'agent appelant a `memory.provider` → query sa DB
|
|
397
|
+
- Sinon → fallback pgvector central (legacy)
|
|
398
|
+
|
|
399
|
+
```typescript
|
|
400
|
+
// src/tools/memory_search.ts
|
|
401
|
+
handler: async (args) => {
|
|
402
|
+
const callerAgent = getCallerAgent();
|
|
403
|
+
if (callerAgent?.memoryProvider === 'postgres') {
|
|
404
|
+
return await queryAgentMemory(callerAgent, args);
|
|
405
|
+
}
|
|
406
|
+
// Legacy fallback
|
|
407
|
+
return await getMemoryProvider().search(args);
|
|
408
|
+
};
|
|
409
|
+
```
|
|
410
|
+
|
|
411
|
+
#### 4.5 Critères de succès Phase 4
|
|
412
|
+
|
|
413
|
+
- [ ] `HermesProfileManager.setMemoryProvider()` fonctionne
|
|
414
|
+
- [ ] Chaque agent a sa propre DB
|
|
415
|
+
- [ ] `memory_search` retourne des résultats **propres à l'agent** (pas de pollution croisée)
|
|
416
|
+
- [ ] Test E2E : `agent_a` stocke "secret-X", `agent_b` ne le voit pas
|
|
417
|
+
- [ ] `PostgresMemoryProvider` reste pour le fallback legacy mais marqué deprecated
|
|
418
|
+
|
|
419
|
+
---
|
|
420
|
+
|
|
421
|
+
## 🔬 Plan de tests de régression
|
|
422
|
+
|
|
423
|
+
À exécuter **après chaque phase** :
|
|
424
|
+
|
|
425
|
+
### Smoke test (5 min)
|
|
426
|
+
|
|
427
|
+
```bash
|
|
428
|
+
# 1. Build + lint + tests
|
|
429
|
+
pnpm run rebuild && pnpm run lint && pnpm run test
|
|
430
|
+
|
|
431
|
+
# 2. E2E manuel via MCP
|
|
432
|
+
overmind --transport httpStream --port 3099 &
|
|
433
|
+
sleep 3
|
|
434
|
+
|
|
435
|
+
# 3. Créer un agent via MCP tool
|
|
436
|
+
curl -X POST http://localhost:3099/mcp \
|
|
437
|
+
-d '{"jsonrpc":"2.0","method":"tools/call","params":{"name":"create_agent","arguments":{"name":"smoke_test_$(date +%s)","runner":"hermes","model":"glm-4.6","prompt":"You are a smoke test agent"}},"id":1}'
|
|
438
|
+
|
|
439
|
+
# 4. Lui poser une question
|
|
440
|
+
curl -X POST http://localhost:3099/mcp \
|
|
441
|
+
-d '{"jsonrpc":"2.0","method":"tools/call","params":{"name":"run_hermes","arguments":{"agentName":"<created>","prompt":"Reply: SMOKE_OK"}},"id":2}'
|
|
442
|
+
|
|
443
|
+
# 5. Cleanup
|
|
444
|
+
curl -X POST http://localhost:3099/mcp \
|
|
445
|
+
-d '{"jsonrpc":"2.0","method":"tools/call","params":{"name":"delete_agent","arguments":{"name":"<created>"}},"id":3}'
|
|
446
|
+
```
|
|
447
|
+
|
|
448
|
+
### Tests unitaires à préserver/ajouter
|
|
449
|
+
|
|
450
|
+
| Phase | Tests à préserver | Tests à ajouter |
|
|
451
|
+
|-------|------------------|-----------------|
|
|
452
|
+
| **Phase 1** | 68 existants | 0 (que suppressions) |
|
|
453
|
+
| **Phase 2** | 68 | +8 `HermesKanbanClient` |
|
|
454
|
+
| **Phase 3** | 76 | +12 `BridgeProxy` discovery |
|
|
455
|
+
| **Phase 4** | 88 | +10 `memoryProvider` isolation |
|
|
456
|
+
|
|
457
|
+
---
|
|
458
|
+
|
|
459
|
+
## 📅 Timeline globale
|
|
460
|
+
|
|
461
|
+
| Semaine | Phase | Livrable | Version |
|
|
462
|
+
|---------|-------|----------|---------|
|
|
463
|
+
| 1 | Phase 1a — Nettoyage dispatcher/YOLO (obligatoire) | -300 LOC, 1 fichier | v4.0.0-alpha |
|
|
464
|
+
| 2 | Phase 2 — Support Kanban OPTIONNEL *(si demandé)* | +1 tool chargé opt-in | v4.0.0-beta |
|
|
465
|
+
| 3-4 | Phase 3 — Decentralized bridges + multi-profile gateway | 1 bridge/agent | v4.0.0-rc |
|
|
466
|
+
| 4-5 | Phase 4 — Mémoire par-profile | isolation mémoire | v4.0.0 |
|
|
467
|
+
| quand prêt | Phase 1b — Suppression Kanban historique *(opt-in après 1 release grâce)* | -930 LOC | v4.1.0 |
|
|
468
|
+
|
|
469
|
+
> **Note** : Phase 2 est conditionnelle. Si Kanban n'est pas dans le scope,
|
|
470
|
+
> on peut release v4.0.0 final après la Phase 3 + Phase 4 sans Phase 2.
|
|
471
|
+
|
|
472
|
+
---
|
|
473
|
+
|
|
474
|
+
## ⚠️ Risques identifiés
|
|
475
|
+
|
|
476
|
+
| Risque | Impact | Mitigation |
|
|
477
|
+
|--------|--------|-----------|
|
|
478
|
+
| **Rétro-compat callers KanbanAdapter** | Élevé — utilisé par 4 fichiers | Wrapper compat pendant 1 release, déprecation warning |
|
|
479
|
+
| **Migration DB pgvector** | Élevé — données existantes | Dual-write 1 release, outil de migration `pnpm run migrate:memory:v4` |
|
|
480
|
+
| **OverBridgeServer supprimé trop tôt** | Élevé — bridge central = SPOF | Feature flag `OVERMIND_BRIDGE_MODE`, bascule progressive |
|
|
481
|
+
| **Hermes API change** (versions futures) | Moyen — pool gateway déjà adapté | Pin Hermes version dans `setup.mjs`, tests d'intégration |
|
|
482
|
+
|
|
483
|
+
---
|
|
484
|
+
|
|
485
|
+
## 🤝 Décisions à prendre avant de commencer
|
|
486
|
+
|
|
487
|
+
1. **Maintenir `OverBridgeServer` central en parallèle** ? Oui, le temps de la migration
|
|
488
|
+
2. **Migration auto des agents existants** ? Oui — script `migrate-agents-v4.ts`
|
|
489
|
+
3. **Deprecation warnings ou rupture nette** ? Deprecation 2 releases (v4.0 + v4.1)
|
|
490
|
+
4. **Documentation site web** : régénérer `docs/index.html` avec nouvelle vision
|
|
491
|
+
|
|
492
|
+
---
|
|
493
|
+
|
|
494
|
+
## 📚 Annexes
|
|
495
|
+
|
|
496
|
+
### A. Inventaire des fichiers (split obligatoire / optionnel)
|
|
497
|
+
|
|
498
|
+
**OBLIGATOIRE (Phase 1a)** :
|
|
499
|
+
```
|
|
500
|
+
src/lib/orchestration/dispatcher.ts (283 LOC) ← SUPPRIMER
|
|
501
|
+
src/lib/orchestration/ (dossier) ← SUPPRIMER
|
|
502
|
+
YOLO_CONFIG (inline dans KanbanAdapter) (~50 LOC) ← SUPPRIMER
|
|
503
|
+
```
|
|
504
|
+
|
|
505
|
+
**OPTIONNEL — conservé tant que Kanban est utilisé** :
|
|
506
|
+
```
|
|
507
|
+
src/services/KanbanAdapter.ts (420 LOC) ← CONSERVÉ
|
|
508
|
+
src/bridge/ScenarioLoader.ts (508 LOC) ← CONSERVÉ
|
|
509
|
+
```
|
|
510
|
+
|
|
511
|
+
**Suppression totale si Kanban confirmé inutilisé (Phase 1b)** :
|
|
512
|
+
```
|
|
513
|
+
src/services/KanbanAdapter.ts (420 LOC) ← SUPPRIMER (v4.1.0)
|
|
514
|
+
src/bridge/ScenarioLoader.ts (508 LOC) ← SUPPRIMER (v4.1.0)
|
|
515
|
+
```
|
|
516
|
+
|
|
517
|
+
### B. Inventaire des fichiers à créer (tous OPTIONNELS sauf ceux de Phase 3-4)
|
|
518
|
+
|
|
519
|
+
```
|
|
520
|
+
# OPTIONNEL (Phase 2 — opt-in Kanban)
|
|
521
|
+
src/tools/kanban_hub.ts (NOUVEAU — 250 LOC) [chargé si OVERMIND_KANBAN_ENABLED=1]
|
|
522
|
+
src/services/HermesKanbanClient.ts (NOUVEAU — 180 LOC) [chargé opt-in]
|
|
523
|
+
src/tools/kanban_hub.test.ts (NOUVEAU — 200 LOC, 8 tests) [opt-in]
|
|
524
|
+
|
|
525
|
+
# OBLIGATOIRE (Phase 3-4 — wrapper pur)
|
|
526
|
+
src/bridge/BridgeProxy.ts (NOUVEAU — 150 LOC)
|
|
527
|
+
src/services/HermesProfileManager.setMemoryProvider (méthode ajoutée)
|
|
528
|
+
scripts/migrate-agents-v4.ts (NOUVEAU — 100 LOC)
|
|
529
|
+
docs/MIGRATION_V4_WRAPPER.md (CE DOCUMENT — déjà créé)
|
|
530
|
+
```
|
|
531
|
+
|
|
532
|
+
### C. Checklist pre-merge
|
|
533
|
+
|
|
534
|
+
- [ ] Tous les tests passent (`pnpm run test`)
|
|
535
|
+
- [ ] Lint clean (`pnpm run lint`)
|
|
536
|
+
- [ ] Build compile (`pnpm run rebuild`)
|
|
537
|
+
- [ ] Smoke test E2E réussi
|
|
538
|
+
- [ ] Documentation à jour (`docs/`, `README.md`)
|
|
539
|
+
- [ ] CHANGELOG.md mis à jour
|
|
540
|
+
- [ ] Tag git posé
|
|
541
|
+
|
|
542
|
+
---
|
|
543
|
+
|
|
544
|
+
_Migration planifiée par DeaMoN888 — 2026-07-10_
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "overmind-mcp",
|
|
3
|
-
"version": "3.
|
|
3
|
+
"version": "3.8.0",
|
|
4
4
|
"description": "Orchestrateur universel agents IA multi-modeles via MCP. Inclut le protocole 'Custom-Nickname' pour identifier vos agents avec des surnoms originaux (The Chaos Prophet, Shadow Sniper, etc.), l'isolation mémoire (Private Memory Context) et le support pour QwenCli et Nous Hermes. Installation automatique des dépendances Docker (PostgreSQL, pgvector) inclus.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "dist/index.js",
|