Búsqueda ordinaria e índice local opcional

	Ordinario (por defecto)	Avanzado: índice local (opcional)
Qué hace	Lee el .fig en cada llamada y responde search, find, inspect y export.	Construye una vez un índice de búsqueda de un ámbito elegido y responde search desde él, con ranking entre fuentes.
Qué se escribe	Ningún workspace ni base de datos de índice (export solo escribe los archivos que pidas).	Un workspace local (base de datos SQLite) en el directorio de estado del usuario, o en el --storage elegido.
Cuándo usarlo	Preguntas puntuales, scripts, CI.	Búsquedas repetidas en un archivo; varios archivos de un proyecto como un solo corpus (--workspace <dir>); usos exactos de componentes, variables, estilos e imágenes.

Una pregunta de diseño normal nunca crea un índice. Lo activas una vez, de forma explícita («crea un índice para este diseño»); figlens elige el almacenamiento y no requiere SQLite ni otra configuración.

# Ordinario: sin estado, no crea nada
figlens search design.fig "checkout button"

# Avanzado, una vez: elige un ámbito (un id de nodo, o 0:0 para todo el archivo); la construcción corre en primer plano
figlens index prepare design.fig --scope 0:0

# Búsqueda indexada; añade --node si el ámbito indexado no es todo el archivo
figlens search --file design.fig "checkout button" --node 0:0

# Tras editar o reexportar el .fig: reconstruye solo los ámbitos cuyos bytes cambiaron
figlens index refresh --file design.fig

# Tras mover el .fig: conserva el workspace y luego refresh (usa el workspaceId que imprime prepare)
figlens index relocate <sourceId> new/design.fig --id <workspaceId>
figlens index refresh --id <workspaceId>

MCP: index prepare devuelve un job; consulta jobs hasta succeeded y busca con el workspaceId de la respuesta.

{"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"}}

Ciclo de vida: refresh reconstruye solo los ámbitos cuyos bytes del .fig cambiaron; rebuild reconstruye aunque no haya cambios; clear_cache borra solo datos que una construcción puede recrear y conserva el registro y los índices publicados; reset borra la base de datos de este workspace (nunca el .fig ni las exportaciones) y solo se ejecuta a petición explícita. Nuevas fuentes, un ámbito más amplio, reset y recrear exigen cada uno su propia petición explícita.

¿Moviste el .fig? index relocate conserva workspaceId, sourceId y el almacenamiento; después haz refresh de los ámbitos afectados. No hay autodescubrimiento ni fusión por hash, y no hace falta reset.

¿Varios diseños en una carpeta? index add <dir> --workspace DIR registra en un solo paso hasta 10 archivos .fig de ese directorio y omite los enlaces que salen de él; la respuesta indica added, existing, skipped y truncated, repetirlo no añade nada y cada archivo sigue necesitando su propio prepare --scope. Un archivo movido dentro de la carpeta es una fuente nueva, salvo que uses relocate. Pasa el nextCursor de la respuesta como --cursor C (MCP cursor) para añadir los 10 siguientes. Los cursores paginados de búsqueda y librería duran una hora; después devuelven cursor_expired, así que busca de nuevo.

Datos: la base de datos SQLite contiene rutas locales registradas, nombres de capas y texto efectivo de los ámbitos elegidos, valores de propiedades de componentes de las instancias, postings de búsqueda, relaciones exactas (contención, instancias, variantes, enlaces de variables/estilos/imágenes, destinos de prototipo) y las definiciones a las que apuntan, hashes, generaciones y jobs. El .fig original permanece sin cambios donde está; sus bytes sin procesar no se guardan en la base de datos. Las capas de modelos semánticos y de visión añaden los vectores que incrustan, y la indexación visual que actives añade renders PNG de las capas indexadas, incluso sin modelo; las imágenes de consulta nunca se guardan.

Pi, OpenCode y OMP usan el mismo índice mediante su propia entrada opt-in, y el workspace se reutiliza entre reinicios y hosts. No implementado: eventos de archivo (un watch sondea el archivo, y solo mientras un holder se ejecuta) y eventos push.