Ce que Pathrule calcule

Vous écrivez trois types de choses : des mémoires, des règles et des skills. Cette partie est réfléchie, soignée, et elle vous appartient.

C'est aussi la plus petite moitié. L'essentiel de ce que contient la couche à un instant donné n'a été saisi par personne. Il est dérivé du déroulement réel du travail, conservé par espace de travail, et recalculé à mesure que le travail avance. Cette page nomme chaque partie dérivée, car savoir ce qui s'y trouve explique pourquoi la récupération se comporte comme elle le fait.

Une représentation du sens pour chaque entrée

Chaque mémoire, règle et skill existe aussi sous forme de représentation calculée de son sens. Lorsqu'une requête arrive, elle est convertie dans le même type de représentation puis comparée directement à ces entrées.

C'est ce qui rend possible la correspondance entre langues. Un prompt en turc fait remonter une mémoire écrite en anglais dès lors que les deux partagent une idée, sans avoir un seul mot en commun. Une recherche par mots-clés en est incapable, faute de chaîne commune sur laquelle s'appuyer. La comparaison a lieu dans un espace où « the payment webhook retries twice » et « ödeme webhook'u iki kez deniyor » se trouvent proches l'un de l'autre.

Les entrées sont représentées à nouveau lorsque leur contenu change, si bien que la correspondance reflète ce que dit l'entrée aujourd'hui, et non ce qu'elle disait lors de sa création.

Une fenêtre mesurée autour de chaque livraison

Lorsque Pathrule livre des connaissances pour un tour, il ouvre un enregistrement de cette livraison. Cet enregistrement indique quelles entrées ont été envoyées, sur quel chemin et pour quel type d'intention.

Le tour renvoie ensuite ses informations dans cette même fenêtre :

• lesquelles des entrées livrées l'assistant a réellement consultées, et pas seulement reçues
• combien d'appels d'outils le tour a nécessités, et combien ont échoué
• quels fichiers ont été modifiés, sous forme de chemins relatifs à l'espace de travail
• la répartition des échecs, sous forme de codes courts plutôt que de texte d'erreur

Cette fenêtre est la matière première de tout ce qui suit. C'est aussi ce qui permet à Pathrule de distinguer un tour qui s'est bien passé d'un tour qui s'est mal passé, sans que personne n'ait à noter quoi que ce soit.

Des poids appris, par type de travail

Les fenêtres s'accumulent. Avec le temps, chaque entrée acquiert une position propre à chaque type de travail dans lequel elle a été livrée, et cette position évolue selon les preuves : elle monte quand l'entrée a été consultée sur un travail qui s'est déroulé proprement, elle baisse quand l'entrée a été livrée dans un tour qui a peiné.

Conséquence : la priorité n'est pas un chiffre unique par entrée. Une même mémoire peut être très prioritaire pour une migration et peu prioritaire pour un petit ajustement d'interface, car ce sont des types de travail différents et les preuves diffèrent. Un simple champ « importance » dans un fichier ne peut pas exprimer cela, et une personne qui le tiendrait à jour à la main en serait réduite à deviner.

L'apprentissage est volontairement prudent. Un résultat ambigu n'enseigne rien plutôt que d'enseigner une erreur, un seul échec net abaisse la position sans effacer l'historique, et l'influence s'estompe à mesure que le code évolue. Comment la récupération trouve les bonnes connaissances détaille ce comportement.

Un graphe des fichiers qui évoluent ensemble

À partir des chemins que remontent les tours, Pathrule construit une image des fichiers que votre équipe modifie habituellement dans un même travail. Les connaissances rattachées à l'un de ces fichiers peuvent alors atteindre une session qui travaille sur son voisin.

Personne ne déclare ces relations et aucun fichier n'est ouvert pour les trouver. Elles sont issues du travail journalisé, elles comportent un seuil de bruit pour qu'une simple coïncidence ne compte pas, et elles s'estompent quand l'association cesse de se produire. Sur un espace de travail Cloud, le graphe bénéficie aussi d'une longueur d'avance : la première fois qu'un agent demande un contexte approfondi, il est amorcé à partir des chemins de fichiers de l'historique git récent, ce qui le rend utile avant même que votre équipe ait journalisé beaucoup de travail. Voir les fichiers qui changent ensemble.

