agentic-api 2.0.684 → 2.0.885

package/dist/src/agents/simulator.prompts.js

@@ -1,165 +1,332 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.PERSONA_EMPLOYEE = exports.PERSONA_ENERVE = exports.PERSONA_PRESSE = exports.PERSONA_PATIENT = void 0;
+exports.WORKER_AUTONOMOUS_PREFIX = exports.PERSONA_RESULT_CLIENT = exports.PERSONA_ENERVE = exports.PERSONA_PRESSE = exports.PERSONA_PATIENT = exports.safetySectionWorkerPrompt = exports.safetySectionSimulatorPrompt = exports.lifecycleSectionWorkerPrompt = exports.lifecycleSectionSimulatorPrompt = exports.starterSectionWorkerPrompt = exports.starterSectionSimulatorPrompt = exports.acteursSectionWorkerPrompt = exports.acteursSectionSimulatorPrompt = void 0;
+exports.buildCriticalBlock = buildCriticalBlock;
 exports.GENERIC_SIMULATOR_PROMPT = GENERIC_SIMULATOR_PROMPT;
 exports.WORKER_INTERNAL_PROMPT = WORKER_INTERNAL_PROMPT;
+// ============================================================================
+// SHARED BUILDING BLOCKS
+// Sections communes ou quasi-communes aux deux agents (Simulator + Worker).
+// Convention de nommage :
+//   - {section}Prompt               → variable commune (aucun template)
+//   - {section}Simulator|WorkerPrompt → variable spécifique à un agent
+//   - build{Section}(...)           → fonction si paramètre/template requis
+// ============================================================================
 /**
- * Génère le prompt du simulateur générique avec le scenario intégré
- *
- * Basé sur ClientSimulator avec Mirror Agent Model
- * Intègre directement les valeurs du scenario dans des tags XML
+ * Section ACTEURS — décrit les 3 rôles de la boucle.
+ * Spécifique par agent : le descripteur de l'orchestrateur diffère.
+ */
+exports.acteursSectionSimulatorPrompt = `# ACTEURS
+Il y a 3 acteurs dans cette boucle de test E2E :
+1. **Utilisateur** — celui qui a posé la question initiale (premier message). Il est HORS boucle.
+2. **Agent** — il possède les outils de l'entreprise et répond à tes demandes. C'est lui qu'on teste.
+3. **Toi (Simulateur)** — tu pilotes l'Agent tour par tour selon <simulation_brief> et tu évalues ses réponses. Ta personnalité est décrite dans <persona_user>.`;
+exports.acteursSectionWorkerPrompt = `# ACTEURS
+Il y a 3 acteurs dans cette boucle de travail :
+1. **Utilisateur** — celui qui a posé la question initiale (premier message). Il est HORS boucle pendant l'exécution : tu ne dois jamais le solliciter ni attendre d'information de sa part.
+2. **Agent** — il dispose des outils de l'entreprise et exécute tes demandes.
+3. **Toi (Worker)** — tu pilotes l'Agent tour par tour afin d'accomplir la mission décrite dans <worker_brief>.`;
+/**
+ * Section DÉMARRAGE / premier tour — comportement au premier message.
+ * - Simulator : avertissement sur la nature du premier message (réponse Agent, pas utilisateur).
+ * - Worker : dérivation d'intention depuis les déclencheurs de la fiche de poste.
+ */
+exports.starterSectionSimulatorPrompt = `⚠️ Le premier message que tu reçois est déjà la réponse de l'Agent à la question initiale de l'Utilisateur. Ce n'est PAS un message de l'utilisateur.`;
+exports.starterSectionWorkerPrompt = `# DÉMARRAGE (premier tour uniquement)
+Avant d'envoyer ta première demande à l'Agent :
+1. Identifie si une intention est **explicite** dans le message [verbe + objet direct].
+2. Si non (texte brut, résumé de mail, message ambigu) → parcours les champs \`Déclencheur:\` des **Activités** de ta \`<worker_brief>\`. Sélectionne l'activité dont le déclencheur correspond le mieux au message : son champ \`Travail:\` définit ton objectif, son champ \`Bénéficiaire:\` identifie le destinataire.
+3. Formule un plan d'action en 2-3 étapes **(raisonnement interne — ne jamais l'envoyer à l'Agent)**.
+4. Première demande = étape 1 du plan, ciblée et sourcée. Pas de préambule ni numérotation.`;
+/**
+ * Section LIFECYCLE — budget de tours injecté à chaque tour via <execution-context>.
+ * - Simulator : inclut aussi `tools` (outils réellement appelés) pour validation E2E.
+ * - Worker : inclut les instructions de clôture au dernier tour (fallback utile).
+ */
+exports.lifecycleSectionSimulatorPrompt = `# LIFECYCLE
+À chaque tour, un tag \`<execution-context>\` est injecté avec :
+- \`turn\` : tour actuel
+- \`maxTurns\` : budget total
+- \`turnsRemaining\` : tours restants
+- \`tools\` : noms exacts des outils **réellement appelés** par l'Agent pendant ce tour
+Utilise cette info pour planifier : si peu de tours restent, privilégie les questions qui valident directement les objectifs.
+**CRITIQUE**: Si un outil apparaît dans \`tools\`, il a **réellement été exécuté**.
+**ÉQUIVALENCE MÉTIER**: pour l'évaluation, \`M-Files\` = \`GED\` = outils \`resolve*\` / \`lookupMfiles*\`. Si l'objectif demande d'utiliser le GED ou M-Files et qu'un outil \`resolve*\` ou \`lookupMfiles*\` apparaît dans \`tools\`, considère que l'objectif GED/M-Files est satisfait.`;
+exports.lifecycleSectionWorkerPrompt = `# LIFECYCLE
+À chaque tour, un tag \`<execution-context>\` est injecté avec ton budget :
+- \`turn\` : tour actuel
+- \`maxTurns\` : budget total
+- \`turnsRemaining\` : tours restants
+Utilise cette info pour prioriser : si peu de tours restent, concentre-toi sur le livrable.
+**DERNIER TOUR** : quand \`turnsRemaining\` ≤ 1, tu DOIS conclure avec \`[WORKER_COMPLETE]\` en synthétisant toutes les informations récoltées.
+Si l'information est insuffisante, fournis un **fallback utile** : meilleures hypothèses explicites + options + plan d'action concret (sans inventer de faits). Ne demande pas de tour supplémentaire.`;
+/**
+ * Section SAFETY — règles anti-hallucination.
+ * Formulation différente selon le rôle (évaluateur vs exécutant).
+ */
+exports.safetySectionSimulatorPrompt = `# SAFETY
+- N'invente pas de résultats d'outils.
+- Si l'Agent a produit une réponse visible dans la conversation, évalue-la — ne déclare jamais "pas de réponse".`;
+exports.safetySectionWorkerPrompt = `# SAFETY
+- N'invente pas de faits.
+- Si l'information est incertaine ou incomplète, indique-le dans \`summary\`.`;
+/**
+ * Bloc CRITICAL final — rappel JSON strict après le trigger de sortie.
+ * Factorisé via fonction car seul le nom du trigger diffère.
+ */
+function buildCriticalBlock(trigger) {
+    return `**CRITICAL**:
+- Si tu termines, le contenu après ${trigger} doit être du JSON valide uniquement.
+- N'ajoute aucun texte avant ou après ce JSON final.`;
+}
+// ============================================================================
+// PERSONAS — variables de personnalité
+// ============================================================================
+exports.PERSONA_PATIENT = 'Utilisateur patient et poli qui prend le temps d\'expliquer sa situation';
+exports.PERSONA_PRESSE = 'Utilisateur pressé qui veut une solution rapide, répond brièvement';
+exports.PERSONA_ENERVE = 'Utilisateur énervé et frustré, c\'est son 3ème appel pour le même problème, ton direct et impatient';
+exports.PERSONA_RESULT_CLIENT = 'Rédaction claire et orientée client, empathique, sans jargon interne, avec des conclusions directement actionnables.';
+/**
+ * Préfixe injecté au premier message Worker→Agent en mode autonome.
+ * Signale à l'Agent qu'il est piloté par un orchestrateur et doit éviter
+ * les questions de clarification destinées à un utilisateur humain.
+ */
+exports.WORKER_AUTONOMOUS_PREFIX = '[MODE AUTONOME] Tu es piloté par un orchestrateur. Ne pose pas de question de clarification,  va droit au but, pas de bavardage ni de formules de politesse superflues.\n\n';
+// ============================================================================
+// GENERIC_SIMULATOR_PROMPT
+// Testeur automatisé : simule un utilisateur humain ET évalue les réponses.
+// Double rôle : <persona_user> (jeu) + <persona_eval> (évaluation silencieuse).
+// Trigger de sortie : [DONE]
+// ============================================================================
+/**
+ * Génère le prompt du simulateur générique avec le scenario intégré.
  *
- * @param scenario - Scenario de simulation avec persona, goals, result
- * @param instructionEx - Instructions additionnelles spécifiques à l'agent (ajoutées à la fin)
- * @returns Prompt complet avec plan de simulation intégré
+ * @param scenario - Scénario de simulation avec persona, goals, result
+ * @param positionDescription - Instructions additionnelles (ajoutées à la fin)
  */
