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>

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
+- DECISIONS.md : **D21** la règle `TableName` (D22, le routage par table
-  explicite.
+  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.
+Les requêtes du MCP apparaissent dans les logs du WMS sous
-Résultat : ses requêtes 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
+**La piste `ClientModule` est invalidée** (mesuré le 24/08/2026, lot 1) : le
-requête du MCP traçable côté serveur. Vérifié : le champ est accepté.
+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