Comment les connaissances fructifient

On peut facilement voir Pathrule comme un endroit où ranger à la main des mémoires, des règles et des skills. C'en est la plus petite partie. L'essentiel est une boucle qui tourne sur le travail réel et s'améliore à mesure que l'équipe l'utilise.

La boucle comporte trois temps : livrer, capturer, noter. Ils se répètent à chaque session.

Livrer avant le travail

Avant que l'assistant ne commence à agir, la portion des connaissances de votre équipe liée au chemin concerné est déjà dans son contexte. Vous n'avez pas à la coller, et l'assistant n'a pas à aller la chercher. Travailler dans /apps/api/payments fait remonter ce qui y est épinglé, ainsi que ce que ce chemin hérite des chemins parents. Dans Claude Code et Codex, un hook de prompt transmet ces éléments avant le premier appel d'outil ; Cursor et GitHub Copilot les reçoivent via des hooks de session et d'outil, et Windsurf via son fichier de règles et MCP. C'est la partie livraison que la plupart des gens remarquent en premier, et elle est décrite dans Fonctionnement des hooks.

Capturer pendant le travail

Les connaissances n'ont pas besoin d'être rédigées lors d'une séance à part. L'essentiel s'accumule à partir du travail lui-même.

Pendant qu'il travaille, l'assistant repère ce qui mérite d'être conservé : une décision que vous venez de prendre, la correction d'un problème sur lequel il butait sans cesse, une convention qu'il a fallu lui indiquer, un piège qui a fait perdre du temps. Lorsqu'il en trouve un, il propose de l'enregistrer comme mémoire, règle ou skill sur le chemin auquel il appartient, et l'enregistre via les outils d'écriture de Pathrule. Vous pouvez aussi lui demander d'enregistrer directement quelque chose.

Deux propriétés comptent ici :

• Vous pouvez voir et annuler chaque écriture. Une écriture faite par un assistant est marquée comme telle, versionnée et réversible. Pathrule ne modifie ni ne supprime vos connaissances de lui-même : les connaissances obsolètes ou contradictoires sont signalées sous forme de tâche d'actualisation, à résoudre par vous ou par votre agent.
• L'entretien reste quasi nul. Comme la capture accompagne le travail normal, la base de connaissances grandit sans imposer une seconde tâche de rédaction de documentation. Vous pouvez toujours rédiger directement avec le CLI, dans l'extension VS Code ou via un client MCP, quand vous le souhaitez.

Ce qui est écrit automatiquement, et ce qui attend une personne

Certaines écritures se font sans étape de confirmation. Elles sont listées ici pour qu'aucune ne vous surprenne :

• Les propres écritures d'un assistant. Un assistant propose généralement d'abord et enregistre une fois que vous êtes d'accord. Pathrule n'ajoute pas sa propre étape de confirmation devant ces écritures ; il rend plutôt chacune d'elles visible et réversible.
• La trace du travail. Ce qui a été livré, ce que l'assistant a consulté et le déroulement du tour sont enregistrés au fil du travail, car ces éléments alimentent la priorisation. Voir ce que Pathrule calcule.
• Un amorçage unique, sur un espace de travail Cloud. La première fois qu'un agent demande un contexte approfondi, Pathrule enregistre les paires de chemins de fichiers qu'il a lues dans l'historique git récent, point de départ des fichiers qui changent ensemble, ainsi que quelques courtes mémoires technologiques à la racine de l'espace de travail, identifiées à partir des noms de fichiers. Ni le contenu des fichiers, ni les diffs, ni les messages de commit ne sont lus pour cela.
• L'apprentissage du projet. Un constat auquel un agent est parvenu en lisant votre code est enregistré avec les fichiers sur lesquels il repose et partagé avec tous les agents de l'espace de travail, sans étape de revue. Il arrive comme un conseil à vérifier, jamais comme une règle, et uniquement tant que ses sources sont inchangées dans cette copie de travail ; un constat qui s'avère faux peut être retiré pour tout le monde d'un coup. Voir Apprentissage du projet.

