Dialogue (conversations)

Ce que c'est

Des conversations stratégiques et multi-tours avec le modèle, qui servent aussi de principal point d'entrée pour transformer une idée en travail approuvé. Une conversation peut lire l'état vivant du système et, quand vous lui demandez d'agir, soit proposer un travail à votre approbation, soit — lorsque le tier d'écriture est activé — accomplir une action bornée.

Surface opérateur

  • conversation_create, conversation_send, conversation_list, conversation_get, conversation_complete — le cycle de vie de la conversation. Chaque conversation est étiquetée avec un Track (Governance / Research / Planning / Build) pour le contexte.
  • conversation_branch — bifurque une conversation pour explorer une alternative.
  • mission_propose — le pont actuel vers l'exécution. Sur un tour où vous demandez une fonctionnalité ou un changement, le modèle appelle cet outil (au lieu de décrire le travail en prose) pour lever une demande d'approbation. Il crée un draft de workflow non publié plus une unique demande d'attention d'approbation qui atterrit dans la file des Decisions — aucune Mission vivante ni workflow publié. Vous examinez et approuvez — et l'approbation crée alors la Mission automatiquement (voir plus bas).
  • dialogue_propose_mission — le pont plus ancien et plus simple, toujours présent : il crée directement une Mission pending (en attente), reliée à la conversation, que vous approuvez. Aucun draft de workflow n'y est attaché.
  • dialogue_check_mission, dialogue_get_mission_results — suivent une proposition et rapatrient les résultats de tasks d'une Mission terminée dans la conversation pour en synthétiser une réponse.

DialogueController et ConversationExportController sous-tendent la surface de chat REST / dashboard.

Comment ça marche

Les conversations sont stockées sous forme de lignes Conversation + ConversationMessage, étiquetées avec leur Track. Les appels au modèle effectués pendant une conversation transitent par la couche LLM sous leur propre Call site de dialogue (p. ex. Dialogue:GeneralDialogue, Dialogue:MissionAssistant) et sont attribués en coût à la conversation. Tout ce que le modèle crée porte l'id de la conversation d'origine (OriginConversationId), de sorte qu'une proposition ou une Mission reste toujours traçable jusqu'au Dialogue qui l'a engendrée. Le dialogue peut s'exécuter contre un provider de modèle direct in-process ou un sidecar, selon le preset et le backend résolus.

Ce que le modèle a le droit de faire (tiers d'outils)

Les outils qu'une conversation peut appeler sont hiérarchisés en tiers selon leur pouvoir de modification. Par défaut, Core les sert in-process (aucun processus Bridge distinct requis) :

  • Tier lecture — toujours disponible. Les outils de status, de liste et de get (missions, tasks, decisions, coûts, pipelines, …) s'exécutent directement. Quelques outils au nom en read qui, à l'exécution, se déploient en appels d'expert ou de modèle — et coûtent donc de l'argent — sont retenus jusqu'à ce qu'un opérateur les active.
  • Tier act / écriture — désactivé par défaut, doublement gaté. Un allowlist organisé d'outils de création/mise à jour (mission_create, task_create, decision_create, mission_add_task, …) n'est servi que lorsqu'un interrupteur au niveau du déploiement (Dialogue:InProcessTools:WriteEnabled) l'admet. Même alors, un outil ne s'exécute que si le tenant a activé les outils d'écriture (une bascule sur l'écran de réglages Fonctionnalités — le message de refus vous y renvoie) et que vous avez explicitement demandé l'action (une intention execution-command) ou qu'un grant de session vivant l'autorise. Sur un tour de feature-request ordinaire, il ne s'exécute pas — le modèle expose l'action proposée et une suggestion est enregistrée à la place. Les verbes de disposition (*_approve / *_reject / *_respond / *_promote) sont exclus purement et simplement, de sorte qu'une conversation ne peut jamais approuver ni résoudre un artefact gaté par un humain — y compris ses propres propositions.
  • Tier propose — mission_propose. Servi sous le même interrupteur de déploiement que le tier d'écriture : sur un déploiement où les outils d'écriture sont éteints, vous ne le verrez pas du tout. Ce que proposer contourne, c'est le gating d'exécution : proposer ne mute rien directement (cela ne fait que lever une demande d'approbation), donc ni la bascule par tenant ni le contrôle d'intention explicite ne s'y appliquent — même un tour de feature-request ordinaire a le droit de proposer. Le système propose ; l'humain dispose.

Ce qu'approuver une proposition fait — et ne fait pas

La proposition atterrit dans la file des Decisions en portant la spec de Mission proposée et une poignée vers le draft de workflow non publié, avec trois options : Approve and create, Request changes, Reject. Choisissez Approve and create et la Mission est créée pour vous : un handler de résolution guette l'approbation et matérialise la Mission par le même chemin que celui qu'emprunte mission_create — aucune ressaisie manuelle, et exactement une Mission par proposition même si l'approbation se déclenche deux fois.

Ce que l'approbation ne fait délibérément pas, c'est publier (ou attacher) le draft de workflow. Si le modèle n'a pas pu esquisser de plan d'exécution, le draft est un graphe placeholder qui échouerait à la validation de publication — le draft reste donc un draft, que vous examinez, complétez et publiez vous-même. En bref : approuver crée la Mission automatiquement ; publier le workflow reste votre acte délibéré.

Si une feature-request n'atteint jamais une proposition formelle, la conversation enregistre tout de même une suggestion (une ligne MissionSuggestionRecord) reliée à la conversation, afin que l'idée soit capturée pour une revue ultérieure plutôt que perdue.