Gortex: Code als Graph für lokale Agenten und IDEs

Vom Quelltext zum persistenten Graphen

Gortex beschreibt sich als Code-Intelligence-Engine für KI-Agenten und IDEs. Dateien werden mit tree-sitter-Grammatiken analysiert und als Graph mit Funktionen, Klassen, Aufrufketten, HTTP-Routen und serviceübergreifenden Verträgen abgelegt. Das Projekt nennt 257 Sprachen und mehrere Auflösungsstufen, darunter compilerähnliche Resolver für eine ausdrücklich aufgeführte Gruppe von Sprachen. Die Daten sollen lokal bleiben; beschrieben werden ein einzelnes statisches Binary und ein SQLite-basierter Graphspeicher. Diese Architektur zielt auf gezielte Quellen statt vollständiger Dateilektüre.

Installation und Daemon-Lebenszyklus

Die README-Installation nutzt unter macOS und Linux `curl -fsSL https://get.gortex.dev | sh`, unter Windows den PowerShell-Aufruf `irm https://get.gortex.dev/install.ps1 | iex`. Gortex soll Betriebssystem und Architektur erkennen sowie SHA256 und cosign prüfen. Danach folgen im Quick Start `gortex install`, `gortex daemon start --detach`, `gortex track ~/projects/myapp` und aus dem Repository heraus `gortex init`. Diese Schritte haben getrennte Aufgaben: Maschinenintegration, Hintergrunddienst, Repository-Registrierung und lokale Agentenkonfiguration. Genau diese Zustände sollten beim ersten Setup kontrolliert werden.

MCP, Agenten und gezielte Abfragen

Das README nennt 175 konfigurierbare MCP-Tools, Ressourcen und Prompts für Symbolsuche, Call Chains, Datenfluss, Klonerkennung und Refactoring. `gortex install` richtet laut Projektbeschreibung erkannte Coding-Assistenten ein; genannt werden unter anderem Claude Code, Cursor, VS Code/Copilot, Codex CLI und Zed. Für einen sicheren Probelauf sollte nur ein Test-Repository mit `gortex track` aufgenommen werden. Danach lässt sich prüfen, ob der Agent Quellen, Änderungsorte und Aufrufbeziehungen aus dem Graphen erhält. Die Zahl der unterstützten Agenten belegt keine identische Integrationstiefe.

Mehrere Repositorys und API-Verträge

Cross-Repo-Unterstützung ist standardmäßig vorgesehen. Gortex normalisiert laut Dokumentation Verträge und kann Provider und Consumer über Repositorygrenzen hinweg vergleichen. Als Beispiel nennt das README HTTP-Routen aus Frameworks wie Gin, Express, FastAPI und Spring. Die Contracts-MCP-Funktion und die Contracts-Seite der Web-UI machen solche Beziehungen sichtbar. Ein konkreter Test sollte zwei kleine Repositorys mit einer Route und einem Client verbinden und anschließend die erkannte Beziehung sowie einen absichtlichen Pfadfehler prüfen. So wird sichtbar, ob die eigene Sprache und das Framework in der gewünschten Auflösungsstufe funktionieren.

Semantik, Vorschau und Änderungswachen

Neben FTS5/BM25 nennt Gortex eine eingebaute GloVe-50d-Repräsentation und adaptive Kombination aus Text- und Vektorsuche. Optionale Wege umfassen MiniLM, Ollama und OpenAI. `preview_edit` und `simulate_chain` sollen WorkspaceEdits untersuchen, ohne die Festplatte zu ändern; `verify_change`, `check_guards` und `audit_agent_config` prüfen mögliche Brüche, Guard-Verletzungen und veraltete Dokumentation. Diese Funktionen sind besonders dann interessant, wenn Agenten Änderungen vorbereiten. Die README-Angabe von bis zu 50x weniger Tokens bleibt eine selbst berichtete Messgröße und muss am eigenen Repository nachvollzogen werden.

Lokale Daten, Telemetrie und Lizenz

Das Projekt beschreibt den Betrieb als lokal und Telemetrie standardmäßig als ausgeschaltet. Optional erfasst sie anonyme Werkzeug- und Befehlszähler, jedoch laut README keinen Code, keine Pfade, Namen oder exakten Zählwerte; gesteuert wird sie mit `gortex telemetry on|off|status`, außerdem wird `DO_NOT_TRACK` beachtet. Diese Angaben sollten mit der eigenen Netzwerkkontrolle abgeglichen werden. Die Metadaten weisen Apache-2.0 aus. Bei Weitergabe sind die Lizenzbedingungen und Hinweise zu berücksichtigen. Version v0.63.8, 1502 Sterne, 140 Forks und 42 offene Issues beschreiben den erfassten Stand, nicht eine Betriebszusage. Für die erste Betriebsentscheidung sind die lokalen Artefakte wichtiger als die Zahlen im Kopfbereich: der SQLite-Graph, die erzeugte `.mcp.json`, Hooks und die vom Daemon verwalteten Prozesse. Ein Team sollte festlegen, welche Repositorys mit `gortex track` aufgenommen werden und wie ein Entfernen wiederholbar erfolgt. Bei unsicheren Ergebnissen helfen die im README genannten Funktionen `preview_edit` und `verify_change`, weil sie eine Änderung vor dem Schreiben einordnen können. Die Web-UI mit ihren Graphansichten ist eine zusätzliche Darstellung, aber kein Beleg dafür, dass jede Beziehung korrekt aufgelöst wurde. Gerade bei seltenen Sprachen, generierten Dateien und dynamischem Routing kann die dokumentierte Auflösungsstufe die entscheidende Grenze sein. Diese Punkte machen Gortex prüfbar, ohne die Projektangaben zu verallgemeinern.

Ergebnisprüfung im eigenen Graphen

Ein sinnvoller Gortex-Test bleibt an einem konkreten Repository nachvollziehbar. Nach `gortex track` und `gortex init` sollte ein bekannter Symbolname gesucht, eine Aufrufkette verfolgt und mit `preview_edit` eine hypothetische Änderung betrachtet werden. Bei zwei Repositorys kommt ein absichtlich fehlerhafter HTTP-Pfad hinzu, damit die Contracts-Auswertung Provider und Consumer unterscheiden muss. Die beobachteten Quellen, Graphkanten und Warnungen zeigen, ob die eigene Sprache und Build-Struktur korrekt erfasst werden. Die README-Zahl zur Tokenersparnis lässt sich erst an diesem Fall einordnen.

Redaktionelles Fazit

Gortex ist für Teams interessant, die Agenten und IDEs mit strukturierten Informationen aus mehreren Codebasen versorgen wollen. Der erste belastbare Versuch besteht aus `gortex install`, `gortex daemon start --detach`, `gortex track` und `gortex init`; anschließend sollten Graphabfragen, ein Call-Chain-Fall und ein API-Vertrag im eigenen Repository geprüft werden. Die README-Zahl von bis zu 50x weniger Tokens ist eine Projektangabe, kein Ergebnis für jede Codebasis.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes