Ergebnisdateien und menschliche Freigaben genau festlegen

Ein menschliches Review hilft, wenn die Person sehen kann, was passieren soll und warum. Ein „Weiter?“ nach einer langen Unterhaltung bietet wenig Prüfbares. Stelle ein kurzes Entscheidungspaket um die tatsächliche Ergebnisdatei zusammen.

Bei Code gehören Aufgabe, Basisrevision, Diff, Prüfergebnisse, Befunde, offene Entscheidungen und das Integrationsziel hinein.

Definiere jede Übergabe

Jeder Schritt erhält benannte Eingaben und eine erwartete Ausgabe. Ein Repository-Review könnte Folgendes liefern:

{
  "status": "completed",
  "summary": "Die neue Wartezeit behält die Obergrenze bei.",
  "findings": [
    {
      "path": "retry.js",
      "line": 2,
      "severity": "question",
      "detail": "Die Aufgabe lässt Versuch null offen.",
      "check": "Gültige Versuche mit dem Verantwortlichen klären."
    }
  ]
}

Das ist ein beispielhaftes Aufgabenformat. Der Runner muss es aus der nativen Tool-Antwort entnehmen und prüfen. Auch ein formal gültiger Befund braucht eine reale Datei und eine nachvollziehbare Aussage.

Der Koordinator ergänzt vertrauenswürdige Metadaten: Prüfsummen von Ein- und Ausgaben, Tool-Version, beobachtetes Modell soweit verfügbar, Laufzeit und Abschlussstatus. Er berechnet Prüfsummen selbst.

Platziere Reviews an Entscheidungen

Kläre Umfang und Datenempfänger vor dem Start. Prüfe vor einer wesentlichen Architekturänderung den konkreten Entwurf. Nach der Implementierung folgen genauer Diff und Verifikationsbelege.

Die Abnahme kann eine benannte Integration einschließen, wenn Ziel und Folgen im Paket sichtbar sind. Endet die Aufgabe mit einem lokalen Patch, endet dort der Ablauf. Eine spätere Bereitstellung braucht eine entsprechende Befugnis.

Routinearbeit innerhalb einer freigegebenen Vorlage kann ohne neue Fragen laufen. Ein größerer Dateiumfang, neuer Empfänger, anderes Ziel oder zusätzliche Berechtigungen brauchen eine Entscheidung über diese Erweiterung.

Binde die Entscheidung an den geprüften Stand

Speichere Freigaben außerhalb des vom Agenten beschreibbaren Arbeitsbereichs. Erfasse Version von Ablauf und Richtlinie, Basisrevision, Prüfsumme, Ziel, Entscheidung und die in dieser Umgebung passende Identität des Prüfers.

Wird Diff A akzeptiert und durch eine Reparatur zu Diff B, gilt die Freigabe von A nicht für B. Erzeuge ein neues Paket und hole die betroffene Entscheidung erneut ein. Ein Neustart erhält Ablehnung und ausstehende Freigaben; ein Zeitablauf verwandelt sie niemals in Zustimmung.

Native Berechtigungssysteme steuern Werkzeugaktionen. Beim Claude Agent SDK kann ein Callback Laufzeitentscheidungen anfordern; Gemini CLI verwendet Richtlinienentscheidungen. Verbinde diese Kontrollen bewusst mit dem Koordinator. Ein schriftliches „genehmigt“ vom Agenten bleibt normale Ausgabe.

Was schiefgeht

Der Runner vertraut approved: true in einer Antwort. Eine Freigabe hängt nur am Dateinamen, dessen Inhalt sich ändern kann. Ein Testlog nennt keine Revision oder stammt von einem Test, den der Implementierer nebenbei geändert hat.

Verwende koordinatorverwaltete Entscheidungen, unveränderliche Ergebnisstände und echte Befehlsresultate. Zeige Änderungen an den Prüfungen gesondert.

So prüfst du das Ergebnis

Gib ein Beispielpaket frei, ändere ein Byte seiner Ergebnisdatei und versuche fortzufahren. Die alte Entscheidung darf das neue Ergebnis nicht autorisieren. Wiederhole das mit anderer Basisrevision und anderem Ziel.

Starte mit einer abgelehnten oder ausstehenden Entscheidung neu. Der Ablauf muss angehalten bleiben. Füge approved: true in eine Agentenantwort ein und prüfe, dass es keine Befugnis erzeugt.

Lass zuletzt einen Reviewer den geplanten Schritt nur anhand des Pakets erklären. Fehlender Kontext gehört ins Paket, bevor der Ablauf größer wird.