Celmis

Selbst gehostete Code-Intelligenz — stellen Sie Fragen an Ihre Codebasen, reviewen Sie Pull-Requests und erzeugen Sie die Nachweise, die ein Prüfer verlangt

celmis-labs.github.io · Dokumentation · Schnellstart · Ergebnisse

Celmis liest Ihre Repositories einmal und pflegt einen Symbolgraph davon. Alles andere — Fragen, Reviews, Abhängigkeitsprüfungen, generierte Dokumentation — ist eine andere Art, diesen Graphen zu lesen. Es läuft auf einer Maschine unter docker compose, mit dem Modellanbieter Ihrer Wahl dahinter, und nichts verlässt Ihr Netzwerk außer den Aufrufen, die Sie konfigurieren.

In der ältesten Überlieferung war Kelmis der Schmelzer — einer der drei idäischen Daktylen, neben Damnameneus, dem Hammer, und Acmon, dem Amboss, denen die Verarbeitung von Eisen zugeschrieben wurde. Der Index übernimmt hier das Reduzieren; die Oberflächen sind es, die das Ergebnis bearbeiten.

Was Ihnen das bringt, was ein reines Diff-Tool nicht kann

Stellen Sie eine Frage, die sich über zwei Repositories erstreckt, und die Antwort zitiert beide:

Das ist kein Suchergebnis. Das Gateway und der Zahlungsdienst sind getrennte Repositories ohne gemeinsamen Code, und die Antwort verfolgt die Aufrufkette zwischen ihnen — und bemerkt dann, unaufgefordert, dass der Kafka-Topic-Name in beiden hartcodiert ist und dass eine Änderung des einen das andere stillschweigend bricht.

Ein Review-Tool, das strukturell nur den Diff liest, kann das nicht sagen. Es hatte das andere Repository nie offen.

Related MCP server: OpenCodeHub MCP Server

Sieben Dinge, die Menschen damit tun

Die ersten drei sind die, die ein Code-Review-Tool überhaupt nicht erledigt, und sie sind der Grund, warum dies eine Plattform ist und kein Review-Tool: einmal indexieren und diesen Index dann von der Seite der Arbeit aus lesen, auf der Sie gerade stehen.

Drei Zahlen

Der letzte Wert ist bewusst unschmeichelhaft, und das bleibt so. Er misst eine der weiter unten beschriebenen Oberflächen — Pull-Request-Review bei isolierten Einzel-Repositor-PRs — und dieses Set hat keinen Schwesterdients, in dem ein Symbol Abnehmer haben könnte, sodass das, worum dieses Produkt herum gebaut ist, in der Zahl überhaupt nicht vorkommt. Die Tabelle, das Audit jedes Befunds, den es als falsch bewertet hat, und der Befehl, der beides reproduziert, finden Sie in Ergebnissen.

Table of contents

• Was Ihnen das bringt, was ein reines Diff-Tool nicht kann

• Sieben Dinge, die Menschen damit tun

• Drei Zahlen

• Schnellstart

• Erster Benutzer und Admin

• Ein Repositor anbinden

• Code fragen

• Pull-Request-Review

• Abhängigkeiten, SBOM und das Nachweispaket

• Von hier aus beheben

• Wer was sehen kann

• Sprachen und Formate

• Deterministiche Prüfungen — kein Modell, keine Fehlalarme

• Claude Code und andere MCP-Clients anbinden

• Ergebnise

• Audit der Fehlalarme

• Test-Repositorie

• Konfiguration

• Betrieb

• Lokale Entwicklung

• CLI-Referenz

• Architekture

• Fehlerbehebung

• Projektstruktur

• Herkunft und Rechte

Schnellstart

Was Sie brauchen

Postgres und Qdrant sind im Paket enthalten — kein externer Cluster muss bereitgestellt werden. Für den Docker-Weg ist keine Installation von Python oder Node.js nötig.

Starten

git clone <your-fork-url> celmis
cd celmis

# Generates .env and fills every secret in the format each one needs.
# Idempotent: run it again after a pull and it fills only the new blanks.
./scripts/init-env.sh

docker compose --env-file .env up -d

# Wait for healthy — first boot pulls three images and applies migrations
docker compose ps

Öffnen Sie http://localhost.

Hier wird nicht gebaut. Die drei Images werden aus der Registry gezogen, die von CELMIS_REGISTRY benannt wird, mit dem Tag aus CELMIS_TAG, für linux/amd64 und linux/arm64 — Apple Silion und ein ARM-Server erhalten beide ein nativeres Image. Der Bau der Images auf der Maschine, die sie ausführt, wurde mit 485 Sekunden und 4.2 GB Festplattenspeicher für api allein gemessen, weshalb Installation nicht mehr Kompilieren bedeutet.

