L4.2 : paramètre application sur les outils AD et workflow (D26)

L'application venait de WMS_APPLICATION (partagée par tous les profils) : le
MCP n'interrogeait que EasyWMS, alors que CustomApp porte le spécifique
client (153 workflows CST_ sur ce tenant) et que 9 applications sont
déclarées par Application/GetAll.

Paramètre application (défaut : l'application du profil, comportement
inchangé sans lui) sur get_ad_elements, search_ad_elements,
get_ad_element_details, search_workflows, get_workflow_details,
list_workflow_categories. Clés de cache : ad-service passe par
(application, type), workflow-service par application — sans quoi un appel
CustomApp polluerait le cache EasyWMS. L'invalidation reste l'abonnement
onSwitch (D8), le chargement reste paresseux (aucun préchargement des 9
applications, D10). list_workflow_categories s'adosse à Application/GetAll
(liste allégée en cache : le blob data de chaque application pèse ~100 Ko) ;
get_application_summary regroupe par application et ne détaille que les
entrées en cache (D24), workflows compris. Acté en D26 ; CLAUDE.md mis à
jour (Caches, AD), L4.2 retiré de la ROADMAP.

Vérifications rejouées via le protocole (LIMAGRAIN / LIMAGRAI2512),
requêtes séquentielles :
- search_workflows(CST_, application:CustomApp) -> 5 objets peuplés dont
  CST_SendRejectContainersToPK ([Workflow] Successfully cached 153 workflows
  for "CustomApp").
- get_ad_elements(Workflow, application:CustomApp) -> count 153, éléments
  CST_* ([AD] Successfully cached 153 CustomApp::Workflow).
- Séquence EasyWMS -> CustomApp -> EasyWMS sur search_workflows : 4012 vs
  153, retour en cache hit ([Workflow] Using cached data for "EasyWMS"),
  aucune pollution ; get_application_summary montre les deux caches
  (workflowCachesByApplication EasyWMS 4012 / CustomApp 153).
- Sans paramètre application -> comportement inchangé (W1 = W3).
- switch_wms_profile EUROTRAFIC puis retour -> [Workflow] Cache cleared,
  [AD] All caches invalidated, [EntityResolver] Cache cleared ; summary vide.
- list_workflow_categories -> 9 applications, comptes réels des applications
  chargées.
Baseline : tools/list 23 (les 23 noms répondent), resources 6, rejet D23
d'un paramètre inconnu OK (search_workflows/applikation), npm test 4/4
exit 0.

Anomalie hors périmètre consignée dans ROADMAP.md : get_workflow_details
peut dépasser le seuil de rejet client (~101 800 caractères mesurés sur
CST_SendRejectContainersToPK), comportement antérieur au lot.

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

DECISIONS.md

@@ -519,3 +519,52 @@ Modalités :
   repli « Metadata injoignable »), car le modèle Writing/Metrics peut contenir
   des entités hors Reading. Le `warning` est conservé aussi dans la réponse
   d'erreur si le WMS échoue ensuite.
+
+---
+
+## D26 — Paramètre `application` : caches par application, chargement toujours paresseux
+
+**Contexte (mesures des 24-25/08/2026, `LIMAGRAI2512`).** L'application
+interrogée venait de `WMS_APPLICATION` (partagée par tous les profils) : le MCP
+ne voyait que `EasyWMS`. Or `POST /AD/api/Application/GetAll` déclare **9
+applications**, et **CustomApp porte le spécifique client** (153 workflows
+`CST_*` sur ce tenant) — précisément ce qu'on cherche en debug. Les 11 entités
+`CustomApp` ne sont requêtables dans aucun contexte : l'API AD est le seul
+accès au spécifique client.
+
+**Décision.** Un paramètre `application` (défaut : l'application du profil,
+donc comportement strictement inchangé sans lui) sur six outils :
+`get_ad_elements`, `search_ad_elements`, `get_ad_element_details`,
+`search_workflows`, `get_workflow_details`, `list_workflow_categories`.
+
+**Contrat de cache.**
+
+| Service | Clé avant | Clé après |
+|---|---|---|
+| `ad-service` | un cache par type | un cache par **(application, type)** (`app::type`) |
+| `workflow-service` | un cache global | un cache par **application** |
+
+Sans ces clés, un appel CustomApp polluerait le cache EasyWMS du même type.
+Règles associées :
+
+- **L'invalidation reste l'abonnement `onSwitch()`** (D8) : la bascule de
+  profil vide **tous** les caches, toutes applications confondues. Aucune
+  invalidation manuelle inter-module.
+- **Pas de préchargement des 9 applications** (D10) : seule l'application
+  effectivement demandée est chargée — le type `Resource` pèse 29 374 éléments
+  sur la seule EasyWMS.
+- `workflow-service` cache aussi la liste de `Application/GetAll`, **allégée**
+  (`name`, `id`, `version`) : chaque élément de la réponse brute embarque un
+  blob `data` de ~100 Ko (la définition EasyBuilder complète) qu'on ne
+  conserve pas.
+- `list_workflow_categories` est adossé à `Application/GetAll` (les 9
+  applications) et non plus aux `applicationName` du seul cache actif. La note
+  de L1.3 reste vraie — pas de champ catégorie ; les comptes de workflows ne
+  sont affichés que pour les applications déjà chargées (paresseux). Le
+  paramètre `category` de `search_workflows` (filtre sur `applicationName`)
+  subsiste : `application` choisit le jeu chargé, `category` filtre dedans —
+  leur articulation est documentée dans les descriptions.
+- `get_application_summary` regroupe l'état par application puis par type et
+  ne détaille que les entrées **effectivement en cache** : la sortie reste
+  bornée quel que soit le nombre d'applications interrogées (D24). Il expose
+  aussi les caches de workflows par application.