Boucles d'événement

Des boucles qui se déclenchent quand quelque chose arrive dans vos outils : une pull request ouverte, un ticket assigné, un label ajouté. C'est exactement ce qu'est la revue de code automatique — une boucle qui vous appartient, que vous pouvez réécrire et désactiver.

Une boucle d'événement se déclenche quand quelque chose arrive dans un outil que vous avez connecté. Pas d'horaire, pas de rituel d'assignation, personne pour taper un prompt : une pull request est ouverte et la revue est déjà en cours avant que quiconque ait changé d'onglet.

Son instruction est une consigne permanente posée par-dessus ce que l'événement apporte déjà. Le goblin reçoit automatiquement la merge request ou le ticket comme contexte ; votre instruction lui dit ce que vous voulez qu'il en fasse.

Les événements sur lesquels vous pouvez boucler

Événement Source Se déclenche quand
Merge request ouverte GitLab Une MR est ouverte, rouverte ou mise à jour avec de nouveaux commits
Ticket assigné GitLab Un ticket est assigné au bot @taskgoblin
Pull request ouverte GitHub Une PR est ouverte, rouverte ou mise à jour avec de nouveaux commits
Ticket labellisé GitHub Le label taskgoblin est ajouté à un ticket
Ticket assigné Linear Un ticket est assigné à l'agent TaskGoblin
Ticket assigné Jira Un ticket est assigné au compte TaskGoblin

Comme les événements « ouverte » couvrent aussi les mises à jour, une boucle de revue réconcilie au lieu de répéter : au second passage, elle relit les constats qu'elle avait laissés, clôt ceux que vous avez corrigés et ne publie que ce qui est réellement nouveau.

Les boucles que vous avez déjà

Vous ne partez pas d'une page blanche. Dès qu'un fournisseur existe pour votre organisation, TaskGoblin installe ses boucles par défaut :

  • GitLab — Relire les merge requests et Traiter les tickets assignés.
  • GitHub — Relire les pull requests et Traiter les tickets labellisés.
  • Linear — Traiter les tickets assignés.
  • Jira — Traiter les tickets assignés.

Elles reproduisent ce qu'on attend d'un agent de code sorti de sa boîte. La différence, c'est qu'elles sont à vous : de vraies boucles sur votre page Loops, avec des instructions que vous pouvez lire et modifier.

L'installation n'a lieu qu'une fois, définitivement. Supprimez une boucle par défaut et elle reste supprimée — reconnecter le fournisseur ne la ressuscite pas en douce.

Réécrire l'instruction, c'est tout l'intérêt

L'instruction de revue par défaut demande correction, sécurité et maintenabilité, et dit au goblin de se taire quand un changement est sain. C'est une position de départ raisonnable, pas une politique imposée. Les équipes la resserrent ou l'élargissent couramment :

  • « Ne signale que les problèmes de sécurité et les risques de perte de données. Rien d'autre. »
  • « Sois strict sur la couverture de tests — tout changement de comportement exige un test ; dis-le s'il manque. »
  • « Vérifie aussi que tout nouvel endpoint passe par notre middleware de rate limiting. »

L'instruction est du texte libre : elle peut donc encoder ce qu'un linter ne peut pas — vos conventions, vos incidents passés, l'erreur que cette équipe répète.

L'instruction par défaut, et une version durcie

Voici ce qui est livré :

Relis cette merge request. Concentre-toi sur la correction, la sécurité et la maintenabilité — signale les vrais problèmes, pas les détails de style qu'un linter attraperait. Ne laisse des commentaires en ligne que là où ils apportent quelque chose, garde-les précis et actionnables, et tais-toi quand le changement est sain.

Elle est délibérément sobre, car un relecteur qui commente tout finit ignoré. Et voici la même boucle après qu'une équipe a vécu un mois avec et connu un incident :

Relis cette merge request pour la correction, la sécurité et la maintenabilité. Signale les vrais problèmes, pas les détails de style.

Vérifie en outre systématiquement : tout changement de comportement a un test ; aucun nouvel endpoint ne part sans notre middleware de rate limiting ; aucune migration ne modifie une migration existante ; rien ne journalise un corps de requête complet. Remonte ces points en critique même si le reste du changement est correct.

Si la MR dépasse 400 lignes, dis-le dans le résumé et relis d'abord les fichiers les plus risqués plutôt que de survoler l'ensemble. Tais-toi quand le changement est sain.

Rien d'exotique dans la seconde version : c'est du savoir institutionnel qui vivait dans un wiki que personne n'ouvrait, désormais attaché au moment où il compte. C'est la différence entre une boucle héritée et une boucle qui vous appartient.

L'interrupteur

Cette partie mérite deux lectures, car elle explique un comportement qui passerait sinon pour un bug.

Un événement soumis aux boucles sans aucune boucle active correspondante ne lance rien. Suspendez votre boucle de revue et les merge requests cessent d'être relues. Supprimez-la, idem. TaskGoblin continue d'accepter le webhook — il n'a simplement aucune consigne permanente sur laquelle agir, donc aucun goblin ne se réveille et rien n'est facturé.

C'est le prix à payer pour que le comportement vous appartienne au lieu de vous être imposé. Si la revue automatique s'est arrêtée, le premier endroit à regarder est si sa boucle est toujours active.

Ce qui n'est jamais filtré

Les demandes humaines explicites s'exécutent toujours, qu'une boucle existe ou non :

  • @taskgoblin mentionné sur une merge request, une pull request ou un commentaire de ticket
  • Un message ou une mention dans Slack ou Microsoft Teams
  • Un commentaire de suivi sur un ticket Linear que le goblin traite déjà
  • Une mention dans un commentaire de ticket Jira
  • Répondre @taskgoblin fix à l'un de ses propres commentaires de revue

Si une personne a demandé directement, un goblin répond. Les boucles régissent le travail non sollicité, et lui seul.

Quand plusieurs boucles correspondent

Rien ne vous empêche de faire tourner plusieurs boucles sur le même événement — une boucle de revue générale plus une plus stricte pour la sécurité, par exemple. Quand un événement en fait correspondre plusieurs, le goblin voit toutes les instructions candidates et juge laquelle s'applique, en consignant son choix sur l'exécution pour que l'historique reste honnête. Le travail reste une exécution unique : les boucles ne se multiplient pas en revues dupliquées sur une même merge request.

Où aller ensuite