Produkt
Wie Reality Graph funktioniert: ein Run, vom Satz zum Ergebnis
Zuletzt aktualisiert:
Die Schleife
Sechs Stationen, und die mit dem Code ist nicht unsere
- 01Ihr und euer Tool
Ihr tippt die Aufgabe
Ein normaler Satz, in eurem Coding-Tool, so wie ihr ihn immer schreibt. Keine neue Oberfläche, die ihr lernen müsst.
- 02Reality Graph
Der Run wird festgehalten, bevor gearbeitet wird
Ein Hook beim Absenden des Prompts speichert Run und Vorgabe zuerst. Der Maßstab existiert also vor der ersten Änderung, statt hinterher rekonstruiert zu werden.
Details - 03Reality Graph
Kontext wird begrenzt und bereinigt
Das Werkzeug bekommt, was die Vorgabe nennt, in fester Reihenfolge, mit entfernten Zugangsdaten, bevor der Prompt entsteht.
Details - 04Ihr und euer Tool
Euer Coding-Tool schreibt die Änderung
Codex, Claude Code, was immer ihr fahrt. Login, Freigaben und Modellsteuerung bleiben unberührt, und Reality Graph fasst euren Quellcode nicht an.
Details - 05Reality Graph
Checks laufen, Belege kommen aus Git
An der Stop-Grenze führt Reality Graph die freigegebenen Checks selbst aus und liest die geänderten Dateien und den Diff aus dem Repository.
Details - 06Reality Graph
Ein Ergebnis, und eure Entscheidung
Geprüft, eingeschränkt geprüft oder blockiert, jedes Mal gleich berechnet. Die Abnahme ist der menschliche Schritt, und ohne sie wird nichts committet oder gepusht.
Details
In der Praxis
Ein Satz im eigenen Tool, und ein Eintrag, den ihr nicht geschrieben habt
Claude Code, von Reality Graph beobachtet
Beispiel – illustrative Sitzung, keine echten Run-Daten$ realitygraph integrate claude
Hooks in .claude/settings.json geschrieben (umkehrbar, projektbezogen)
$ claude
> Behebe den Validierungsfehler im Checkout, ohne die Zahlungsanbindung anzufassen
reality graph Run rg-4f2a festgehalten, vor der ersten Änderung
…Claude Code arbeitet…
reality graph Stop: 3 geänderte Dateien aus Git gelesen
pytest -q ausgeführt -> exit 0
Ergebnis BLOCKED - geschützter Pfad geändert:
src/payments/gateway.pyNichts in dieser Sitzung verlangt eine Planfreigabe. Der Hook beim Absenden des Prompts hält Run und Vorgabe fest, bevor Claude Code startet, und an der Stop-Grenze liest Reality Graph das Repository, führt die freigegebenen Checks aus und schreibt ein Review. Ein zweiter Befehl ist nicht nötig.
Der menschliche Schritt sitzt am anderen Ende. Ein Ergebnis ist ein Signal, keine Entscheidung: Ihr nehmt es ab oder nicht, und ohne diese Abnahme wird nichts committet oder gepusht. Die Fakten darunter kommen aus dem Repository, ein Run wird also nie nach dem Bericht des Modells über sich selbst beurteilt. Git wird vorausgesetzt, und ab 500 KB bereinigtem Diff bricht die Erfassung ab.
Bewusst so gebaut
Es sitzt zwischen eurem Coding-Tool und eurem Review und ersetzt keines
Was ihr bekommt
- Aus einem Satz eine Vorgabe machen, die ihr bestätigt, mit Akzeptanzkriterien, die nicht leer bleiben dürfen.
- Den Kontext auf das begrenzen, was die Vorgabe deklariert, und Zugangsdaten entfernen, bevor der Prompt existiert.
- Die freigegebenen Checks selbst ausführen und den beobachteten Exit-Code festhalten.
- Geänderte Dateien und Diffs aus Git lesen und ein deterministisches Ergebnis berechnen.
- Einen lokalen Eintrag hinterlassen: Runs, Belege und Nachweise in einfachen Dateien, die ihr exportieren könnt.
Was es nicht ist
- Euren Code schreiben, reparieren, stagen, committen oder pushen.
- Irgendetwas verhindern. Ein geschützter Pfad wird hinterher erkannt, nie abgefangen.
- Review, CI oder eine Sandbox ersetzen. Es gibt keine Pipeline-Anbindung und keine Isolierung.
- Als Team-Werkzeug arbeiten. Ein Operator, eine Maschine, keine Konten, keine geteilte Historie.
- Belegen, dass euer Code korrekt ist. Das Ergebnis ist ein Signal für euer Team, kein Zertifikat.
Jede Station hat ihre eigene Seite: die Vorgabe, das Context Pack und das Ergebnis. Neben welchen Werkzeugen es läuft, steht auf Integrationen.
Fragen, die wirklich gestellt werden
- Muss ich die Vorgabe selbst schreiben?
- Nein, und ihr müsst auch keine freigeben. Der Hook beim Absenden des Prompts leitet Ziel, Anforderungen, erwartete Pfade, eine Untergrenze gesperrter Pfade und den Testbefehl aus eurem eigenen Satz ab und hält sie fest, bevor die erste Änderung passiert. Von Hand schreiben könnt ihr sie weiterhin, und die Automatisierungsform verlangt eine ausdrückliche Bestätigung, aber der Alltagsweg unterbricht euch nicht.
- Wie unterscheidet sich das von Code-Review oder einem Linter?
- Ein Linter beurteilt den Code, der vor ihm liegt. Eine Reviewerin beurteilt die Änderung gegen ihre Erinnerung an das, was beauftragt war. Reality Graph beurteilt den Run gegen eine Vorgabe, die vorher entstand, anhand geänderter Dateien aus Git. Es beantwortet, ob das die beauftragte Änderung war und ob sie in ihren Grenzen geblieben ist, nicht, ob der Code gut ist.
- Schreibt oder repariert Reality Graph Code?
- Nein. Das ist die Station in der Kette, die bewusst nicht unsere ist. Euer Coding-Tool schreibt die Änderung, und Reality Graph schreibt euren Quellcode nicht, staged nicht, committet nicht und pusht nicht.
- Kann eine grüne Testsuite trotzdem blockiert enden?
- Ja. Blockierende Bedingungen werden getrennt von den Check-Ergebnissen ausgewertet, ein Run mit lauter bestandenen Tests ist also blockiert, wenn ein geschützter Pfad sich geändert hat oder ein gefordertes Ergebnis fehlt. Im Produkt gibt es einen Test, der genau das prüft.
- Mit welchen Coding-Tools läuft das?
- Die Codex-CLI und Claude Code sind über umkehrbare Projekt-Hooks gebunden, und genau das macht das automatische Festhalten möglich. Jedes andere Werkzeug läuft daneben, mit einem Prompt, den ihr selbst einfügt, und Reality Graph schreibt nichts in ein fremdes Werkzeug hinein, startet keines und liest aus keinem zurück.
Schickt eine Änderung durch die Schleife und lest den Eintrag
Der interessante Moment ist nicht das Ergebnis. Es ist die Stelle, an der im Eintrag etwas steht, das sonst niemand aufgeschrieben hätte.