La mission de nuit : une file de tickets, une équipe, un rapport au réveil

Une mission de nuit, c’est une mission d’orchestrateur ordinaire avec trois différences : les tâches viennent d’une liste de tickets, l’équipe les enchaîne sans toi, et un rapport résume la nuit à ton retour. Personne ne surveille pendant ce temps, donc les choix que tu fais avant de partir comptent plus que d’habitude.

Cet article suppose que tu connais déjà l’orchestrateur : le plan, une branche et un worktree par agent, la branche de mission openvibe/<mission>. Si ce n’est pas le cas, lis d’abord l’article sur l’orchestration.

Lancer la mission

Relie un orchestrateur à un groupe, comme pour une mission ordinaire, puis ouvre Mission de nuit… dans le panneau de la mission. La fenêtre demande :

Champ	Ce qu’il règle
Temps d’absence	En heures : 8 par défaut, 72 au plus. Il devient le budget global de la mission, en temps réel
Agents	Le nombre d’agents de l’équipe, 8 au plus
Source des tickets	Issues GitHub portant un label, ou `BACKLOG.md`
Autorisations des agents	Demander, Fichiers (par défaut) ou Fichiers et commandes
Lancer sans attendre mon feu vert	Décoché par défaut : le plan attend ton clic

Avant d’accepter, OpenVibe vérifie que le dossier du projet est un dépôt git et, pour une source GitHub, que gh répond. Si l’usage de ton forfait Claude atteint 80 %, il te prévient que la nuit pourrait s’arrêter sur la limite ; c’est un avertissement, pas un refus. Préparer la nuit transmet le tout à l’orchestrateur.

L’orchestrateur lit alors les tickets, garde ce qui tient dans le temps imparti avec le nombre d’agents choisi, met le reste en file et propose son plan. Par défaut, ce plan attend ton feu vert : clique Lancer la mission avant de partir, sinon rien ne démarre.

D’où viennent les tickets

Les issues GitHub. OpenVibe les lit avec gh, qui doit être installé et connecté (gh auth login). Seules les issues qui portent le label choisi sont lues, overnight par défaut. La raison : n’importe qui peut ouvrir une issue sur un dépôt public, alors que poser un label demande des droits.

BACKLOG.md. Le fichier doit être à la racine du projet. Chaque puce de premier niveau devient un ticket, avec le titre de la section où elle se trouve ; une case cochée compte comme faite et n’est pas lue.

## Interface

- Ajouter un état vide à la liste des commandes
- [ ] Traduire les messages d'erreur du formulaire
- [x] Corriger le contraste du bouton principal

## API

- Paginer la route /orders

Ici, l’orchestrateur reçoit trois tickets : la puce cochée est ignorée.

Dans les deux cas, le texte d’un ticket est traité comme une donnée, jamais comme une consigne. L’orchestrateur et les agents sont prévenus qu’un ticket peut venir d’un inconnu, et qu’ils ne doivent faire que le travail décrit. Kanban n’est pas encore une source pour la mission de nuit.

Comment la file avance

Une fois l’équipe formée, chaque agent prend une tâche sur sa propre branche, dans son worktree. Quand il rend compte « terminé », OpenVibe fusionne sa branche dans la branche de mission, puis lui donne la tâche suivante de la file, dans une nouvelle conversation : le contexte d’une tâche ne déborde pas sur la suivante. L’agent garde son worktree et commence par y fusionner la branche de mission, pour partir du travail déjà fait.

Quelques règles complètent le tableau :

Une tâche peut être réservée à un groupe : seul un agent de ce groupe la prendra.
Un agent qui rend compte « bloqué » ou « échec » ne repart pas tout seul : l’orchestrateur décide (tâche suivante, réattribution ou fin).
Si la fusion d’une branche se heurte à un conflit, elle est annulée et signalée, et l’agent ne prend pas de nouvelle tâche tant que sa branche n’est pas fusionnée.
La nuit, le budget d’une sous-tâche est une cible : l’orchestrateur est prévenu quand un agent la dépasse et regarde où il en est, mais aucune notification ne t’est envoyée.
Sur la fin du temps d’absence (10 % de la durée, 10 minutes au moins), la file ne donne plus de tâche : l’orchestrateur fusionne ce qui est fait, le fait vérifier, puis termine.

