Comment Pathrule démontre ses affirmations les plus exigeantes

L'exigence technique de Pathrule est simple : une affirmation produit doit reposer sur une entrée bornée, un comportement défini lorsque les preuves manquent, et un résultat vérifiable de manière indépendante.

Cette page rassemble ces contrats pour la manière dont les connaissances entrent dans Pathrule, sont sélectionnées puis livrées. Une connexion Remote MCP a une frontière de livraison différente : elle n'installe aucun hook, les connaissances arrivent donc lorsque l'agent appelle les outils de Pathrule.

La qualité des connaissances passe par plusieurs filtres

Pathrule n'injecte pas chaque fichier Markdown dans chaque prompt. Les connaissances franchissent des contrôles indépendants :

1. Découverte sélective. Lorsque votre agent lance l'analyse du projet, les fichiers d'instructions actifs, leur chaîne d'imports, les règles des outils et les décisions d'architecture sont distingués de la documentation générale. La documentation générale est proposée en revue au lieu d'être importée par défaut comme instruction active.

2. Revue avant persistance, exceptions comprises. Les connaissances déduites attendent une personne : les candidats issus de l'analyse du projet ne sont ajoutés qu'une fois approuvés, les suggestions de Team Intelligence n'atteignent les agents qu'après vérification par une personne, les corrections de connaissances obsolètes ne modifient rien tant qu'une tâche d'actualisation n'est pas résolue, et une contrainte exécutable qu'un agent propose pour une règle est stockée comme proposition et n'est pas appliquée tant qu'une personne ne l'a pas approuvée. Les écritures d'un assistant passent par les outils d'écriture de Pathrule, sont marquées comme provenant d'un assistant, versionnées et réversibles. Les constats de l'apprentissage du projet sont partagés sans étape de revue, comme des conseils à vérifier et jamais comme des règles. Deux choses sont écrites sans demander, uniquement sur un espace de travail Cloud et seulement la première fois qu'un agent demande un contexte approfondi : les paires de chemins de fichiers lues dans l'historique git récent, qui amorcent la détection des fichiers modifiés ensemble, et de courtes mémoires technologiques à la racine de l'espace de travail, reconnues à partir des noms de fichiers. Aucun contenu de fichier, diff ou message de commit n'est lu dans l'un ou l'autre cas. Voir Comment les connaissances fructifient.

3. Rattachement à un chemin. Une entrée appartient au chemin le plus restreint de l'espace de travail qui la possède. Un travail mené en dehors de ce chemin ne la reçoit pas au seul motif qu'elle se trouve dans le même dépôt.

4. Pertinence pour la requête. Une entrée doit encore être retenue pour la requête en cours, à chaque fois. L'éligibilité et l'ordre sont décidés séparément et ne s'intervertissent jamais : l'une décide si une entrée est éligible, l'autre décide de l'ordre parmi celles qui le sont déjà. L'apprentissage n'agit que sur l'ordre. Il peut faire passer une mémoire éprouvée de la quatrième à la première place ; il ne peut jamais faire livrer une entrée inéligible. Le volume est lui aussi borné : la livraison tient dans un budget par prompt, de sorte que la quantité livrée ne croît pas avec la taille de la base de connaissances.

   C'est pourquoi une rédaction rigoureuse n'est pas une condition préalable à un prompt sans bruit. Une entrée vague ou mal rédigée ne devient pas du bruit ; elle n'est simplement jamais retenue pour une requête sans rapport avec elle. Le coût visible d'une mémoire faible, c'est qu'elle n'apparaît pas.

5. Livraison et usage mesurés. Pathrule enregistre ce qu'il a livré et ce que l'assistant a consulté. Les couches dérivées indiquent quand elles ont reçu des données pour la dernière fois, ce qui permet de distinguer un système calme d'un système déconnecté.

   La même rigueur s'applique aux raisons pour lesquelles une entrée n'a pas été livrée. « Rien n'a été retenu », « l'appel de priorisation a expiré », « la réponse était mal formée » et « il n'y avait rien à prioriser » sont enregistrés comme des résultats distincts plutôt que sous un seul terme, car ce sont des situations différentes appelant des corrections différentes. Un ralentissement est signalé comme tel, il n'est donc jamais confondu avec une base de connaissances vide.

   Lorsque des connaissances pertinentes ne tiennent pas dans le budget, ou que leur contenu n'est pas déjà présent sur la machine, elles sont proposées par leur titre au lieu d'être abandonnées, afin que l'assistant puisse aller les chercher délibérément. Écarter une réponse correcte parce qu'elle est mal placée est précisément ce que ce mécanisme cherche à éviter.

6. Maintenance sous revue. Les connaissances qu'un agent juge obsolètes, contredites par le code, dupliquées ou peu claires sont soumises à revue sous forme de tâche d'actualisation, et rien n'est modifié tant que cette tâche n'est pas résolue. Les écritures sont versionnées, les conflits sont explicites et les suppressions sont réversibles.

Ces filtres font des connaissances partagées un petit système d'exploitation inspectable pour un dépôt. C'est grâce à eux qu'un projet peut accumuler ses décisions sans transformer toute son archive documentaire en contexte par défaut. Voir Comment les connaissances fructifient et Suggestions et auto-audit.

Vérification datée

Le 23 août 2026, des vérifications automatisées ciblées sur ces contrats ont réussi dans le dépôt principal du produit Pathrule, notamment sur la découverte des connaissances, l'ordre des imports et l'exclusion des sources bruitées.

Le benchmark public de livraison de contexte est reproductible séparément sur github.com/pathrule/benchmarks. Notre méthode de mesure en publie la méthode, les artefacts bruts et les résultats contrastés. Les résultats mesurés décrivent les configurations sur lesquelles ils ont été obtenus ; ils ne constituent pas une garantie pour votre dépôt.

Une règle d'évaluation utile

Pour toute affirmation de Pathrule, posez trois questions :

1. Quelles preuves entrent dans la décision ?
2. Que se passe-t-il lorsque ces preuves manquent ou sont ambiguës ?
3. Quel résultat est autorisé à modifier ou à bloquer le travail ?

Les contrats ci-dessus répondent à ces trois questions. C'est ce qui distingue une description de fonctionnalité d'une affirmation d'ingénierie.