Les PR mergées font avancer les tickets et un résumé part

Garder un board fidèle à ce qui a réellement été livré est une corvée permanente : quelqu'un doit se souvenir quelle PR a fermé quel ticket, cliquer sur chacune, l'avancer, puis séparément dire à l'équipe ce qui vient d'atterrir. Un jour chargé, c'est la dernière partie qu'on saute en premier.

Les deux moitiés existent déjà comme données. Un code host comme GitHub sait déjà exactement ce qui a été mergé et quand ; un tracker de tickets connaît déjà le statut de chaque ticket ouvert. Le travail, c'est lire l'un, rattacher à l'autre et réécrire, la même jointure chaque jour, à quelque heure que personne ne veut faire ça à la main. Ce qui en fait un travail naturel pour un agent IA placé entre le code host et Linear.

Ce que lit l'automatisation des pull requests mergées

L'exécution liste chaque pull request mergée depuis la veille, sur tous les dépôts qui comptent, avec son titre, sa description et son horaire de merge. Le code host est lu via l'accès dont l'assistant dispose déjà ; ce n'est pas quelque chose que Tulina connecte. Le tracker de tickets et l'outil de messagerie d'équipe sont les deux connexions faites dans Tulina.

La fenêtre reste courte volontairement, un jour plutôt qu'une semaine. C'est ce qui rend l'exécution idempotente : déclenchée deux fois par accident, la seconde passe reconfirme ce que la première avait déjà fait plutôt que de retraiter un arriéré qui grandit.

Rattacher chaque pull request à son ticket

Le premier endroit à regarder, c'est la pull request elle-même. La plupart des PR ouvertes contre un vrai ticket le mentionnent quelque part dans le titre ou la description, et cette référence explicite est un rattachement rapide et précis.

Sans référence, l'agent compare le titre de la PR aux tickets ouverts de l'équipe par mot-clé, et ne retient ce rattachement que s'il en est vraiment sûr. La rigueur du rattachement, c'est ce qui fait gagner ou perdre la confiance ici : un mauvais rattachement fait avancer le mauvais travail, et la personne qui le remarque n'est rarement pas celle qui a lancé l'automatisation. Une PR non rattachée laisse le board tranquille et apparaît quand même dans le résumé, donc rien ne merge silencieusement.

Rien de tout ce rattachement n'est spécifique à Linear. Une référence explicite d'abord, puis un repli prudent par mot-clé, fonctionne de la même façon contre n'importe quel tracker que l'assistant peut atteindre.

Faire avancer les tickets, et seulement avancer

Avant de changer quoi que ce soit, l'agent lit l'état actuel du ticket. Un ticket déjà plus avancé que ce que « code mergé » suggérerait (en revue, en attente d'une personne précise, déjà livré) reste exactement où il est. Le travail consiste à remettre le board à jour, jamais à écraser une décision qu'une personne a prise plus récemment que cette exécution.

Chaque avancée est précédée d'un commentaire nommant la pull request précise, avec son titre et son lien. Un statut qui change sans trace du pourquoi est indiscernable d'un statut qui est faux.

L'état cible suit ce qui est réellement connu. Mergé est un signal ; confirmé en ligne dans un environnement de préproduction ou de staging en est un plus fort, et l'agent ne le revendique pas sans vérifier. Certains dépôts déploient dès qu'une pull request atterrit sur la branche principale, d'autres ont besoin d'une étape séparée, et les deux sont faciles à confondre sans vérifier dépôt par dépôt. Distinguer les deux, c'est ce qui garde « Terminé » vraiment terminé.

Un résumé de ce qui a été livré

L'équipe reçoit un court message dans Slack, groupé par dépôt, en sautant les dépôts sans rien de mergé. Chaque pull request apparaît avec son titre, son ticket s'il en a un, et si elle est mergée ou confirmée en ligne.

Un jour où rien n'a mergé nulle part, le message le dit aussi. Une routine qui reste silencieuse un jour calme est indiscernable d'une routine cassée.