Roadmap et décisions : exploitation de la référence API du service

Source : la page d'aide générée https://<host>/ApplicationService/Help, qui
documente des champs et des endpoints que le MCP n'utilise pas. Toutes les
affirmations ci-dessous ont été testées contre LIMAGRAI2512.

D3 corrigé — QueryContextType a quatre valeurs, pas deux :
Reading 0 (ApplicationReadingContext), Writing 1 (ApplicationWritingRepository),
DataWarehouse 2 (non configuré sur ce tenant : IDataWarehouse non résolu),
Metrics 3 (ApplicationMetricDataContext, présent, modèle non exploré). Le
message d'erreur nomme le contexte, ce qui donne un moyen rapide de savoir quel
QueryType a servi.

L4.1 étendu aux quatre contextes.

L4.2 tranché sur son point dur : le champ Application ne partitionne pas le
contexte de lecture. Context.AgvTasks répond aussi bien avec Application AGV
qu'avec EasyWMS — le contexte est commun au tenant. La table de résolution du
lot 2 devra donc agréger le Metadata de toutes les applications, mais un
paramètre application sur QueryExecute serait inutile. Les entités CustomApp
restent inatteignables sous les quatre QueryType, au singulier comme au
pluriel, et Metadata renvoie 0 entité pour cette application : ce sont des
définitions EasyBuilder sans projection requêtable. L'API AD est le seul accès
au spécifique client.

Trois chantiers ajoutés :
- L4.3 ClientModule, non renseigné, d'où des requêtes du MCP journalisées sous
  « Client: GNA » et indistinguables du vrai client GNA.
- L4.4 API WorkflowLog (GetInstances, GetLogs, Validate), joignable et
  fonctionnelle, susceptible de remettre en cause D16.
- L4.5 champs inexploités de QueryExecute : Parameters (requêtes paramétrées,
  piste pour D13), CommandTimeout, QueryId + QueryCancel, QueryExecuteStream
  (piste pour L3.1), plus les endpoints event sourcing et les sondes
  healthcheck/ready.

CLAUDE.md pointe désormais vers la page d'aide comme source de vérité.
MONITORING.md documente healthcheck/ready comme sonde légère.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

DECISIONS.md

@@ -46,17 +46,25 @@ Voir `src/services/api-service.js`, méthode `authenticate()`.
 
 ## D3 — `QueryType: 0` (Reading), pas 1
 
-**Piège.** `QueryType` sélectionne le modèle de données interrogé :
+**Piège.** `QueryType` (type `QueryContextType`) sélectionne le contexte de
+données interrogé. Il a **quatre** valeurs, pas deux — vérifiées une à une sur
+le tenant `LIMAGRAI2512` :
 
-| Valeur | Modèle | Champs de statut |
+| Valeur | Contexte | Statut sur ce tenant |
 |---|---|---|
-| `0` | **Reading** | chaînes de caractères (`"Release"`) |
-| `1` | Writing | énumérations |
+| `0` | **Reading** — `ApplicationReadingContext` | opérationnel, champs de statut en **chaînes** (`"Release"`) |
+| `1` | Writing — `ApplicationWritingRepository` | opérationnel, champs de statut en **énumérations** |
+| `2` | DataWarehouse | **non configuré** : `Could not resolve serviceType 'IDataWarehouse…'` |
+| `3` | Metrics — `ApplicationMetricDataContext` | contexte présent, modèle de données non exploré |
 
 Les comparaisons de statut par chaîne — de loin le cas le plus courant en
 debug — **échouent** en `QueryType: 1`. Le code force donc `0` dans
 `executeQuery()` et `executeScalarQuery()`.
 
+Le message d'erreur nomme le contexte (`ApplicationReadingContext`,
+`ApplicationWritingRepository`, …) : c'est le moyen le plus rapide de savoir
+quel `QueryType` a réellement été utilisé.
+
 **Attention.** D'anciens exemples (dont le PHP de référence) utilisent `1`. Ne
 les recopiez pas.