Quand la configuration ne charge pas

Un bandeau rouge annonce Error loading … et Chat is disabled until a model is available. Le chat ne répond plus. Le bandeau offre trois commandes : Help, Reload et View.

Ce bandeau signale que le chargement de la configuration s’est arrêté sur une erreur fatale. Ce n’est ni une panne du modèle ni une panne du réseau : le produit refuse de démarrer sur une configuration qu’il n’a pas comprise en entier.

Commencez par View : la page de configuration affiche le détail de l’erreur et nomme la cause dans la plupart des cas.

Les causes, dans l’ordre où elles se rencontrent

Un modèle mal déclaré

La validation refuse un modèle sans nom, ou dont provider n’est pas une chaîne. Le message cite l’index du modèle en cause, par exemple Model at index 2 has an invalid or missing 'title'. L’index compte à partir de zéro, dans l’ordre du fichier. Le title du message est le name écrit dans workstation.yaml.

Un cas voisin n’est pas fatal : un modèle dont contextLength et completionOptions.maxTokens sont trop proches. La validation demande au moins 1000 jetons d’écart et émet un avertissement en dessous, parce que la question serait tronquée.

Pour la liste des valeurs de provider acceptées, voyez Fournisseurs de modèles ; pour la forme attendue du fichier, Le fichier de configuration.

Un champ dont le type ne correspond pas

models, context et les commandes de session doivent être des listes ; un champ booléen, tel que disableSessionTitles, doit valoir true ou false. Un disableSessionTitles: "true" entre guillemets est une chaîne et non un booléen, et l’erreur est fatale.

Un bloc référencé qui n’existe pas

Le message Failed to load config due to missing blocks signale que le fichier importe un bloc (un modèle, une règle) qui n’a pas pu être résolu. La liste des blocs manquants est affichée sous le message. Chaque entrée est soit un nom mal orthographié, soit un bloc auquel votre organisation n’a pas accès.

Le fichier n’est pas de l’YAML valide

Une indentation irrégulière, un deux-points dans une valeur sans guillemets, une tabulation : l’analyse échoue avant toute validation, et le message porte la ligne et la colonne fautives. Pour vérifier le fichier hors de l’éditeur :

python3 -c "import yaml,sys; yaml.safe_load(open(sys.argv[1]))" ~/.lemniscate/workstation.yaml

Un secret que rien ne résout

Une valeur écrite ${{ secrets.MA_CLE }} est remplacée au chargement. Quand aucune source ne la fournit, le bloc qui la porte reste incomplet et rejoint la liste des blocs manquants du message précédent.

Quatre endroits sont consultés, dans cet ordre : les variables d’environnement du processus, le fichier ~/.lemniscate/.env, le fichier .lemniscate/.env du dépôt ouvert, puis un .env à la racine de ce dépôt. Une valeur vide est ignorée et la recherche continue à la source suivante. Une ligne par valeur :

MA_CLE=sk-exemple-remplacez-cette-valeur

Une erreur de lecture du fichier .env n’interrompt pas le chargement : elle est écrite dans le journal sous la forme Error reading ~/.lemniscate/.env file, et le secret reste introuvable. Dans ce cas, le bandeau ne dit pas la cause ; le journal, décrit plus bas, la porte.

Un provider interdit par votre organisation

Ce cas n’est pas fatal : la configuration charge, et un modèle manque. Si la page de configuration affiche Model provider "…" is forbidden by your organization's policy, une politique d’organisation interdit ce fournisseur de modèles sur le poste. L’entrée est écartée, même si sa clé d’API est valide, et les autres modèles du fichier chargent. La règle est posée par l’administrateur du parc : modifier workstation.yaml ne la lève pas.

Deux éléments qui portent le même identifiant

Les réglages viennent de plusieurs fichiers superposés : celui du dépôt (.lemniscate/project.yaml), celui de la machine (~/.lemniscate/workstation.yaml), et ceux que l’un ou l’autre inclut. Deux éléments de même identifiant (id:) venus de deux fichiers refusent le chargement. Le message nomme les deux fichiers :

The rule `house-style` is defined in both .lemniscate/project.yaml and
~/.lemniscate/workstation.yaml. Add `replaces: house-style` to the one in
.lemniscate/project.yaml to take its place, or give one of them another id.

Deux réparations, au choix : donner un autre identifiant à l’un des deux, ou déclarer que le plus proche remplace l’autre :

rules:
  - id: house-style
    replaces: house-style
    name: House style
    rule: "Noms explicites, en anglais"

Un replaces: qui ne désigne rien refuse aussi le chargement. C’est le cas d’une faute de frappe, et le refus la rend visible.

Deux fichiers de blocs de même nom (.lemniscate/rules/house-style.md dans le dépôt et sur la machine) sont le même cas : un fichier de bloc porte l’identifiant de son nom de fichier.

Une inclusion qui ne se lit pas

include: n’accepte que des chemins locaux, relatifs au fichier qui les écrit ou absolus. Trois refus possibles, chacun nommé dans le message : un fichier introuvable, une adresse réseau (https://…), et une boucle d’inclusions. Dans ce dernier cas, le message affiche la chaîne complète des inclusions.

Un ancien config.yaml qui traîne

Le fichier de la machine s’appelle workstation.yaml. Un ~/.lemniscate/config.yaml n’est pas lu, et sa présence sans workstation.yaml refuse le démarrage :

~/.lemniscate/config.yaml is no longer read: the settings file of the machine is now
workstation.yaml, so that the file of a repository can be named project.yaml without
the two sharing a name. Rename it to ~/.lemniscate/workstation.yaml — its contents
do not change.

La réparation est le renommage ; le contenu ne change pas.

Repartir d’une configuration qui charge

Quand la cause reste introuvable, mettez votre fichier de côté et laissez le produit en recréer un :

mv ~/.lemniscate/workstation.yaml ~/.lemniscate/workstation.yaml.avant-panne

Reload dans le bandeau recharge la configuration sans redémarrer l’éditeur. Un fichier neuf est écrit, le chat repart, et vous réintroduisez vos blocs un par un jusqu’à retrouver celui qui casse.

Attention à l’ancien format. Un ~/.lemniscate/config.json n’est lu que si workstation.yaml est absent. Déplacer le YAML fait donc reprendre le JSON, avec ses propres erreurs : déplacez les deux pour repartir de zéro.

Retrouver les journaux

Le bandeau ne montre que le dernier message. Le journal garde la trace complète du chargement, pile d’appels comprise. C’est le fichier à joindre à un signalement de bogue.

Le fichier est le même sur les trois environnements : ~/.lemniscate/logs/core.log.

Un second fichier, ~/.lemniscate/logs/prompt.log, enregistre ce qui a été envoyé aux modèles. Il contient le contenu de vos échanges : relisez-le avant de le joindre à un signalement.

Environnement	Chemin d’accès
VS Code	commande Lemniscate: View Logs, qui ouvre les outils de développement
JetBrains	action Open Logs, qui ouvre ~/.lemniscate/logs/core.log
lemni	pas de commande dédiée : lisez le fichier

Pour joindre les dernières lignes à un signalement :

tail -n 100 ~/.lemniscate/logs/core.log

Si LEMNISCATE_GLOBAL_DIR est définie dans votre environnement, tous les chemins de cette page vivent sous ce répertoire et non sous ~/.lemniscate.