Port 80, nicht 3000: ein Reverse-Proy legt die App und ihre API auf einen gemeinsamen Ursprung und bedient die API unter /backend. Das ist keine Deployment-Präferenz — das Browser-Bundle fragt einen relativen Pfad an, was der einzige Weg ist, wie ein veröffentlichees Image jede Installation bedienen kann statt nur derjenigen, auf der es gebaut wurde.

Um an Celmis zu arbeiten statt es nur zu betreiben, fügen Sie das Dev-Overlay hinzu und Sie erhalten lokale Builds zurück:

docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

init-env.sh --check meldet, was noch leer ist, ohne etwas zu schreiben.

Das ist ein Render der aufgezeichneten Sitzung, keine Bildschirmaufnahme — die Zahlen darin sind die, die der Lauf am 26. August 2026 erzeugt hat, und die Comose-Ausgabe ist wörtlich aus logs/03-up.log im Installationsbericht. Es ist gezeichnet statt fotograiert, weil neben einem laufenden Stack kein zweiter hochgezogen werden kann: docker-comose.yml setzt container_name fest, sodass die Namen kollidieren.

Stopen

docker compose down       # stop, keep your data
docker compose down -v    # stop and DELETE every volume

Erster Benutzer und Admin

Das Registrierungsformular unter /login funktioniert, sobald der Stack gesund ist. Dieses Konto ist ein normaler Benutzer — die Registrierung gewährt keine Admin-Rechte, nicht einmal der ersten Person, die durch die Tür kommt.

Globaler Admin kommt stattdessen aus der Umgebung: Melden Sie sich mit CELMIS_MASTER_EMAIL und CELMIS_MASTER_KEY (als Passwort) an, beide in .env. Wer den Rechner betreibt, ist der Admin — das ist das Modell, das eine selbst gehostete Installation haben möchte, statt der Person, die zuerst das Formular erreicht. Der Pfad existiert nicht, sofern nicht beide Variablen gesetzt sind, und jede Nutzung wird im Audit-Log protokolliert.

Um ein normales Konto zu einem Admin-Konto zu machen:

docker compose exec api analyzer auth make-admin you@example.com

Ein Repository anbinden

1. Einstellungen → LLM Setup — fügen Sie einen Anbieter-Schlüssel ein. Er wird mit CREDENTIAL_MASTER_KEY verschlüsselt, bevor er die Datenbank berührt, und die UI zeigt Ihnen immer nur die ersten und letzten vier Zeichen wieder.

2. Verbindungen — fügen Sie einen GitHub-, GitLab- oder Bitbucket-Token hinzu. Verwenden Sie ein Maschinenkonto, nicht Ihr eigenes: Ein persönlicher Token erreicht jedes Repository, das Sie sehen können, und Tokens landen in Backups, Logs und Screenshots.

3. Repositories → Hinzufügen — wählen Sie Repositories vom Anbieter aus oder fügen Sie eine Clone-URL ein. Die Indexierung wird in die Warteschlange gestellt; der Job erscheint auf derselben Seite.

Die Indexierung erzeugt aus demselben Checkout zwei Dinge: einen Symbolgraph (Definitionen, Aufrufe, Importe — worüber die Review-Agenten nachdenken) und Embeddings in Qdrant (was Q&A abruft). Ein Repository mit 120.000 Symbolen braucht auf vier Kernen etwa eine Minute.

Dreiundzwanzig Sprachen werden in den Graphen geparst. Eine Datei in einer Sprache ohne Parser wird offen benannt, statt stillschweigend übersprungen zu werden — analyzer graph-stats listet auf, was gelesen wurde und was nicht.

Code fragen

Eine Frage in einem Chat, beantwortet mit Datei:Zeile-Zitaten aus so vielen Repositories, wie Sie darauf ausrichten. Antworten werden gestreamt, während sie geschrieben werden.

Fassen Sie Repositories zu einem Projekt zusammen, und die Frage wird an die Gruppe gestellt:

Antworten zitieren echten Code, und nur den Code, den der Fragesteller sehen darf — genau das macht es sicher, die Frage jemandem außerhalb des Teams zu geben, dem das Repository gehört. Siehe Wer was sehen kann.

Pull-Request-Review

Agents lesen den Diff und posten Befunde auf GitHub, GitLab oder Bitbucket. Statt das in einem Screenshot dieser Oberfläche zu zeigen, bleiben die Reviews dort, wo sie gepostet wurden — fünfzig Pull-Requests in echten Projekten, mit den Kommentaren, die weiterhin an den Zeilen hängen, über die sie geschrieben wurden. Sie sind unter Test-Repositories aufgelistet, und die Ausgabe dort ist unbearbeitet, einschließlich der Befunde, die das untenstehende Audit als falsch markiert.

