Planification et exécution

Un flux de travail de planification et d’exécution répartit un travail entre deux rôles : une session de planification, qui prépare et valide le travail, et une ou plusieurs sessions d’exécution, qui le réalisent. Ce chapitre explique comment démarrer un flux de travail depuis le menu ou depuis une session, valider un découpage en tâches, choisir les répertoires de travail et suivre l’avancement du flux de travail.

1. Déroulement du flux de travail

Un flux de travail comporte deux rôles, chacun exécuté dans sa propre session de la barre latérale :

• Planification et validation. La session de planification étudie la tâche et le projet, rédige la mission de la session d’exécution et examine chaque résultat. Elle demande des corrections jusqu’à ce que le résultat soit acceptable, et ne l’accepte qu’après avoir vérifié les modifications effectives et les preuves de vérification.
• Exécution. La session d’exécution réalise la mission et rend compte de son travail. Les corrections sont adressées à la même session d’exécution, qui conserve son contexte d’un cycle à l’autre.

La session d’exécution apparaît comme enfant de la session de planification dans la barre latérale. Les deux sessions s’exécutent dans la vue conversation. Les messages que les rôles s’échangent indiquent l’icône de l’agent expéditeur, le nom de la session et le rôle (« Planification » ou « Exécution ») ; vous pouvez ainsi suivre l’échange dans l’une ou l’autre conversation.

Les deux rôles nécessitent un agent compatible avec la vue conversation : Claude Code, Codex, OpenCode, Pi ou OMP. Les sessions de planification et d’exécution peuvent utiliser des agents, des modèles et des efforts de raisonnement différents.

Vous pouvez à tout moment consulter l’une ou l’autre session, y répondre ou l’interrompre. Les demandes d’autorisation de chaque rôle attendent toujours votre réponse.

2. Démarrer depuis le menu

Ouvrez le menu contextuel d’un projet, d’un groupe ou d’une session, ou son sous-menu « Nouvelle session enfant », puis choisissez « Nouvelle session planification/exécution… ». La boîte de dialogue comprend les éléments suivants :

• « Créer dans » : l’emplacement où la session de planification sera créée. La session d’exécution est créée sous la session de planification.
• « Instructions de la tâche » : décrivez la tâche, les exigences et les critères de validation. Vous pouvez coller des images ; elles sont envoyées avec la tâche de la session de planification et avec la première mission de la session d’exécution.
• « Diviser automatiquement en plusieurs tâches » : voir le §4.
• « Planification et validation » et « Exécution » : l’agent (« Type de session »), le « Modèle » et l’« Effort de raisonnement » de chaque rôle. Les choix de modèle et d’effort proviennent de l’agent sélectionné. La boîte de dialogue mémorise vos derniers choix pour chaque rôle.
• « Chemin du dossier de travail » et le choix du répertoire : voir le §5.

Choisissez « Créer et démarrer » pour démarrer la session de planification. Celle-ci crée la session d’exécution lorsque le plan est prêt. L’ouverture ou l’annulation de la boîte de dialogue ne crée rien. La boîte de dialogue dispose de sa propre adresse : vous pouvez copier le lien, actualiser la page ou utiliser les boutons Précédent et Suivant du navigateur sans la perdre.

3. Démarrer depuis une session

Dans n’importe quelle session démarrée par VelaTerm, exécutez :

vspawn --plan-execute \
  --plan-agent claude --plan-model opus --plan-effort high \
  --exec-agent codex --exec-model gpt-5.5 --exec-effort medium \
  "Implement the agreed changes and verify all acceptance criteria"

Dans Claude Code, /vspawn --plan-execute <task> produit le même résultat ; dans Codex, utilisez $vspawn --plan-execute <task>. La compétence rédige une tâche autonome à partir de la conversation en cours avant de démarrer le flux de travail. Ces compétences nécessitent les Vela Skills (Paramètres ▸ Général).

La nouvelle session de planification est créée sous la session qui a exécuté la commande. La demande ouvre d’abord la carte de confirmation décrite dans Création de sessions et collaboration dans Git, §4, où vous pouvez vérifier et modifier la tâche ainsi que les réglages des deux rôles.

