User Intelligence

Workspace Intelligence porte le projet. User Intelligence porte la personne derrière le travail.

Deux ingénieurs travaillant dans le même dépôt n'attendent pas la même chose d'un agent, et la différence n'a rien de cosmétique. Elle porte sur la part de décision que l'agent doit prendre seul, sur le moment où il doit s'arrêter pour proposer des options plutôt que d'implémenter, sur le niveau de vérification jugé suffisant, et sur la direction à prendre quand deux conceptions se défendent toutes les deux.

C'est un véritable ensemble de connaissances, et faute d'endroit où le conserver, il vit dans les corrections que vous retapez à chaque nouvelle session.

Ce qu'elle modélise

Préférences d'exécution

Si vous voulez un refactoring incrémental ou si vous êtes ouvert à une réécriture. Si vous tenez à voir des options avant une implémentation, ou si vous préférez que l'agent avance directement sur un certain type de changement. Le niveau d'abstraction que vous jugez justifié. Les types de changement sur lesquels vous voulez être consulté avant qu'ils aient lieu.

Schémas de décision

Les compromis que vous avez tendance à faire. Performance contre maintenabilité. Développer contre adopter. Votre degré d'exigence sur la rétrocompatibilité. Ce que vous pesez en premier quand une décision produit entre en conflit avec une décision technique.

Exigences de qualité

Le volume de tests que vous attendez. Quand vous voulez un benchmark plutôt qu'un argument. Quand la recherche suffit, et quand elle est devenue un prétexte pour ne pas livrer. Ce que vous entendez par « terminé », et le niveau de validation qui va avec.

Style de collaboration

Le degré d'autonomie de l'agent. Quand vous attendez une question. Quand vous attendez un choix. La façon dont vous voulez qu'on vous rende compte du travail, et avec quelle densité d'explication.

Ce qu'elle ne modélise pas

Pas qui vous êtes. Ni données démographiques, ni personnalité, ni rien qui soit déduit de vous en tant que personne. L'unité est une préférence de travail sur la manière de mener le développement logiciel, et chacune d'elles est quelque chose que vous auriez pu dire à voix haute.

Trois types d'énoncés sont refusés d'emblée au lieu d'être stockés :

• Tout ce qui est personnel. Santé, religion, politique, sexualité, origine ethnique, finances et relations privées sortent du périmètre de ce que Pathrule conserve, quel que soit le sujet de la phrase.
• Une règle déguisée en préférence. Une préférence est un conseil donné à un agent. Un énoncé formulé comme une interdiction (« jamais », « ne doit pas », « interdit ») se lirait comme une exigence du projet, une autorité qu'il n'a pas, il n'est donc pas stocké. Si quelque chose ne doit vraiment jamais se produire dans un projet, sa place est dans ce projet, sous forme de règle.
• Un fait propre à un projet. « Dans ce dépôt, on utilise le helper de configuration partagé » est vrai pour une base de code, pas pour vous. Stocké comme une préférence personnelle, il vous suivrait dans le dépôt d'un client où il serait faux. Ce sont des connaissances de l'espace de travail, et elles restent dans l'espace de travail.

Comment elle apprend

C'est vous qui l'alimentez. Lancez pathrule me teach avec la phrase que vous retaperiez sinon à chaque nouvelle session :

pathrule me teach "Show me options before implementing anything that changes a public API"

Le modèle local, optionnel, lit la phrase sur votre propre machine et la transforme en préférence de travail structurée. Tout ce qu'il en conclut doit figurer dans vos propres mots : il n'a pas le droit de vous paraphraser pour en tirer une préférence que vous n'avez jamais exprimée, et lorsqu'il ne peut pas désigner ce que vous avez écrit, rien n'est stocké et le CLI vous en indique la raison.

What you teach
      |
Checked against your own words
      |
Refused, or stored as a preference
      |
Active, and delivered where it applies

Concrètement, si vous répétez sans cesse une variante de « ne transforme pas chaque implémentation en projet de recherche », la représentation utile n'est pas une citation enregistrée. C'est une préférence de travail :

Prefer implementation once the primary correctness
questions are resolved.

Source:     you told Pathrule
Applies:    across workspaces

