L5.1 : fenetre verbatim sur le blob data de get_workflow_details

La reponse embarquait la definition EasyBuilder complete, au-dela du seuil de
rejet du client MCP (~70 000 caracteres, D24). Deux parametres de fenetre au
schema (D23) : max_data_chars (defaut 20 000) et data_offset (defaut 0). Les
metadonnees du workflow restent completes dans chaque tranche ; seul `data`
est fenetre, et dataTotalChars est porte par toute reponse.

La tranche est verbatim -- decoupe de chaine, rien d'autre. Ne jamais resumer
ni parser ce blob : la concatenation des tranches doit reconstituer la
definition a l'octet pres. Verifie : 20 000 + 20 000 + 20 000 + 11 512 =
71 512, concatenation identique au blob d'origine (premiers et derniers
caracteres compris).

Mesures avant/apres (protocole, LIMAGRAIN, longueur de content[0].text) :

  StackerCrane_LocationIsAccessibleByExtractor_PR   79 092 -> 23 117
    (blob data : 71 512, desormais annonce par dataTotalChars)
  CST_SendRejectContainersToPK (CustomApp)         101 816 -> 23 023
    (blob data : 92 362)
  StackerCrane_LoadMovementForOutboundTask_PR       10 587 -> 10 652
    (blob de 9 013 : sous le defaut, objet workflow identique a l'octet pres,
     ni truncated ni hint -- les +65 caracteres sont les trois champs de
     fenetre, contrat "total toujours porte" de D24)

Gardes de valeur dans le code de l'outil, pas dans le wrapper (D23 ne valide
que les noms) : data_offset: -5 et max_data_chars: 1.5 echouent avant tout
appel reseau avec un message nommant l'attendu.

Baseline preservee : 23 outils, 6 resources.

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

DECISIONS.md

@@ -458,7 +458,7 @@ sa réponse et **signale** la coupe. Le signal est commun :
 | `truncated: true` | présent **uniquement** quand la réponse a été coupée — jamais `truncated: false` |
 | `hint` | présent ssi `truncated` ; actionnable : dit comment continuer (`offset` suivant) ou réduire (filtres, `context_lines`…) |
 | `returned` | nombre d'éléments effectivement renvoyés |
-| total (`totalParameters`, `totalResults`) | total **avant** la coupe — `truncated` se vérifie donc depuis la réponse elle-même |
+| total (`totalParameters`, `totalResults`, `dataTotalChars`) | total **avant** la coupe — `truncated` se vérifie donc depuis la réponse elle-même |
 
 Les mécanismes restent **volontairement locaux**, car ils diffèrent :
 `get_system_parameters` pagine (`limit`/`offset` au schéma — rien n'est perdu,
@@ -468,6 +468,22 @@ on continue avec l'offset suivant) ; `search_logs` plafonne le volume
 en plus `omitted`, le compte écarté. Pas de helper partagé : le factoriser
 forcerait une abstraction commune à deux mécanismes qui n'en ont pas.
 
+**Périmètre étendu (lot 5, 25/08/2026).** Trois familles d'outils dépassaient
+encore le seuil, toutes mesurées sur `LIMAGRAI2512` :
+
+`get_workflow_details` **fenêtre le blob `data`** (`max_data_chars`, défaut
+20 000 ; `data_offset`, défaut 0) — 79 092 caractères pour un StackerCrane
+(dont 71 512 de blob), 101 816 pour `CST_SendRejectContainersToPK` (92 362 de
+blob), ramenés à ~23 000. La tranche est **verbatim** : découpe de chaîne, rien
+d'autre. Ne jamais résumer, reformuler ni « parser » cette définition
+EasyBuilder — la concaténation des tranches dans l'ordre des offsets doit la
+reconstituer à l'octet près (vérifié : 20 000 + 20 000 + 20 000 + 11 512 =
+71 512, concaténation identique au blob d'origine). Les métadonnées du workflow
+restent complètes dans chaque tranche ; seul `data` est fenêtré, et
+`dataTotalChars` est porté par **toute** réponse — y compris non tronquée, où
+la seule différence avec l'ancienne réponse est ces trois champs de fenêtre
+(+65 caractères mesurés).
+
 Deux garde-fous de cadrage :
 
 - **Ne pas réduire les défauts existants** (`max_results` 50, `context_lines` 2)