Fichier de configuration

Ces clés sont celles que le schéma de validation décrit. Une clé absente de cette page n’est pas pour autant refusée : le schéma laisse plusieurs objets ouverts, et le site enseigne ailleurs des clés qui fonctionnent sans figurer ici, celles d’un modèle en premier lieu. Voir ce que cette page ne couvre pas, en bas.

Les deux fichiers, et ce que chacun décide

Les réglages vivent dans deux fichiers, de même format :

Fichier	Portée
~/.lemniscate/workstation.yaml	la machine, tous projets confondus
.lemniscate/project.yaml	le dépôt, partagé par l’équipe qui y travaille

Le fichier de la machine décide de toutes les clés. Le fichier du dépôt ne décide que le contenu de l’équipe : context, docs, metadata, name, prompts, rules, schema, version. Tout le reste, écrit dans un fichier de dépôt, est ignoré : l’outil le dit au chargement, en nommant le fichier, la clé et la raison.

La clé prompts ne fait plus rien

Écrire une commande dans le fichier de configuration a été retiré le 2026-08-26. La clé prompts est encore acceptée pour que votre configuration continue de charger, mais son contenu n’est plus lu : elle ne produit plus de commande, ni dans l’IDE ni au terminal. Au chargement, l’outil nomme le bloc et dit quoi écrire à la place.

Ce qui la remplace : un fichier de commande posé dans .lemniscate/prompts/, dont le nom devient le nom de la commande. Reprenez le corps du bloc tel quel. Voir Écrire une commande personnalisée.

Pourquoi ce retrait : il y avait deux façons d’écrire la même chose, et l’utilisateur n’avait aucun moyen de savoir laquelle choisir. Le fichier de commande est celui que la documentation enseigne, que /init écrit, et qu’une équipe partage par son dépôt.

Pourquoi cette asymétrie : cloner un dépôt ne doit pas suffire à décider ce qui tourne sur la machine qui l’a cloné. Sans cette règle, un fichier versionné pourrait imposer le serveur par lequel sortent vos appels, éteindre la vérification des certificats, ou faire exécuter une commande. Une clé nouvelle est fermée par défaut : elle n’est décidable par un dépôt que si elle est ajoutée à cette liste, délibérément.

Sur les clés qu’il décide, le plus proche gagne : ce que dit le projet l’emporte sur ce que dit la machine. Un fichier peut en inclure un autre avec include: (chemins locaux uniquement) ; l’inclus devient une couche de plus, placée immédiatement en dessous de celui qui l’inclut, et un fichier inclus par un fichier de dépôt ne décide pas plus que lui.

Dans les listes, un élément peut porter un identifiant (id:), distinct de son nom affiché. Deux éléments de même identifiant venus de deux couches refusent le chargement, sauf si le plus proche déclare replaces: : aucune valeur n’est remplacée sans que le fichier le déclare. Un élément sans identifiant, lui, s’additionne toujours.

Au-dessus de tout, la politique de votre organisation : si un fichier règle ce qu’elle impose, l’outil l’affiche au chargement et applique la valeur imposée.

Les noms de clés ne se traduisent pas : ils s’écrivent tels quels dans ces fichiers.

Le schéma ne porte aucune description. Cette page liste donc les clés, leur type et leur caractère obligatoire, sans expliquer à quoi chacune sert. Le jour où le schéma sera annoté, les descriptions apparaîtront ici sans que personne n’ait à réécrire cette page.

À la racine

Clé	Type	Obligatoire
include	liste de string	non
name	string	non
version	string	non
schema	string	non
metadata	objet	non
env	object	non
requestOptions	object	non
execution	object	non
documentation	object	non
formatter	liste d’objets	non
models	liste (2 formes acceptées)	non
context	liste (2 formes acceptées)	non
data	liste (2 formes acceptées)	non
mcpServers	liste (2 formes acceptées)	non
rules	liste (2 formes acceptées)	non
prompts	liste (2 formes acceptées)	non
docs	liste (2 formes acceptées)	non

La clé execution

Les bornes de session, la détection de boucle et les filets de délégation. Ce que chaque clé fait, et ses défauts, sont expliqués sur Les garde-fous d’exécution et Déléguer à des sous-agents.

Clé	Type	Obligatoire
sessionMaxActions	integer	non
sessionMaxMinutes	integer	non
sessionMaxExtensions	integer	non
toolLoopDetection	boolean	non
toolLoopThreshold	integer	non
subagentMaxDepth	integer	non
subagentMaxPerSession	integer	non
subagentMaxConcurrent	integer	non

Un modèle

Le schéma accepte 2 formes pour une entrée de models.

Forme 1

Clé	Type	Obligatoire

Forme 2

Clé	Type	Obligatoire
uses	plusieurs formes acceptées	oui
with	object	non
override	plusieurs formes acceptées	non

Ce que cette page ne couvre pas

Le champ provider d’un modèle est validé comme une chaîne libre : la liste des valeurs qui fonctionnent réellement vit dans le code et non dans le schéma. Elle a sa propre page, Fournisseurs de modèles.

Les paramètres de chaque fournisseur de contexte ne sont pas décrits par le schéma non plus : il les accepte sans les contraindre.

Les clés d’un modèle ne sont pas décrites ici : le tableau des formes de modèle est vide parce que le schéma les accepte sans les nommer. Les clés que le reste du site fait écrire (provider, model, apiBase, apiKey, roles, capabilities, requestOptions, contextLength, autocompleteOptions) fonctionnent, et sont enseignées par les guides. Elles apparaîtront ici le jour où le schéma les portera.

Même chose pour connectionTimeout (serveurs MCP) et quickActions (extension VS Code) : le site les enseigne, le schéma ne les décrit pas.