CoroidIhre AI Software-Fabrik
Dokumentation

Wie Coroid seine eigene Arbeit überprüft

Warum ein pull request aus Coroid bereits überprüft vorliegt und welche Aussage jede Überprüfungsebene tatsächlich trifft.

Ein pull request aus Coroid durchläuft vor der Anzeige eine Verifizierung. Dieser Abschnitt erläutert die Bedeutung und die Konfiguration.

Die Ebenen

Die Verifizierung besteht nicht aus einer einzigen Komponente – vier Ebenen arbeiten dabei, jede beantwortet eine andere Frage.

Ihr Test-Suite. Das stärkste verfügbare Signal, da es bereits widerspiegelt, was Ihr Team als wichtig erachtet. Coroid führt es in einem sauberen Arbeitsbereich für jeden Task aus.

Qualitäts-Gates. Richtlinienbasierte Prüfungen – Abdeckungsgrad, Linting, Browser-Tests und die Globalisierungs-Prüfung für mehrsprachige Projekte. Blockierende Gates stoppen den Task; beratende Gates zeichnen das Ergebnis auf und erlauben die Fortsetzung. Siehe Qualitäts-Richtlinien und Gates. Die Sicherheitsprüfung hat ihren eigenen Platz: siehe Sicherheit.

Rezension. Ein Rezensions-Agent liest den fertigen Diff und erstellt Ergebnisse. Korrigierbare Ergebnisse werden dem Entwickler zur Überarbeitung zurückgegeben; die übrigen werden dem pull request zugeordnet.

Nachweise. Vorschau-Deployments, Scan-Ergebnisse und Abdeckungs-Differenzen werden direkt dem pull request zugeordnet, sodass die Verifizierung mit dem Code einhergeht. Siehe Rezensions-Nachweise.

  1. Ihr Test-SuiteStört die Änderung das Bestehende?
  2. Qualitäts-GatesErfüllt sie die in Ihren Richtlinien festgelegten Standards?
  3. ReviewWürde ein aufmerksamer Leser des Diffs die Änderung akzeptieren?
  4. NachweiseIst der Nachweis dem Code beigefügt?
  5. Ihr ReviewIst dies die richtige Änderung?

Jede automatisierte Ebene läuft vor der Erstellung des pull request, sodass Fehler als Nacharbeit innerhalb des Laufs auftreten.

Jede automatisierte Ebene beantwortet eine andere Frage. Keine von ihnen entscheidet, ob dies die richtige Lösung ist – das bleibt bei Ihnen.

Was dies beweist und was nicht

Die Verifizierung bestätigt, dass die Änderung das tut, was angegeben ist, das Bestehende nicht stört und Ihre festgelegten Standards erfüllt.

Sie beweist nicht dass die Änderung das Richtige zum Bauen ist. Das übernehmen die Akzeptanzkriterien in der Spezifikation sowie Ihre Rezension.

Eine Änderung kann alle Ebenen bestehen und dennoch falsch sein. Diese klare Unterscheidung sorgt dafür, dass das System vertrauenswürdig bleibt – sobald die Verifizierung als Urteil dargestellt wird, hören die Menschen auf zu rezensieren.

Der Sinn des frühen Ausführens

Jede Ebene läuft bereits vor der Existenz des pull request, sodass Fehler als Überarbeitung innerhalb des Prozesses zurückkommen – statt als abgelehnter pull request.

Es ist günstiger, im Arbeitsbereich zu scheitern als auf dem Bildschirm. Ihre Rezension sollte der erste menschliche Blick sein – nicht der erste Eindruck.

Wo Sie beginnen sollten

Falls Sie dies zum ersten Mal konfigurieren:

  1. Stellen Sie sicher, dass Ihre Test-Suite funktioniert – siehe Build- und Test-Konfiguration. Alles andere ist irrelevant, wenn dies nicht stimmt.
  2. Legen Sie eine organisationsweite Standard-Richtlinie auf Ihrer Standard Ebene fest – nicht auf der strengsten.
  3. Verbinden Sie die Nachweis-Anbieter, die Sie bereits nutzen.
  4. Fügen Sie die Gates einzeln hinzu – zuerst die beratenden.

In diesem Abschnitt