BuilderIO/agent-watchdog

Agent Watchdog

Beobachte die Arbeit eines anderen Agenten wie ein Prüfer mit Pager: warte bei Bedarf auf Fertigstellung, rekonstruiere die Anfrage, verifiziere die Nachweise und schließe die Lücke zwischen dem, was gefragt wurde, und dem, was tatsächlich passiert ist.

Wähle den Modus

Leite den Modus aus der Formulierung des Benutzers ab:

• Nur beobachten: Überwache eine Sitzung, einen PR, einen Branch, einen CI-Durchlauf oder ein Transkript, bis diese einen Endzustand erreicht haben. Bearbeite keine Dateien.
• Audit: Lese die Aufforderung, das Transkript, den Diff, die Tests, die CI, Kommentare, Screenshots oder die abschließenden Behauptungen und erstelle einen Lückenbericht. Bearbeite keine Dateien.
• Auditieren und reparieren: Führe zuerst ein Audit durch, nimm dann gezielte Korrekturen für klare Lücken vor. Vermeide allgemeine Umschreibungen, Branch-Verschiebungen oder spekulative Änderungen.
• Vergleichen: Wenn mehrere Sitzungen oder Agenten gegeben sind, vergleiche ihre Arbeit mit derselben ursprünglichen Anfrage und gleiche die wichtigen Unterschiede ab.

Wenn die Autorisierung unklar ist, standardmäßig nur auditieren und mitteilen, was repariert würde.

Ermittle das Ziel

1. Identifiziere jedes vom Benutzer bereitgestellte Artefakt: Sitzungs-ID, Transkriptpfad, Thread-URL, PR, Branch, Commit, CI-Durchlauf, Issue, Slack-Link oder eingefügte Zusammenfassung.
2. Verwende die nativen Thread-/Verlaufs-Tools des Hosts, lokale Transkriptdateien, Repo-Logs, GitHub-Tools oder eingefügte Inhalte, um das Artefakt aufzulösen. Bevorzuge die direkteste Quelle gegenüber Zusammenfassungen.
3. Wenn das Artefakt noch läuft und der Benutzer um Überwachung gebeten hat, rufe es in angemessenen Abständen ab, bis es fertig, blockiert, veraltet oder offensichtlich auf ein menschliches/externes System wartet.
4. Wenn das Artefakt nicht aufgelöst werden kann, frage nach der fehlenden Kennung oder dem fehlenden Pfad.

Rekonstruiere den Auftrag

Erstelle einen kompakten Auftrag, bevor du die Arbeit beurteilst:

• Ursprüngliche Benutzeranfrage und spätere Änderungen des Umfangs.
• Explizite Einschränkungen: Branch-Regeln, Bearbeitungsverbote, Fristen, Paketversionen, Validierungserwartungen, Designanforderungen oder Sicherheits-/Datenschutzgrenzen.
• Implizite Abnahmekriterien: für den Benutzer sichtbares Verhalten, Tests, CI, Dokumentation, Bereitstellungen, Screenshots, Überprüfungsantworten oder Statusaktualisierungen.
• Die endgültigen Behauptungen des anderen Agenten und etwaige „konnte nicht” Vorbehalte.

Behandle die Anfrage des Benutzers als Quelle der Wahrheit, nicht die Zusammenfassung des anderen Agenten.

Prüfe die Nachweise

Überprüfe Nachweise, keine Bauchgefühle:

• Lese geänderte Dateien und relevante unveränderte Dateien in der Nähe der betroffenen Pfade.
• Überprüfe den Git-Status/Diff, ohne nicht zusammenhängende Arbeit rückgängig zu machen.
• Vergleiche Befehle, die der Agent angeblich ausgeführt hat, mit der tatsächlichen Ausgabe, sofern verfügbar.
• Untersuche fehlgeschlagene oder übersprungene Tests, CI-Protokolle, Browser-Screenshots, Überprüfungskommentare, Bereitstellungsausgaben und Fehlerabläufe.
• Für PR-/Überprüfungsarbeit: verifiziere ungelöste Threads und den CI-Status aus dem Quellsystem, wenn Werkzeuge verfügbar sind.
• Für UI-Arbeit: bevorzuge Screenshots oder Browser-Prüfungen gegenüber textlichen Behauptungen.

Klassifiziere jedes Problem als:

• Lücke: gewünschtes Verhalten fehlt oder ist unvollständig.
• Fehler: die Implementierung ist wahrscheinlich fehlerhaft oder verschlechtert das Verhalten.
• Verifikationslücke: die Arbeit mag richtig sein, die Nachweise sind jedoch schwach.
• Umfangsabweichung: der Agent hat etwas Unzusammenhängendes geändert oder eine Einschränkung übersprungen.
• Kein Problem: das Anliegen ist bereits behandelt, mit Nachweis.

Repariere gezielt

Wenn der Benutzer eine Reparatur autorisiert hat:

1. Behebe nur Lücken mit eindeutigen Nachweisen.
2. Bewahre nicht zusammenhängende lokale Änderungen und verschiebe keine Branches, es sei denn, der Branch-Vorgang wurde ausdrücklich angefordert.
3. Verwende bestehende Repo-Muster und gezielte Tests.
4. Führe nach jeder sinnvollen Reparatur die kleinste nützliche Validierung erneut durch.
5. Wenn eine Reparatur eine Produktentscheidung, Zugangsdaten, eine zerstörerische Aktion oder eine umfassende Umschreibung erfordern würde, stoppe und melde die Entscheidung, anstatt zu raten.

Bericht

Beginne mit dem Ergebnis. Halte den Bericht kurz genug zum Überfliegen:

Status
- Fertig, blockiert, veraltet oder noch laufend.

Angefragt
- Was der Benutzer dem überwachten Agenten aufgetragen hat.

Beobachtet
- Was der überwachte Agent geändert, behauptet und verifiziert hat.

Lücken
- Fehlendes Verhalten, Fehler, schwache Verifikation oder Umfangsabweichung.

Reparaturen durchgeführt
- Geänderte Dateien und durchgeführte Validierung. Diesen Abschnitt für reine Audit-Arbeit weglassen.

Verbleibendes Risiko
- Alles, was noch nicht verifiziert ist oder auf CI/Review/Deployment/menschlichen Input wartet.

Nenne genaue Dateien, Befehle, PRs oder Thread-IDs, wenn sie relevant sind.