Recherche ordinaire et index local optionnel

	Ordinaire (par défaut)	Avancé : index local (optionnel)
Ce que ça fait	Lit le .fig à chaque appel et répond à search, find, inspect et export.	Construit une fois un index de recherche d'une portée choisie, puis répond à search depuis cet index, classé entre les sources.
Ce qui est écrit	Ni workspace ni base d'index (export n'écrit que les fichiers demandés).	Un workspace local (base SQLite) dans le répertoire d'état de l'utilisateur, ou sous le --storage choisi.
Quand l'utiliser	Questions ponctuelles, scripts, CI.	Recherches répétées dans un fichier ; plusieurs fichiers d'un projet comme un seul corpus (--workspace <dir>) ; usages exacts des composants, variables, styles et images.

Une question de design ordinaire ne crée jamais d'index. Vous l'activez une fois, explicitement (« crée un index pour ce design ») ; figlens choisit le stockage et n'exige ni SQLite ni autre configuration.

# Ordinaire : sans état, ne crée rien
figlens search design.fig "checkout button"

# Avancé, une fois : choisir une portée (un id de nœud, ou 0:0 pour tout le fichier) ; la construction s'exécute au premier plan
figlens index prepare design.fig --scope 0:0

# Recherche indexée ; ajouter --node si la portée indexée n'est pas tout le fichier
figlens search --file design.fig "checkout button" --node 0:0

# Après modification ou réexport du .fig : reconstruire seulement les portées dont les octets ont changé
figlens index refresh --file design.fig

# Après déplacement du .fig : garder le workspace, puis refresh (utiliser le workspaceId affiché par prepare)
figlens index relocate <sourceId> new/design.fig --id <workspaceId>
figlens index refresh --id <workspaceId>

MCP : index prepare renvoie un job ; interroger jobs jusqu'à succeeded, puis chercher avec le workspaceId de la réponse.

{"tool": "index", "arguments": {"action": "prepare", "file": "/abs/path/design.fig", "scope": "0:0"}}
{"tool": "jobs", "arguments": {"action": "status", "jobId": "<jobId from the reply>"}}
{"tool": "search", "arguments": {"workspaceId": "<workspaceId from the reply>", "node": "0:0", "query": "checkout button"}}

Cycle de vie : refresh reconstruit seulement les portées dont les octets du .fig ont changé ; rebuild reconstruit même sans changement ; clear_cache supprime seulement ce qu'une construction peut recréer et garde le registre et les index publiés ; reset supprime la base de ce workspace (jamais le .fig ni les exports) et ne s'exécute que sur demande explicite. De nouvelles sources, une portée plus large, reset et recréation exigent chacun leur propre demande explicite.

.fig déplacé ? index relocate garde workspaceId, sourceId et le stockage ; faites ensuite refresh des portées concernées. Pas de découverte automatique ni de fusion par hash, et aucun reset n'est nécessaire.

Plusieurs designs dans un dossier ? index add <dir> --workspace DIR enregistre en une fois jusqu'à 10 fichiers .fig de ce répertoire et ignore les liens qui en sortent ; la réponse liste added, existing, skipped et truncated, une répétition n'ajoute rien, et chaque fichier a toujours besoin de son propre prepare --scope. Un fichier déplacé dans le dossier est une nouvelle source, sauf avec relocate. Passez le nextCursor de la réponse en --cursor C (MCP cursor) pour ajouter les 10 suivants. Les curseurs paginés de recherche et de bibliothèque durent une heure ; ensuite ils renvoient cursor_expired, il faut donc relancer la recherche.

Données : la base SQLite contient les chemins locaux enregistrés, les noms de calques et le texte effectif des portées choisies, les valeurs des propriétés de composant des instances, les postings de recherche, les relations exactes (imbrication, instances, variantes, liaisons de variables/styles/images, cibles de prototype) et les définitions qu'elles désignent, les hashes, les générations et les jobs. Le .fig d'origine reste inchangé où il est ; ses octets bruts ne sont pas stockés dans la base. Les couches des modèles sémantiques et de vision y ajoutent les vecteurs qu'elles intègrent, et l'indexation visuelle que vous activez ajoute des rendus PNG des calques indexés, même sans modèle ; les images de requête ne sont jamais stockées.

Pi, OpenCode et OMP utilisent le même index via leur propre entrée opt-in, et le workspace est réutilisé entre redémarrages et hôtes. Non implémenté : événements de fichier (un watch interroge le fichier, et seulement tant qu'un holder tourne) et événements push.