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>

ROADMAP.md

@@ -25,58 +25,6 @@ exploration à part — c'est probablement là que vivent les données agrégée
 produites par les jobs `MetricGatherer`. Livrable : un rapport, pas du code
 (même phase d'investigation que L4.4).
 
-### L4.2 — Une seule application sur neuf est visible
-
-`Application` vient de `WMS_APPLICATION` dans `.env`, **partagé par tous les
-profils**, sans surcharge par appel ni paramètre d'outil. Le MCP n'interroge donc
-jamais que `EasyWMS`.
-
-`POST /AD/api/Application/GetAll` en déclare **9** :
-
-| Application | Workflows | Queries | Entities |
-|---|---:|---:|---:|
-| EasyWMS | 4012 | 2239 | 338 |
-| **CustomApp** | **153** | **54** | **11** |
-| AGV | 71 | 14 | 5 |
-| Notifications | 26 | 35 | 24 |
-| GalileoFaults | 9 | 20 | 24 |
-| Common | 1 | 7 | 25 |
-| SmartUI, User, WarehouseWebDesigner | 0 | 0–8 | 0 |
-
-**CustomApp porte le spécifique client** — ses workflows sont préfixés `CST_`
-(`CST_SendRejectContainersToPK`, `CST_Task`, `CST_Container`…). C'est
-précisément ce qu'on cherche en debug, et c'est aujourd'hui invisible. Au total
-**260 workflows et ~130 queries** hors périmètre.
-
-Deux chantiers de difficulté très différentes :
-
-**API AD — simple.** L'application est un champ du payload
-(`[application, tenant, pageSize, offset]`). Vérifié : `["CustomApp", tenant,
-5, 0]` sur `/Workflow/GetByApplication` renvoie bien les workflows `CST_`. Il
-suffit d'un paramètre `application` sur les outils AD et workflow, avec une clé
-de cache incluant l'application (sinon un cache pollué mélange les
-applications).
-
-**QueryExecute — tranché : le champ `Application` ne partitionne rien.**
-`Context.AgvTasks` (entité de l'application AGV) répond aussi bien avec
-`Application: "AGV"` qu'avec `Application: "EasyWMS"`. Le contexte de lecture est
-**commun au tenant** : toutes les applications y déversent leurs entités.
-
-Conséquence — traitée : la table de résolution (D21) **agrège le Metadata de
-toutes les applications** déployées, et non le seul `EasyWMS`. Inutile en
-revanche d'ajouter un paramètre `application` à `QueryExecute` : il ne changerait
-rien.
-
-**Les entités `CustomApp` ne sont interrogeables dans aucun contexte.** Les 11
-entités `CST_` ont été testées sous les quatre `QueryType`, au singulier et au
-pluriel : échec partout, et `Metadata/Entities` comme `Metadata/EntitiesAll`
-renvoient **0 entité** pour `CustomApp`. Aucune n'est marquée
-`isDataWarehouse`. Ce sont des définitions EasyBuilder (`FromMetadata: false`)
-sans projection dans un contexte requêtable.
-
-**L'API AD reste donc le seul accès au spécifique client** — ce qui rend le
-paramètre `application` sur les outils AD et workflow d'autant plus utile.
-
 ### L4.3 — Identifier le MCP dans les logs du WMS
 
 Les requêtes du MCP apparaissent dans les logs du WMS sous
@@ -170,6 +118,13 @@ plus riche que `/AD/api/Application/GetAll`), `GET /healthcheck?tenantCode=` et
   début de chaque appel).
 - **`select_expression`** : les projections via le paramètre `Select` provoquent
   des erreurs de compilation côté serveur (D13). Irritant principal restant.
+- **`get_workflow_details` peut dépasser le seuil de rejet client** (constaté
+  le 25/08/2026, livraison du lot 4). La définition complète de
+  `CST_SendRejectContainersToPK` (application `CustomApp`) fait ~101 800
+  caractères via le protocole — au-delà du seuil de rejet mesuré en D24
+  (~70 000). Comportement antérieur au lot 4 (les grosses définitions
+  `EasyWMS` sont dans le même cas) : à borner et signaler (`truncated`/`hint`,
+  D24) dans un lot futur.
 - **Déploiement SSH sur la VM** : l'exécutable est validé, la configuration SSH
   reste à faire.
 - **Historique des shipment templates** : hors de portée, les logs concernés