zehuichan/vibe-harness

Überprüfung einer Änderung

Diese Fähigkeit dient als Leitfaden, nicht als vollständige Checkliste. Überprüfen und holen Sie die aktuelle Basis und den exakten Head der Änderung, listen Sie dann die geänderten Pfade mit dem Befehl commands.change-scope des Profils auf, bevor Sie den Diff und genügend umgebenden Code lesen, um das Design zu verstehen. Stellen Sie die Basis nach einem Retarget oder Merge wieder her. Priorisieren Sie Korrektheit, Lebenszyklus, Sicherheit und unterbrochenes erforderliches Verhalten vor Stil; eine kurze Überprüfung mit einem begründeten Blockierer ist besser als eine Liste von Nichtigkeiten.

Lesen Sie die Anforderungen, bevor Sie den Diff beurteilen. Ordnen Sie die geänderten Pfade den folgenden Quellen zu, öffnen Sie jede zugehörige Seite, und lesen Sie erst dann den Diff vor dem Hintergrund dieser Anforderungen. Das Beurteilen eines Diffs aus dem Gedächtnis an die Regeln ist der Grund, warum ein Verstoß die Überprüfung passiert.

Quellen der Wahrheit

• AGENTS.md im Stammverzeichnis und in jedem betroffenen Teilbaum: ständige Anweisungen.
• .agents/project-profile.md: Befehle, aktivierte Oberflächen, Nachweise pro Oberfläche und projektspezifische Regeln.
• docs/defensive-patterns/: Regeln, die bei der Überprüfung durchgesetzt werden, eine Seite pro Artefaktfamilie; lesen Sie jede Seite, die der Diff berührt.
• docs/AGENTS.md und docs-standard: Dokumentationsplatzierung und -disziplin.
• prose-standard: erforderliche Abdeckung und redaktionelles Urteil für Kommentare, Dokumentationen, Prompts und sichtbare Zeichenfolgen.
• error-handling: Fehlerklassifizierung, Eigentümerschaft, Eingrenzung, Garantien und Berichte.
• lifecycle-review: Singleton-Zustand, nicht rückgängig gemachte Effekte und Bereinigungsreihenfolge in Plugins, Diensten und Komponenten.
• test-reliability: Isolation und Regressionssicherheit für ressourcenbesitzende, asynchrone oder flaky Tests.
• .agents/notes/: Designbegründung. Behandeln Sie eine Meinungsverschiedenheit mit einer Agenten-Notiz als Design-Diskussion, nicht als automatisches Veto.
• Wenn das Profil surfaces.ui aktiviert, die Fähigkeiten ui-ux-review und responsive-ui.

Blockierende Anforderungen

1. Neue Prosa erhält eine semantische Überprüfung. Verwenden Sie den prose-standard bei jedem hinzugefügten oder geänderten Markdown-Abschnitt, API-Dokument, Kommentar, Prompt, Beschreibung, Diagnose und sichtbaren Zeichenfolge. Automatisierte Prüfungen stellen keine Genauigkeit, Platzierung oder Abdeckung fest.
2. Dokumentation stimmt mit dem Code überein. Konfiguration, Standardwerte, Fehler, Wire-Felder, Ereignisse und öffentliches Verhalten aktualisieren die zugehörige README und API-Dokumente im selben Diff. Markieren Sie Implementierungsbeschreibungen, Test-Durchläufe, Überprüfungsverlauf und duplizierte Begründungen.
3. Eigentümerschaft und Bereinigung. Für Plugin-, Dienst- oder Komponentencode mit einem Lebenszyklus wenden Sie den lifecycle-review auf das geänderte Verhalten und die betroffenen Verbraucher an. Jede neue Registrierung weist ihre Entsorgung nach.
4. Erforderliche Nachweise existieren. Überprüfen Sie, ob der Autor die relevanten Prüfungen für den Diff durchgeführt hat (siehe pre-push-checks) und dass CI den Rest abdeckt; überprüfen Sie die semantischen Lücken, die keiner von beiden erkennen kann.
5. Lokalisierte UI-Kopien. Wenn das Profil surfaces.localized-ui aktiviert, lehnen Sie Produkttext ab, der in Markup, Vorlagen, Hilfsfunktionsrückgaben, Barrierefreiheitsattributen oder Komponentenstandards eingebettet ist; verlangen Sie den Lokalisierungsmechanismus und Nachweise in jeder betroffenen Locale. Benutzer-, Modell- und Wire-Daten bleiben unverändert.
6. Breaking Changes werden dokumentiert. Wenn das Profil surfaces.public-api aktiviert, enthält ein extern wahrnehmbarer Bruch eine Upgrade-Anleitung im selben Diff (siehe upgrade-guide).

Manuelle Prüfungen