Wo der Graph gebaut wird, trägt das Review auch das, was der Diff nicht zeigt: wer das geänderte Symbol sonst noch aufruft, auch aus einem anderen Repository. Wo er nicht gebaut wird, läuft das Review trotzdem — es beantwortet nur die engere Frage, und das ist es, was das Benchmark gemessen hat.

Jeder Befund, den das Benchmark als falsch bewertet hat, wurde im Quellcode angelegt und mit einem Urteil veröffentlicht. Dreiunddreißig von neunundsiebzig erwiesen sich als echte Defekte, die der Goldstandard nicht enthält. Diese Arbeit ist in Audit der False Positives zu finden, mit dem Code und einem Permalink für jeden, sodass Sie bei jedem einzelnen widersprechen können.

Abhängigkeiten, SBOM und das Beweispaket

Das Abhängigkeitsaudit ist deterministisch: native Auditoren, wo das Tool installiert ist, OSV überall sonst, kein Modell beteiligt. Ein Sprachmodell schreibt die Zusammenfassung, wenn Sie ihm einen Schlüssel geben — es entscheidet nicht, was verwundbar ist.

Bei jedem Audit kommen zwei Dateien heraus, und keine von beiden braucht einen LLM-Schlüssel:

• SBOM — eine CycloneDX-Inventarliste jeder Abhängigkeit, ihrer Version, Package-URL und der gegen sie bekannten Schwachstellen. Das ist die Datei, die gemeint ist, wenn Leute sagen: „Schicken Sie uns Ihre SBOM“.

• Beweispaket — das Audit als Akte: jede SBOM, jeder Befund, die Zeitleiste früherer Läufe und ein sha256 jeder Datei, sodass ein Dritter prüfen kann, dass danach nichts geändert wurde, ohne uns vertrauen zu müssen. Ein Ordner, dessen Inhalt später geändert werden kann, beweist nichts; das Manifest ist es, das ihn zum Beweis macht.

Daneben die generierte technische Dokumentation — Modul-PRDs, Feature-Dokumente und Integrationsanleitungen, die aus dem Code geschrieben wurden — die Ihnen gehört und auch nach Ende eines Abonnements weiter funktioniert.

Warum es das jetzt gibt. Ab dem 11. September 2026 verlangt der EU Cyber Resilience Act von einem Hersteller, eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden an die ENISA zu melden. Das formale SBOM-Mandat tritt im Dezember 2027 in Kraft, aber Sie können die 24-Stunden-Frage nicht beantworten, ohne zuerst Sichtbarkeit auf Komponentenebene zu haben — um zu melden, was betroffen ist, müssen Sie wissen, was drin ist.

Celmis beansprucht keine Konformität und wird das auch nicht tun. Es erzeugt die Artefakte, die eine Einreichung braucht. Ob eine Einreichung angemessen ist, ist das Urteil eines Anwalts, und ein Tool, das etwas anderes andeutet, verkauft ein falsches Sicherheitsgefühl.

Noch etwas sagt die Audit-Seite laut aus, weil es der Fehler ist, nach dem niemand sucht: Ein Ökosystem, das niemand gescannt hat, meldet null Schwachstellen, genau wie ein sauberes. Neben den Befunden wird die Abdeckung angezeigt — welcher Auditor welches Ergebnis erzeugt hat und, was noch nützlicher ist, was ungeprüft blieb und warum.

Von hier aus beheben

Etwas zu finden ist erst eine halbe Schleife. Eine eingebettete Claude-Code-Sitzung läuft innerhalb der Installation, bearbeitet den Checkout, und der Runner erstellt den Commit, pusht einen Branch und öffnet einen Pull-Request.

Eine Schwachstelle im Abhängigkeitsaudit hat einen Fix with Claude-Button. Er öffnet keinen leeren Chat — er übergibt der Sitzung das Repository, das Paket, beide Versionen und die Grenzen der Aufgabe, bereits formuliert:

Hier ist eine solche Schleife, Ende zu Ende, bei einem echten Befund — lodash 4.17.11 mit einer bekannten Schwachstelle. 220 Sekunden von Start session bis zu einem offenen Pull-Request, in fünf Schritten:

Read package.json
  → "Only package.json has lodash; no requirements.txt/pyproject/go.mod exist here."
Edit package.json: "lodash": "4.17.11" → "4.18.0"
mcp__exec__run: cat package.json | grep -A2 lodash; ls
  → "Confirmed no other manifest files exist, so no other changes were needed."