L'apprentissage nécessite un Mac Apple Silicon avec le modèle local installé. Tout le reste de cette page, y compris la transmission, fonctionne sans lui.

Changer d'avis

Quand vous enseignez une nouvelle préférence qui contredit une préférence antérieure portant sur le même type de travail, la nouvelle remplace l'ancienne. L'ancienne est retirée, pas supprimée, et garde un lien vers celle qui l'a remplacée : la question « pourquoi cela a-t-il changé ? » a donc toujours une réponse. Deux préférences portant sur des types de travail différents restent simplement valables toutes les deux.

Qui est « l'utilisateur »

Les préférences sont rédigées à votre sujet. Quand vous parlez des personnes qui utilisent ce que vous construisez, la formulation risque donc de les transformer discrètement en vous. « Résoudre les problèmes sans montrer d'erreurs aux utilisateurs » serait lu par un agent comme « ne me montre pas d'erreurs », soit l'inverse de ce que vous vouliez dire. Lorsque vos propres mots portaient sur vos utilisateurs, la préférence continue de parler d'« utilisateurs finaux ».

Où une préférence s'applique

User Intelligence vous appartient, pas à un dépôt. Le périmètre d'application de chaque préférence est une question distincte.

• Ce que vous enseignez s'applique partout. La préférence n'a pas été apprise à partir d'un projet, elle n'est donc rattachée à aucun.
• Vous pouvez en limiter une à un espace de travail. pathrule me scope <id>, lancé dans un dépôt, limite cette préférence à l'espace de travail où vous l'exécutez. pathrule me scope <id> --everywhere la rend de nouveau applicable dans tous les espaces de travail.

Comment une préférence parvient à un agent

Avant chaque tour, Pathrule sélectionne les préférences qui s'appliquent au travail sur le point d'être fait.

• Uniquement les préférences actives. Une préférence qui n'est pas encore utilisée apparaît dans pathrule me list mais ne parvient jamais à un agent. Les préférences retirées et rejetées ne sont pas utilisées non plus.
• Uniquement celles qui sont dans le périmètre de l'espace de travail, comme décrit plus haut.
• Uniquement celles qui concernent cette tâche. Une préférence sur la façon de travailler avec vous s'applique à n'importe quelle tâche. Une préférence portant sur un type de travail, comme l'architecture ou les migrations, ne parvient à un agent que lorsque la tâche porte sur ce sujet.
• Un petit nombre par tour, les plus fortes en premier. S'il y en a davantage qui s'appliquent, ce sont les plus faibles qui sont écartées.
• Chacune indique son origine, pour qu'un agent puisse accorder à « vous l'avez dit » le poids qui lui revient.

Elles arrivent par le hook de prompt, chacune une seule fois par session, sous un intitulé qui indique à l'agent que les règles et les vérifications obligatoires de l'espace de travail passent en premier. Aujourd'hui, cela concerne les sessions Claude Code et Codex. Cursor et GitHub Copilot disposent de hooks de session et d'outil mais pas de hook de prompt, et Windsurf n'a aucun hook : les préférences ne leur parviennent donc pas. Voir le fonctionnement des hooks.

Autorité : que se passe-t-il quand vous et le projet n'êtes pas d'accord

Une préférence utilisateur ne prime pas sur la vérité du projet.

User Intelligence
Prefer minimal testing.

Workspace Intelligence
Rule: run migration verification before completion.

C'est la règle qui s'applique. Elle constitue une exigence de l'espace de travail, et une préférence pour moins de vérification n'est pas une raison de l'abandonner.

Le principe général, qui mérite d'être énoncé clairement :

• Workspace Intelligence représente la vérité et les exigences du projet. Ses règles et ses vérifications obligatoires sont des exigences strictes.
• User Intelligence façonne la collaboration : la manière d'aborder le travail, la part réalisée de façon autonome, la manière d'en rendre compte. Elle ne redéfinit pas ce que « correct » veut dire.

Lorsque les deux ne portent que sur le style, votre préférence s'applique. Lorsque l'espace de travail pose une exigence de sécurité ou de correction, cette exigence est maintenue.

