Les fichiers qui changent ensemble

Certains fichiers vont par deux. Une route et son validateur. Une migration et le type qui la reflète. Un composant et le fichier de tokens qu'il lit. Personne ne le note, et la structure des dossiers le montre rarement, mais au bout de quelques mois toute l'équipe le sait.

Pathrule l'apprend à partir du travail lui-même. Lorsque vos agents journalisent ce qu'ils ont fait, chaque entrée indique les chemins qu'elle a touchés. Si deux chemins apparaissent régulièrement dans le même travail, Pathrule enregistre qu'ils changent ensemble. Sur un espace de travail Cloud, il prend aussi de l'avance grâce à votre historique git, ce qui rend le signal utile dès la première semaine plutôt qu'au bout de quelques mois.

Ce que cela apporte à la récupération

La portée par chemin et la correspondance par le sens partent toutes deux de l'endroit où vous vous trouvez. Le co-changement y ajoute les fichiers voisins.

Lorsque l'assistant travaille dans /apps/api/payments/refund.ts, la récupération prend déjà en compte ce qui est épinglé à ce chemin et ce qui correspond à l'intention. Le co-changement permet aussi de faire remonter les connaissances attachées aux chemins qui évoluent habituellement avec lui. Une règle sur le module d'écriture du grand livre peut ainsi atteindre une session qui n'a jamais mentionné le grand livre, parce que dans ce code les remboursements et le grand livre ont toujours été modifiés ensemble.

C'est surtout utile pour les connaissances que personne n'a pensé à attacher à deux endroits. Une décision consignée une seule fois, sur le fichier où elle a été prise, peut quand même atteindre les sessions qui en ont besoin.

Ce que voit l'assistant

Sur un espace de travail Cloud, le co-changement apparaît à trois endroits dans le contexte qu'un agent demande à Pathrule (via pathrule_get_context) :

• Un avertissement. Lorsqu'un voisin change particulièrement souvent avec le fichier sur lequel travaille l'assistant, celui-ci reçoit une seule ligne qui le signale : ce fichier change généralement en même temps que celui-ci. Une ligne au maximum, et uniquement pour une relation forte, afin qu'elle se lise comme un avertissement et non comme du bruit.
• Les chemins liés. En plus du contexte d'une requête ciblée ou approfondie, l'assistant reçoit une courte liste des chemins qui changent habituellement avec celui sur lequel il travaille.
• Les zones couplées dans une réponse approfondie. Lorsqu'un agent demande un contexte approfondi, la réponse nomme les parties de l'espace de travail couplées à la zone concernée, avec les titres des mémoires, règles et skills qui y sont attachés.

Cette récupération est traitée à part : si elle échoue, le tour ne perd pas pour autant les mémoires et les règles qu'elle devait accompagner.

Comment la relation est mesurée

Une paire journalisée compte lorsque les deux chemins apparaissent dans le même travail journalisé. Partager un dossier ne suffit pas, pas plus qu'être modifié le même jour par des tâches différentes. L'unité retenue est un travail, car c'est ce qui révèle une vraie dépendance plutôt qu'une coïncidence d'organisation.

Les relations sont reconstruites à partir de l'activité récente : une relation qui cesse de se produire s'estompe sans que personne ait besoin de la supprimer. Un refactoring qui sépare deux fichiers se traduit par l'affaiblissement de leur relation au fil des semaines suivantes.

L'avance donnée par l'historique git

Un nouvel espace de travail n'a encore aucun travail journalisé, et c'est justement le moment où connaître les voisins serait le plus utile. Sur un espace de travail Cloud, la première fois qu'un agent demande à Pathrule un contexte approfondi, le runtime local lit donc les chemins de fichiers de l'historique git récent. Les fichiers modifiés dans un même commit forment une paire, et les très gros commits, qui sont généralement des refactorings ou des renommages, sont ignorés parce qu'ils associent tout avec tout. Les paires de chemins de fichiers obtenues, avec la fréquence de chaque paire, sont enregistrées dans l'espace de travail sur Pathrule Cloud.

Cela se produit une seule fois, sans demande de confirmation, et ne lit rien d'autre que des chemins de fichiers. À mesure que votre équipe journalise du travail, les relations qu'elle enregistre pèsent plus et l'amorçage git pèse moins : l'image passe ainsi de la façon dont le code a évolué par le passé à la façon dont votre équipe y travaille aujourd'hui.

Sur quoi il repose, et sur quoi il ne repose pas

Le signal repose uniquement sur des chemins de fichiers : les chemins du travail que vos agents journalisent et, sur un espace de travail Cloud, les chemins de fichiers de l'historique git récent. Pathrule ne lit ni votre code source, ni vos diffs, ni vos messages de commit pour le calculer, et rien d'autre que le chemin d'un fichier n'en fait partie.

Un espace de travail local, utilisé sans compte, n'a pas d'amorçage git. Ses paires proviennent uniquement du travail journalisé, ce qui a une conséquence pratique bonne à connaître : il lui faut un vrai historique de modifications. Un espace de travail où chaque tâche journalisée touche exactement un fichier ne produit aucune paire, puisqu'il n'y a rien à associer. Dans ce cas, la récupération continue de s'appuyer sur la portée par chemin et sur le sens, et le co-changement n'apporte rien plutôt que de deviner.

Le signal est aussi propre à chaque espace de travail. Les relations apprises dans un espace de travail ne sont pas reportées dans un autre, et le signal est soumis au même contrôle d'accès que le reste de vos connaissances.

Où regarder

Le co-changement fonctionne en arrière-plan : il n'y a rien à configurer ni à activer. Il gagne en utilité à mesure que votre équipe journalise du travail, ce qui rend aussi plus utiles les épisodes de travail et les suggestions. Si vos agents journalisent leur travail, ce signal s'accumule déjà. Ce que calcule Pathrule détaille ce que Pathrule lit dans une copie de travail.