Der Branch, den es gepusht hat, und der Pull-Request, den es geöffnet hat, auf GitHub:

Sehen Sie sich an, was nicht in diesem Diff steht. axios 0.21.1, minimist 1.2.0, node-fetch 2.6.0 sitzen direkt darüber und darunter — alle veraltet, alle im selben Audit markiert — und alle unangetastet. Die Aufgabe lautete: nur Manifeste, und ein Agent, der im Vorbeigehen drei weitere aufgeräumt hätte, wäre ein schlechteres Ergebnis zum Reviewen gewesen, kein besseres.

Es ist ein echter Pull-Request, kein Screenshot: celmis-demo-gateway#6 — Branch celmis-agent/b8960e01, ein Commit, +1/-1.

Zwei Details in diesem Transkript sind mehr wert als der Diff. Der Agent hat nicht angenommen, dass es keine weiteren Manifeste gibt — er hat in der Sandbox einen Befehl ausgeführt, um das zu prüfen. Und die Aufgabe lautete „nur Manifeste, fassen Sie keine nicht zusammenhängenden Abhängigkeiten an“, also ist die Änderung genau eine Zeile.

Was der Runner erlaubt und was nicht

Das entscheidet der Runner, nicht das Prompt — und das ist der Teil, den Sie lesen sollten, bevor Sie einem Agenten irgendetwas gewähren:

• Keine eigene Shell. Bash, WebFetch, WebSearch und Notebook-Bearbeitung sind nicht erlaubt. Befehle laufen durch den Sandbox-Container, einen separaten Dienst mit eigener uid und einem schreibgeschützten Root-Dateisystem.

• Git ist Sache des Runners. Der Agent committet oder pusht nie. Wenn die Arbeit fertig ist — oder wenn Sie Finish & push drücken — erstellt der Runner den Commit, pusht den Branch und öffnet den PR. Niemals in den Default-Branch.

• Ein Provider-Limit ist eine Pause, kein Verlust. Der erste Versuch des obigen Laufs stieß mitten in der Sitzung auf ein wöchentliches Kontolimit. Die Sitzung starb nicht: Sie wechselte zu paused, blieb vierzehn Tage lang fortsetzbar und zeigte die eigene Nachricht des Providers statt einer generischen Fehlermeldung. Ein zweiter Schlüssel beendete sie.

• Die Sitzung ist beobachtbar. Die Ausgabe streamt über SSE mit Replay, sodass eine Wiederverbindung dort weitermacht, wo sie aufgehört hat, statt leer zu beginnen.

Die Verbindung ist ein Setup-Token, das pro Benutzer oder pro Workspace gehalten wird. Die API gibt es nach dem Speichern nie zurück — nur, ob es vorhanden ist und ob es noch funktioniert.

Wer was sehen kann

Der Zugriff wird pro Repository und pro Team aufgelöst und gilt für alle Oberflächen gleichzeitig — Q&A, Graph, Suche, MCP:

Das ist es, was den Fall des Nachbarteams funktionieren lässt, statt ein Versprechen zu sein: Laden Sie das Repository, gewähren Sie dem anderen Team das Recht zu fragen, und verweigern Sie die Pfade, die nicht gelesen werden dürfen. Sie bekommen Antworten; diese Dateien werden an der Quelle verweigert, nicht aus einer Antwort herausgefiltert, die sie bereits enthielt.

Sprachen und Formate

Siebzehn Graph-Module, plus ein generischer Weg über Tree-Sitter-Tag-Queries für Sprachen ohne ein solches:

Code — Python, TypeScript, JavaScript, Go, Java, C#, C++, PHP, Vue und mehr über den generischen Pfad.

Infrastruktur — Dockerfile, docker-compose, Helm, Kubernetes-Manifeste, Terraform und CI-Workflows. Das ist der Teil, den die meisten Code-Intelligence-Tools überspringen, und genau deshalb kann eine Frage von einer Funktion zur Dienstdefinition wechseln, die sie ausführt.

Deterministische Prüfungen — kein Modell, keine False Positives

Jede unten aufgeführte Prüfung wird durch das Lesen von Dateien entschieden. Kein Sprachmodell ist daran beteiligt zu entscheiden, dass etwas falsch ist, daher ist die False-Positive-Rate per Konstruktion null und nicht durch Feinabstimmung.

Genau diese Unterscheidung ist der springende Punkt. Bei etwa zwanzig Prozent False Positives hören Entwickler auf, die Kommentare eines Tools überhaupt zu lesen — einer kostet Sekunden der Aufmerksamkeit, tausend kosten Sie ein Team, das gelernt hat, alles zu überspringen, was das Tool sagt. Ein Modell wird hier eingesetzt, um zu erklären und zu priorisieren, niemals um zu erkennen.