Permissions : à lire avant de choisir

Trois réglages, du plus fermé au plus ouvert. Ils ne valent que pour les sessions de la mission : tes propres réglages de Claude Code ne sont pas modifiés.

Réglage	Ce que font les agents	Ce que ça donne la nuit
Demander	Comme d’habitude : chaque dialogue d’autorisation attend une réponse	Chaque dialogue arrête l’agent jusqu’à ton retour
Fichiers (par défaut)	Modifient les fichiers sans demander	Un agent s’arrête à sa première commande, jusqu’à ton retour
Fichiers et commandes	Lancent n’importe quelle commande sans demander	Le réseau et les comptes connectés sur ce PC leur sont ouverts

Trois points à garder en tête :

Par défaut, le plan attend ton feu vert et les agents ont Fichiers. Ils modifient les fichiers sans demander et s’arrêtent à leur première commande jusqu’à ton retour. C’est le choix le plus prudent, et il limite ce qu’une nuit peut faire : une tâche qui demande de lancer les tests s’arrêtera là, et le rapport la montrera comme pas finie.

Fichiers et commandes est un choix explicite. Les agents lancent n’importe quelle commande sans demander : le réseau et les comptes connectés sur ce PC leur sont ouverts. Utilise un dépôt que tu peux te permettre de perdre.

Le blocage du push n’est pas une frontière de sécurité. git push et les commandes gh qui atteignent le dépôt distant sont refusés par des règles sur le texte de la commande et par un réglage git du terminal. Ils arrêtent les accidents. Un agent qui lance des commandes peut les contourner : une relecture l’a fait avec -c remote.origin.pushurl et GIT_CONFIG_COUNT=0. Si ça compte pour toi, reste sur Fichiers, ou utilise un dépôt et des comptes que tu peux te permettre d’exposer.

Le rapport du matin

À ton retour, le rapport s’affiche dans le panneau de la mission. Il apparaît quand la mission est terminée, ou quand le temps d’absence est écoulé, même si l’orchestrateur s’est arrêté en route. Il donne :

le temps passé, rapporté au temps d’absence prévu ;
ce qu’il faut vérifier à la main, signalé par les agents et par l’orchestrateur, en tête du rapport ;
ce qui est fait, tâche par tâche, avec l’agent, le temps passé face au budget, la branche, le résumé et la mention « fusionné » quand c’est le cas ;
ce qui a échoué ou est bloqué ;
ce qui n’est pas fini, les tâches encore en cours à la fin ;
ce qui est resté dans la file, les tâches qu’aucun agent n’a prises.

Le travail fusionné est sur la branche de mission. Relis-le, puis fusionne-le toi-même dans ta branche : la mission ne le fait jamais, et ne pousse jamais.

Le PC pendant la nuit

Tant que la mission tourne, OpenVibe empêche Windows de se mettre en veille de lui-même. Ce maintien est relâché quand la mission se termine, ou 30 minutes après la fin du temps d’absence si personne ne l’a close.

Deux choses l’endorment quand même : fermer le capot, et demander la mise en veille. Un portable qu’on referme avant d’aller dormir arrête donc la nuit. L’écran, lui, peut s’éteindre : seul le système est maintenu éveillé.

Enfin, OpenVibe doit rester ouvert. Les agents ne survivent pas à sa fenêtre : le fermer les arrête.

Avant de partir

Le projet est un dépôt git avec au moins un commit.
Pour GitHub : gh est installé et connecté, et les issues voulues portent le label.
Pour BACKLOG.md : le fichier est à la racine, et ce qui est fait est coché.
Les autorisations sont un choix réfléchi ; Fichiers et commandes seulement sur un dépôt que tu peux te permettre de perdre.
Le plan est validé (Lancer la mission), ou Lancer sans attendre mon feu vert est coché.
L’usage de ton forfait Claude laisse de la marge pour la nuit.
Le PC est branché, le capot reste ouvert, et rien ne va demander la mise en veille.
OpenVibe reste ouvert.