jcosxgb/graphe

Graphe — Une question, exécutée sous forme de graphe

Transformez une question ou un workflow conséquent en un graphe de preuves par étapes :

PLAN → VOIES PARALLÈLES → SKEPTIC → FUSION → VALIDATION HUMAINE

Cette compétence est explicitement invoquée avec :

/graphe <question ou workflow>

Quand l'utiliser

Utilisez /graphe lorsque l'utilisateur souhaite explicitement qu'une question, décision, investigation ou workflow conséquent soit décomposé en voies de preuves indépendantes, contesté par un sceptique séparé, et renvoyé à une porte de décision humaine. C'est particulièrement utile pour la validation de marché, les choix techniques, la conception opérationnelle et les décisions où des preuves faibles pourraient entraîner un travail gaspillé. Ne l'activez pas implicitement pour des questions ordinaires ; la commande oblique est la confirmation explicite.

Une invocation est une adhésion délibérée à un travail multi-agents. Ne la réduisez pas à une réponse ordinaire d'agent unique simplement parce que la question semble simple.

Principes de conception

• Définissez le résultat final avant de tracer les tâches.
• Traitez le graphe comme des tâches reliées par des flèches ; les flèches encodent les dépendances réelles, et les notes/résultats partagés sont l'état.
• Construisez le plus petit graphe qui améliore sensiblement la qualité. Plus d'agents peuvent créer un bruit redondant.
• Supprimez l'attente factice : les tâches indépendantes s'exécutent en parallèle ; les tâches dépendantes attendent.
• Séparez les travailleurs des vérificateurs. Les chercheurs ne notent pas leur propre travail.
• Arrêtez-vous lorsque la réponse est suffisamment bonne pour le critère de décision énoncé.
• Préservez l'état utile — plan, preuves, sources, verdicts du sceptique et décision — lorsque l'utilisateur demande une piste de vérification réutilisable ou que l'espace de travail a déjà une convention d'artefact de recherche.
• L'outil d'orchestration est secondaire par rapport au workflow. Pour un nouveau graphe récurrent, prouvez la forme manuellement avant d'ajouter un cadre plus lourd ou une automatisation externe.

Règles non négociables

1. La séquence est stricte. Ne fusionnez pas avant la fin du sceptique. N'exécutez pas la recommandation avant la validation humaine.
2. Les voies de recherche sont en lecture seule. Elles peuvent inspecter les sources, fichiers, systèmes et informations publiques, mais ne doivent pas publier, envoyer, acheter, supprimer, déployer, modifier la production ou contacter des personnes.
3. Les preuves sont au niveau des affirmations. Chaque affirmation factuelle matérielle nécessite une URL/chemin source, un type de source et un niveau de confiance. « Le sous-agent l'a dit » n'est pas une preuve.
4. Les sources primaires l'emportent. Privilégiez les documents officiels, les données de première main, le code source, les contrats, les preuves directes des clients ou les enregistrements originaux. Étiquetez les preuves secondaires et les inférences.
5. Le sceptique est une tâche séparée. Il attaque indépendamment les affirmations, vérifie les sources originales, trouve les contradictions et marque chaque affirmation keep (conserver), qualify (nuancer) ou reject (rejeter).
6. Seuls les survivants fusionnent. Les affirmations rejetées ne peuvent pas apparaître comme des faits dans la recommandation finale.
7. L'humain choisit la prochaine action. Utilisez l'outil clarify pour la validation. Ne choisissez jamais silencieusement ou ne commencez pas une option.
8. Pas de parallélisme factice. Utilisez un seul appel delegate_task(tasks=[...]) pour les voies indépendantes. N'effectuez pas d'appels séquentiels à enfant unique pour des voies parallèles.
9. Respectez la délégation asynchrone d'Hermes. Après avoir envoyé un lot, n'interrogez pas et ne réclamez pas la fin. Les résultats de recherche reviennent dans la conversation lorsque toutes les voies sont terminées ; puis lancez le sceptique.
10. Gardez la sortie à la taille d'une décision. La fusion est une recommandation d'une page, pas un vidage de chaque rapport de voie.

Étape 0 — Analyser l'invocation

Traitez le texte après /graphe comme la question. Des mots de mode facultatifs peuvent être fournis :

• fast : 2 voies, passage de preuves étroit.
• standard : 3 voies ; par défaut.
• deep : 3 voies avec une couverture source plus large et des lacunes de suivi explicites.

Si aucune question n'est fournie, demandez une clarification ouverte : « Quelle question ou workflow dois-je exécuter sous forme de graphe ? » Ne commencez pas la recherche sans cible.

Étape 1 — PLAN

L'agent parent est propriétaire de la planification. Avant de déléguer, produisez un plan de graphe compact avec :

• Décision/question — une phrase.
• Critère de sortie — ce qu'une réponse utile doit décider ou permettre.
• Contraintes — temps, marché, juridiction, budget, limites du dépôt/système et effets secondaires interdits.
• Voies — 2 ou 3 tâches de recherche orthogonales, chacune avec une question claire et un critère d'arrêt.
• Validation — indiquez que l'exécution attend le choix humain.

