Coroid schließt den Vorgang ab, indem es eigenständig einen pull request (Pull Request) auf einem eigenen Branch gegenüber Ihrem Basis-Branch eröffnet. Es führt niemals selbst einen Merge durch. Ein Merge ist immer eine Entscheidung einer Person – entweder in Ihrem Provider oder mit Freigeben & mergen in Coroid. Siehe Merge-Vorgang.
Was dabei herauskommt
- die Code-Änderung
- die dazu geschriebenen oder aktualisierten Tests
- das Ergebnis der Ausführung Ihres bestehenden Test-Suites
- das Ergebnis der von Ihrer Organisation definierten Qualitätsprüfungen
- eine Überprüfung der Differenz, wobei bereits behobene oder aufgelistete Feststellungen enthalten sind
Es geht nicht darum, Ihre Überprüfung zu ersetzen. Vielmehr soll Ihre Überprüfung nicht die erste sein.
main- Die Code-Änderung4 Dateien
- Geschriebene oder aktualisierte Tests2 Dateien
- Ihr bestehendes TestpaketBestanden
- Qualitätsprüfungen1 Hinweis zur Beratung
- Freigabe zur Überprüfung2 behoben, 1 aufgelistet
Was genau zu prüfen ist
Die mechanischen Aspekte wurden bereits überprüft. Konzentrieren Sie sich auf die Dinge, die nur Sie beurteilen können:
- Löst es das richtige Problem? Vergleichen Sie es mit den Akzeptanzkriterien der Spezifikation – nicht mit Ihrer Erinnerung an die ursprüngliche Anforderung.
- Passt es zum vorhandenen Codebestand? Konventionen, Benennungsregeln, die Struktur der Abstraktion. Coroid analysiert Ihren Code, um diese zu erkennen, und trifft meist die richtigen Entscheidungen – doch nicht immer.
- Welche Bereiche werden berührt, die Sie nicht erwartet haben? Sehen Sie sich die Dateiliste vor der Differenz an.
- Sind die neuen Tests sinnvoll? Ein bestehender Test, der nichts beweist, ist schlimmer als gar kein Test.
Arbeit zurücksenden
Sie haben drei Optionen – je nach Aufwand steigend:
- Kommentar hinzufügen und Nachbesserung anfordern – die Aufgabe wird mit Ihren Hinweisen an den Entwickler-Agenten zurückgesendet, wobei der Kontext erhalten bleibt. Ideal für den Fall „Die Lösung ist richtig, aber unvollständig“.
- Plan ablehnen und erneut ausführen – wenn der Ansatz falsch ist, nicht die Umsetzung.
- Aufgabe abbrechen – wenn die Arbeit überhaupt nicht erfolgen soll. Das Abbrechen stoppt den Prozess und gibt den Agenten-Slot frei.
Seien Sie bei den Kommentaren zur Nachbearbeitung genauso präzise wie bei einem Kollegen. „Das behandelt nicht den leeren Fall in parseRange" liefert eine Korrektur; „braucht Arbeit“ führt zu einer
Vermutung.
Zusammenführen
Coroid führt niemals von selbst ein Zusammenführen durch. Es gibt keine Einstellung, die ein Zusammenführen nach Abschluss einer Aufgabe auslöst. Ein Zusammenführen erfolgt auf zwei Arten – jeweils beginnend mit der Entscheidung einer Person zum Zusammenführen.
Dies gilt auch für Arbeiten, die unter einem Auftrag ebenfalls. Coroid zeichnet auf, welche Entscheidung es bezüglich jedes Zusammenführungsvorgangs getroffen hätte, um seine eigene Urteilsfähigkeit zu messen – handelt jedoch nie auf Grundlage dieser Aufzeichnung. Siehe Was Coroid entscheidet und was bei Ihnen bleibt.
In GitHub oder GitLab
Führen Sie das Zusammenführen des pull request in Ihrem Provider durch – unter Verwendung Ihrer üblichen Branch-Schutzmechanismen, erforderlichen Prüfungen und Freigaberegeln. Das pull request ist ein gewöhnlicher Branch – das ist beabsichtigt –, sodass es die gleichen Überprüfungen und CI-Prozesse durchläuft, denen Sie bereits vertrauen.
Von Coroid aus mit „Approve & merge“
Die Überprüfungsbildschirme in Coroid enthalten einen Approve & merge Button. Er fordert Sie auf, die Entscheidung zu bestätigen; anschließend führt Coroid das Zusammenführen des pull request für Sie über GitHub oder GitLab durch, unter Nutzung der Repository-Verbindung des Projekts. Es handelt sich dabei um dasselbe Zusammenführen wie das Drücken des Zusammenführungs-Buttons in Ihrem Provider – somit gelten dort Ihre Branch-Schutzmechanismen, erforderlichen Prüfungen und Freigaberegeln. Falls diese das Zusammenführen blockieren, zeigt Coroid den Grund vom Provider an und es wird nichts zusammengeführt.
Was vor dem Zusammenführen geschieht, hängt davon ab, was Sie freigeben:
- Eine Aufgabe. Die Aufgabe benötigt zunächst ein pull request. Falls noch keines vorhanden ist, bietet der Überprüfungsbildschirm Erstellen Sie ein PR vor Approve & merge. Wenn Sie die Freigabe erteilen, pusht Coroid den Aufgaben-Branch, sodass der pull request die neuesten überprüften Commits enthält, und führt anschließend das Zusammenführen des pull request durch. Zur Freigabe einer Aufgabe ist Schreibzugriff auf das zugehörige Projekt erforderlich.
- Ein Plan. Die zu einem Plan gehörenden Aufgaben können nicht einzeln zusammengeführt werden. Der einzige pull request des Plans wird während der Promotionsüberprüfung freigegeben. Zuerst prüft Coroid, ob sich der Basis-Branch seit Beginn des Plans geändert hat (siehe Wenn sich der Basis-Branch ändert), die erforderlichen Qualitätsprüfungen bestanden sind, für pull request keine Merge-Konflikte bestehen und kein Lane-Gate blockiert. Anschließend wird pull request zusammengeführt. Zum Genehmigen eines Plans ist Schreibzugriff auf das zugehörige Projekt erforderlich.
- Erzwingen des Zusammenführens. Die Promotionsüberprüfung eines Plans bietet außerdem Erzwingen des Zusammenführens. Dabei werden die Prüfungen von Coroid bezüglich des Basis-Branches, der Zusammenführungskonflikte und der Lane-Gates übersprungen – nicht jedoch die erforderlichen Qualitätsprüfungen oder die Regeln Ihres Providers. Eine schriftliche Begründung ist erforderlich; diese wird zusammen mit der Promotionsentscheidung festgehalten. Zudem ist Administratorzugriff auf das Projekt nötig.
Der Chat-Assistent und MCP-Clients können ebenfalls den Plan für die pull request genehmigen oder erzwingen zu kombinieren. Sie handeln in Ihrem Namen, weshalb dieselben Prüfungen und Projektzugriffsrechte gelten. Der Assistent bittet Sie stets zuvor um Bestätigung. Eine erzwungene Kombination durch einen MCP-Client wartet immer in Freigaben auf eine menschliche Entscheidung. Ob eine Genehmigung durch einen MCP-Client dort verweilt, hängt von Ihren Automatisierungsrichtlinien ab. Keiner der beiden kann ein einzelnes Task ausführen.
Vorbereiten des zukünftigen Releases
Nach der Kombination öffnen Sie die Releases Registerkarte und wählen Sie Neues Release. Wählen Sie den kombinierten Commit aus, den Sie veröffentlichen möchten; Coroid listet die darin enthaltenen Pull Requests auf. Die Release-Seite führt anschließend jedes Umfeld durch vier Schritte: Prüfung, Genehmigung, Ausrollen und Integritätscheck. Ihr Repository und CI/CD übernehmen weiterhin das Ausrollen. Coroid markiert ein Release erst als ausgerollt, wenn Ihre Pipeline dies bestätigt oder wenn ein Inhaber oder Administrator eine verifizierte externe Ausrollung dokumentiert.
Weiter
Releases – bereiten Sie den kombinierten Commit vor und verfolgen Sie dessen Weg durch jedes Umfeld. Nächste Schritte listet die anderen Arbeitsabläufe auf.