Roadmap : retire le lot 1 livré, invalide la piste ClientModule (L4.3)
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 <noreply@anthropic.com>
This commit is contained in:
Arthur Ria
+14
-65
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user