Création de sessions et collaboration dans Git

Deux fonctionnalités complémentaires : la délégation de sous-tâches à des sessions enfants indépendantes (éventuellement dans des worktrees Git isolés) et une fusion graphique qui réunit les branches parallèles. Ensemble, elles permettent à plusieurs agents de travailler en parallèle sur le même dépôt.

1. Principe de la création de sessions

Depuis n’importe quelle session, vous pouvez confier une sous-tâche à une autre session. VelaTerm crée une nouvelle session enfant sous le nœud actuel (l’arborescence devient hiérarchique : parent → enfant → petit-enfant), lui attribue éventuellement un worktree Git isolé et envoie la description de la tâche comme premier message de la nouvelle session. Le nouvel agent commence à travailler dès son lancement, sans autre explication.

Le résultat est une véritable session de l’arborescence, dotée de son propre processus, que vous pouvez suivre, à laquelle vous pouvez répondre, et que vous pouvez rouvrir et reprendre à tout moment. Il ne s’agit pas d’une tâche cachée en arrière-plan.

Pour un travail qui doit être planifié, réalisé et validé par des agents distincts, utilisez plutôt un flux de travail de planification et d’exécution ; voir Planification et exécution.

2. Méthodes de création

Les deux commandes sont disponibles dans toutes les sessions démarrées par VelaTerm. Les compétences d’agent nécessitent les Vela Skills : choisissez « Install » dans Paramètres ▸ Général, puis démarrez une nouvelle conversation Claude Code ou Codex pour que l’agent les prenne en compte. Les agents n’appellent ces compétences que lorsque vous le leur demandez.

Une nouvelle session ne voit pas la conversation dont elle est issue. Lorsque vous utilisez la compétence, l’agent inscrit dans la tâche l’objectif, les fichiers pertinents, les conclusions obtenues jusque-là, les contraintes et les critères de validation. Lorsque vous exécutez vous-même la commande, incluez ces éléments dans le texte de la tâche.

3. Répertoire, agent et modèle

• Répertoire. La session enfant démarre dans le répertoire où la commande est exécutée, qui est aussi le dépôt utilisé pour un worktree. Passez --cwd <path> pour utiliser un autre projet, par exemple vspawn-tree --cwd /work/project "fix the parser". Cette option est utile dans une collection, qui ne possède pas de dossier de projet propre. Les compétences ajoutent --cwd lorsque la conversation désigne clairement un dépôt.
• Agent. La session enfant utilise le même agent que la session actuelle ; depuis un terminal classique, c’est Claude Code qui est lancé. --claude, --codex, --copilot ou --kiro permettent de choisir un autre agent, et la carte de confirmation propose tous les types d’agent.
• Modèle et effort. --model <name> et --effort <level> définissent le modèle et l’effort de raisonnement de la session enfant, par exemple vspawn --model opus --effort high "port the parser". Les noms de modèle sont ceux de l’agent qui s’exécutera. Un réglage que l’agent ne prend pas en charge est refusé avant la création de la session. Sans ces options, une session enfant du même type d’agent hérite des arguments de lancement et du réglage d’autorisations de la session parente ; une session enfant d’un autre type utilise les valeurs par défaut de cet agent définies dans Paramètres ▸ Agents.
• Vue. Une session enfant compatible avec la vue conversation s’ouvre dans la même vue que sa session parente si celle-ci est également compatible, et sinon dans la vue par défaut de l’agent.

Toutes les options sont décrites dans Commandes de session, §3.

4. Confirmation avant le lancement

Par défaut, chaque demande de création affiche d’abord une carte de confirmation intitulée « Démarrer une session enfant ». La carte ne retire pas le focus de la session dans laquelle vous travaillez, et une notification système (« Session enfant en attente de confirmation ») vous signale qu’elle attend votre réponse.

• La carte indique la session à l’origine de la demande et son répertoire (« Session à l’origine de la demande »), les « Instructions de la tâche », qui deviennent le premier message de la session enfant, les « Paramètres d’exécution » (« Type de session », « Modèle », « Effort de raisonnement ») et le choix du « Dossier de travail » : « Dossier actuel » ou « Worktree distinct ».
• Les suggestions de modèles proviennent de l’agent sélectionné. Si aucune liste n’est disponible, vous pouvez saisir un identifiant de modèle. Si vous laissez un champ sur « Valeur par défaut de l’agent », le réglage propre à l’agent s’applique.
• Un terminal classique s’ouvre dans le répertoire de travail ; il n’exécute pas les instructions de la tâche.
• « Démarrer la session » (ou ⌘Entrée / Ctrl+Entrée) démarre la session enfant ; « Annuler » rejette la demande. Les demandes suivantes attendent dans une file, et la carte indique combien il en reste (« N autres demandes à examiner »).

