FunktionMission Contract
Fertig steht vor der ersten Änderung fest. Nicht danach im Rückblick.
Zuletzt aktualisiert:
Der Einstieg
Ein Satz rein, eine Vorgabe zurück
die Vorgabe, die Reality Graph festgehalten hat
Beispiel – illustrativer Eintrag, kein echter Run> Behebe den Validierungsfehler im Checkout, ohne die Zahlungsanbindung anzufassen
festgehalten beim Absenden des Prompts, vor der ersten Änderung
goal Validierungsfehler im Checkout beheben, Zahlungsanbindung unberührt
intent bugfix
requires der Validierungsfehler im Checkout ist behoben
die Zahlungsanbindung bleibt unberührt
allowed src/checkout/validation.py, tests/
protected .env, .git/, **/secrets/**
tests pytest -qLest die erlaubten Pfade genau, denn dort ist die Ableitung am dünnsten. Steht ein Pfad in eurem Satz, übernimmt Reality Graph ihn. Steht keiner darin, kommt höchstens eine Quelldatei aus der Git-Dateiliste dazu, und auch die nur oberhalb einer Relevanzschwelle. Betrifft die Änderung vier Dateien, tragt ihr drei davon selbst nach.
Die Vorgabe entsteht vor der Arbeit, und genau daher hat sie ihren Wert: Ein Maßstab, der hinterher geschrieben wird, ist eine Erinnerung, und Erinnerungen sind großzügig. Was ihr entscheidet, ist das Ergebnis, am anderen Ende des Runs.
Die Datei
Sechs Felder, und jedes wird an etwas Echtem gemessen
| Feld | Was ihr festlegt | Woran es gemessen wird |
|---|---|---|
| goal | Das eine Ergebnis, für das dieser Run existiert. | Vorhandensein und Form. Wie gut das Ziel formuliert ist, bewertet Reality Graph nicht. |
| intent | Einen von elf deklarierten Werten, von euch gewählt. | Zugehörigkeit zum Wortschatz. Alles andere wird abgelehnt statt auf den nächstliegenden Wert gebogen. |
| non_goals | Die benachbarte Arbeit, die dieser Run ausdrücklich nicht erledigt. | Nichts Automatisches. Der Eintrag wandert in die Run-Historie, damit ein späteres Wenn-ich-schon-mal-hier-bin sichtbar wird. |
| allowed_files | Die Pfade, die sich in diesem Run ändern dürfen. | Die Liste geänderter Dateien, die nach dem Run aus Git kommt. |
| forbidden_files | Die Pfade, die gesperrt bleiben, egal was sonst passiert. | Dieselbe Liste. Ein Treffer erzwingt einen blockierenden Befund, den auch eine grüne Testsuite nicht aufhebt. |
| acceptance_criteria | Was wahr sein muss, damit dieser Run als fertig zählt. | Pflichtfeld. Ist die Liste leer, besteht die Vorgabe die Prüfung nicht. |
Zwei Einschränkungen gehören neben diese Tabelle. Die Liste geänderter Dateien kommt aus Git, und ab 500 KB bereinigtem Diff bricht die Erfassung ab, statt ein halbes Bild zu melden. Der Scope wird im Nachhinein geprüft: Reality Graph erkennt die Änderung, es fängt keinen Schreibvorgang ab. Warum sich das Aufschreiben lohnt, steht in prüfbare Vorgaben für KI-Agenten.
Bewusst so gebaut
Was die Vorgabe bindet und was sie bewusst in Ruhe lässt
Was ihr bekommt
- Aus einem Satz Ziel, Anforderungen, erlaubte Pfade und Testbefehl ableiten und festhalten, bevor die erste Änderung passiert.
- Zu jeder Vorgabe eine feste Untergrenze gesperrter Pfade ergänzen, ob ihr daran gedacht habt oder nicht.
- Eine Vorgabe mit leeren Akzeptanzkriterien durchfallen lassen.
- Eine Empfehlung von Target Guard zurückgeben: proceed, proceed with warnings oder do not proceed.
- Eine aus einem beobachteten Prompt rekonstruierte Mission als beratend führen und den Run als eingeschränkt markieren.
Was es nicht ist
- Verstehen, was ihr vorhabt. Die Ableitung ist ein Abgleich eurer eigenen Worte, kein Modell ist beteiligt.
- Euer Repository durchsuchen. Höchstens eine Quelldatei kommt aus der Git-Dateiliste dazu.
- Beurteilen, ob eure Akzeptanzkriterien stark genug sind.
- Blockieren, patchen, ein Veto einlegen, ändern, committen oder pushen. Target Guard hat dafür keinerlei Befugnis.
- Begrenzen, was euer Coding-Agent anfassen kann. Die Vorgabe bindet die Bewertung, nicht den Agenten.
Die Prüfung bleibt durchgehend beratend: Reality Graph meldet, ihr entscheidet, und eure Entscheidung steht neben dem Run.
Diese Grenze ist der Grund, warum Reality Graph neben Claude Code, Cursor, Copilot oder der Codex-CLI steht und nicht an deren Stelle. Diese Werkzeuge schreiben die Änderung, die Vorgabe legt fest, was die Änderung sein sollte. Welchen Kontext sie bekommen, steht auf der Seite zu Context Packs.
Fragen, die wirklich gestellt werden
- Muss ich die Vorgabe selbst schreiben?
- Nein. Ihr tippt einen Satz in euer Coding-Tool, und der Hook leitet die Vorgabe daraus ab: Ziel, Anforderungen, erwartete Pfade, eine feste Untergrenze gesperrter Pfade und den Testbefehl. Festgehalten wird das, bevor irgendetwas passiert, ohne Rückfrage. Von Hand schreiben geht weiterhin, und die Automatisierungsform verlangt eine ausdrückliche Bestätigung.
- Versteht Reality Graph, was ich meine?
- Nein. Die Vorgabe entsteht aus einem deterministischen Abgleich von Stichwörtern und Pfaden in eurem eigenen Satz, dazu die Dateiliste aus Git. Kein Modell ist beteiligt, nichts wird interpretiert. Sie ist deshalb ein Maßstab für den Run und kein Plan, dem ihr vertrauen sollt: Sie hält in euren Worten fest, was ihr verlangt habt, bevor es jemand anders erinnern kann.
- Was passiert, wenn die Akzeptanzkriterien fehlen?
- Dann besteht die Vorgabe die Prüfung nicht, und ihr merkt das beim Schreiben statt nach dem Run. Hat nie jemand festgelegt, was fertig heißt, fehlt hinterher der Maßstab für das Ergebnis. Beratend bleibt die Prüfung trotzdem: Reality Graph meldet, ihr entscheidet.
- Begrenzt die Vorgabe, was mein Coding-Agent anfassen kann?
- Nein. Sie bindet die Bewertung des Runs, nicht die Rechte des Agenten. Ändert sich ein gesperrter Pfad, findet Reality Graph das hinterher im Repository und erzwingt einen blockierenden Befund, den auch eine grüne Testsuite nicht aufhebt. Verhindern und Erkennen sind zwei Versprechen; hier gilt nur das zweite.
Nehmt die Änderung, die ihr ungern unbeaufsichtigt lasst
Beschreibt sie in einem Satz, lest die Vorgabe, die zurückkommt, und schaut, wie viel davon ihr sonst selbst getippt hättet.
Weiterlesen
Schritt 1 von 9