Choisissez les voies en fonction du domaine plutôt que de réutiliser aveuglément des étiquettes.

Modèles de voies par défaut

Pour les questions de marché/produit/entreprise, privilégiez :

1. Douleur client / comportement actuel — comment l'utilisateur cible gère le problème aujourd'hui ; preuves directes, solutions de contournement, urgence et volonté de changement.
2. Concurrents / alternatives / économie — qui résout déjà le problème, substituts, positionnement, tarification, coûts de changement et modes d'échec.
3. Distribution / exécution / contraintes — comment le public est réellement atteint, faisabilité opérationnelle, contraintes juridiques/sécurité et coût pour tester.

Pour la recherche générale ou les décisions techniques, privilégiez :

1. Vérité terrain / état actuel — faits primaires, exigences et comportement du système.
2. Alternatives / contre-preuves — approches concurrentes, preuves infirmantes et compromis.
3. Exécution / risque / vérification — chemin d'implémentation, dépendances, modes d'échec et comment tester en toute sécurité.

Pour les workflows d'implémentation, gardez toutes les voies en lecture seule jusqu'à la validation. Les agents parallèles peuvent inspecter différentes zones, mais ne doivent pas éditer le même checkout ou créer des effets secondaires externes.

Évitez les voies redondantes. Si deux voies devaient rechercher les mêmes sources pour les mêmes affirmations, reconcevez-les.

Étape 2 — RECHERCHE EN PARALLÈLE

Appelez delegate_task une fois avec un lot de 2 à 3 tâches feuilles. Donnez à chaque enfant la question complète, les contraintes partagées, sa mission de voie, le contrat de preuves ci-dessous et la langue de sortie requise.

Utilisez un output_schema permissif par tâche nécessitant uniquement les champs que le parent lira :

{
  "type": "object",
  "required": ["lane", "bottom_line", "claims", "gaps"],
  "properties": {
    "lane": {"type": "string"},
    "bottom_line": {"type": "string"},
    "claims": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["id", "claim", "evidence", "source", "locator", "source_type", "confidence"],
        "properties": {
          "id": {"type": "string"},
          "claim": {"type": "string"},
          "evidence": {"type": "string"},
          "source": {"type": "string"},
          "locator": {"type": "string"},
          "observed_or_published_at": {"type": "string"},
          "source_type": {"type": "string"},
          "confidence": {"type": "string"},
          "assumptions": {"type": "array"},
          "caveat": {"type": "string"}
        }
      }
    },
    "contradictions": {"type": "array"},
    "gaps": {"type": "array"},
    "candidate_next_moves": {"type": "array"}
  }
}

Contrat de preuves de voie

Chaque voie doit :

• Enquêter indépendamment ; ne pas coordonner avec les voies sœurs.
• Utiliser des sources actuelles et originales lorsque cela est accessible.
• Citer une URL, un chemin de fichier avec référence de ligne/page, ou un identifiant d'enregistrement direct pour chaque affirmation matérielle.
• Attribuer des identifiants d'affirmation stables et inclure une citation, une page, une ligne, une section, un horodatage ou tout autre localisateur lorsque disponible.
• Séparer le fait observé, l'affirmation rapportée, le calcul et l'inférence.
• Inclure les dates pour les preuves sensibles au temps.
• Rapporter les preuves contradictoires et les inconnues, ne pas les cacher.
• Si le contexte manque, signaler le blocage ou étiqueter clairement une hypothèse ; les enfants ne peuvent pas demander de clarification et ne doivent pas deviner.
• S'arrêter lorsque son critère d'arrêt énoncé est atteint ou lorsque des recherches supplémentaires ont des rendements fortement décroissants.
• N'apporter aucun changement externe.

Après que l'outil de répartition confirme que le lot est en cours d'exécution, indiquez brièvement quelles voies sont actives. Ne fabriquez pas leurs résultats et n'interrogez pas.

Étape 3 — SKEPTIC

Lorsque les résultats consolidés des voies reviennent dans la conversation, normalisez-les en une matrice d'affirmations/preuves indexée par identifiant d'affirmation stable, puis lancez une nouvelle tâche feuille delegate_task en tant que sceptique. Fournissez la question originale, les contraintes, la matrice normalisée et toutes les sorties des voies.

Le sceptique doit :

1. Attaquer d'abord les affirmations les plus critiques pour la décision.
2. Ouvrir/vérifier la source originale citée lorsque accessible ; une simple chaîne de citation est insuffisante.
3. Tester la qualité de la source, l'actualité, la pertinence, le biais d'échantillonnage, les sauts causaux, les hypothèses cachées, les calculs, la dépendance aux sources et la corroboration circulaire.
4. Rechercher spécifiquement les preuves infirmantes et les contradictions entre les voies.
5. Marquer chaque affirmation keep, qualify ou reject, donner une raison, et étiqueter le défaut fatal, material ou minor lorsque applicable.
6. Distinguer les erreurs factuelles des désaccords de préférence.
7. Identifier quelles preuves changeraient la décision et la plus petite vérification supplémentaire qui pourrait résoudre chaque objection matérielle.
8. Recommander au maximum trois prochaines actions à faible coût qui résolvent les plus grandes incertitudes.
9. N'effectuer aucun effet secondaire.