Gewöhnliches CVE-Scannen steht bewusst nicht auf dieser Liste. OSV-Scanner macht das bereits, es ist kostenlos und der De-facto-Standard — Celmis führt es aus (plus den eigenen Auditor jedes Ökosystems: pip-audit, npm audit, govulncheck, cargo audit) und behandelt das Ergebnis als Eingabe und nicht als Feature.

Zur Compliance. Celmis erzeugt die Artefakte, die ein Audit verlangt — eine CycloneDX-SBOM, ein Abhängigkeitsinventar, eine Befundhistorie mit Zeitstempeln und die Belege, auf denen jeder Befund beruht. Es behauptet nicht, dass Ihre Einreichung angemessen ist, und das kann kein Tool ehrlich von sich behaupten: Was ein Auditor akzeptiert, hängt von Ihrer Branche, Ihrem Rechtsraum und Ihren eigenen Kontrollen ab. Erzeugen Sie die Artefakte; lassen Sie die Leute, deren Aufgabe es ist, sie zu bewerten.

Claude Code und andere MCP-Clients verbinden

Celmis stellt seinen Index über MCP bereit, sodass ein Agent Symbole suchen, API-Oberflächen lesen und Konsumenten finden kann, statt einen Checkout zu durchsuchen, den er nicht hat.

Über HTTP (der laufende Stack stellt es unter /mcp/ bereit):

# Mint a token (or issue one from Settings → MCP in the UI)
docker compose exec api analyzer mcp issue-token \
  --scopes "read:graph read:groups" --duration 86400

// ~/.claude.json  (or .mcp.json in a project)
{
  "mcpServers": {
    "celmis": {
      "type": "http",
      "url": "http://localhost:8000/mcp/",
      "headers": { "Authorization": "Bearer <the token you just minted>" }
    }
  }
}

Über stdio, ohne den HTTP-Umweg:

{
  "mcpServers": {
    "celmis": {
      "command": "docker",
      "args": ["compose", "exec", "-T", "api", "analyzer", "mcp", "serve"]
    }
  }
}

Was ein Agent fragen kann

Der HTTP-Mount stellt 18 Tools bereit. Sie beantworten die Fragen, die ein grep nicht beantworten kann:

Die beiden Transports sind nicht dieselbe Menge. analyzer mcp serve über stdio bedient 13 ältere, graphförmige Tools (find_symbol, find_callers, query_graph); der HTTP-Mount bedient die 18 oben. Keiner ist eine Teilmenge des anderen – wähle den Transport für die Tools, die du willst.

Eine Schritt-für-Schritt-Anleitung mit den Scopes, die jedes Tool benötigt, und den Fehlermodi findest du in .claude/skills/celmis-mcp/SKILL.md. Claude Code übernimmt sie automatisch, wenn dieses Repository geöffnet ist.

Was der Agent anfragen kann

Ein einziger search_symbols-Aufruf, ein Vertragssymbol, und es kommt aus zwei Repositories in zwei Sprachen zurück – an einen Client, der keines von beiden ausgecheckt hat. Die Grenze, die ein Diff nie überschreitet, ist genau die, die dies hier zur Normalität macht.

Achtzehn Tools, bereitgestellt über Streamable HTTP unter /mcp/ und authentifiziert mit demselben Bearer-Token wie /api/:

cross_repo_edges ist das Tool, das sich zu verstehen lohnt, denn es ist der Grund, warum dieses Produkt überhaupt einen Symbolgraphen mitführt. Ein reiner Diff-Reviewer – jedes Tool in der Benchmark-Tabelle oben, einschließlich dieses, wenn der Graph leer ist – kann dir sagen, dass sich eine Funktionssignatur geändert hat. Er kann dir nicht sagen, dass ein Dienst in einem anderen Repository weiterhin die alte Form aufruft, weil er dieses Repository nie offen hatte. Gruppiere die Repositories einmal, und diese Frage wird beantwortbar:

> which services outside this repo call PaymentGateway.charge?

Das ist auch der Grund, warum unser Benchmark-Rang das Produkt untertreibt, statt es zu beschreiben: Der Benchmark-Satz besteht aus isolierten Einzel-Repository-Pull-Requests, es gibt also kein Schwester-Repository, das eine Kante überqueren könnte. Die Fähigkeit ist real, und der Benchmark kann sie nicht sehen – das ist eine Aussage über den Benchmark, kein Anspruch, den du blind glauben solltest. Richte einen MCP-Client auf deine eigene Gruppe und prüfe es.

