Que fait Exécution autonome ?
Ce mode correspond à « voici le plan, exécute-le » : implémente-le de bout en bout sans que personne ne soit au clavier, et sois révisable quand l'humain revient. Il n'est pas lié à un moment de la journée. Il s'applique à toute période où personne n'est là pour répondre à une question.
Il présuppose un plan approuvé
Ce mode ne dispense pas de la règle « proposer avant de construire » (voir coding-process). Il s'agit de ce qui se passe après l'approbation. À l'intérieur du plan approuvé, décide toi-même des détails d'implémentation réversibles et écris chaque hypothèse. Une hypothèse documentée vaut mieux qu'une session qui a attendu toute la nuit. C'est l'entièreté de la dérogation.
Quatre vérifications que tu ne franchis jamais seul
Elles restent des vérifications même quand l'étape est réversible. Aucune d'elles n'est une question de jugement.
- Périmètre. Tout ce que le plan approuvé ne couvre pas déjà : une nouvelle fonctionnalité, une refactorisation que personne n'a demandée, ou le fait d'abandonner une étape parce qu'elle s'est avérée difficile. Mettre en place un harnais de test manquant compte comme du périmètre.
- Tout ce qui quitte la machine : messages externes, publications, ou appels à un service tiers. Le travail dans le dépôt (branches, commits, pushes, PRs) fait partie du plan ; parler au monde extérieur, non.
- Tout ce qui dépense de l'argent : APIs payantes, infrastructure provisionnée, tout ce qui est facturé.
- Tout ce qui est destructeur ou irréversible : perte de données, force-pushes vers des branches partagées, production.
Maintenir le travail durable
- Isoler d'abord. Utilise un worktree sauf si le harnais t'en a déjà fourni un. Une exécution autonome est exactement le moment où quelqu'un d'autre peut toucher au checkout principal.
- Commit et push après chaque unité logique, pas seulement à la fin. Un travail non poussé est perdu si la session se termine brusquement. Dans ce mode, cela remplace la règle habituelle « demander avant de commiter ».
- Ne jamais entrer en pause avec du travail non commité. Si ton agent expose des limites d'utilisation, mets en pause près de la limite, attends la réinitialisation, puis reprends.
- Exécute les vérifications complètes aux points de contrôle, pas après chaque édition. En cours d'édition, exécute la vérification la plus étroite qui détecterait ce que tu viens de changer : la vérification de type d'un package, ou un fichier de test unique. Exécute la construction, le lint, la suite de tests complète et la vérification équivalente à CI une fois qu'une unité de travail est terminée et avant qu'elle ne soit poussée pour révision. Ré-exécuter une suite qui a réussi il y a dix minutes, sur du code que tu n'as pas touché, dépense du calcul pour n'apprendre rien.
Délégation (si ton agent peut engendrer des sous-agents)
- Délègue le travail mécanique à des modèles moins coûteux : cloner une structure existante, du code standard, synchroniser la documentation, des modifications répétitives. Garde le modèle principal pour la logique critique en termes de correction (schéma, limites de sécurité, services centraux) et pour les décisions de jugement.
- Limite la concurrence à environ cinq. Au-delà, l'audit cesse d'être réel, et les agents parallèles entrent en collision sur les mêmes fichiers.
- Audite tout ce qui est délégué. N'intègre jamais la sortie d'un sous-agent sans l'avoir lue. Vérifie qu'elle a du sens, suit les conventions, et que la construction et les tests sont verts. Quand c'est faux, évalue l'écart : corrige un petit écart toi-même, et renvoie un grand écart avec la correction.
Blocages
- Révèle-les ; ne devine pas. Quand une étape du plan comporte un point de contrôle explicite, ou rencontre un véritable blocage (infrastructure manquante, hypothèse erronée), signale-le clairement plutôt que d'inventer une solution de contournement qui change la conception.
- Fais d'abord tout ce qui ne dépend pas de la réponse, de sorte que l'humain revienne avec une question plus du travail terminé, pas seulement une question.
- Une revue de PR bloquée est aussi un blocage. Signale-la, et continue à construire les étapes au-dessus localement là où elles ne dépendent pas de la réponse.
La vérification de l'interface utilisateur n'est pas facultative quand personne ne regarde
Conduire l'interface utilisateur dans un navigateur est l'étape la plus facile à abandonner quand personne
ne regarde, et celle dont l'absence ne se voit pas dans le diff. Suis
verify-ui. Si l'environnement ne peut vraiment pas exécuter la fonctionnalité (identifiants
manquants, infrastructure que tu ne possèdes pas), dis-le dans la section Test de la PR :
nomme ce qui a bloqué et ce qui a été vérifié à la place. Le silence est interprété comme
« vérifié ».
Quand tu as terminé
Rapporte l'état du travail : ce qui a été livré (PRs et branches), ce qui
attend une révision, chaque hypothèse prise, et chaque blocage signalé. Écris-le
sous forme de compte rendu dans docs/plans/ si la session se termine.