REA CI- und Tests-Prüfung
Ermitteln, welche Prüfungen echte Regressionen abfangen und welche Kosten ohne Schutzverlust entfernt werden können. Das Ergebnis kann ein verifizierter Fix, eine evidenzbasierte Empfehlung oder eine explizite Entscheidung zum Stoppen sein.
Folgen Sie der AGENTS.md des Checkouts, der Testanleitung und den Beitragsregeln. Verwenden Sie deren aktuelle Befehle und die festgelegte Toolchain, nicht Befehle, die aus einer früheren Prüfung in Erinnerung geblieben sind. Bewahren Sie den angeforderten Umfang: Eine Untersuchung allein berechtigt nicht zu Änderungen; diese Fähigkeit erteilt keine Erlaubnis, Issues zu veröffentlichen, zu pushen oder zu mergen. Die bestehende Benutzerautorisierung gilt weiterhin. Bewahren Sie Prüfnotizen und Rohdaten außerhalb des versionierten Baums auf, normalerweise in einem aufgabenspezifischen /tmp-Verzeichnis.
Die ausgeführte Basislinie ermitteln
Holen Sie sich die neueste Version von main, wenn der Benutzer danach fragt. Fixieren Sie den Basis-SHA und die geprüfte Workflow-Revision; verwenden Sie einen isolierten Worktree, wenn Code geändert oder verglichen wird. Ändern Sie nicht den Checkout einer anderen Aufgabe. Zeichnen Sie ungesicherte Änderungen und den genauen Befehl, die Toolchain, den Host, die ausgewählten Tests, die Instrumentierung und die Voraussetzungen auf. Ein alter Lauf ist ein Beleg für seine ausgeführte Revision, selbst wenn main fortschreitet.
Verfolgen Sie Workflow-Trigger, Auswahl geänderter Pfade, Job-Abhängigkeiten, wiederverwendbare Aktionen, Paketskripte, Testermittlung, Artefaktproduzenten und Berichtsgates bis zu den tatsächlich ausgeführten Befehlen. Beziehen Sie Skripte, generierte Daten, Runtime-Registrierung und Teilprozessgrenzen ein, die in Importgraphen fehlen. Überprüfen Sie positive und negative Auswahlpfade: Erforderliche Dateien müssen einmal pro beabsichtigter Testkonfiguration gefunden werden; bewusste Wiederholungen von Plattform/Konfiguration sind getrennte Abdeckungen. Ein fehlender expliziter Test oder ein fehlender erforderlicher Bericht darf nicht grün werden. Optionale Spuren können übersprungen werden; bewahren Sie ihre angegebenen Voraussetzungen.
Verwenden Sie vorhandene Zeit- und Fehlerartefakte, um verdächtige Familien auszuwählen. Führen Sie relevante Prüfungen durch, um eine Basislinie zu erstellen; heben Sie sich eine vollständige lokale Suite für eine breite CI-Diagnose oder Unsicherheiten auf, die fokussierte Prüfungen nicht auflösen können. Bauen Sie eine unveränderte vollständige Suite nicht nach jeder Dokumentationsänderung neu auf oder führen Sie sie nicht erneut aus.
Den Fehler oder den Schutz nachweisen
Geben Sie für jeden Kandidaten das erwartete beobachtbare Verhalten und dessen Besitzer an, erstellen Sie dann die kleinste Reproduktion gegen das Produktionsverhalten. Folgen Sie dem Produzenten und den betroffenen Verbrauchern, bevor Sie entscheiden, wo der Fehler behoben werden soll.
- Bei Drift vergleichen Sie Fixtures mit aktuellen Anforderungskriterien, Protokollantworten, benannten Verträgen, Tool-Versionen und tatsächlichen öffentlichen Einstiegspunkten. Ein plausibel aussehender Mock kann fehlschlagen, bevor das Verhalten erreicht ist, das sein Test abdecken soll. Durchsuchen Sie die gesamte betroffene Fixture-Familie, einschließlich anderer Versionsstrings. Bewahren Sie absichtlich fehlerhafte Fixtures auf und testen Sie deren beabsichtigte Ablehnung.
- Bei einem verdächtig grünen Test stören Sie das relevante Verhalten in einer isolierten Kopie oder injizieren Sie einen kontrollierten Fehler. Verifizieren Sie, dass die vorhandene Assertion oder das Gate ihn erkennt. Ein Test kann lediglich seinen Mock wiederholen, veralteten Code importieren oder einen Teilprozess/Prüferfehler verbergen. Stellen Sie Mutationen nach dem Experiment wieder her.
- Bei gemeinsam genutztem Setup oder Bereinigung ordnen Sie unterschiedliche Assertions ihren beibehaltenen Szenarien zu. Bewahren Sie fehlerhafte Eingaben, Abbruch, Bereinigungsfehler, Berechtigungen, Kapazität, Identität und sinnvolle Parallelitätsinteraktionen auf. Ein schnellerer Lauf, der einen Fall überspringt oder sein Orakel schwächt, ist keine Verbesserung.
- Bei der Anbieterabdeckung trennen Sie Nachweise von Fake-Produzenten, Grenzfällen und tatsächlicher Engine. Überprüfen Sie benannte Überspringungen und Voraussetzungen; Fixtures belegen kein echtes Ghidra-, LLDB-, Browser- oder anderes Anbieterverhalten.
Klassifizieren Sie Ergebnisse als reproduzierte Fehler, unterstützte Kosten, Hypothesen oder nicht verfügbare Nachweise. Notieren Sie den Basisbefehl, die beobachtete Ausgabe/den Exit-Status, das erwartete Ergebnis, den betroffenen Umfang und eine konkurrierende Erklärung. Ein Fehler auf main kann bereits vorhanden sein; das macht ihn nicht automatisch irrelevant für eine CI-Prüfung. Führen Sie PR-Fehler auf die ausgeführte Revision und eine saubere Basislinie zurück, nicht nur auf deren Ähnlichkeit mit einem früheren Fehler. Wiederholen Sie nur, um eine bestimmte transiente Erklärung zu testen; behalten Sie den ursprünglichen Fehler bei und hören Sie auf, wenn die Wiederholung keine neuen Erkenntnisse bringt. Eine erfolgreiche Wiederholung begründet weder eine Ursache noch einen Fix.
Effizienz bewerten, ohne das Gate zu verlieren
Lesen Sie Messung und CI-Prüfungen, wenn Sie Langsamkeit, Caching, Runner-Wartezeiten, gemeinsame Artefakte oder Log-Rauschen untersuchen. Vergleichen Sie gleichwertige abgeschlossene Arbeiten, bevor Sie eine Beschleunigung behaupten. Unterscheiden Sie Setup/Build-Zeit, Testausführung, Coverage-Instrumentierung, Abhängigkeitswartezeiten und Runner-Scheduling; geben Sie an, welche Kosten weiterhin ungemessen bleiben.
Bevorzugen Sie das Entfernen nachweislich doppelter Vorbereitung, die Wiederverwendung unveränderlicher Setups und die Reduzierung wiederholter Teilprozessarbeit vor der Verkleinerung der Korrektheitsabdeckung. Bewahren Sie unabhängige Sitzungen auf, bei denen der Lebenszyklus oder die Parallelität das Orakel ist. Halten Sie Live-Tests aktuell; ein zwischengespeicherter vorheriger Bestehen kann den aktuellen Host, installierte Anbieterinhalte, Berechtigungen oder externen Zustand nicht validieren.
Beheben, verifizieren und innerhalb des Umfangs übergeben
Wenn die Implementierung autorisiert ist, nehmen Sie die kleinste strukturelle Änderung an der verantwortenden Grenze vor und fügen Sie eine Regression hinzu, die auf der Basislinie aus dem richtigen Grund fehlschlägt. Testen Sie betroffene Verbraucher und sinnvolle negative Pfade erneut; verifizieren Sie die Cache-Invalidierung oder -Ermittlung, wenn sich diese Mechanismen ändern. Lesen Sie die installierte Turbo-Dokumentation, bevor Sie dessen Konfiguration oder Befehle ändern.
Führen Sie die anwendbaren Prüfungen des Repositorys durch und überprüfen Sie die vollständigen CI-Ergebnisse des aktuellen Heads vor einem autorisierten Merge. Bewahren Sie die erforderliche Abdeckung und Ermittlungsgates. Unterdrücken Sie keinen Fehler, fügen Sie keine pauschalen Wiederholungen hinzu, erhöhen Sie keine Timeouts und löschen Sie keine eindeutigen Assertions nur, um CI grün zu machen. Änderungen an diesen Kontrollen benötigen einen eigenen nachgewiesenen Grund und eine beibehaltene Fehlererkennung.
Melden Sie jedes bestätigte Problem mit genauer Revision, Reproduktion, Konsequenz, vorgeschlagener Korrektur und Validierungsgrenzen. Melden Sie Leistung mit Arbeitslast und Messungen, nicht nur einem Prozentsatz. Verwenden Sie englische Issue/PR-Datensätze, wenn dies angefordert wird; folgen Sie den Zuweisungen, Commit-Identität, Review- und Merge-Präferenzen des Benutzers, ohne diese für andere Benutzer anzunehmen. Öffnen Sie bereit zur Überprüfung stehende PRs nur, wenn dieser Lebenszyklus autorisiert ist. Lösen Sie notwendige Review-Feststellungen auf und überprüfen Sie den endgültigen main gegen den getesteten Baum nach dem Merge.
Hören Sie auf, wenn die autorisierte Arbeit verifiziert ist, verbleibende Vorteile nicht nachgewiesen sind oder weitere Änderungen Korrektheit gegen spekulative Geschwindigkeit eintauschen würden. Listen Sie echte Unsicherheiten auf, ohne sie in weitere Optimierungsrunden zu verwandeln.