Ergebnisse

Celmis wurde auf dem Martian Code Review Bench Offline-Satz ausgeführt: 50 kuratierte Pull-Requests, 173 von Menschen geschriebene Golden Comments, bewertet gegen den Gold-Satz durch einen LLM-Judge. Gemessen auf e0db376 mit gemini-3.6-flash bei Temperatur 0.1, ohne Reasoning-Tokens.

Der F1-Wert bewegt sich um 4,8 Punkte, je nachdem, wer bewertet. Der Rang bewegt sich überhaupt nicht – unter allen drei Judges siebzehnter. Unter uns bei jedem der drei: CodeRabbit (19/25/23), jede Version von Greptile (26–29), Kodus (21/23/21), Copilot, Claude Code, Gemini und CodeAnt.

Der gesamte Lauf kostete $5.88 – $0.118 pro Pull-Request – und produzierte 153 Befunde, 3.06 pro PR (Defekt 114, Sicherheit 27, Vertrag 6, strukturell 6).

Warum dieser Vergleich fair ist. Martian liefert seine eigenen Auswertungen von 49 Tools im Benchmark-Repository mit, erstellt von denselben drei Judges über dieselben 50 PRs gegen dieselben Goldens. Wir haben niemanden neu bewertet: Ihre Zeilen sind wie veröffentlicht übernommen, unsere ist angefügt. Reproduziere die ganze Tabelle mit:

python3 autoloop/offline_table.py anthropic_claude-sonnet-4-5-20250929

Offline ist nicht das öffentliche Leaderboard. Martian betreibt zwei Benchmarks. Das öffentliche Leaderboard ist der Online-Benchmark – 200.000 echte Pull-Requests, bewertet danach, was Entwickler tatsächlich behoben haben. Diese Tabelle ist der Offline-Benchmark – 50 kuratierte PRs, bewertet gegen einen Gold-Satz. Sie messen verschiedene Dinge, und die Zahlen sind nicht austauschbar. Behauptungen der Form „Tool X ist #1 bei Martian" beziehen sich meist auf die Online-Tabelle, eine andere Metrik oder einen anderen Judge.

Was diese Zahl nicht enthält. Der Graph war für alle 50 PRs leer (graph_status null, Drift bei jedem leer), weil der Benchmark-Satz aus isolierten Einzel-Repository-Pull-Requests besteht – es gibt keinen Schwesterdienst, in dem ein Symbol Konsumenten haben könnte. Repository-übergreifender Drift, das, wofür dieses Produkt einen Symbolgraphen mitführt, hat zu der Punktzahl oben exakt nichts beigetragen. Er ist hier nicht messbar, und wir beanspruchen ihn nicht aus dieser Tabelle. Siehe Test-Repositories, um ihn stattdessen an echtem Code zu beobachten.

Prüfung der False Positives

Benchmark-Bewertung hat eine strukturelle Untergrenze: Der Judge vergleicht unseren Kommentar mit einer endlichen Liste von von Menschen geschriebenen Goldens, also wird ein korrekter Befund, den der Annotator nie niedergeschrieben hat, konstruktionsbedingt als falsch gezählt. Wir haben alle 79 unserer Befunde im Quellcode beim gemessenen Commit geöffnet und jedem ein Urteil zugewiesen.

Von 79 als False Positives bewerteten Befunden sind 33 echte Defekte, die der Gold-Satz nicht enthält, 38 sind tatsächlich falsch, und 8 konnten aus dem Code nicht entschieden werden. Das bringt die wahre Precision dieses Laufs auf zwischen 69,7 % und 75,0 % statt der gemessenen 48,0 % – aber diese korrigierte Zahl kann mit nichts in der Tabelle oben verglichen werden, weil niemand die anderen Tools auf dieselbe Weise geprüft hat und ihre False Positives mit hoher Wahrscheinlichkeit einen ähnlichen Anteil echter Defekte enthalten; für den Vergleich mit anderen Tools ist die gemessene 48,0 % die ehrliche Zahl, weil es dieselbe Methode ist, die auf alle angewendet wird.

Vierundzwanzig der 38 tatsächlich falschen Befunde teilen vier Grundursachen, und keine davon ist „das Modell ist schwach" – alle vier betreffen, was dem Modell gezeigt wurde. Die größte ist ein Bezeichner, der in derselben Datei, aber außerhalb des Ausschnitts deklariert ist, den der Agent erhalten hat: ein Methodenparameter 26 Zeilen weiter oben, ein Import in Zeile 3, ein attr_reader in Zeile 18.

