Sécurité et repli

Quand Pathrule n'est pas sûr, il ne fait pas semblant.

Quelques mécanismes y veillent. Certains décident de ce qui a le droit d'atteindre un agent. Un autre retire des mains de l'agent les connaissances qui ne doivent pas dépendre de son jugement, lorsque le client le permet.

Un conseil est présenté comme un conseil

Tout ce que reçoit un agent n'a pas le même poids, et la livraison l'indique. Les règles arrivent en tant que règles. Les constats que les agents ont enregistrés sur le code arrivent présentés comme des conseils à vérifier, et les agents ont pour consigne de les traiter comme des informations et non comme des instructions : un texte glissé dans un fichier ne peut donc pas devenir un ordre permanent. Les préférences personnelles arrivent sous un intitulé qui indique à l'agent que les règles de l'espace de travail et les vérifications obligatoires passent en premier. Voir Knowledge IR.

Les constats obsolètes ou contradictoires sont retenus

Un constat est enregistré avec les fichiers sur lesquels il repose, et il est revérifié par rapport à votre copie de travail chaque fois qu'il doit être livré.

• Sources inchangées. Le constat est livré.
• Une source a changé. Le constat est retenu jusqu'à ce qu'un agent relise le code et le confirme ou le corrige.
• Deux constats se contredisent. Les deux sont retenus plutôt que de choisir l'un au hasard.

Une livraison plus réduite mais toujours vraie vaut mieux qu'une livraison plus complète portant sur du code qui n'existe plus.

Rien de ce qui est appris n'est fiable par lui-même

C'est de l'inférence que naissent les erreurs assurées et bien formulées. Rien de ce qui est inféré ne devient donc une connaissance fiable sans l'intervention d'une personne.

• Un pattern Team Intelligence n'atteint les agents qu'après vérification par un propriétaire ou un administrateur de l'organisation.
• Une contrainte exécutable qu'un agent associe à une règle est stockée comme proposition et n'est pas appliquée tant qu'une personne ne l'a pas approuvée. Un agent ne peut pas approuver sa propre proposition.
• Une préférence personnelle qui n'est pas encore utilisée apparaît dans pathrule me list mais n'est jamais livrée, et en enseigner une n'enregistre rien qui ne puisse être ancré dans vos propres mots.
• Un constat est l'exception assumée : il est partagé comme conseil sans étape de revue, et il ne devient jamais une règle.

Voir Proposed Knowledge pour savoir où chacun de ces éléments attend.

Le texte complet est toujours à une lecture près

La livraison est budgétée par prompt, si bien que tout ce qui s'applique n'arrive pas en entier. Ce qui ne tient pas est listé par titre au lieu d'être supprimé sans bruit, pour que l'agent sache que cela existe. Lire une mémoire par son nom, avec pathrule_read_memory, renvoie toujours tout ce que votre équipe a écrit, car une lecture explicite est une demande de la source et non une livraison. Voir ce qui arrive en entier et ce qui arrive sous forme de nom.

Application déterministe

Le dernier mécanisme concerne ce qui ne devrait pas être une suggestion au départ.

Comprendre le sens d'un paragraphe, c'est le travail d'un modèle. S'assurer qu'une modification interdite n'a pas lieu ne l'est pas, et le confier à un modèle revient à compter sur un agent qui pèse correctement une phrase au quarantième tour d'une longue session.

• Une règle peut porter une contrainte exécutable, c'est-à-dire un motif qu'une modification ne doit pas contenir. Une fois approuvée par une personne, le hook pré-outil peut bloquer une modification correspondante et indiquer à l'agent quoi faire à la place, dans les clients dont les hooks d'outil permettent le blocage. Voir les règles comme garde-fous.
• Windsurf n'a pas de hooks : une règle y est livrée sous forme de texte et ne peut rien bloquer. Avec Remote MCP, aucun hook n'est installé non plus.
• La simple livraison n'est pas une application. Une règle sans contrainte exécutable approuvée est une exigence dont l'agent est informé, pas une exigence que le runtime vérifie.

Certaines connaissances ne doivent pas être de simples suggestions. C'est la frontière entre un produit de mémoire et un runtime, et c'est pourquoi la couche sémantique et la couche d'application sont séparées au lieu d'être fondues dans un prompt astucieux.

Ce que Pathrule ne revendique pas

Pathrule ne revendique ni zéro hallucination, ni un rappel parfait, ni une exactitude garantie. Aucun système faisant intervenir un modèle de langage ne peut honnêtement le prétendre, et un produit qui le prétend vous renseigne sur ses affirmations plutôt que sur son architecture.

Ce qu'il revendique est précis et vérifiable :

• La livraison transmet ce que votre équipe a écrit, en séparant les règles des conseils.
• Les constats ne sont livrés que tant que le code sur lequel ils reposent n'a pas changé, et les constats contradictoires sont retenus.
• Ce qu'un modèle ou un agent infère reste une proposition jusqu'à ce qu'une personne l'approuve.
• Ce qui ne tient pas est listé par titre, et le texte complet est toujours à une lecture près.
• Une contrainte exécutable approuvée peut être appliquée par le hook pré-outil dans les clients qui le permettent, au lieu d'être simplement mentionnée.