• Absichts- und Schnittstellenverträge: Verfolgen Sie beide Seiten jeder geänderten Schnittstelle. Bestätigen Sie, dass die Implementierung der Beschreibung und allen Agenten-Notizen entspricht, einschließlich Fehler, Abbruch, Eigentümerschaft und Entsorgung.
• Fehlerbehandlung: Lehnen Sie Catch-and-Continue ab, es sei denn, der Zustandsinhaber stellt fest, dass die Vorbedingungen für die spätere Arbeit erfüllt sind.
• Lebenszyklus und Nebenläufigkeit: Prüfen Sie bei asynchronem Setup, Callbacks, Prozessen oder Teardown auf Wettlaufsituationen vor der Veröffentlichung, Abbruch während Await, unabhängige Fehlerberichterstattung, Callback-Eingrenzung, Eigentümerschaft vor Wiedereintritt, vollständige Detach-Bereinigung und quieszente Entsorgung.
• Fähigkeit und Verbraucherpassung: Verfolgen Sie jeden aktuellen Verbraucher, markieren Sie dann verbraucherspezifisches Verhalten, das in eine gemeinsame Schnittstelle durchsickert. Markieren Sie auch das Gegenteil: eine neue öffentliche Methode auf einem generischen Dienst, deren einziger Aufrufer ein interner Verbraucher ist; bevorzugen Sie eine private Fähigkeit, die diesem Verbraucher bei der Konstruktion übergeben wird.
• Umfang, Eigentümerschaft und Notwendigkeit: Ordnen Sie jede Abstraktion, jeden Zustandsautomaten, jede Option, jede defensive Kopie und jeden Kompatibilitätspfad seinem aktuellen Vertrag, Produktionsverbraucher und besitzenden Modul zu. Hinterfragen Sie nicht zusammenhängende Funktionen und spekulative Allgemeinheit.
• Konfiguration und öffentliche Entscheidungen: Fragen Sie, welche aktuellen Verbrauchernachweise oder Vorkenntnisse jeden Standardwert, jede öffentliche Operationsmenge, jedes Format oder jedes importierte externe Konzept stützen. Verlangen Sie eine explizite Entscheidung oder Vertagung, wenn dieser Nachweis fehlt.
• Modellperspektive: Wenn das Projekt Prompts, Tool-Schemas oder Ergebnisse an ein Modell sendet, überprüfen Sie den genauen Text, den das Modell erhält. Markieren Sie Konzepte außerhalb der Aufgabe des Modells, und überprüfen Sie stabilen Text wörtlich und dynamisches Verhalten durch Tests oder Schnappschüsse.
• Durchsetzung: Folgen Sie jedem Ablehnungspfad bis zu der Operation, die ihn ausführt; testen Sie direkte und alternative Aufrufer, die Schemas, Prompts, Fassaden, Wrapper oder Listener-Reihenfolge umgehen können.
• Ausgeliehener und abgeleiteter Zustand: Bestimmen Sie, ob jeder beibehaltene Wert ausgeliehen oder besessen ist, verfolgen Sie dann Benachrichtigungen und jeden Cache, Prompt, UI-Echo, Wiederholung und Abfrageansicht bis zum dokumentierten Erfolgspunkt und der maßgeblichen Quelle.
• Grenzen decken die endgültige Operation ab: Lokalisieren Sie den Inhaber des vollständigen emittierten oder beibehaltenen Ergebnisses, einschließlich Wrapper und Metadaten. Untersuchen Sie winzige und exakte Grenzen, überdimensionierte einzelne Blöcke und Multibyte-Text auf Byte-Grenzen.
• Echter Einstiegspfad: Tests üben den ausgelieferten Loader, Binary, Worker oder Subprozess aus, wo relevant. Ein handzusammengestelltes Test-Setup fängt keine ungültigen Exporte.
• Teststärke: Zusicherungen schlagen beim beabsichtigten Regressionsfall fehl und überprüfen externen Zustand, Logs, Ereignisse oder Entsorgung, anstatt die Implementierung neu zu formulieren. Abdeckung ist notwendig, aber kein Nachweis dafür, dass das Szenario korrekt ist.
• Negativkontrollen: Überprüfen Sie, dass ein absichtlich ungültiger Fall durch den echten Runner für jede geänderte Akzeptanzregel fehlschlägt.
• Implementierte Agenten-Notizen stimmen mit der ausgelieferten Realität überein: Wenn eine Änderung eine vorgeschlagene Notiz implementiert, verschieben und schreiben Sie sie als gegenwärtigen, ausgelieferten Zustand im selben Diff um.
• Übersetzungen: Vergleichen Sie Bedeutung und Terminologie auf beiden Seiten; übereinstimmende Struktur beweist keine Übersetzungsqualität.

Melden von Ergebnissen

Geben Sie den Defekt, den Ort, die Auswirkung und den Nachweis an. Platzieren Sie einen lokalisierten Defekt inline im engsten relevanten Diff-Bereich; verwenden Sie einen Top-Level-Kommentar für übergreifende Architektur, Umfang oder Synthese. Trennen Sie Blockierer von Vorschlägen und lassen Sie Probleme weg, die bereits durch eine bestandene Prüfung durchgesetzt wurden. Wenn Sie eine Überprüfung erhalten, überprüfen Sie jede Behauptung und beheben oder widerlegen Sie sie auf technischer Grundlage.