Tout le reste, c'est-à-dire ce qui a été déduit plutôt que rédigé par une personne, attend une personne :

• L'analyse du projet que votre agent lance lorsque vous lui demandez de configurer Pathrule pour un projet propose des mémoires, des règles et des skills, et seuls ceux que vous approuvez sont écrits.
• Team Intelligence, sur Pathrule Cloud, transforme les éléments recueillis auprès de l'équipe en patterns suggérés. Seules les entrées vérifiées par une personne parviennent aux agents.
• Les corrections de connaissances obsolètes, contradictoires ou en double ne changent rien tant qu'une tâche d'actualisation n'est pas résolue, par vous ou par un agent à qui vous le demandez.

Noter, pour que le meilleur remonte en premier

La priorisation décide lesquels des candidats pertinents remontent pour une requête, et dans quel ordre. En mode Cloud, Pathrule suit aussi quelles connaissances ont réellement aidé sur un travail similaire et s'en sert pour ordonner les résultats futurs, afin que les plus utiles remontent en premier. Les sessions restent précises au lieu de devenir bruyantes, et une entrée qu'un agent juge obsolète peut être signalée comme tâche d'actualisation à examiner. Voir Suggestions et auto-audit pour le détail.

L'apprentissage modifie l'ordre, pas l'éligibilité. Une entrée doit toujours être pertinente pour la requête en cours. Une mémoire qui a aidé lors de plusieurs migrations ne peut pas s'inviter dans un tour de conception sans rapport au seul motif qu'elle a un bon historique.

Comment le bruit reste hors du prompt

La boucle est volontairement sélective. Par défaut, la documentation générale est proposée en revue au lieu d'être importée comme instruction active. Les connaissances déduites attendent une personne, et chaque écriture est visible et réversible. La portée de chemin limite les endroits où une entrée peut remonter, et la pertinence pour la requête s'applique toujours à l'intérieur de cette portée.

La livraison et l'utilisation sont ensuite mesurées. Les connaissances qu'un agent juge obsolètes, contredites par le code ou en double sont soumises à revue sous forme de tâche d'actualisation. Les réparations sont versionnées et réversibles, ce qui permet à l'équipe d'améliorer l'ensemble sans en perdre l'historique.

Le résultat est un petit ensemble de décisions et de pièges ciblés et vérifiables, et non un déversement de documentation à l'échelle du dépôt. Comment Pathrule démontre ses affirmations les plus exigeantes documente chaque garde-fou.

Pourquoi la boucle est le produit

Un fichier statique ou la mémoire intégrée d'un outil peut assurer la livraison. Ce qui fructifie, c'est la boucle : chaque tâche peut rendre l'équipe un peu plus avisée, et la session suivante part de là.

Cet effet cumulatif n'a rien d'abstrait. Chaque passage dans la boucle laisse quelque chose dont le passage suivant peut se servir : une trace mesurée de ce qui a été livré et du déroulement du tour, des éléments sur ce qui aide pour chaque type de travail, une relation entre deux fichiers qui changent sans cesse ensemble, un échec rattaché à un chemin. Ce que Pathrule calcule liste chacune de ces couches et ce qui l'alimente. Des entrées rédigées ne fructifient pas à elles seules, car rien en elles ne change selon que le travail se passe bien ou mal.

Comme les connaissances vivent en dehors de tout agent particulier, elles sont portables. Les mêmes mémoires, règles et skills parviennent à Claude Code, Codex, Cursor, GitHub Copilot et Windsurf via le CLI ou l'extension VS Code, et à tout client MCP via le MCP local ou Remote MCP. Une fonctionnalité de mémoire native à un outil ne remplace pas cela, car cette mémoire reste dans cet outil. La valeur durable, ce sont les connaissances accumulées par l'équipe, pas une règle ou un fichier de prompt en particulier.