Pour démarrer les demandes sans passer par la carte, désactivez « Confirm before spawn » dans Paramètres ▸ Comportement, ou ajoutez --yes à une commande donnée.

5. Worktrees : travailler en parallèle sans conflit

Avec un worktree, la session enfant travaille sur une nouvelle branche dans son propre répertoire, isolée de l’espace de travail principal et des autres sessions enfants. C’est la configuration recommandée lorsque plusieurs agents modifient simultanément le même dépôt. Les nouveaux worktrees partent du commit actuel et n’incluent pas les modifications non validées. Si aucun worktree ne peut être créé pour une session lancée de cette façon, la session utilise le répertoire d’origine.

Une session qui travaille dans un worktree affiche un petit badge sur son icône dans la barre latérale ; survolez-le pour afficher le nom et le chemin du worktree.

Autres façons de travailler avec les worktrees :

• « Nouvelle session worktree… », dans le menu d’un projet, d’un groupe ou d’une session, ouvre la boîte de dialogue de création avec l’option « Worktree » réglée sur « Nouveau ». Saisissez un « Nom du worktree », qui sert de nom au répertoire et à la branche. La boîte de dialogue permet aussi de rattacher la session à un worktree « Existant », ou de choisir « Aucun ».
• « Déplacer vers un worktree… », dans le menu d’un groupe, associe le groupe à un worktree nouveau ou existant. Les sessions créées ensuite dans le groupe utilisent ce worktree ; celles qui s’y trouvent déjà conservent leur répertoire. Un groupe associé à un worktree propose aussi « Infos du groupe ».

Le sous-menu Git d’une session ou d’un groupe dont le répertoire est un dépôt Git contient les éléments suivants :

Après la suppression d’un worktree associé, le menu de la session ou du groupe propose « Convert to normal session » ou « Convert to normal group », qui supprime l’association : la session démarre de nouveau dans le répertoire du projet.

Lorsque vous supprimez une session dont la sous-arborescence contient des worktrees, la confirmation propose de supprimer également ces worktrees.

6. Merge : fusion Git graphique

Une fois le travail terminé, fusionnez-le. Pour toute session ou tout groupe dont le répertoire est un dépôt Git, avec ou sans worktree, choisissez « Git ▸ Merge… » pour ouvrir la boîte de dialogue « Merge branches » :

• Choisissez les deux branches. Sélectionnez une « Source branch » et une « Target branch » ; « Swap direction » les intervertit. La même boîte de dialogue permet de fusionner la branche d’une session enfant dans la branche principale, ou d’intégrer la branche principale dans une session enfant pour la mettre à jour.
• La boîte de dialogue répertorie, avant votre confirmation, les modifications que la fusion apporte à la branche cible.
• La fusion s’exécute dans l’arbre de travail où la branche cible est extraite. Si la branche cible n’est extraite nulle part, la fusion ne peut pas avoir lieu ; extrayez-la d’abord.
• Si l’arbre de travail de la branche source contient des modifications non validées, celles-ci sont d’abord validées avec le message que vous saisissez (« Commit & merge »).
• En cas de conflits, VelaTerm les laisse en place et vous indique où les résoudre. Résolvez-les dans le terminal de ce worktree (ou demandez-le à un agent), puis validez.

La fusion ne supprime pas le worktree. Supprimez-le ensuite avec « Git ▸ Delete worktree… » lorsque vous n’en avez plus besoin.

7. Exemple de déroulement

1. Dans la session principale, discutez de la tâche avec Claude Code, puis exécutez /vspawn-tree refactor the checkout module (nécessite les Vela Skills).
2. Vérifiez la tâche sur la carte de confirmation et choisissez « Démarrer la session ». La session enfant démarre dans son propre worktree et apparaît dans la barre latérale sous sa session parente, avec un point d’état vert pendant qu’elle travaille.
3. Poursuivez votre travail dans la session principale. Lorsque la session enfant pose une question ou termine, son point change de couleur et une notification s’affiche.
4. Examinez le travail de la session enfant, puis choisissez « Git ▸ Merge… » pour fusionner sa branche dans la branche principale.
5. Supprimez le worktree avec « Git ▸ Delete worktree… », puis archivez la session enfant pour en garder une trace.