Ce qu'une session d'IA enregistre

L'essentiel de ce que Pathrule apprend sur votre projet, il l'apprend du travail effectué, pas de ce que l'on rédige. Lorsqu'une session d'IA termine un travail, elle enregistre une courte entrée structurée, et c'est sur cette seule entrée que reposent plusieurs autres fonctionnalités.

Cette page décrit ce que contient cette entrée, ce qui en est volontairement exclu, et ce qu'elle permet ensuite de faire fonctionner.

Ce qui est enregistré

Chaque entrée se compose de quelques champs, tous de petite taille :

• Domaine, action et portée. Le type d'élément touché (ui, backend, database, infra, config, test, docs), ce qui lui a été fait (create, update, fix, refactor, delete, style), et à quel niveau (un composant, une page, une API, une migration, un service).
• Sujets. Jusqu'à cinq mots-clés en minuscules, comme vous étiquetteriez ce travail dans une conversation.
• Un résumé d'une phrase. Ce qui a changé et pourquoi, en une ligne.
• Les chemins modifiés, regroupés par domaine.
• Le client d'IA dans lequel la session s'est déroulée, et à quel moment.
• Le déroulement du tour : combien d'appels d'outils il a nécessité, combien ont échoué, et un code court pour chaque type d'échec (timeout, exit_nonzero, not_found et autres). Uniquement des compteurs et des codes, jamais la commande ni le texte de l'erreur.

C'est tout l'enregistrement. Il est conçu pour se lire d'un coup d'œil des mois plus tard, et c'est aussi pour cela qu'il reste court. La vue Recent Activity de Pathrule pour VS Code liste les dernières entrées de l'espace de travail.

L'assistant rédige la phrase. Pathrule y joint la mesure. Le résumé, le domaine et les chemins proviennent de la session qui a effectué le travail, tandis que le nombre d'appels d'outils, les échecs et les entrées livrées qui ont réellement été consultées sont observés par la couche qui les a livrées. Cette répartition compte : un assistant peut oublier de mentionner que quatre commandes ont échoué, le compteur est là malgré tout.

Ce qui n'est jamais enregistré

Votre code n'y figure pas. Aucun contenu de fichier, aucun diff, aucun patch, aucun message de commit, et aucun texte de prompt. Les chemins sont présents pour que d'autres fonctionnalités puissent savoir où le travail a eu lieu ; le fond de la modification, lui, n'est pas stocké.

Les chemins sont également normalisés avant d'être stockés. Un chemin arrive tel que l'agent l'a vu sur sa machine, puis il est converti sous forme relative à l'espace de travail : /Users/you/projects/app/src/api.ts devient ainsi src/api.ts. Rien de propre à une machine n'atteint les connaissances partagées de l'équipe, et un même fichier reste le même fichier, quelle que soit la personne qui l'a modifié.

Ce qu'alimente une entrée

Ce qui rend cet enregistrement utile, c'est ce qui le lit :

• Épisodes de travail. Les entrées liées d'une même session de travail sont regroupées en un enregistrement titré décrivant un problème résolu par votre équipe, qu'une session ultérieure peut retrouver.
• Fichiers qui changent ensemble. Ce sont les chemins de chaque entrée qui apprennent à Pathrule quels fichiers vont de pair.
• Apprentissage de la récupération. Lorsque des connaissances ont été présentées à un agent et que celui-ci a ensuite travaillé dans ce même domaine, c'est la preuve que ces connaissances étaient pertinentes. Avec le temps, cela fait évoluer la priorité, comme décrit dans le fonctionnement de la récupération.

Aucune de ces fonctionnalités ne vous demande d'étape supplémentaire. Elles proviennent toutes de la même courte entrée.

La journalisation ne bloque jamais le travail

Un choix de conception délibéré mérite d'être souligné, car il se voit dans le comportement de l'outil. La journalisation n'échoue jamais pour une question de taille. Si un résumé est trop long ou si une tâche a touché des dizaines de fichiers, l'entrée est tronquée côté serveur puis stockée, au lieu d'être rejetée.

La rejeter serait pire que la tronquer. Un agent qui reçoit une erreur de validation la comprend comme « corrige les arguments et réessaie », et passe les tours suivants à réécrire un résumé au lieu de terminer votre tâche. Les limites sont donc appliquées discrètement, à l'entrée, et la réponse indique à l'agent ce qui a été stocké.

À quoi servent les compteurs d'échecs

Les compteurs d'appels d'outils et d'échecs permettent à Pathrule de répondre à la question « dans quels fichiers de ce code un assistant a-t-il du mal ? » à partir du travail réel plutôt que d'opinions. Deux mécanismes les exploitent.

Le premier est un regroupement hebdomadaire. Chaque échec est enregistré sous forme de triplet : le type d'outil, le fichier sur lequel il travaillait, et un code court indiquant la nature de l'échec. Regroupé par semaine, cela donne une simple liste des fichiers dans lesquels un assistant échoue le plus souvent, et du type d'échec qu'il y rencontre. Un fichier qui revient régulièrement sous file_not_found correspond généralement à un chemin obsolète dans votre propre documentation ou à un module déplacé que rien n'a mis à jour. Un fichier sous syntax_error est généralement un fichier difficile à modifier sans risque.

Le second est l'apprentissage de la récupération. Si un tour a reçu des connaissances de Pathrule et a tout de même rencontré des échecs d'outils, cela joue contre les connaissances qui lui ont été fournies. Ce signal rejoint la boucle d'apprentissage décrite dans ce qui donne une priorité plus élevée aux connaissances, si bien que des connaissances qui reviennent sans cesse dans des tours qui se passent mal cessent progressivement d'être choisies.

Ce qu'un compteur d'échecs peut voir, et ce qu'il ne voit pas

Cela dépend de l'assistant que vous utilisez, et la réponse honnête n'est pas la même partout.

Les outils de fichiers remontent correctement les informations. Une lecture, une modification ou une écriture qui échoue arrive avec son message : elle est donc classée et attribuée au bon fichier. C'est le cas le plus utile, car c'est le chemin du fichier qui rend le chiffre exploitable.

Le code de sortie du shell, souvent, non. Certains assistants ne remontent pas du tout un code de sortie non nul : une commande qui échoue et une commande qui réussit arrivent sous une forme identique. Pathrule ne devine pas. Il enregistre ce que l'assistant a réellement remonté et classe le reste comme inconnu au lieu d'inventer un échec, car un faux échec attribué à un fichier est pire qu'un échec manquant.

Accès et portée

Les entrées sont conservées dans l'espace de travail où elles ont été enregistrées, derrière le même contrôle d'accès par utilisateur que les mémoires, les règles et les skills. Un membre de l'équipe voit l'activité des espaces de travail auxquels il a déjà accès, et rien d'autre. Les entrées les plus anciennes expirent selon un calendrier défini au lieu de s'accumuler indéfiniment.