Activer l'indexation du code

Vous ouvrez cette page parce que @codebase ne retourne rien, ou parce que l’agent ignore visiblement le reste du dépôt. Ce n’est pas une panne.

Par défaut, rien n’est indexé. La configuration livrée déclare une liste de modèles vide et aucun fournisseur de contexte. Or la liste des index à construire est dérivée des fournisseurs de contexte déclarés : sans fournisseur qui en dépend, cette liste est vide, et le mécanisme tourne sans rien produire.

Les deux conditions

L’indexation démarre quand les deux sont réunies. Il en manque une, rien n’est construit, et aucun message ne le dit.

1. Un fournisseur de contexte qui dépend de l’index est déclaré dans le bloc context de la configuration. Trois seulement en dépendent : codebase, folder et code.
2. Un modèle portant le rôle embed est sélectionné.

repo-map et docs n’en font pas partie : le premier construit sa carte à la volée, le second a son propre index, séparé.

Sous VS Code

Un modèle d’embeddings local est ajouté d’office à la liste du rôle embed quand l’extension tourne dans VS Code. La deuxième condition est donc déjà remplie, et il reste à déclarer le fournisseur :

name: Local Config
version: 1.0.0
context:
  - provider: codebase

Enregistrez le fichier : l’ajout d’un index déclenche un cycle d’indexation sans qu’il faille redémarrer l’éditeur.

Sous JetBrains, ou avec votre propre modèle d’embeddings

Le modèle local n’est ajouté d’office que sous VS Code. Ailleurs, déclarez-en un explicitement :

name: Local Config
version: 1.0.0
models:
  - name: Embeddings
    provider: ollama
    model: nomic-embed-text
    roles:
      - embed
context:
  - provider: codebase

roles est obligatoire ici. Un modèle déclaré sans roles reçoit les rôles conversationnels et jamais embed : il ne servira pas à l’indexation, même s’il s’agit d’un modèle d’embeddings. C’est la cause la plus fréquente d’une indexation qui ne démarre pas.

La valeur de provider doit venir de Fournisseurs de modèles ; un identifiant inconnu écarte le modèle en silence.

Vérifier que l’index existe vraiment

Trois signaux mentent, et il faut le savoir avant de les lire :

• le dossier ~/.lemniscate/index/ est créé dans tous les cas ;
• le fichier ~/.lemniscate/index/index.sqlite apparaît dès qu’un cycle démarre, y compris quand ce cycle n’a aucun index à construire ;
• la progression affichée peut atteindre 100 % et annoncer la fin alors que rien n’a été écrit — le parcours des fichiers a lieu avant que la liste des index soit consultée.

Le signal fiable est le contenu du dossier des vecteurs :

ls -1 ~/.lemniscate/index/lancedb/

Un dossier vide, ou absent, signifie qu’aucun index n’a été construit. Le contrôle en usage reste ensuite fonctionnel : ouvrir le chat, écrire @codebase suivi d’une question sur un fichier que vous n’avez pas ouvert, et vérifier que la réponse cite du code réel.

Reconstruire, mettre en pause, exclure

Deux commandes de la palette agissent sur l’index. Codebase Force Re-Index relance un cycle sur ce qui a changé ; Rebuild codebase index efface les index existants avant de repartir — c’est celle à utiliser après avoir changé de modèle d’embeddings, les vecteurs produits par deux modèles n’étant pas comparables.

Le réglage lemniscate.pauseCodebaseIndexOnStart met le cycle en pause au démarrage de l’éditeur, sans le désactiver. L’écran Settings → Indexing porte un interrupteur qui, lui, coupe l’indexation.

Pour soustraire des fichiers à l’index, écrivez un .lemniscateignore à la racine du dépôt. Sa syntaxe est celle de .gitignore, et ses motifs peuvent annuler ceux du .gitignore du dépôt. Un fichier global, ~/.lemniscate/.lemniscateignore, s’applique à tous vos dépôts. Le nom .continueignore n’a aucun effet.

Un avertissement que vous allez rencontrer

L’écran Settings → Indexing affiche un bandeau annonçant l’indexation comme dépréciée, avec un lien vers un autre mécanisme. Le comportement décrit sur cette page est celui du code livré : les deux conditions ci-dessus produisent bien un index. Aucune date de retrait n’est annoncée dans le produit.