L5.4 : découvrabilité des applications dans les réponses de recherche

Cas réel du 25/08/2026 : une session Cowork cherchant des workflows CST_
sans passer application=CustomApp a conclu à tort à leur absence de l'AD.
Vérifié en révision : CST_PickingTasksSequencing_PR et
CST_ChooseDestinationFromPS existent bien dans CustomApp sur LIMAGRAI2512.
Le correctif (rappel de l'application interrogée + hint sur résultat
maigre, depuis la liste Application/GetAll déjà en cache) rejoint le
lot 5, pas encore lancé.

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

ROADMAP.md

@@ -117,6 +117,21 @@ Les `catch` locaux d'`api-tools.js` renvoient `{ success: false, error }` sans
 le champ `tool` du contrat (convention 3) — antérieur au lot 4. Balayer tous
 les modules d'outils pour le même motif.
 
+### L5.4 — Rendre les autres applications découvrables depuis `search_workflows`
+
+Cas réel (25/08/2026, session Cowork sur LIMAGRAIN) : une session cherchant
+des workflows `CST_*` sans passer `application: "CustomApp"` a conclu à tort
+« l'AD contient 4 012 workflows, aucun CST_ » — alors que
+`CST_PickingTasksSequencing_PR` et `CST_ChooseDestinationFromPS` existent bien
+dans CustomApp (vérifié en révision). Le paramètre `application` (D26) existe,
+mais rien dans la **réponse** ne signale qu'on n'a regardé qu'une application.
+
+Ajouter aux réponses de `search_workflows` (et `search_ad_elements`) un rappel
+peu coûteux : l'application interrogée, et — quand la recherche renvoie peu ou
+pas de résultats — un hint listant les autres applications (la liste allégée
+d'`Application/GetAll` est déjà en cache, D26) avec renvoi vers le paramètre
+`application`. Aucun préchargement des autres applications (D26).
+
 ---
 
 ## Écarté

docs/handoff-lot5.md

@@ -10,7 +10,8 @@ de toucher au code.
 le seuil de rejet des clients MCP (~70 000 caractères, D24) — lot 5 de
 [../ROADMAP.md](../ROADMAP.md) : pagination du blob `data` de
 `get_workflow_details` (L5.1), garde de taille sur les trois outils de requête
-(L5.2), champ `tool` manquant dans les enveloppes d'erreur locales (L5.3).
+(L5.2), champ `tool` manquant dans les enveloppes d'erreur locales (L5.3),
+découvrabilité des applications dans les réponses de recherche (L5.4).
 
 **Hors périmètre** : tout le reste de la roadmap (L4.3, L4.4, L4.5,
 exploration Metrics). **`QueryExecuteStream` est explicitement interdit** —
@@ -179,13 +180,42 @@ contient `"tool": "call_query_api"` ; un `grep` sur `src/tools/` ne montre plus
 d'enveloppe `success: false` sans `tool` (colle le résultat du grep dans le
 compte-rendu).
 
+## L5.4 — Découvrabilité des applications dans les réponses de recherche
+
+**Problème (cas réel du 25/08/2026).** Une session Cowork cherchant des
+workflows `CST_*` sans passer `application: "CustomApp"` a conclu à tort que
+l'AD n'en contenait aucun — alors que `CST_PickingTasksSequencing_PR` et
+`CST_ChooseDestinationFromPS` existent (vérifié :
+`search_workflows {"query":"CST_PickingTasksSequencing","application":"CustomApp"}`
+→ 1 résultat). Le paramètre `application` (D26) existe, mais rien dans la
+**réponse** ne dit qu'on n'a interrogé qu'une application sur neuf.
+
+**À faire.** Dans les réponses de `search_workflows` et `search_ad_elements` :
+- toujours rappeler l'application interrogée (champ `application`) ;
+- quand la recherche renvoie **peu ou pas** de résultats (seuil à ta main, 0
+  au minimum), ajouter un hint nommant les autres applications déclarées et le
+  paramètre `application`. La liste vient de la **liste allégée
+  d'`Application/GetAll` déjà en cache** (D26) — n'ajoute aucun appel réseau ni
+  préchargement pour construire ce hint ; si la liste n'est pas encore en
+  cache, le hint générique (« d'autres applications existent —
+  `list_workflow_categories` pour les voir ») suffit.
+
+**Vérification attendue** (protocole, LIMAGRAIN) :
+- `search_workflows {"query":"CST_"}` (sans `application`) → 0 résultat **avec**
+  un hint nommant `CustomApp` (ou renvoyant vers `list_workflow_categories`).
+- `search_workflows {"query":"CST_","application":"CustomApp"}` → résultats
+  peuplés, champ `application: "CustomApp"` dans la réponse.
+- `search_workflows {"query":"stacker"}` → résultats inchangés par ailleurs,
+  champ `application: "EasyWMS"` présent, pas de hint parasite.
+- stderr : aucun fetch d'une application non demandée.
+
 ---
 
 ## Méthode
 
 1. Phase 0 d'abord (cinq mesures, rejouées telles quelles).
-2. L5.1, puis L5.2, puis L5.3 — chaque bloc vérifié **en exécution via le
-   protocole** avant de passer au suivant.
+2. L5.1, puis L5.2, puis L5.3, puis L5.4 — chaque bloc vérifié **en exécution
+   via le protocole** avant de passer au suivant.
 3. Rappel : le serveur traite les `tools/call` en concurrence (point ouvert de
    la ROADMAP) — pour les vérifications qui comparent des réponses successives,
    envoie les requêtes séquentiellement.
@@ -198,7 +228,7 @@ compte-rendu).
 
 ## Livraison
 
-- Un commit par bloc (L5.1, L5.2, L5.3), messages expliquant le pourquoi,
+- Un commit par bloc (L5.1, L5.2, L5.3, L5.4), messages expliquant le pourquoi,
   **mesures avant/après dans le corps du message** (tailles en caractères).
 - Documentation dans les mêmes commits : **compléter D24** (périmètre étendu
   aux outils de requête et à `get_workflow_details`) ; CLAUDE.md — la nouvelle