Une carte des frictions

Les échecs sont regroupés en triplets : le type d'outil, le fichier et un code court décrivant la nature de l'échec. Regroupés par semaine, ils dessinent une image des endroits de votre code où un assistant bloque régulièrement, et de quelle manière. Cette carte alimente la priorité sous forme de signal négatif lorsqu'un tour qui a reçu des connaissances a malgré tout rencontré des difficultés. Voir les fichiers qui ralentissent un assistant.

Une mesure de la justesse du routage

Chaque prompt reçoit aussi un itinéraire : les chemins où le travail a le plus de chances de se trouver, nommés avant que l'assistant n'ouvre quoi que ce soit. Pathrule enregistre ensuite si l'assistant s'y est bien rendu. Sur une fenêtre glissante, cela donne un chiffre unique de précision, accompagné d'une comparaison entre le volume de travail sur les outils de fichiers d'une session routée et celui d'une session qui ne l'a jamais été.

C'est le seul chiffre qui indique si désigner un chemin aide réellement, plutôt que de simplement paraître utile, et c'est ce qui permet d'ajuster le routage sur des preuves plutôt qu'au goût de chacun.

Chaque couche indique si elle est toujours alimentée

Chacune des couches dérivées ci-dessus dépend du travail qui l'alimente, et une couche qui ne reçoit plus rien ne renvoie rien. Cela ressemble exactement à une couche qui n'a rien à signaler. Ces deux situations appellent des réponses opposées, c'est pourquoi Pathrule ne les laisse pas se confondre.

Chaque couche est régulièrement interrogée sur la date à laquelle elle a reçu des données pour la dernière fois, et la réponse est enregistrée dans l'un de trois états : à jour, rien reçu récemment, ou jamais alimentée. Le même contrôle repère les tours provenant d'un client assez ancien pour être antérieur à une partie de l'enregistrement, si bien qu'une mise à jour qui vaut la peine d'être installée apparaît sous forme d'un décompte nommé, et non de résultats qui se sont dégradés en silence.

Voilà pourquoi une couche dérivée qui se tait est un état signalé et daté, et non quelque chose que l'on remarque des mois plus tard en se demandant pourquoi un résultat s'est dégradé.

Épisodes et jugements de fraîcheur

Deux autres couches dérivées reposent sur la même activité.

Les épisodes de travail relient des tours apparentés pour reconstituer l'histoire de la résolution d'un problème, afin que la question « comment avons-nous fait la dernière fois ? » ait une réponse qui ne dépende pas de la mémoire d'une personne. Voir comment avions-nous résolu ce problème.

Les jugements d'obsolescence comparent ce qu'affirme une entrée à l'état actuel du code, et remontent celles qui semblent dépassées sous forme de modifications proposées, plutôt que de baisser leur priorité en silence. Voir suggestions et auto-audit.

Préférences personnelles, conservées sur votre machine

Une couche part de vous plutôt que du travail journalisé. Lorsque vous indiquez à Pathrule votre façon de travailler, par exemple pathrule me teach "I prefer incremental refactors", le modèle local optionnel transforme la phrase en une préférence courte et ciblée. Elle est stockée sur votre machine, pas envoyée, et livrée à vos agents là où elle s'applique.

Vous en gardez la maîtrise : pathrule me list affiche ce qui est utilisé, pathrule me explain indique d'où vient une préférence, pathrule me scope la limite à un espace de travail ou lui permet de s'appliquer à tous, pathrule me forget cesse de l'utiliser, et pathrule me context donne un aperçu de ce qu'un agent recevrait pour une tâche. Voir User Intelligence.

Ce sur quoi rien de tout cela ne repose

Pas sur le contenu de votre code source. Le code source du dépôt n'est pas envoyé automatiquement. Chaque couche dérivée ci-dessus provient de ce que votre équipe a choisi d'écrire et de ce que le travail a rapporté sur lui-même, et aucun diff ni message de commit n'est stocké.

