Coroid ist eine AI-Softwarefabrik für Produktionssysteme. Die Entwicklungsteams legen den Standard einmal fest: den Projektkontext, die Qualitätsrichtlinien, die jede Änderung erfüllen muss, die Überprüfungsregeln sowie die Personen, die die Freigabe erteilen. Danach kann jeder Mitarbeiter in Ihrem Unternehmen eine Änderung in einfacher Sprache anfordern – ohne CLI und ohne Kenntnis der Code-Erstellungsprozesse. Coroid plant die Arbeit, schreibt den Code, testet ihn, überprüft ihn gemäß diesem Standard und öffnet anschließend einen pull request in Ihrem Repository zur Freigabe durch Sie.
Diese Dokumentation behandelt das Produkt in seiner aktuellen Auslieferungsversion. Falls eine Funktion hier nicht dokumentiert ist, steht sie noch nicht zur Verfügung.
Neu hier?
Gehen Sie Schritt für Schritt vor: Erste Schritte in der richtigen Reihenfolge. So gelangen Sie von einem leeren Konto zu einem zusammengeführten pull request: Erstellen Sie eine Organisation, verknüpfen Sie ein Repository, legen Sie ein Projekt an, führen Sie eine Aufgabe aus und überprüfen Sie das Ergebnis.
Verstehen Sie die Funktionsweise
Wie eine Aufgabe zu einem pull request wird ist die Seite, auf die alle anderen Verweise enthalten – der vollständige Weg von Ihrer Beschreibung bis zu einem PR, wobei jede Phase benannt ist.
Anschließend Agent-Rollen zeigen, wer welche Aufgaben übernimmt, und Leitfaden zur spezifikationsgesteuerten Entwicklung, womit Sie die größte Hebelwirkung erzielen können. Die Qualität dessen, was Coroid erstellt, hängt von der Qualität der vorgegebenen Anforderungen ab.
- 1
SpezifikationWas gebaut werden soll und wie Sie erkennen, dass es funktioniert.
ArchitektSie können bearbeiten - 2Planung
Geordnete Schritte, die vor dem Schreiben von Code geprüft werden.
ArchitektSie genehmigen - 3
ErstellungCode und Tests werden in einer isolierten Arbeitsumgebung geschrieben.
Entwickler - 4
ÜberprüfungIhr Test-Suite sowie Prüfungen und Qualitätskriterien.
QA - 5
ReviewEine automatisierte Überprüfung der Differenzen.
Rezensent - 6Pull-Request
Auf einem Branch in Ihrem Repository, wartet auf Sie.
Sie führen zusammen
Fehlgeschlagene Verifizierungen und behebbare Rezensionsergebnisse gehen als Nachbesserung an den Entwickler zurück, bevor ein pull request erstellt wird.
Sich zurechtfinden
| Abschnitt | Inhalt |
|---|---|
| Erste Schritte | Vom Konto zum ersten zusammengeführten pull request |
| Konzepte | Wie das System tatsächlich funktioniert |
| Arbeit und Planung | Arbeitsbeginn, Aufgaben, Pläne, Releases |
| Projekte und Code | Repositorys, Einrichtung von Build- und Testprozessen, Kontext |
| Die Fabrik | Ausführung der Arbeit, Automatisierungen, Berichte |
| Qualität und Überprüfung | Prüfschritte, Ergebnisse, Nachweise, Browser-Tests |
| Globalisierung | Sprachen, Übersetzungen, weltweit einsetzbarer Code |
| Betrieb und Überwachung | Mission Control, Ergebnisse, Benachrichtigungen |
| Organisationseinstellungen | Mitglieder, Schlüssel, Richtlinien, Aufbewahrung |
| Abrechnung und Kapazität | Slots, Credits, Nutzung, Rechnungen |
| Integrationen | Quellcode-Verwaltung, Chat, MCP, Nachweise, Hooks |
| Referenz | Glossar, Statusangaben, Grenzwerte, Fehlerbehebung |
Drei Dinge, die Sie sofort wissen sollten
Agent-Slots bestimmen, wie viele Aufgaben gleichzeitig ausgeführt werden – nicht jedoch deren Ausführungsgeschwindigkeit. Die Dauer einer einzelnen Aufgabe hängt von der Größe der Änderung und Ihrem Test-Suite ab. Siehe Kapazität und Agent-Slots.
NEEDS_HUMAN_REVIEW ist kein Fehler. Das bedeutet, dass die Arbeit eine Entscheidung erfordert, die nur Sie treffen können. Beantworten Sie die Anfrage, und die Aufgabe wird fortgesetzt. Siehe
Aufgabenstatus.
Etwas verhält sich nicht wie erwartet
Beginnen Sie beim Index zur Fehlerbehebung, der Symptome mit passenden Lösungen verknüpft.