Il en va de même en l'absence de règle d'espace de travail. Une préférence susceptible de réduire la vérification est mise de côté dès que le travail touche à l'authentification, aux paiements, aux migrations de données, à la cryptographie ou à la sécurité. Les erreurs y sont silencieuses et coûteuses, et une préférence forgée sur du code ordinaire ne dit rien de sa pertinence dans ces domaines.

Ce que vous contrôlez

Tout. User Intelligence est inspectable plutôt qu'implicite. Pour chaque préférence, vous voyez :

• Son statut : candidate, active, retirée ou rejetée.
• Son origine, et son degré de certitude.
• Son périmètre : tous les espaces de travail, ou un seul.
• Sa justification : les mots sur lesquels elle repose, avec leurs dates.

Et vous pouvez :

• Enseigner une préférence directement.
• Oublier une préférence. Elle cesse d'être utilisée et elle est conservée comme rejetée, pour que le même énoncé ne la fasse pas revenir aussitôt. Ajoutez --delete pour la supprimer complètement.
• En limiter une à cet espace de travail, ou en étendre une à tous.
• Vérifier ce qu'un agent recevrait pour une tâche avant de la commencer.

Une inférence que vous ne voyez jamais est une inférence que vous ne pouvez pas contester : c'est pourquoi chaque préférence est à une commande de distance.

En ligne de commande

pathrule me list                    # what is in use, and what is not yet
pathrule me teach "I prefer incremental refactors"
pathrule me explain <id>            # the evidence behind one preference
pathrule me scope <id>              # keep it to the workspace you run this in
pathrule me scope <id> --everywhere # let it apply in every workspace
pathrule me forget <id>             # stop using it
pathrule me forget <id> --delete    # remove it entirely
pathrule me context "add a payments webhook"

pathrule me context affiche exactement ce qu'un agent recevrait pour cette tâche, ainsi que les préférences mises de côté et la raison. C'est le moyen le plus rapide de vérifier qu'une préférence atteint bien le travail auquel vous la destiniez, et uniquement celui-là. Toutes les sous-commandes acceptent --json.

Passer d'un projet à l'autre

Ouvrez un autre dépôt et les connaissances du projet qui vous entourent changent du tout au tout. Les préférences que vous avez enseignées, sauf celles que vous avez limitées à un seul espace de travail, vous suivent.

C'est là que les deux se rejoignent lors d'un tour : l'espace de travail apporte ce qui est vrai et exigé ici, vous apportez la manière de faire le travail, et la transmission place les exigences du projet au-dessus de vos préférences. Voir Agent IR.

Limites à connaître

• La correspondance se fait sur les mots, pas sur le sens. Une préférence atteint une tâche qui partage ses termes. Une préférence formulée très différemment de la tâche peut la manquer.
• L'apprentissage nécessite le modèle local, qui ne tourne que sur les Mac Apple Silicon.
• Les préférences ne parviennent qu'aux clients dotés d'un hook de prompt : Claude Code et Codex.
• Elle s'abstient plutôt que de deviner. Une phrase qu'elle ne peut pas ancrer dans vos propres mots n'est pas stockée. Manquer une préférence vous coûte une phrase de plus ; en inventer une vous représenterait faussement auprès de chaque agent avec lequel vous travaillez.

Confidentialité

L'inférence qui transforme ce que vous enseignez en préférence structurée s'exécute sur votre propre appareil, et vos préférences sont conservées dans un stockage privé sur votre machine.

Si vous partagez un espace de travail avec une équipe, ce qui se synchronise, ce sont les connaissances de l'espace de travail, pas vos préférences de travail personnelles. Et lorsque vous utilisez Claude Code, Codex ou un autre agent, les limites propres au fournisseur de cet agent s'appliquent à tout ce qui lui parvient. La page Sécurité distingue ces limites, car les fondre en une seule phrase, c'est le moyen le plus sûr de rendre une affirmation fausse.

Pour aller plus loin

• Workspace Intelligence : ce qu'apporte le projet, et pourquoi ses exigences priment.
• Le modèle local : ce qui s'exécute sur votre appareil et comment l'installer.
• Référence des commandes CLI : toutes les sous-commandes pathrule me, aux côtés du reste du CLI.