Normale Suche und der optionale lokale Index

	Normal (Standard)	Fortgeschritten: lokaler Index (optional)
Was es tut	Liest die .fig bei jedem Aufruf und beantwortet search, find, inspect und export.	Baut einmal einen Suchindex für einen gewählten Bereich und beantwortet search daraus, gerankt über Quellen.
Was geschrieben wird	Kein Workspace und keine Index-Datenbank (export schreibt nur die angeforderten Dateien).	Ein lokaler Workspace (SQLite-Datenbank) im Statusverzeichnis des Benutzers oder unter dem gewählten --storage.
Wann sinnvoll	Einzelfragen, Skripte, CI.	Wiederholte Suchen in einer Datei; mehrere Dateien eines Projekts als ein Korpus (--workspace <dir>); exakte Verwendungen von Komponenten, Variablen, Styles und Bildern.

Eine normale Designfrage legt nie einen Index an. Sie aktivieren ihn einmal ausdrücklich („Lege einen Index für dieses Design an“); figlens wählt den Speicherort und braucht kein SQLite oder sonstiges Setup.

# Normal: zustandslos, legt nichts an
figlens search design.fig "checkout button"

# Fortgeschritten, einmalig: Bereich wählen (Node-ID oder 0:0 für die ganze Datei); der Build läuft im Vordergrund
figlens index prepare design.fig --scope 0:0

# Indexierte Suche; --node ergänzen, wenn der indexierte Bereich nicht die ganze Datei ist
figlens search --file design.fig "checkout button" --node 0:0

# Nach Änderung oder neuem Export der .fig: nur Bereiche mit geänderten Bytes neu bauen
figlens index refresh --file design.fig

# Nach dem Verschieben der .fig: Workspace behalten, dann refresh (workspaceId aus der Ausgabe von prepare)
figlens index relocate <sourceId> new/design.fig --id <workspaceId>
figlens index refresh --id <workspaceId>

MCP: index prepare liefert einen Job; jobs abfragen, bis succeeded, dann mit der workspaceId aus der Antwort suchen.

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

Lebenszyklus: refresh baut nur Bereiche neu, deren .fig-Bytes sich geändert haben; rebuild baut auch Unveränderte neu; clear_cache löscht nur Daten, die ein Build neu erzeugen kann, und behält Registry und veröffentlichte Indizes; reset löscht die Datenbank dieses Workspaces (nie die .fig oder Exporte) und läuft nur auf ausdrücklichen Wunsch. Neue Quellen, ein größerer Bereich, reset und Neuanlage brauchen jeweils eine eigene ausdrückliche Anfrage.

.fig verschoben? index relocate behält workspaceId, sourceId und Speicherort; danach die betroffenen Bereiche mit refresh aktualisieren. Es gibt keine automatische Erkennung und kein Hash-basiertes Zusammenführen; ein reset ist nicht nötig.

Mehrere Designs in einem Ordner? index add <dir> --workspace DIR registriert bis zu 10 .fig-Dateien unter diesem Verzeichnis in einem Schritt und überspringt Links, die aus ihm herausführen; die Antwort nennt added, existing, skipped und truncated, eine Wiederholung fügt nichts hinzu, und jede Datei braucht weiterhin ihr eigenes prepare --scope. Eine innerhalb des Ordners verschobene Datei ist eine neue Quelle, es sei denn, sie wird mit relocate umgezogen. Mit nextCursor der Antwort als --cursor C (MCP cursor) werden die nächsten 10 hinzugefügt. Seitenweise Such- und Library-Cursor gelten eine Stunde; danach liefern sie cursor_expired, also erneut suchen.

Daten: Die SQLite-Datenbank enthält registrierte lokale Pfade, Layer-Namen und effektiven Text der gewählten Bereiche, die Komponenten-Property-Werte von Instanzen, Such-Postings, exakte Beziehungen (Verschachtelung, Instanzen, Varianten, Variablen-/Style-/Bild-Bindungen, Prototyp-Ziele) und die Definitionen, auf die sie zeigen, Hashes, Generationen und Jobs. Die ursprüngliche .fig bleibt unverändert, wo sie ist; ihre Rohbytes werden nicht in der Datenbank gespeichert. Semantische und visuelle Modell-Layer ergänzen ihre eingebetteten Vektoren, und eine aktivierte visuelle Indexierung ergänzt PNG-Renderings der indexierten Layer, auch ohne Modell; Abfragebilder werden nie gespeichert.

Pi, OpenCode und OMP nutzen denselben Index über ihren eigenen Opt-in-Einstieg; der Workspace wird über Neustarts und Hosts hinweg wiederverwendet. Nicht implementiert: Datei-Events (ein Watch fragt die Datei ab, und nur solange ein Holder läuft) und Push-Events.