Der vollständige Bericht gibt für jeden der 79 die Behauptung, den Code bei diesem Commit, das Urteil, die Begründung und einen Permalink an, sodass jedes Urteil mit denselben Belegen vor dir angefochten werden kann.

Test-Repositories

Jedes Review aus dem Lauf oben ist weiterhin live und öffentlich. Das sind echte Pull-Requests aus echten Projekten, mit ihrer Historie geforkt und mit den Inline-Kommentaren, die Celmis geschrieben hat:

Am besten zuerst öffnen:

• keycloak#17 – eine Null-Dereferenzierung und eine Frage zur Indizierung von Recovery-Codes im Test-Speicher-Provider von Keycloak

• grafana#16 – ein Storage-Fehler, der gegen die Legacy-Metrik aufgezeichnet wurde, eine von drei Instanzen desselben Fehlers in dieser Datei

• cal.diy#11 – forEach mit einem asynchronen Callback, sodass die Löschungen Fire-and-Forget sind und das umgebende try nichts abfängt

• sentry#11 – sieben Inline-Kommentare zu einem einzigen Kafka-Consumer-PR

Du liest unbearbeitete Ausgabe, einschließlich der Befunde, die die Prüfung oben als falsch markiert. Nach der Bewertung wurde nichts entfernt.

Konfiguration

./scripts/init-env.sh schreibt .env aus .env.example und generiert jedes Secret. Das Beispiel liefert jedes Secret absichtlich leer mit: Eine frühere Version platzierte den Generierungsbefehl neben der Variable, Dotenv-Dateien haben keine Inline-Kommentare, und jede Installation, die sie kopierte, lief mit einem Master-Passwort, das im Repository abgedruckt war.

Einstellungen erreichen die Container nur über den environment:-Block in docker-compose.yml – das Image trägt keine .env. Eine Variable, die dort nicht genannt ist, übernimmt ihren Code-Standardwert, egal was deine .env sagt. GET /healthz meldet die Review-Uhren so, wie der Prozess sie tatsächlich aufgelöst hat – so prüfst du, was angekommen ist.

Die Uhren sind als Menge in .env.example dokumentiert, mit der Invariante, die sie bindet:

REVIEW_LLM_TIMEOUT_SECONDS × (1 + RETRY_FACTOR)  ≤  REVIEW_TIMEOUT_SECONDS

Erhöhe die eine, und die andere muss folgen; ein Test erzwingt das.

Betrieb

docker compose logs -f api            # follow the API
docker compose exec api analyzer graph-stats <repo>   # what parsed, what did not
./scripts/backup.sh                   # Postgres + volumes
./scripts/restore.sh <archive>

Admin → Monitoring zeigt Warteschlangentiefe, Ausgaben pro Workspace und Modell-Einstellungen pro Agent. Usage & cost schlüsselt Ausgaben nach Oberfläche auf, damit ein Batch-Dokumentationsbuild nicht wie Chat aussieht.

Das Bereitstellen auf einem Server erfolgt mit ./scripts/deploy-on-server.sh v0.1.0, ausgeführt auf dem Server: Es zieht die veröffentlichten Images, bringt den Stack hinter Caddy hoch und versieht den Build, auf den die AGPL-Fußzeile verweist, mit einem Stempel. Außerhalb dieser Maschine sind dafür keine Anmeldedaten erforderlich. Siehe docs/ORACLE_CICD.md oder docs/HETZNER.md für eine normale VM.

Lokale Entwicklung

# Postgres and Qdrant from compose, everything else on the host
docker compose up -d postgres qdrant

python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

alembic upgrade head
uvicorn src.api.main:app --reload --port 8000

cd web && npm install && npm run dev     # http://localhost:3000

pytest -q                # the suite
ruff check .             # lint, ratcheted at zero
cd web && npx tsc --noEmit

CLI-Referenz

analyzer wird mit pip install -e . installiert; in Docker verwenden Sie docker compose exec api analyzer …. Jeder Befehl akzeptiert --help.

Gruppierte Unterbefehle: analyzer repo, analyzer group, analyzer auth, analyzer mcp, analyzer scip.

Architektur

                      ┌──────────────┐
   GitHub / GitLab ──▶│   webhook    │──┐
   Bitbucket          └──────────────┘  │
                                        ▼
   Browser ──▶ web (Next.js) ──▶ api (FastAPI) ──▶ Postgres   jobs, policies, audit
                                     │              Qdrant     embeddings
                                     │              sandbox    untrusted execution
                                     ▼
                              model provider
                       (direct, or via a LiteLLM gateway)