Sans agent explicite, une session de planification démarrée depuis une session Claude, Codex, OpenCode, Pi ou OMP utilise le même agent ; depuis toute autre session, elle utilise Claude Code. Un modèle ou un effort que l’agent sélectionné ne prend pas en charge est refusé avant tout démarrage.

Les nouvelles sessions ne voient pas la conversation d’origine. Incluez dans la tâche les décisions prises jusque-là, les modifications existantes, les contraintes et l’emplacement de livraison attendu.

4. Découper le travail en plusieurs tâches

Activez « Diviser automatiquement en plusieurs tâches » dans la boîte de dialogue, ou ajoutez --split-tasks à vspawn --plan-execute. La session de planification analyse alors le travail et propose de 1 à 12 tâches indépendantes. Aucune session d’exécution ne démarre tant que vous ne les avez pas confirmées.

La proposition ouvre la boîte de dialogue « Vérifier les tâches à exécuter » :

• Sélectionnez une tâche dans la liste pour modifier son « Nom de la session », ses « Instructions de la tâche », son agent, son « Modèle » et son « Effort de raisonnement ». Vos modifications sont conservées lorsque vous passez d’une tâche à l’autre.
• « Retirer la tâche » supprime une tâche ; « Annuler le retrait » la rétablit. Au moins une tâche doit subsister.
• Le bouton de démarrage (« Démarrer N sessions ») crée une session d’exécution par tâche.
• La fermeture de la boîte de dialogue laisse la proposition en attente. Un lien « Vérifier les tâches à exécuter » reste alors affiché pour la rouvrir. L’annulation de la proposition arrête le flux de travail sans créer de session d’exécution.
• La boîte de dialogue dispose de sa propre adresse et reste disponible après une actualisation de la page ; les modifications qui n’ont pas encore été confirmées sont toutefois perdues lors de l’actualisation.

Lorsque la compétence est utilisée avec le découpage en tâches, elle ajoute --yes afin que seule cette validation finale s’affiche. Cette validation permet de modifier les réglages de chaque session d’exécution, mais pas ceux de la session de planification, qui est déjà en cours d’exécution.

Une seule session de planification reçoit les rapports de toutes les sessions d’exécution et examine chaque tâche séparément, avec ses propres cycles de correction. Le flux de travail n’est terminé que lorsque toutes les tâches ont été acceptées.

Découpez le travail en tâches qui ne modifient pas les mêmes fichiers. Chaque session d’exécution fait tourner son propre processus d’agent : choisissez donc le nombre de tâches en tenant compte des ressources de la machine.

5. Répertoires de travail et worktrees

Le choix du répertoire s’applique à tous les rôles du flux de travail :

Les nouveaux worktrees partent du commit actuel et n’incluent pas les modifications non validées. Si un worktree ne peut pas être créé, la session concernée ne démarre pas ; elle ne se replie pas sur un autre répertoire. En ligne de commande, --worktree seul équivaut à shared.

Les résultats restent dans les worktrees jusqu’à ce que vous les fusionniez. Utilisez « Git ▸ Merge… » sur une session pour fusionner une branche (voir Création de sessions et collaboration dans Git, §6). Le flux de travail ne fusionne pas, ne pousse pas et ne supprime pas les worktrees de lui-même.

6. Suivre l’avancement

• La conversation de planification affiche chaque rapport et chaque correction au fur et à mesure. Pendant que les sessions d’exécution travaillent, la session de planification attend leurs rapports.
• vflow status <workflow-id> affiche l’état d’un flux de travail, ses tâches, ses sessions et le cycle en cours. L’identifiant du flux de travail figure dans les messages du flux.
• vflow stop <workflow-id> empêche les cycles suivants et demande aux sessions en cours d’exécution de s’arrêter. L’arrêt de l’ensemble du flux de travail arrête ses tâches ; l’arrêt d’une tâche n’affecte pas les autres.
• vstat indique quelles sessions travaillent, demandent une autorisation ou sont en attente. Une session d’exécution en attente n’a pas nécessairement terminé sa tâche ; seule l’acceptation par la session de planification fait foi.
• Si un rôle termine son tour sans transmettre le travail, le flux de travail est bloqué. Consultez la conversation, apportez les réponses nécessaires, puis poursuivez depuis la session de planification.

Les commandes sont décrites dans Commandes de session.