Modes

Qu’est-ce qu’un mode ?

Un mode est une propriété d’un espace, stocké dans une seule colonne de la ligne de l’espace. Toutes les conversations d’un espace le partagent, y compris les fils — un fil hérite du mode de son espace comme n’importe quelle autre conversation. Le même agent peut donc se trouver dans des modes différents dans des espaces différents en même temps, et changer le mode d’un espace modifie ce qui se passe au tour suivant sans toucher à l’agent.

Il en existe exactement quatre : chat, review, plan, orchestrate. L’énumération elle-même ne porte aucune politique. Tout ce qu’un mode garantit est déclaré une seule fois, dans un profil de capacités, dont chaque couche d’application est dérivée :

1. Surface d’outils — les outils qui existent tout court dans ce mode, exprimés sous forme de palier d’approbation maximal, de liste d’autorisation, de liste de refus et d’un ensemble de classes d’effets refusées.
2. Verbe de sortie requis — ce que l’exécution doit appeler pour avoir livré quoi que ce soit.
3. Classes d’effets refusées — ce que le garde-fou des actions refuse d’emblée.
4. Posture de l’arbre de travail — si des écritures sont permises dans l’arbre de travail. Elle est appliquée en retirant les outils de mutation de la surface, ce qui la fait tenir sur tous les hôtes. Lorsque l’hôte dispose d’un bac à sable du système d’exploitation, la même posture découpe aussi les règles d’écriture du système de fichiers — un mode en lecture seule monte l’arbre de travail en lecture seule — mais il s’agit d’une deuxième copie de la garantie, pas de celle qui fait le travail.
5. Bloc d’invite système — un préambule de capacités généré à partir de la liste d’outils réellement matérialisée, plus des consignes rédigées à la main.

Chaque couche d’application dérive de ce seul profil, de sorte que la surface d’outils, le garde-fou, la posture de l’arbre de travail et l’invite ne peuvent pas se contredire.

Les quatre modes

Clavardage — affiché sous le nom “Agent”

Le mode par défaut et le seul sans contrainte supplémentaire : la surface d’outils complète jusqu’au palier d’exécution, un arbre de travail inscriptible, aucune classe d’effets refusée et aucun contrat d’achèvement. Utilisez-le pour l’implémentation, les corrections de bogues, les questions sur la base de code et tout ce qui est ponctuel.

Remarquez l’intitulé : dans le compositeur, le mode s’affiche sous le nom “Agent”, et non “Clavardage”.

Plan — lecture seule, un seul livrable

Le mode plan rend l’arbre de travail en lecture seule et retire complètement les outils d’écriture de la surface, de sorte que la restriction est structurelle plutôt qu’énoncée. L’agent lit, cherche et se documente, et livre exactement une chose : un appel submit_plan portant un graphe de dépendances typé — un objectif plus des nœuds avec des clés, des titres, des descriptions et les clés des nœuds dont chacun dépend.

Le plan s’affiche sous forme de ligne compacte dans la conversation et ouvre Plan Studio dans un onglet à côté. L’approuver compile le graphe en une orchestration, exécute le travail généré et fait repasser l’espace d’où vient le plan en mode agent.

Si une exécution en mode plan se termine sans jamais appeler submit_plan, la boucle injecte d’abord une relance indiquant que le plan n’existe pas tant que cet appel n’a pas réussi. La relance autorise explicitement une sortie honnête du type “aucun plan n’est nécessaire ici”, parce que le mode plan est un réglage d’espace et qu’une simple question posée dans cet espace ne devrait pas forcer un plan artificiel.

Un contrat non rempli n’est pas une exécution échouée

Une exécution qui se termine sans son plan est quand même consignée avec le statut completed — le processus s’est terminé proprement. La vérité repose sur la vitalité de l’exécution (empty), la famille d’erreurs (silentRun) et un résumé qui nomme ce qui n’a pas été produit. Voir Cycle de vie du lancement d’un agent.

Il existe une deuxième sortie, distincte : exit_plan_mode. C’est un contrôle d’approbation strict, pas un verbe de sortie — un agent qui l’appelle au lieu de submit_plan n’a rien livré. Le premier appel ouvre une approbation plan_exit durable et renvoie pending, et l’espace reste en lecture seule ; les appels répétés restent pending plutôt que d’ouvrir un second contrôle. Ce n’est qu’une fois l’approbation accordée qu’un appel ultérieur fait passer l’espace en clavardage. Un refus permet à l’agent d’ouvrir une nouvelle demande pour un plan révisé.

Pour quitter vous-même le mode plan, changez le menu déroulant du compositeur (ou Shift+Tab). exit_plan_mode se décide avec l’outil MCP decide_approval. Les lignes “approbation d’agent” de la boîte de réception sont autre chose : des demandes de confirmation par tour provenant d’un agent en cours d’exécution.

Révision — lecture seule, sans contrat

Le mode révision sert à réviser les demandes de tirage. Il rend l’arbre de travail en lecture seule, plafonne la surface d’outils sous le palier d’exécution et applique une liste d’autorisation restreinte d’outils de révision, de tickets et de communication. Un espace ouvert pour une demande de tirage est créé automatiquement en mode révision.

La sortie de l’agent est constituée de constats structurés — les nœuds de révision — et, lorsqu’une révision est finalisée, d’un verdict. Un nœud porte un type (bug, suggestion, recommendation, question ou ticket), une priorité allant de P0 (bloque la publication) à P3 (facultatif), un niveau de confiance autoévalué, une ancre facultative (un fichier et une plage de lignes ; les notes à l’échelle du dépôt n’en ont aucune) et un statut de cycle de vie qui passe de open à consensusReady dès qu’un pair — jamais l’auteur — le confirme. Un constat dont la priorité ou la confiance est absente ou hors limites est écarté à la frontière de lecture plutôt que de polluer le verdict.