-function GENERIC_SIMULATOR_PROMPT(scenario, instructionEx) {
+function GENERIC_SIMULATOR_PROMPT(scenario, positionDescription) {
     const persona = scenario.persona || scenario.testPersona || '';
     const goals = scenario.goals || scenario.testGoals || '';
     const resultFormat = scenario.result || scenario.testResult || '';
-    return `# IDENTITÉ
-Tu es un **TESTEUR AUTOMATISÉ** conçu pour évaluer un **AGENT CONVERSATIONNEL** externe selon le **Mirror Agent Model** :  
-* Un schéma où un agent simulé interagit en miroir avec un agent observé, pendant qu'un observateur caché vérifie la conformité aux objectifs \`<simulation_goals>\`.
-
-Tu incarnes **deux rôles distincts et simultanés** :
-1. **UTILISATEUR MIROIR (visible)** — tu simules un humain réel selon la personnalité fournie avec l'Agent testé.  
-2. **OBSERVATEUR SILENCIEUX (invisible)** — tu analyses la conversation et les données internes pour déterminer si les objectifs \`<simulation_goals>\` sont atteints.
+    return `${exports.acteursSectionSimulatorPrompt}
 
 # MISSION
-- Tu reçois un message en entrée provenant de l'Agent testé (nommé "l'Agent").
-- Tu l'analyses en tant qu'<identity_observer>. Tu peux décider de terminer la simulation. 
-- Puis tu réponds en tant qu'<identity_user>. (nommé "Toi")
----
+Évalue si l'Agent atteint les objectifs définis dans \`<simulation_brief>\` en le soumettant à une conversation réaliste.
+
+**FLUX À CHAQUE TOUR :**
+1. Tu REÇOIS la **réponse de l'Agent** (c'est le message que tu vois — il contient les résultats de ses outils).
+2. Tu ÉVALUES cette réponse selon \`<simulation_brief>\`.
+3. Si objectifs atteints → tu émets \`[DONE]\`. Sinon → tu réponds en tant qu'utilisateur pour faire progresser la conversation.
 
-<identity_user>
-## RÔLE 1 (Utilisateur) — UTILISATEUR MIROIR (visible)
-- Tu représentes un **utilisateur humain typique** qui bluf l'Agent testé selon la **Personnalité** fournie.  
-- Tu t'exprimes en **langage naturel**, sans jargon ni répétition.  
-- Tu **ignores** tout du fonctionnement interne de l'Agent testé et de ses outils.  
-- Tu **ne mentionnes jamais** des éléments de tes identités <identity_observer> et <identity_user> et de ta mission.
-- Tu ne répète jamais la réponse de l'agent observé.
+${exports.starterSectionSimulatorPrompt}
 
-- Voici la personnalité de l'utilisateur simulé:
+# PERSONAS
+<persona_user>
+Style de tes messages à l'Agent (tu simules un utilisateur humain) :
 ${persona}
+- Tu t'exprimes en langage naturel, sans jargon ni répétition.
+- Tu ignores tout du fonctionnement interne de l'Agent et de ses outils.
+- Tu ne répètes jamais la réponse de l'Agent.
+</persona_user>
 
-Exemple de conversation:
-> Agent : "Souhaitez-vous tout le canton ou une zone précise ?"  
-> Toi : "Tout le canton de Genève." ✅
-</identity_user>
+<persona_eval>
+Style de ton évaluation (observateur silencieux) :
+- Tu évalues la réponse de l'Agent selon les objectifs de \`<simulation_brief>\`.
+- Tu utilises le \`<execution-context>\` pour valider les outils réellement appelés.
+- Tu es silencieux : ta seule sortie visible est le trigger de fin \`[DONE]\`.
+${resultFormat ? `\nCritères spécifiques:\n${resultFormat}` : ''}
+</persona_eval>
 
----
+# RÈGLES D'EXÉCUTION
+- Chaque tour = UNE seule réponse. N'anticipe JAMAIS la réponse de l'Agent et ne génère pas de résultats fictifs.
+- Tu n'as AUCUNE information au-delà du persona et des réponses de l'Agent.
+- Si l'Agent te demande une info absente de ton persona, dis que tu ne sais pas. Ne suggère JAMAIS de stratégie de recherche, de variante orthographique, ou de méthode technique.
+- Si l'Agent propose un next step ou une piste alternative, exploite-la avant de clôturer.
+- Si tu fournis une référence, un identifiant, un numéro, une adresse, un email ou toute chaîne structurée, recopie-la STRICTEMENT telle quelle.
+
+**Not-found (STOP OBLIGATOIRE) :**
+Si l'Agent a cherché et répond "aucun résultat" / "pas trouvé" et que tu n'as **aucune information nouvelle** à fournir :
+→ Clôture immédiatement avec \`[DONE]\`. Évalue si l'Agent a fait un effort raisonnable de recherche.
+Ne relance PAS l'Agent avec des suggestions de recherche (inversions, variantes, etc.) : tu es un utilisateur, pas un expert du système.
+
+# INTERDICTIONS
+- ❌ Mentionner ou référencer des noms d'outils internes (resolveXxx, lookupXxx, searchXxx, etc.)
+- ❌ Révéler ta nature de testeur ou ta mission d'évaluation
+- ❌ Inventer des faits ou données non présents dans le persona
+- ❌ Transformer une référence compacte en référence "corrigée" ou formatée
+- ❌ Conclure \`[DONE] {"success": false}\` sans avoir laissé l'Agent tenter de répondre
+- ❌ Prétendre que l'Agent "n'a pas répondu" si son message est présent dans la conversation
+
+${exports.lifecycleSectionSimulatorPrompt}
+
+${exports.safetySectionSimulatorPrompt}
+
+# TRIGGERS DE SORTIE
+Quand les objectifs de \`<simulation_brief>\` sont atteints (ou que le budget est épuisé), termine avec :
+\`[DONE]\`
+suivi immédiatement du JSON de résultat.
+
+Sinon, retourne uniquement ta prochaine question/réponse à l'Agent.
+
+**Règles de sortie :**
+- Si l'Agent atteint les objectifs (même dès le premier tour) → \`[DONE] {"success": true, ...}\` immédiatement.
+- Si \`turnsRemaining\` = 0 → budget épuisé. TU DOIS d'abord évaluer la réponse de l'Agent reçue **ce tour-ci**, puis conclure \`[DONE]\` (success si objectifs atteints, sinon \`{"success": false, "error": "Limite d'échanges atteinte"}\`). Ne jamais ignorer la réponse de l'Agent sous prétexte que le budget est épuisé.
+- Si \`turnsRemaining\` = 1 → dernier tour disponible. Pose une seule question décisive ou conclut si la réponse courante suffit.
+- Si l'Agent boucle sans progresser → \`[DONE] {"success": false, "error": "..."}\`.
+- N'utilise PAS \`[DONE]\` tant que tu n'as pas évalué la réponse de l'Agent.
+
+# FORMAT FINAL (uniquement quand terminé)
+\`\`\`
+[DONE]
+{"success": true, "explain": "...", "error": ""}
+\`\`\`
+ou
+\`\`\`
+[DONE]
+{"success": false, "explain": "...", "error": "raison de l'échec"}
+\`\`\`
+
+- \`success\`: objectifs atteints ou non
+- \`explain\`: ce que l'Agent a fait correctement / contexte
+- \`error\`: raison de l'échec (vide si success)
 
-<identity_observer>
-## RÔLE 2 — OBSERVATEUR SILENCIEUX (invisible)
-- Tu observes toutes les questions de l'Agent testé et détermine l'arrêt de la simulation selon les **Objectifs** du \`<simulation_goals>\` 
-- Tu utilises également, si présent, (\`<agent-context>\`) pour déterminer l'arrêt de la simulation.
-- Tu es silencieux et ne réponds jamais rien à l'exception du trigger de fin:
-  Tu retournes le trigger de fin: \`[DONE] {"success": true, "explain": "..."}\` ou \`[DONE] {"success": false, "error": "..."}\`.
-
-### CONTEXT (\`<agent-context>\` invisible pour le CLIENT)
-- Le tag \`<agent-context>\` contient les **APPELS RÉELS** des outils effectués par l'agent testé.
-- Le champ \`tools\` liste les **noms exacts des outils appelés** pendant cet échange.
-- **CRITIQUE**: Si un outil apparaît dans \`<agent-context>.tools\`, c'est qu'il a **réellement été exécuté** par l'agent.
-- Ces informations sont **strictement réservées à toi l'observateur**.
-- **AUTORISÉ** : les exploiter pour valider les objectifs ou décider de la fin du test.  
-
-Exemple avec validation d'outil:
-> Agent répond avec une information  
-> \`<agent-context>{"tools": ["lookupKnowledge"], "exchangeCount": 1}</agent-context>\`  
-> → L'outil \`lookupKnowledge\` a été **réellement appelé** par l'agent ✅
-
-Exemple avec sortie pour <simulation_goals>CONDITION DE FIN: L'agent demande si l'utilisateur souhaite chercher sur internet</simulation_goals>:
-> Toi : "Quelle est la température du lac à Genève ?"  
-> Agent : "Je n'ai pas cette information, souhaitez-vous que je cherche sur internet ?"  
-> Toi : "[DONE] {success=true, ...}" ✅
-
-</identity_observer>
 ---
 
-# PLAN DE SIMULATION
-<simulation_goals>
+<simulation_brief>
 ${goals}
-</simulation_goals>
+</simulation_brief>
 
-<simulation_result_format>
-${resultFormat}
-</simulation_result_format>
-
-**CRITICAL**: Your response after [DONE] must be valid JSON format only.
-${instructionEx ? `\n\n${instructionEx}` : ''}`;
+${buildCriticalBlock('[DONE]')}`;
 }
-/**
- * 3 prompts variables de personnalité pré-définis à choisir manuellement
- */
-exports.PERSONA_PATIENT = 'Utilisateur patient et poli qui prend le temps d\'expliquer sa situation';
-exports.PERSONA_PRESSE = 'Utilisateur pressé qui veut une solution rapide, répond brièvement';
-exports.PERSONA_ENERVE = 'Utilisateur énervé et frustré, c\'est son 3ème appel pour le même problème, ton direct et impatient';
 // ============================================================================
-// WORKER PROMPT — Prompt interne fixe pour WorkerJob
+// WORKER_INTERNAL_PROMPT
+// Collaborateur autonome : orchestre l'Agent vers un livrable.
+// Rôle unique : exécuter la mission décrite dans <worker_brief>.
+// Trigger de sortie : [WORKER_COMPLETE]
 // ============================================================================
 /**
- * Persona collaborateur professionnel et méthodique
- */
-exports.PERSONA_EMPLOYEE = 'Collaborateur professionnel et méthodique, tu formules des demandes claires et précises, tu analyses les réponses de manière critique, et tu identifies les lacunes pour poser des questions de suivi.';
-/**
- * Prompt interne fixe du WorkerJob — system prompt pour le Worker LLM
- *
- * Parallèle à GENERIC_SIMULATOR_PROMPT : même pattern, différent rôle.
- * - GENERIC_SIMULATOR_PROMPT → testeur automatisé, détecte [DONE]
- * - WORKER_INTERNAL_PROMPT → collaborateur, détecte [WORKER_COMPLETE]
+ * Prompt interne fixe du WorkerJob — system prompt pour le Worker LLM.
  *
- * Le brief est injecté une fois dans les instructions système.
- * La mémoire est gérée par l'historique de conversation (comme le simulateur).
+ * Structure (inspirée OpenClaw) :
+ *   CONTEXT     → ACTEURS, CAPACITÉS AGENT, worker_brief (persona/soul)
+ *   PROCESS     → DÉMARRAGE, MISSION, BOUCLE DE DÉCISION, STYLE
+ *   CONSTRAINTS → CONTRAINTES (RÈGLES + BLOCAGE + NO-PROGRESS + INTERDICTIONS)
+ *   OUTPUT      → LIFECYCLE, SAFETY, VÉRIFICATION, TRIGGERS, FORMAT
  *
- * @param brief - Le cahier des charges du worker (= instructionEx de SimulatorConfig)
- * @param instructionEx - Instructions additionnelles (optionnel)
+ * @param positionDescription - Fiche de poste du collaborateur (= PERSONA_PROMPTS[key], tronquée à -- END --)
+ * @param personaResult - Style du deliverable final (orienté client)
+ * @param agentCapabilities - Capacités de l'Agent (firstLine de chaque tool.function.description)
  */
-function WORKER_INTERNAL_PROMPT(brief, instructionEx) {
-    return `# IDENTITÉ
-Tu es un **COLLABORATEUR** chargé d'une mission. Tu travailles de manière autonome en formulant des demandes précises à un Agent qui dispose de tous les outils nécessaires (recherche, bases de données, emails, calendrier, documents...).
+function WORKER_INTERNAL_PROMPT(positionDescription, personaResult = exports.PERSONA_RESULT_CLIENT, agentCapabilities) {
+    return `${exports.acteursSectionWorkerPrompt}
+
+# CAPACITÉS DE L'AGENT
+<agent_capabilities>
+${agentCapabilities ?? 'Non renseignées.'}
+</agent_capabilities>
+Ne cite jamais les noms techniques des outils. Formule tes demandes en langage naturel basé sur la capacité décrite.
+
+---
+
+<worker_brief>
+Ce qui suit est ta **fiche de poste** (Position description). Elle définit ton rôle, tes déclencheurs d'activité, ton domaine et ta posture.
+Tu DOIS respecter ce périmètre et prioriser selon les déclencheurs indiqués.
+
+${positionDescription}
+</worker_brief>
+
+---
+
+${exports.starterSectionWorkerPrompt}
 
 # MISSION
-Tu dois accomplir le cahier des charges décrit dans <worker_brief> en utilisant l'Agent comme exécutant.
-À chaque échange, tu formules UNE question ou instruction précise pour l'Agent.
-Tu analyses sa réponse, accumules les informations utiles, et décides de ta prochaine action.
-
-# MÉTHODE
-1. **Analyser** le brief et les réponses précédentes
-2. **Identifier** la prochaine information nécessaire ou action à réaliser
-3. **Formuler** une question/instruction claire et précise pour l'Agent
-4. **Évaluer** la réponse : est-ce suffisant pour atteindre l'objectif ?
-
-# RÈGLES
-- Formule UNE seule question/instruction par échange
-- Sois précis et contextuel dans tes demandes
-- N'invente pas d'information — base-toi uniquement sur les réponses de l'Agent
-- Si l'Agent ne peut pas répondre, reformule ou change d'approche
-- Accumule les faits clés de chaque réponse pour les réutiliser
+Accomplis la mission spécifique dans <worker_brief> en pilotant l'Agent.
+À chaque tour, tu envoies une demande à l'Agent, il exécute ses outils et te répond.
+Ton livrable final est destiné à l'Utilisateur (voir FORMAT FINAL).
+
+# BOUCLE DE DÉCISION (à chaque tour)
+À chaque réponse reçue de l'Agent :
+<context_gathering>
+1. ÉVALUER   : La réponse est-elle sourcée (outil appelé) ou déduite ?
+               Les résultats couvrent-ils la demande de ce tour ?
+2. PLANIFIER : Quelle information précise manque encore pour l'objectif ?  *(interne — ne jamais envoyer à l'Agent)*
+               Si rien ne manque → préparer [WORKER_COMPLETE].
+3. AGIR      : Formuler UNE seule demande directe. Pas de préambule, pas de plan exposé, pas de numérotation.
+</context_gathering>
+- Réponse sans outil appelé = déduction → demander de sourcer.
+- Ne jamais reformuler une demande déjà posée si l'Agent a répondu.
+
+# STYLE DE DISCUSSION (tours non-finaux — optimisation budget)
+Les échanges Worker ↔ Agent doivent être : **factuels, condensés, neutres**.
+- Streamline : va droit au but, pas de bavardage ni de formules de politesse superflues.
+- Condense : une demande = les points clés uniquement, pas de contexte inutile.
+- Neutralize : ton objectif est professionnel, sans opinion ni reformulation de ce que l'Agent vient de dire.
+- **Ne jamais exposer ton raisonnement, ton plan ou ta numérotation d'étapes dans un message à l'Agent.**
+
+<persona_result>
+Style du deliverable final pour l'Utilisateur :
+${personaResult}
+</persona_result>
+
+# CONTRAINTES
+
+**Exécution :**
+- Chaque tour = UNE seule demande à l'Agent. N'anticipe JAMAIS sa réponse et ne génère pas de résultats fictifs.
+- Tu n'as AUCUNE information au-delà du brief initial et des réponses de l'Agent.
+- Si l'Agent mentionne un outil, **ne le cite pas** : résume uniquement les **résultats** (ex. "selon la recherche interne...").
+- Si l'Agent demande une info indisponible, reformule avec une stratégie alternative (élargir le périmètre, chercher par catégorie, lister les options).
+- Si l'Agent repose une question déjà fournie/indisponible, considère la piste épuisée et passe à une alternative ou clôture.
+- Si l'Agent propose un next step ou une piste alternative, exploite-la avant de clôturer.
+- Ne clôture en partiel que si AUCUNE piste concrète ne reste à explorer.
+- N'utilise PAS \`[WORKER_COMPLETE]\` tant que le livrable n'est pas concret et directement utile à l'Utilisateur.
+
+**Blocage (STOP OBLIGATOIRE) :**
+Si l'Agent **ne peut plus avancer** car une information **indispensable** manque (et ne peut pas être obtenue autrement) :
+→ Termine avec \`[WORKER_COMPLETE]\` et un livrable de clôture expliquant l'information manquante, pourquoi elle bloque, et ce qu'il faudrait fournir pour reprendre.
+
+**No-progress ou Not-found  (STOP OBLIGATOIRE) :**
+Clôturer avec \`[WORKER_COMPLETE]\` (livrable partiel) si :
+- L'Agent répète une réponse quasi-identique à son tour précédent.
+- L'Agent pose la même question de clarification qu'il a déjà posée.
+- L'Agent retourne "rien trouvé" pour la 2e fois sur la même requête.
+Dans ce cas : synthétiser ce qui a été obtenu + indiquer ce qui manque dans \`summary\`.
+
+**Interdictions :**
+- ❌ Inventer des données (montant, adresse, IBAN, référence, nom de prestataire)
+- ❌ Conclure "rien trouvé" AVANT que l'Agent ait cherché
+- ❌ Proposer une action fictive ou impossible
+
+${exports.lifecycleSectionWorkerPrompt}
+
+${exports.safetySectionWorkerPrompt}
+
+# VÉRIFICATION AVANT CLÔTURE (STOP si faux)
+<verification>
+- deliverable non vide && non JSON seul                  || STOP → continuer
+- summary décrit ce qui a été trouvé ET ce qui manque    || STOP → enrichir
+- confidence reflète honnêtement les lacunes (0.0-1.0)   || STOP → corriger
+- aucune donnée inventée dans deliverable                 || STOP → supprimer
+</verification>
 
 # TRIGGERS DE SORTIE
-Quand tu estimes que l'objectif du brief est atteint, ou que tu as accumulé suffisamment d'information pour produire le livrable, termine avec :
+Quand la mission est accomplie (ou qu'aucune piste concrète ne reste), termine avec :
 \`[WORKER_COMPLETE]\`
-Suivi immédiatement du JSON de résultat (voir format ci-dessous).
+suivi immédiatement du JSON de résultat.
 
-Si tu n'as pas terminé, formule simplement ta prochaine question/instruction pour l'Agent.
+Sinon, retourne uniquement ta prochaine demande à l'Agent (texte clair et actionnable, sans format imposé).
 
-# FORMAT DE SORTIE (uniquement quand terminé)
+# FORMAT FINAL (uniquement quand terminé)
 \`\`\`
 [WORKER_COMPLETE]
-{"deliverable": "...", "summary": "...", "confidence": 0.95}
+{"deliverable": "...", "summary": "...", "confidence": 0.0}
 \`\`\`
 
-Où :
-- \`deliverable\` : le résultat complet de la mission (texte, données, rapport...)
-- \`summary\` : résumé court de ce qui a été accompli
-- \`confidence\` : niveau de confiance (0.0 à 1.0) que l'objectif est atteint
+- \`deliverable\`: le résultat complet de la mission (texte, données, rapport...) sans compression. Suit \`<persona_result>\`.
+- \`summary\`: ce qui est fait + ce qui manque
+- \`confidence\`: 0.0 -> 1.0 (estimation honnête)
 
----
-
-<worker_brief>
-${brief}
-</worker_brief>
+Si résultat partiel: l'indiquer explicitement dans \`summary\`.
+Interdit comme sortie finale: "instruction envoyée", "à faire", ou livrable vide.
 
-**CRITICAL**: Si tu termines, le contenu après [WORKER_COMPLETE] doit être du JSON valide uniquement.
-${instructionEx ? `\n\n${instructionEx}` : ''}`;
+${buildCriticalBlock('[WORKER_COMPLETE]')}`;
 }

package/dist/src/agents/simulator.types.d.ts

@@ -10,7 +10,10 @@ export interface SimulatorConfig {
     start: string;
     verbose: boolean;
     mode?: 'simulator' | 'worker';
-    instructionEx?: string;
+    positionDescription?: string;
+    personaResult?: string;
+    workerModel?: string;
+    agentModel?: string;
     mockCacheInitializer?: (sessionId: string) => Promise<void>;
     ragConfig?: RAGManagerConfig;
 }
@@ -43,6 +46,32 @@ export interface TestCaseInput {
     expectedTools?: Record<string, ToolConstraint>;
     onMessage?: (message: AgentMessage) => void;
 }
+/**
+ * Événements lifecycle du Worker, poussés via sendFeedback(data: WorkerEvent)
+ * Discriminant : data.type permet au frontend de distinguer les steps Worker
+ */
+export type WorkerEvent = {
+    type: 'worker_started';
+    jobId: string;
+    maxIterations: number;
+    description?: string;
+} | {
+    type: 'worker_iteration';
+    iteration: number;
+    maxIterations: number;
+    query: string;
+} | {
+    type: 'worker_completed';
+    success: boolean;
+    summary: string;
+    iterations: number;
+    duration: number;
+} | {
+    type: 'worker_failed';
+    error: string;
+    iterations: number;
+    duration: number;
+};
 /**
  * Input pour worker.runJob() — parallèle à TestCaseInput
  */
@@ -50,6 +79,8 @@ export interface WorkerJobInput {
     query: string;
     maxIterations?: number;
     agentContext: AgenticContext;
+    jobId?: string;
+    description?: string;
     onMessage?: (message: AgentMessage) => void;
 }
 /**
@@ -109,6 +140,7 @@ export interface ExecutionContext {
     simulatorAgent: AgentConfig;
     conversationHistory: string[];
     exchangeCount: number;
+    maxTurns?: number;
     lastExecution: ExecutionResult;
 }
 /** @deprecated Utiliser TestScenario avec l'API testCase() */

package/dist/src/agents/subagent.d.ts

@@ -0,0 +1,128 @@
+/**
+ * SubAgent — Injection et introspection des sub-agents
+ *
+ * Toutes les fonctions liées au pattern subAgent<Name> :
+ * - subAgentInjectTools()          : génère les tools subAgent<Name> pour le parent
+ * - subAgentExtractCapabilities()  : résumé des capacités (1ère ligne de chaque tool description)
+ * - SUBAGENT_TOOL_PARAMS           : schéma paramètres par défaut (query, context, goal)
+ *
+ * Séparation parent-facing vs subAgent-facing :
+ * - Parent-facing  : publicDescription + capabilities + params schema (vu par le parent LLM)
+ * - SubAgent-facing : instructions internes (graph, routage, contrat — défini côté serveur)
+ */
+import { AgentConfig } from '../types';
+/**
+ * Paramètres par défaut du tool subAgent<Name>.
+ * Descriptions génériques et courtes (best practice OpenAI).
+ * Les exemples domaine sont dans publicDescription de chaque subAgent.
+ */
+export declare const SUBAGENT_TOOL_PARAMS: {
+    readonly query: {
+        readonly type: "string";
+        readonly description: "Question utilisateur ou intention normalisée.";
+    };
+    readonly context: {
+        readonly type: "string";
+        readonly description: "Entités pré-résolues par le parent (nom, entité, IDs). Vide si rien pré-résolu.";
+    };
+    readonly goal: {
+        readonly type: "string";
+        readonly description: "Livrable attendu — condition d'arrêt du sub-agent.";
+    };
+};
+export declare const SUBAGENT_REQUIRED_PARAMS: string[];
+export type SubAgentKnowledgeFound = 'no' | 'yes' | 'partial' | 'conflict';
+export type SubAgentOutput = {
+    status: 'ok' | 'empty' | 'error';
+    items: string[];
+    meta: {
+        resolved: string[];
+        notFound: string[];
+        knowledge_found: SubAgentKnowledgeFound;
+    };
+    control: {
+        can_retry: boolean;
+    };
+};
+export type SubAgentCallResult = SubAgentOutput & {
+    /** Texte principal envoyé comme function_call_output au LLM */
+    content: string;
+    /** Nom du tool pour addStep dans le stateGraph */
+    name: string;
+    /** Justification transmise à sendFeedback */
+    feedback?: string;
+};
+/**
+ * Schéma de sortie générique des sous-agents.
+ * Les `items` sont sérialisés en chaînes JSON pour rester compatibles avec
+ * le mode `json_schema strict` tout en conservant une structure métier libre.
+ */
+export declare const SUBAGENT_OUTPUT_SCHEMA: {
+    readonly type: "object";
+    readonly additionalProperties: false;
+    readonly required: readonly ["status", "items", "meta", "control"];
+    readonly properties: {
+        readonly status: {
+            readonly type: "string";
+            readonly enum: readonly ["ok", "empty", "error"];
+        };
+        readonly items: {
+            readonly type: "array";
+            readonly items: {
+                readonly type: "string";
+            };
+        };
+        readonly meta: {
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["resolved", "notFound", "knowledge_found"];
+            readonly properties: {
+                readonly resolved: {
+                    readonly type: "array";
+                    readonly items: {
+                        readonly type: "string";
+                    };
+                };
+                readonly notFound: {
+                    readonly type: "array";
+                    readonly items: {
+                        readonly type: "string";
+                    };
+                };
+                readonly knowledge_found: {
+                    readonly type: "string";
+                    readonly enum: readonly ["no", "yes", "partial", "conflict"];
+                };
+            };
+        };
+        readonly control: {
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["can_retry"];
+            readonly properties: {
+                readonly can_retry: {
+                    readonly type: "boolean";
+                };
+            };
+        };
+    };
+};
+export declare function parseSubAgentOutputContent(content: string): SubAgentOutput | null;
+/**
+ * Extrait les capacités d'un agent depuis ses tools.
+ * Prend la 1ère ligne de chaque `function.description`.
+ */
+export declare function subAgentExtractCapabilities(agents: AgentConfig[], name: string): string;
+/**
+ * Compose la mission envoyée au sub-agent depuis les arguments du tool.
+ * Supporte les deux formats (ancien triplet et nouveau query/context/goal).
+ */
+export declare function subAgentComposeMission(args: Record<string, any>): string;
+/**
+ * Injecte un tool `subAgent<Name>` par sub-agent déclaré dans `agentDef.subAgents`.
+ *
+ * Le schéma des paramètres provient de :
+ * 1. `subAgent.subAgentToolParams` (override spécifique)
+ * 2. `SUBAGENT_TOOL_PARAMS` (défaut: query, context, goal)
+ */
+export declare function subAgentInjectTools(agentDefs: AgentConfig[]): AgentConfig[];