Deux éléments sont lus depuis votre copie de travail, uniquement sur un espace de travail Cloud et uniquement la première fois qu'un agent demande un contexte approfondi :

• Les chemins de fichiers de l'historique git récent, pour repérer les fichiers modifiés dans un même commit. Les très gros commits, généralement des refactorisations ou des renommages, sont ignorés. Les paires de chemins de fichiers obtenues sont enregistrées dans l'espace de travail comme point de départ du graphe de co-changement. Les messages de commit, les auteurs et les diffs ne sont pas lus.
• Les noms de fichiers proches du sommet de l'arborescence, pour reconnaître les technologies utilisées à partir des fichiers de configuration, par exemple une configuration TypeScript, Vite, Docker ou GitHub Actions. Chaque technologie reconnue devient une courte mémoire à la racine de l'espace de travail, écrite sans demander. C'est une mémoire ordinaire, que vous pouvez modifier ou supprimer.

Tant que l'historique propre à l'espace de travail reste mince, cette même réponse approfondie nomme aussi les dossiers de premier niveau du projet et les fichiers les plus souvent modifiés dans l'historique git récent. Ces informations sont lues depuis votre copie de travail et transmises à l'agent pour cette réponse, sans être stockées par Pathrule.

Un espace de travail local, conservé sur votre machine sans compte, ne fait rien de tout cela : son graphe de co-changement provient uniquement du travail journalisé.

Deux autres éléments quittent votre machine en mode Cloud, et les voici :

• Le début de chaque prompt. La première partie du prompt, environ ses 1 000 premiers caractères, est envoyée à Pathrule Cloud pour prioriser les connaissances qui y répondent.
• Un instantané du projet, lorsque vous ou votre agent lancez pathrule snapshot. Il envoie l'arborescence des fichiers, les manifestes, de courts extraits de la documentation et les métadonnées git récentes. Il ne s'exécute que lorsqu'on l'invoque.

L'analyse du projet est une étape distincte que vous lancez vous-même, en demandant à votre agent de configurer Pathrule pour le projet. Votre agent lit le projet pour proposer des mémoires, des règles et des skills, et seul ce que vous approuvez est enregistré.

Par ailleurs, un CLI géré et connecté ne peut envoyer de télémétrie d'usage anonyme qu'après votre accord explicite via pathrule telemetry enable. Elle ne contient ni code, ni chemins, ni prompts, ni connaissances, ni noms de fichiers, ni adresses e-mail, ni identifiants de compte. pathrule telemetry disable, NO_TELEMETRY=1 et DO_NOT_TRACK=1 la maintiennent désactivée.

Les chemins de fichiers sont normalisés sous forme relative à l'espace de travail avant toute conservation, si bien que rien de propre à une machine ne circule non plus.

Pourquoi les mêmes fichiers dans un dossier ne sont pas la même chose

Vous pourriez placer les mêmes mémoires, règles et skills dans un répertoire et y diriger un assistant. Certaines équipes le font. Mais ce répertoire est incapable de faire quoi que ce soit de ce que décrit cette page.

Il ne sait pas ce qui a été livré au dernier tour, et ne peut donc pas savoir ce qui a aidé. Il n'a aucune représentation du sens, si bien qu'une question formulée autrement ne trouve rien. Il ne sait pas quels fichiers évoluent ensemble, si bien que les connaissances consignées sur un fichier n'atteignent jamais son voisin. Il ne distingue pas un type de tâche d'un autre, si bien que tout a la même priorité pour tout. Et il grossit : chaque entrée ajoutée alourdit chaque tour à venir, car un répertoire n'a aucun moyen de n'envoyer que les quelques entrées qui comptent.

Les entrées écrites sont la partie que vous maîtrisez. La couche dérivée est ce qui les réduit aux quelques entrées utiles pour ce tour, et c'est pour cela que la réponse s'améliore à mesure que le travail avance, au lieu de rester exactement aussi bonne que le jour où elle a été écrite.