Écrire des règles pour l'agent

Une règle porte une consigne que vous répétez sinon à chaque conversation : la convention de nommage du projet, le framework de test à utiliser, l’interdiction de toucher un dossier.

Une règle fait partie de votre consigne. Elle s’écrit donc dans votre configuration : la consigne du développeur est la seule source de contrôle d’une session, et un fichier lu dans le dépôt n’en est pas une (livre blanc sécurité V3, section 5.2). La section Les fichiers de consignes présents dans un dépôt décrit ce que l’agent fait de ces fichiers.

Écrire la règle dans le fichier de configuration

Le bloc rules de ~/.lemniscate/workstation.yaml accepte une consigne en clair, ou un objet :

name: Local Config
version: 1.0.0
rules:
  - Répondre en français.
  - name: Pas de secrets
    rule: Ne jamais écrire de clé d'API dans un fichier suivi par git.
    globs: "**/*.ts"

Sous la forme objet, name et rule sont tous deux obligatoires. Les champs globs, regex et alwaysApply y ont le même sens que dans un fichier de règle, décrit plus bas.

Écrire la règle dans votre dossier personnel

Un fichier .md déposé dans ~/.lemniscate/rules/ est une règle qui vous suit sur tous vos dépôts. Les sous-dossiers sont parcourus.

# Conventions de test

- Les tests utilisent Vitest, jamais Jest.
- Aucun accès réseau dans un test.
- Les messages d'erreur sont en français.

Sans front-matter, la règle s’applique à chaque requête, quel que soit le fichier ouvert.

La règle qui ne vaut que pour certains fichiers

Un front-matter dit à quoi la règle s’applique :

---
name: Composants React
description: Conventions des composants de l'interface
globs:
  - "src/components/**/*.tsx"
---

- Un composant par fichier, exporté nommément.
- Aucun appel réseau dans un composant : passer par un hook.

Champs reconnus dans le front-matter :

Champ	Effet
name	le nom affiché ; à défaut, les deux derniers segments du chemin
description	une phrase, à destination du modèle
globs	les fichiers concernés, une chaîne ou une liste
regex	une expression régulière sur le contenu
alwaysApply	force l’application, ou l’empêche
invokable	fait de la règle une commande à appeler, non une règle permanente

Le champ invokable fait basculer le fichier d’une famille à l’autre : une règle appelable n’est plus jointe à vos demandes, elle attend que vous tapiez son nom. Réciproquement, un fichier de règle ordinaire n’apparaît pas dans la liste des commandes.

Un front-matter dont le YAML est invalide est ignoré sans refus : le fichier entier devient le corps de la règle, et les globs qu’il déclarait n’existent pas. Une règle qui s’applique partout alors qu’elle visait un dossier se diagnostique là.

Le terminal ne retient que les règles qui s’appliquent sans condition. Une règle qui porte globs, regex ou alwaysApply: false se déclenche en fonction des fichiers en contexte ; lemni n’a pas cette notion et l’écarte, qu’elle vienne du bloc rules ou du dossier personnel.

Deux combinaisons à connaître

Sans globs, sans regex et sans alwaysApply, la règle s’applique toujours.

alwaysApply: false sans globs ni regex donne une règle qui ne s’applique jamais : rien ne la déclenche. C’est une façon de désactiver une règle sans la supprimer.

La règle d’une seule session

Dans lemni, l’option --rule ajoute une règle pour la session qu’elle lance. Elle reçoit un texte, ou le chemin d’un fichier de votre poste, et se répète :

lemni --rule "Répondre en français." --rule "Les tests utilisent Vitest."

Les fichiers de consignes présents dans un dépôt

Un dépôt peut contenir des fichiers écrits pour instruire un agent : un fichier AGENTS.md ou CLAUDE.md à la racine, un dossier .lemniscate/rules/, un rules.md posé dans un dossier.

Ces fichiers font partie de la copie de travail. L’agent peut les lire comme n’importe quel autre fichier du dépôt, et leur contenu est alors marqué comme non fiable et présenté au modèle dans une zone distincte de votre consigne. Un contenu lu dans le dépôt n’active aucun outil et n’élargit aucun droit : les outils disponibles sont fixés par la politique du projet avant toute lecture (livre blanc sécurité V3, section 5.2).

Pour qu’une convention écrite dans un de ces fichiers ait valeur de consigne, relisez-la et recopiez-la dans une de vos règles.

Quand deux règles se contredisent

Vous pouvez poser une consigne à plusieurs endroits, et deux consignes peuvent se contredire. Le produit tranche selon la portée.

Chaque consigne est remise à l’agent étiquetée de la portée pour laquelle elle a été écrite, de la plus large à la plus étroite :

Portée	Ce qu’elle recouvre
product	le message de base du produit
configuration	le bloc rules de votre fichier de configuration, l’option --rule
personal	les fichiers de votre dossier de règles personnel

La portée la plus étroite l’emporte, et l’agent a pour consigne de dire laquelle il a écartée. Une règle de votre dossier personnel passe donc avant une entrée du bloc rules, et toute règle que vous écrivez passe avant le message de base du produit.

Deux consignes de la même portée ne se départagent pas. Deux fichiers de votre dossier personnel sont des pairs : l’agent a pour consigne de signaler la contradiction plutôt que d’en choisir une. Leur nom de fichier n’entre pas dans la décision.

Aucune règle ne modifie la politique du projet. Celle-ci est écrite par l’administrateur, évaluée par la passerelle avant chaque action, et n’est pas lue comme une consigne par le modèle (livre blanc sécurité V3, section 5.1).

Vérifier qu’une règle est prise en compte

Dans l’IDE, l’enregistrement d’un fichier de règles recharge la configuration : la règle est active à la requête suivante, sans redémarrage. lemni lit les règles au démarrage de la session : après avoir écrit une règle, relancez-le.

Le contrôle le moins ambigu consiste à poser dans la règle une consigne dont l’effet est visible dans la réponse, une formule imposée ou un refus attendu, puis à la demander. Une règle qui ne change rien à la réponse n’est pas chargée.

Vous pouvez aussi demander à l’agent d’où vient une consigne : chaque règle lui arrive avec le nom du fichier qui la porte, et il peut le citer.