Le verdict est ship, hold ou block, et les résultats par axe qui y sont intégrés ne peuvent que le rendre plus sévère : un axe verrouillé qui a échoué force block et un axe verrouillé qui n’a pas pu s’exécuter force au moins hold. L’absence de preuve ne fait jamais passer un verrou au vert.

Contrairement aux modes plan et orchestration, la révision ne comporte aucun contrat d’achèvement. Les constats s’accumulent par add_review_node et sont publiés par finalize_review, et les deux peuvent légitimement être appelés zéro fois — un agent de pipeline exécuté en mode révision peut être là pour mener un ticket à bien.

Orchestration — lecture seule, propose une équipe

Le mode orchestration transforme un objectif en un plan pour toute une équipe. Comme le mode plan, il est en lecture seule et ne peut pas écrire de fichiers ; par-dessus la surface de recherche, il dispose d’un seul verbe privilégié, propose_orchestration, qui émet une proposition structurée : des rôles, une arborescence de sous-tickets, une étape de synthèse et un budget. L’invite ne nomme que les outils présents sur la surface, de sorte que le modèle ne gaspille pas de tours à décrire des embauches ou du travail de tickets qu’il ne peut pas déclencher.

Rien dans la proposition ne s’exécute avant que vous l’approuviez. À l’approbation, un matérialiseur déterministe embauche les agents, crée les tickets et un projet et exécute un pipeline généré. L’approbation est réservée à l’opérateur : il n’existe aucun outil MCP pour cela, donc un agent peut proposer mais jamais approuver son propre plan. Les repropositions lancées par un agent sont limitées par un délai d’attente de deux minutes : les replanifications consécutives sont donc refusées et invitées à se regrouper. Voir Orchestration.

Deux règles à connaître

Le verbe de sortie d’un mode ne peut jamais être refusé. submit_plan et propose_orchestration sont épinglés dans la surface d’outils et préapprouvés sans passer par le filtre d’outils, le contrôle d’approbation et le garde-fou des actions, de sorte que le cadran d’autonomie propre à l’espace ne peut pas faire taire le livrable d’un mode. L’outil ask_user du harnais est épinglé pour la même raison : c’est ainsi qu’une exécution atteint l’opérateur, donc le verrouiller provoquerait un interblocage d’une exécution qui doit poser une question. Il est de palier lecture, donc chaque mode en lecture seule le conserve, et il est exempté de l’enveloppe d’approbation — une invite devant une autre invite échoue en mode fermé lorsqu’aucun approbateur n’est connecté, ce qui priverait un agent du simple fait de poser une question.

Les modes en lecture seule ne refusent ni l’accès réseau ni les secrets. Les classes d’effets que refusent les modes révision, plan et orchestration sont celles qui changent le monde : la suppression de fichiers, les écritures hors de l’arbre de travail, les commits, les push, la création et la publication de PR, les écritures de synchronisation des fournisseurs, l’installation de paquets, le lancement de processus, la mutation de l’espace de travail et le contrôle d’enceinte. La sortie réseau et l’accès aux secrets restent volontairement à leurs valeurs par défaut — la recherche est toute la raison d’être d’un mode en lecture seule.

Choisir et changer de mode

Le menu déroulant des modes du compositeur propose trois options : Agent (clavardage), Plan et Orchestrate. review n’est pas sélectionnable par l’utilisateur — il est défini par le système à la création d’un espace de révision de PR et par les étapes de pipeline.

Un nœud de pipeline qui ouvre un espace peut épingler le mode de ce salon au moyen d’une clé extras['mode'] (chat, review ou plan). La clé doit correspondre exactement : toute autre graphie — y compris orchestrate — est ignorée en silence et le salon reçoit la valeur par défaut du corps (review sur le corps de création d’espace). Une étape d’agent rejoint un salon qu’elle n’a pas créé et ne modifie pas ses permissions.

La résolution elle-même est simple. Le répartiteur lit la colonne mode de l’espace ; une répartition sans espace — une exécution ponctuelle, un appel de la CLI ou un id d’espace provenant d’un autre espace de travail, qui n’est tout simplement pas dans le fichier de base de données de cet espace de travail — est résolue vers chat. Changer le mode prend effet à partir du tour suivant.

Où la garantie tient réellement

La surface d’outils d’un mode est construite et appliquée par le harnais intégré. C’est le seul transport capable de rendre un outil invisible plutôt que simplement refusé, de contrôler chaque appel avant son exécution et d’observer un contrat d’achèvement.

Sur le transport Claude Code, un mode autre que le clavardage est passé sous la forme --permission-mode plan. Claude le respecte par convention ; ses propres outils de lecture, d’écriture et de modification s’exécutent sans être vus, et ses commandes shell ne sont vérifiées que par un hook qui lit la ligne de commande. Pour ce transport, le mode est une indication, non une frontière de Control Center — voir Le modèle d’agent.

Les listes d’autorisation contraignent les outils du palier d’écriture et des paliers supérieurs. Le palier lecture du harnais intégré atteint encore des outils qu’aucune liste ne nomme ; sur Claude Code, un outil que la liste d’autorisation omet est refusé, que le serveur le propose ou non.

Voir aussi

• Cycle de vie du lancement d’un agent : où le mode est résolu et projeté
• Le modèle d’agent : quels transports peuvent appliquer un mode
• Garde-fous : la politique de classes d’effets dans laquelle s’insère le préréglage d’un mode
• Orchestration : ce que fait une proposition d’orchestration approuvée
• Utiliser le mode plan : le guide pratique