From e5614f3b6080523ed72a510d43b43d990aff94be Mon Sep 17 00:00:00 2001 From: Arthur Ria Date: Mon, 24 Aug 2026 16:47:14 +0200 Subject: [PATCH] =?UTF-8?q?Roadmap=20:=20retire=20le=20lot=201=20livr?= =?UTF-8?q?=C3=A9,=20invalide=20la=20piste=20ClientModule=20(L4.3)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Le lot 1 (erreurs HTTP détaillées, routage par table, projections des workflows) est livré et vérifié contre le WMS réel — il sort de la roadmap. D22 étant écrite, L3.2 est ajusté en conséquence. L4.3 est corrigé d'après mesure : le champ ClientModule de QueryExecute est accepté mais sans effet observable dans les logs du WMS — une requête en échec envoyée avec ClientModule: "MCP-WMS" reste tracée « Execute error. Client: GNA », et la chaîne n'apparaît dans aucun log. Le champ n'a donc pas été renseigné. Co-Authored-By: Claude Opus 5 --- ROADMAP.md | 79 ++++++++++-------------------------------------------- 1 file changed, 14 insertions(+), 65 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index e447525..6ef4bc0 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -42,64 +42,6 @@ Conséquences déjà constatées : --- -## Lot 1 — Déblocage - -Objectif : rendre le MCP auto-diagnosticable et réparer ce qui est cassé. Ce lot -seul aurait suffi à ce qu'une session se débrouille sans intervention. - -### L1.1 — Remonter le détail des erreurs HTTP - -Aujourd'hui toute erreur d'API se résume à `Request failed with status code 500`. -Or le WMS renvoie déjà le diagnostic complet dans le corps de la réponse : - -```json -{"ClassName":"System.AggregateException","Message":"Compile Error: ... -'ApplicationReadingContext' ne contient pas de définition pour 'Container' ..."} -``` - -Enrichir l'erreur au point de passage unique (`api-service.post` / `.get`) avec : -statut, URL, verbe, payload envoyé, corps de réponse tronqué à ~2000 caractères. - -**Fichier :** `src/services/api-service.js` (catch de `post` et `get`). - -### L1.2 — Fiabiliser le routage des outils - -Deux outils sont listés dans `tools/list` mais ne sont routés vers aucun module, -à cause du routage par préfixe : - -| Outil | Cause | Erreur observée | -|---|---|---| -| `get_entity_metadata` | capté par `startsWith('get_entity_')` avant sa propre branche | `Unknown WMS query tool` | -| `list_log_files` | ne contient pas `_logs` mais `_log_files` | `Unknown tool` | - -Remplacer le routage par préfixe par une **table explicite nom → module**, -construite depuis les `listTools()` de chaque module. Un outil listé mais non -routé devient alors impossible par construction, au lieu d'être rattrapé au cas -par cas. - -**Fichier :** `src/index.js` (handler `tools/call`). - -### L1.3 — Corriger les projections de champs des workflows - -L'API AD renvoie les champs en minuscules (`id`, `name`, `version`, -`applicationName`). Deux endroits supposent une autre forme : - -- `search_workflows` projette `w.Id`, `w.Code`, `w.Name`, `w.Category` → tous - `undefined`, supprimés par `JSON.stringify` → **50 objets vides** pour un - `count` pourtant correct ; -- `workflow-service` lit `w.category || w.Category`, deux clés inexistantes → - `list_workflow_categories` renvoie **0 catégorie** et classe les 4012 - workflows en `Uncategorized`. - -Le champ le plus proche d'une catégorie est `applicationName`, mais il vaut -`EasyWMS` pour tous les workflows : la notion de catégorie n'a **aucun support** -dans les données. Décider en connaissance de cause plutôt que d'inventer une -taxonomie. - -**Fichiers :** `src/tools/workflow-tools.js`, `src/services/workflow-service.js`. - ---- - ## Lot 2 — Correctif de fond ### L2.1 — Résolution des entités via l'API Metadata @@ -143,8 +85,8 @@ que la cause réelle est l'absence de signal. ### L3.2 — Documentation -- DECISIONS.md : **D21** la règle `TableName`, **D22** le routage par table - explicite. +- DECISIONS.md : **D21** la règle `TableName` (D22, le routage par table + explicite, a été livrée avec le lot 1). - CLAUDE.md : corriger la liste d'entités (`Aliases` → `Alias`) et renvoyer vers `get_entity_metadata` comme source de vérité. - `wms://query-examples` : un exemple singulier/pluriel commenté. @@ -153,7 +95,7 @@ que la cause réelle est l'absence de signal. ## Lot 4 — Modèle de données et applications -Deux angles morts constatés le 24/08/2026, plus larges que les lots 1 à 3. Les +Deux angles morts constatés le 24/08/2026, plus larges que les lots 2 et 3. Les chiffres ci-dessous sont mesurés sur le tenant `LIMAGRAI2512`. ### L4.1 — Le modèle Writing est inatteignable @@ -231,13 +173,20 @@ paramètre `application` sur les outils AD et workflow d'autant plus utile. ### L4.3 — Identifier le MCP dans les logs du WMS -`QueryExecute` accepte un champ **`ClientModule`** que le MCP n'envoie pas. -Résultat : ses requêtes apparaissent dans les logs du WMS sous +Les requêtes du MCP apparaissent dans les logs du WMS sous `Execute error. Client: GNA` — le client OAuth partagé — donc indistinguables de celles du vrai client GNA. -Renseigner `ClientModule` (`"MCP-WMS"` ou le nom du profil actif) rend chaque -requête du MCP traçable côté serveur. Vérifié : le champ est accepté. +**La piste `ClientModule` est invalidée** (mesuré le 24/08/2026, lot 1) : le +champ est bien accepté par `QueryExecute` (pas d'erreur), mais il est **sans +effet observable**. Une requête en échec envoyée avec +`ClientModule: "MCP-WMS"` est tracée `Execute error. Client: GNA`, et ni +`MCP-WMS` ni `ClientModule` n'apparaissent nulle part dans +`ApplicationService.log` ni `HttpResponseTime.log`. Le `Client:` des logs vient +du client OAuth, pas du payload — le champ n'a donc **pas** été renseigné. + +Piste restante (non vérifiée) : un client OAuth dédié au MCP côté EasySTS +changerait le `Client:` des logs, mais suppose une configuration côté WMS. ### L4.4 — Historique d'exécution des workflows par API