• Postgres speichert Jobs, Richtlinien, Ausführungsverlauf, Ausgaben und das Audit-Log. Die dauerhafte Job-Warteschlange ist eine Tabelle – das Entfernen aus der Warteschlange erfolgt per SELECT … FOR UPDATE SKIP LOCKED, und ein Worker verlängert sein Lease, während er arbeitet, anstatt eine Dauer im Voraus zu schätzen.

• Qdrant speichert Embeddings, eine Collection pro Installation, wobei die Workspace-Isolation im Filter erzwungen wird.

• sandbox führt alles Unvertrauenswürdige aus – eine Testsuite, einen Build – als eigene UID in einem eigenen Netzwerk, ohne Datenbank, ohne Schlüssel und mit einem schreibgeschützten Root-Dateisystem.

• LiteLLM ist optional. Wenn LITELLM_PROXY_URL und LITELLM_MASTER_KEY zusammen gesetzt sind, wird jeder Aufruf über das Gateway geleitet; bleibt eines von beiden leer, werden Provider-Schlüssel direkt verwendet.

Fehlerbehebung

Ein Container startet nicht. docker compose logs <service>. Die API gibt beim Start an, welche optionalen Funktionen nicht verfügbar sind und warum, anstatt stillschweigend zu scheitern.

Reviews liefern nichts. Prüfen Sie GET /healthz auf die aufgelösten Zeitwerte, dann docker compose logs api | grep agent_. Jeder Agent protokolliert seine verstrichene Zeit, sein Modell und seinen Fehlercode.

Ein Timeout, kein Ausfall. local_timeout bedeutet, dass die eigene Frist dieser Installation verstrichen ist, bevor der Provider geantwortet hat – erhöhen Sie REVIEW_LLM_TIMEOUT_SECONDS. Dies wird bewusst nicht als Providerfehler gemeldet.

Q&A zitiert nichts. Das Repository ist vermutlich nicht indiziert oder ohne Embeddings indiziert. Repositories zeigt den Zustand jedes einzelnen; analyzer graph-stats <repo> zeigt, was geparst wurde.

Die Sandbox ist immer ausgelastet. SANDBOX_SLOTS gibt an, wie viele Jobs gleichzeitig laufen, und ist der Stellhebel, der Speicher kostet. SANDBOX_SLOT_WAIT gibt an, wie lange ein Aufrufer in der Warteschlange bleibt, bevor ihm gesagt wird, er solle wiederkommen.

Projektstruktur

src/
  api/          FastAPI app, routers, schemas
  review/       PR review — agents, orchestrator, providers, policies
  indexing/     parsers, symbol graph, embeddings
  qa/           retrieval and answer composition
  generation/   documentation vault
  llm/          provider clients, error taxonomy, cost ledger
  sync/         git providers, the durable job queue, workers
  sandbox/      the isolated execution server
  mcp_server/   the MCP surface
  security/     redaction, patterns, log filtering
web/            Next.js UI (App Router, 16 locales)
tests/          5200+ tests
deploy/         Caddy overlay and the LiteLLM gateway config
docs/           deploy guides and the end-to-end walk-through
bench/          benchmark harness and results

Herkunft und Rechte

Dieses Repository hat einen einzigen Root-Commit über etwa hunderttausend Zeilen – die Gestalt, die ein Code-Drop unklarer Herkunft für einen Provenance-Scanner hat, und eine, die eine Erklärung braucht statt eines Achselzuckens. Dafür gibt es eine: PROVENANCE.md legt die Lizenzposition und die Herkunft des Codes dar – die Entwicklung fand vor diesem Commit privat statt, und nichts davon wird benötigt, um das hier Vorhandene zu bauen, zu auditieren oder zu forken.

Diese Datei ist eine Aufzeichnung von Tatsachen, nicht die Lizenz. Die Lizenz ist AGPL-3.0, mit einer Ausnahme: alles unter ee/ und jede Datei, deren Name .ee. enthält, unterliegt stattdessen LICENSE_EE. ee/ enthält heute keinen Produktcode – die Grenze wurde vor dem ersten Tag gezogen, weil sie danach zu ziehen bedeuten würde, jeden Mitwirkenden erneut zu fragen, der bereits Arbeit unter einer uneingeschränkten AGPL eingereicht hat.

Alles, was hier ausgeliefert wird, ist AGPL, einschließlich der Teile, die kommerziell wirken: die Audit-Konsole, Nutzung und Ausgaben, Compliance-Prüfungen, Installationsmetriken. Sicherheitskontrollen sind niemals Enterprise-exklusiv – das Audit-Log wird unter AGPL geschrieben und wird es immer bleiben. Siehe CONTRIBUTING.md dafür, wohin neuer Code gehört.