Utilisez un schéma de sortie nécessitant :

{
  "type": "object",
  "required": ["claim_verdicts", "contradictions", "decision_risks", "best_next_tests"],
  "properties": {
    "claim_verdicts": {"type": "array"},
    "contradictions": {"type": "array"},
    "decision_risks": {"type": "array"},
    "best_next_tests": {"type": "array"}
  }
}

Après avoir envoyé le sceptique, indiquez que l'attaque des preuves est en cours. Ne fusionnez pas tôt et n'interrogez pas.

Étape 4 — FUSION

Lorsque le résultat du sceptique revient, l'agent parent crée une recommandation d'une page en utilisant uniquement les affirmations keep et clairement nuancées qualify. Rouvrez toute source nécessaire pour résoudre une ambiguïté matérielle ; les résumés de sous-agents ne sont pas une preuve d'effets secondaires externes ou de l'état réel du système.

Utilisez cette structure exacte :

# Recommandation

**Décision :** <une phrase>
**Confiance :** <faible / moyenne / élevée, avec raison en une ligne>

## Pourquoi
- <affirmation survivante + citation>
- <affirmation survivante + citation>
- <affirmation survivante + citation>

## Ce qui n'a pas survécu
- <affirmation rejetée ou matériellement affaiblie + raison>

## Risques et inconnues clés
- <risque/inconnue>

## Meilleures prochaines actions
1. <plus petit test qui réduit la plus grande incertitude>
2. <deuxième option>
3. <troisième option, uniquement si utile>
4. Passer — ne rien faire maintenant

Limitez-vous à environ une page rendue. Liez ou citez les sources en ligne. Mettez le matériel détaillé des voies dans une annexe uniquement si l'utilisateur le demande.

Étape 5 — VALIDATION HUMAINE

Immédiatement après la fusion d'une page, appelez clarify en mode sélection unique avec au maximum quatre choix :

• Jusqu'à trois prochaines actions concrètes dérivées des preuves.
• Incluez toujours Passer — ne rien faire maintenant.

Placez chaque option uniquement dans le tableau choices ; ne dupliquez pas les choix dans la prose de la question. Demandez : « Quelle prochaine action souhaitez-vous autoriser ? »

N'exécutez aucune option jusqu'à ce que la sélection de l'utilisateur arrive. L'invocation /graphe elle-même n'est jamais une approbation pour un effet secondaire. Après la sélection :

• Reformulez la prochaine action sélectionnée et le périmètre analytique autorisé en une phrase.
• Si l'action devait envoyer un message, publier, acheter, modifier un compte, déployer, supprimer un fichier, muter une API ou provoquer un autre effet secondaire externe, présentez la cible/compte/espace de travail exact, la charge utile/commande/modification proposée, le coût prévu et l'audience, la réversibilité/plan de restauration, la stratégie de prévention des doublons, la méthode de vérification et les risques non résolus avant l'exécution ; obtenez toute approbation supplémentaire que les règles de sécurité ordinaires exigent.
• Exécutez uniquement l'action autorisée.
• Appliquez les règles de sécurité/approbation ordinaires pour les envois, achats, déploiements, actions destructrices, secrets ou modifications de production.
• Relisez ou récupérez l'objet résultant et ne signalez que les effets vérifiés indépendamment.

Comportement en cas d'échec et de repli

• Une voie échoue : Réessayez une fois uniquement si l'échec est transitoire. Sinon, continuez avec les voies restantes et baissez sensiblement la confiance.
• Sources inaccessibles : Signalez l'échec d'accès ; ne remplacez jamais les preuves manquantes par une prose plausible.
• Voies en conflit : Préservez le conflit à travers l'étape du sceptique. Ne faites pas la moyenne de revendications incompatibles.
• Délégation indisponible : Dites que le graphe multi-agents demandé ne peut pas être exécuté comme prévu. Proposez un repli d'agent unique clairement étiqueté ; ne le substituez pas silencieusement.
• La question change en cours d'exécution : Arrêtez l'ancien graphe, reformulez la décision révisée et réplanifiez. Ne greffez pas des résultats de voies non liés à la nouvelle question.
• Demande dangereuse ou interdite : Les règles de sécurité normales remplacent le graphe. Refusez ou réduisez la partie dangereuse tout en préservant l'analyse sécurisée.

Liste de contrôle qualité

Avant d'ouvrir la validation humaine, confirmez :

• Le parent a produit un plan explicite.
• 2 à 3 voies indépendantes ont été exécutées en un seul lot parallèle.
• Chaque affirmation matérielle a une preuve traçable.
• Un sceptique séparé a attaqué les preuves.
• Les affirmations rejetées ont été exclues de la recommandation.
• La fusion est concise et orientée décision.
• Aucun effet secondaire externe n'a eu lieu avant la validation.
• L'humain se voit offrir des choix concrets, y compris Passer.