Deux secondes après le merge
J'avais écrit que changer d'outil de suivi ne me coûterait plus une réécriture. J'ai branché Linear pour vérifier. Un ticket fermé tout seul, sept autres écrits dans une archive en lecture seule, et un adaptateur de 5 853 lignes.
Le 23 septembre, à 16 h 49 et 20 secondes, je merge une PR.
À 16 h 49 et 22 secondes, un autre ticket passe tout seul à « Terminé ». Sa PR à lui est encore en brouillon. Ses dix critères d'acceptation sont tous ouverts.
Ce ticket, c'était celui de la migration vers Linear.
Vérifier ma propre promesse
Il y a moins de trois semaines, j'écrivais ici que mon outil de suivi n'était plus câblé en dur, et que le prochain ne me coûterait pas une réécriture. Dans Foundry, le tracker est une prise : d'un côté le pipeline, de l'autre un adaptateur.
Ce que je cherche avec Foundry, c'est qu'il ne dépende de rien. Ni du modèle, ni de l'outil de suivi. Côté modèle, c'est déjà le cas : les mêmes commandes tournent sur Claude Code et sur Codex. Je veux pouvoir dire pareil du tracker : que ça s'utilise de la même façon, peu importe ce qu'il y a derrière.
Sauf qu'une prise avec un seul appareil branché dessus, ça ne prouve rien. YouTrack était le seul adaptateur réel. Tant qu'il n'y en avait pas un deuxième, mon « peu importe » était une promesse.
Alors j'ai branché Linear. Sur un seul dépôt : celui de Foundry. Orfeo et Luchamon restent sur YouTrack, et ça aussi fait partie du test — deux outils en même temps, chacun dans son dépôt.
Le plan
Pas de grand déménagement, cette fois. Seuls les quatre tickets encore ouverts sont partis vers Linear. Tout le reste est resté dans YouTrack, déclaré archive en lecture seule.
Et avant de toucher à quoi que ce soit, j'ai écrit la règle de retour arrière : possible tant que rien n'a été écrit dans Linear. Après la première écriture, plus de marche arrière. On répare en avant.
La bascule a eu lieu le 22 septembre.
Deux secondes
Le lendemain, donc, je merge une petite PR qui préparait le terrain pour le ticket de migration. Et Linear ferme le ticket de migration.
Ce n'était pas un bug. C'était une fonction. Linear a une automatisation GitHub : quand une PR est mergée, les tickets qui lui sont liés passent à « Terminé ». Très pratique quand un humain tient le tableau. Catastrophique quand un outil garantit, lui, qu'un ticket n'est terminé que si ses critères sont vérifiés.
J'avais deux systèmes qui se croyaient chacun responsable de l'état du ticket.
J'ai coupé l'automatisation. Et comme je ne me fais pas confiance pour ne jamais la réactiver, Foundry refuse maintenant de merger tant qu'elle existe.
Écrire sans pouvoir verrouiller
Le vrai problème de fond est ailleurs. Linear n'offre pas de moyen de dire : modifie ce champ, mais seulement si personne n'y a touché depuis ma lecture. Si deux écritures se croisent, la dernière gagne, en silence.
Pour un humain qui déplace des cartes, ça n'a aucune importance. Pour un outil qui veut prouver qu'un ticket est passé en revue puis terminé, dans cet ordre, c'est un trou.
Alors Foundry ne remplace rien dans Linear. Il ajoute. Chaque étape — en cours, en revue, terminé — est un commentaire, et l'état réel d'un ticket se déduit de la suite des commentaires.
Ça marche. Ça a un prix un peu ridicule : le tableau Linear, lui, affiche les champs d'origine. La plupart de mes tickets livrés y apparaissent « en cours ». La vérité est dans les commentaires.
La ligne vide
Je range aussi mes décisions d'architecture dans le tracker. Vingt-sept à importer. Et pour une décision, je veux une garantie simple : ce que je relis est exactement ce que j'ai écrit.
Linear réécrit le Markdown. Les tirets de liste deviennent des astérisques. Les chevrons sont échappés. Les lignes vides bougent.
Chaque réécriture, c'est un texte relu qui ne correspond plus au texte écrit, donc une alerte. J'ai passé plusieurs tickets là-dessus. L'un d'eux a existé à cause d'une seule ligne vide, supprimée sur deux.
Avant d'importer les vingt-sept, j'ai fini par faire ce que j'aurais dû faire au début : envoyer des textes pièges dans un projet jetable, et regarder comment Linear les rendait.
Sept tickets dans l'archive
Le 26 septembre, je lance une commande depuis une copie du dépôt qui n'avait pas encore le marqueur indiquant « ici, c'est Linear ». Sans marqueur, Foundry est retombé sur l'outil par défaut de ma machine.
YouTrack. L'archive.
Sept tickets créés dedans avant que la commande échoue.
« Lecture seule » ne voulait dire qu'une chose : le Foundry à jour refusait d'y écrire. Le serveur, lui, n'en savait rien. Il a suffi d'un chemin que le garde ne couvrait pas.
Le ticket de migration avait un critère : YouTrack strictement en lecture seule pendant l'opération. Il n'est pas rempli, et je ne l'ai pas coché. Le ticket a été mergé sous dérogation, avec la trace. Dans le tableau de bord il affiche aujourd'hui : terminé, 0 critère sur 10.
Je préfère un 0 sur 10 honnête à un 10 sur 10 arrangé.
Alors, cette promesse ?
Je n'ai pas réécrit le pipeline. Les skills ne savent toujours pas à quel outil ils parlent. J'ai écrit un adaptateur, comme annoncé.
L'adaptateur YouTrack fait 878 lignes.
L'adaptateur Linear en fait 5 853. C'est le plus gros fichier du projet.
Donc la promesse tient, à la lettre. Changer d'outil, c'est écrire un adaptateur. Je n'avais simplement pas précisé la taille.
Ce que j'ai appris est plus utile que la promesse : deux outils de suivi ne diffèrent pas par leurs écrans. Ils diffèrent par ce qu'ils garantissent quand on écrit dedans. Et ça, aucune page de présentation ne te le dit. Tu le découvres deux secondes après un merge.
— Pato