Kernkonzepte

CodeCourier baut auf einem kleinen Satz miteinander verbundener Konzepte auf. Zu verstehen, wie sie zusammenhängen, ist der Schlüssel, um die Plattform effektiv zu nutzen. Diese Seite erläutert jedes Konzept, seine Rolle im System und wie es mit allem anderen verbunden ist.

Projekte

Ein Projekt ist die oberste organisatorische Einheit in CodeCourier. Jede andere Ressource - Sandboxes, Workflows, Läufe, Personas, Kontexte, Assets, Pläne, Issues, Learnings, wiederkehrende Aufgaben, Sprint Chains, Teammitglieder und API-Keys - gehört zu genau einem Projekt.

Jedes Projekt hat einen eindeutigen Slug, der in allen URLs erscheint (z. B. /p/my-app/dashboard), einen Owner und optionale Metadaten wie eine GitHub-Repository-URL und ein Projekt-Logo. Projekte können mit einem GitHub-Repository verknüpft werden, was die automatische Branch-Erstellung und PR-Generierung aus Workflow-Läufen ermöglicht.

Projekteinstellungen

Die Projekteinstellungen steuern Standardverhalten im gesamten Projekt:

• Sandbox-System-Prompt - Eine Standard-Anweisung, die jeder Sandbox-Session im Projekt angehängt wird
• CLAUDE.md-Inhalt - Markdown, der als CLAUDE.md-Datei in die Sandbox geschrieben wird für CLI-Tools, die dies unterstützen
• Session-spezifische Konfigurationen - Jeder Session-Typ (learning, merging, issue, answering, evaluator, judge) hat seine eigene dedizierte Konfigurationsseite, auf der Sie einen Kontext binden, Skills, Commands und Scripts auswählen und weitere Session-Standards setzen können
• Umgebungsvariablen - Schlüssel-Wert-Paare, die in Sandbox-Umgebungen eingespeist werden, mit Unterstützung für die Markierung sensibler Werte als Secrets
• Git-Konfiguration - Benutzerdefinierter Commit-Autorname und -E-Mail-Adresse für vom Agenten erzeugte Commits
• Learning- und Merging-Einstellungen - Konfigurieren Sie, welches KI-Modell und Template für Learning-Extraktion und Branch-Merging verwendet wird

Team-Rollen

Projekte unterstützen drei Rollen:

• Owner - Vollständiger Zugriff, einschließlich Projekt-Löschung und Mitgliederverwaltung
• Admin - Kann Einstellungen, Mitglieder und alle Ressourcen innerhalb des Projekts verwalten
• Member - Kann eigene Ressourcen (Sandboxes, Läufe, Workflows) innerhalb des Projekts erstellen und verwalten

Mitglieder werden per E-Mail eingeladen und müssen die Einladung annehmen, bevor sie Zugriff erhalten. Jedes Mitglied kann eigene API-Keys konfigurieren, die für die Sandbox-Provisionierung verwendet werden.

Sandboxes

Eine Sandbox ist eine isolierte virtuelle Linux-Maschine, die über E2B bereitgestellt wird. Sandboxes sind die Ausführungs-Umgebung, in der KI-Coding-Agenten laufen. Jede Sandbox ist ein vollständiges Linux-System mit eigenem Dateisystem, Netzwerk-Stack und Prozess-Raum.

Sandbox-Konfiguration

Jede Sandbox wird mit einem Konfigurationsobjekt erstellt, das definiert:

• Template-ID - Bestimmt das Basis-Image und die vorinstallierten Tools. Verschiedene Templates unterstützen verschiedene CLI-Tools (Claude Code, OpenCode, Codex, Pi usw.)
• Timeout - Wie lange die Sandbox laufen kann, bevor sie automatisch beendet wird, von 1 Minute bis 4 Stunden
• Speicher- Zugewiesener RAM von 256 MB bis 8 GB
• CPU-Anzahl - Anzahl der CPU-Kerne von 1 bis 8
• Modell-Overrides - Geben Sie unterschiedliche KI-Modelle für Designer- und Checker-Schritte an
• Thinking-Effort- Pro-Modell-Thinking-Effort-Levels (z. B. high, medium, low), die steuern, wie viel Reasoning das Modell vor der Antwort betreibt

Sandbox-Lebenszyklus

Sandboxes durchlaufen diese Zustände:

• Creating - Die E2B-API stellt die VM bereit
• Running - Die Sandbox ist aktiv und der Agent wird ausgeführt
• Paused - Die Sandbox wurde pausiert, kann aber fortgesetzt werden
• Killed - Die Sandbox wurde beendet (entweder durch Timeout, Nutzeraktion oder Abschluss)
• Error - Die Sandbox ist während der Bereitstellung oder Ausführung auf einen fatalen Fehler gestoßen

Workflows

Ein Workflow ist ein wiederverwendbarer Blueprint, der definiert, wie KI-Agenten eine Aufgabe verarbeiten sollen. Workflows geben den Typ der Pipeline, die Standard-Sandbox-Konfiguration und schritt-spezifische Anweisungen an.

Workflow-Typen

Single Designer

Der einfachste Typ. Ein einzelner Agent erhält den Prompt und führt ihn in einem Durchgang aus. Am besten geeignet für unkomplizierte Aufgaben, bei denen keine Prüfung nötig ist.

Designer & Checker

Der häufigste Typ. Ein Designer-Agent schreibt Code basierend auf dem Prompt, dann prüft ein Checker-Agent die Ausgabe gegen konfigurierbare Anweisungen. Wenn der Checker ablehnt (sein Urteil hat pass: false), erhält der Designer das Feedback und iteriert. Diese Schleife setzt sich fort, bis der Checker zustimmt oder die maximale Iterationsanzahl erreicht ist.

Custom Pipeline

Definieren Sie eine beliebige Abfolge von Schritt-Typen: designer, checker, optimizer, prompter, investigator, deep-dive, evaluator oder judge. Jeder Schritt kann optional sein eigenes CLI-Tool, Modell, Thinking-Effort und Anweisungen angeben. Schritte können in Schleifen mit konfigurierbaren maximalen Iterationen gruppiert werden.

Persona Pipeline

Verketten Sie benannte Personas zu einer sequenziellen Pipeline. Jeder Schritt referenziert eine Persona per ID und erbt deren vollständige Konfiguration. Dies ist der flexibelste Typ und erlaubt Ihnen, komplexe Multi-Agent-Workflows aus wiederverwendbaren Persona-Definitionen zu komponieren.

Läufe

Ein Lauf ist eine einzelne Ausführung eines Workflows (oder einer eigenständigen Sandbox-Session). Läufe speichern Prompt, Konfiguration, Status, GitHub-Branch-Informationen, PR-Details, Kostenverfolgung, Qualitätsbewertung, CI-Check-Status sowie Verweise auf den Workflow und das Projekt, zu dem sie gehören.

Jeder Lauf enthält einen oder mehrere Lauf-Schritte. Ein Lauf-Schritt repräsentiert einen einzelnen Agent-Aufruf - einen Designer-Durchgang, eine Checker-Prüfung, eine Evaluator-Bewertung usw. Schritte verfolgen ihre Rolle (designer, checker, optimizer, prompter, investigator, deep-dive, evaluator, judge oder merge_agent), Status, Dauer, die verwendete Sandbox, Checker-Urteile und einzelne Qualitätsbewertungen.

Personas

Eine Persona ist eine wiederverwendbare KI-Agent-Konfiguration, die auf ein Projekt beschränkt ist. Personas ermöglichen es Ihnen, standardisiertes Agent-Verhalten zu definieren, das über Workflows und Pipeline-Schritte hinweg referenziert werden kann.

Jede Persona enthält:

• Typ - Die Rolle, die die Persona ausfüllt. Der vollständige Satz von Persona-Typen ist:
  • designer - Implementiert Features und Fixes
  • checker - Prüft und validiert die Ausgabe
  • optimizer - Refaktoriert und verbessert bestehenden Code
  • prompter - Generiert oder verfeinert Prompts für nachgelagerte Agenten
  • investigator - Erkundet Codebases und recherchiert vor Änderungen
  • planner - Erzeugt strukturierte Pläne und Issue-Listen
  • deep-dive - Führt tiefgehende Analysen mit erweitertem Reasoning durch
  • reviewer - Fokussiert auf Code-Review, Lesbarkeit und Wartbarkeit
  • custom - Unbeschränkter Typ für spezialisierte Anwendungsfälle
• CLI-Tool - Welcher CLI-Client in der Sandbox verwendet wird (identifiziert durch eine Tool-ID-Zeichenkette)
• Modell- Welches KI-Modell verwendet wird (z. B. claude-opus-4-6, claude-sonnet-4-6)
• Thinking-Effort - Wie viel Reasoning das Modell anwenden soll
• Anweisungen - Benutzerdefinierte System-Anweisungen, die das Verhalten des Agenten prägen
• Skills, Commands und Scripts - Die Asset-Sets, die für diese Persona in der Sandbox aktiviert sind
• Learnings - Ob kompilierte Projekt-Learnings in den Kontext des Agenten aufgenommen werden

Personas werden auf Projektebene aktiviert oder deaktiviert. Deaktivierte Personas erscheinen nicht in der Workflow-Konfiguration oder in der Auswahl für Persona-Pipeline-Schritte.

Kontexte

Kontexte sind wiederverwendbare, versionierte Dokumente, die den System-Prompt und CLAUDE.md-Inhalt definieren, der in Agent-Sessions eingespeist wird. Anders als der globale Sandbox-System-Prompt (der für jede Sandbox im Projekt gilt) sind Kontexte auf bestimmte Session-Typen beschränkt - sie geben Ihnen präzise Kontrolle darüber, welche Anweisungen jede Klasse von Agent erhält.

Beschränkung auf Session-Typen

Jedes Kontext-Dokument ist an einen der folgenden Session-Typen gebunden:

• learning - Sessions, die Learnings aus abgeschlossenen Läufen extrahieren und prüfen
• merging - Sessions, in denen ein Merge-Agent Branches integriert
• issue - Issue-Discovery- und Scanning-Sessions
• answering - Answering-Sessions, die Fragen aus Issue-Sessions vor der Implementierung beantworten
• evaluating - Evaluator-Agent-Sessions, die die Output-Qualität von Läufen bewerten
• judging - Judge-Agent-Sessions, die Ausgaben über parallele Branches hinweg vergleichen

Kontext-Versionierung

Jedes Kontext-Dokument ist versioniert. Wenn Sie einen Kontext aktualisieren, bleibt die vorherige Version erhalten, sodass Sie verfolgen können, wie sich Ihre Anweisungen entwickelt haben, und zurückrollen können, falls eine Änderung die Agent-Leistung verschlechtert. Die aktive Version eines Kontexts ist diejenige, die in neue Sessions dieses Typs eingespeist wird. Kontext-Dokumente sind innerhalb Ihres Projekts unter /p/[id]/context erreichbar.

Assets: Skills, Commands und Scripts

Assets sind unabhängig versionierte, veröffentlichbare Pakete, die Agent-Fähigkeiten innerhalb der Sandbox erweitern. Assets werden auf Projektebene erstellt und verwaltet und können selektiv an einzelne Personas oder über Session-Konfigurationen an bestimmte Session-Typen angehängt werden.

Skills

Skills sind domänenspezifische Wissenspakete. Im Gegensatz zu einer einzelnen Anweisungs-Datei ist ein Skill aus mehreren Dateien zusammengesetzt - ein Convex-Skill könnte zum Beispiel ein Patterns-Referenz-Dokument, eine Code-Snippets-Datei und eine Architektur-Richtlinien-Datei enthalten. Alle Dateien eines Skills werden zu Beginn der Session in das Sandbox-Dateisystem geschrieben, sodass der Agent sie lesen, referenzieren und darauf aufbauen kann.

Skills werden unabhängig versioniert. Das Veröffentlichen einer neuen Skill-Version wirkt sich nicht auf derzeit laufende Sessions aus - nur neue Sessions übernehmen die aktualisierten Dateien.

Commands

Commands sind Shell-Befehl-Aliase, die Agenten in der Sandbox zur Verfügung stehen. Ein Command hat einen Namen, einen Shell-Ausdruck und eine optionale Beschreibung. Zum Beispiel könnte ein Command run-tests zu npx vitest run --reporter=verbose expandieren und Agenten einen stabilen, projektspezifischen Alias geben, unabhängig davon, wie Ihr Test-Runner konfiguriert ist. Commands werden beim Start der Session in die Sandbox-Umgebung eingespeist.

Scripts

Scripts sind ausführbare Shell- oder Python-Skripte, die zu bestimmten Lebenszyklus-Punkten in einem Workflow ausgeführt werden können - bevor der Agent startet, nachdem der Agent abgeschlossen hat oder bei Bedarf. Skripte sind nützlich, um die Sandbox mit dynamischen Daten vorzubefüllen, die Ausgabe nach Abschluss zu validieren oder Post-Processing-Schritte auszuführen, die für einen Agenten zu prozedural sind.

Asset-Auswahl pro Persona und Session-Typ

Skills, Commands und Scripts können auf zwei Ebenen angehängt werden:

• Pro Persona - Wenn eine Persona in einem Pipeline-Schritt verwendet wird, werden ihre konfigurierten Assets nur für diesen Schritt in die Sandbox eingespeist
• Pro Session-Typ - Auf der Session-Konfigurationsseite für jeden Session-Typ (issue, learning, merging, answering, evaluating, judging) können Sie auswählen, welche Assets für alle Sessions dieses Typs verfügbar sind

Issues und Answering Sessions

Issue-Sessions ermöglichen es Ihnen, eine Codebasis auf Probleme und Verbesserungsmöglichkeiten zu scannen. Eine Issue-Session erstellt eine Sandbox, die das Repository analysiert und eine strukturierte Liste von Issues erzeugt, jedes mit Titel, Beschreibung, Priorität (low, medium, high, critical) und einem vorgeschlagenen Prompt zur Lösung.

Answering Sessions

Wenn eine Issue-Session Fragen oder ungelöste Annahmen produziert - zum Beispiel: „Soll dies die bestehende Cache-Schicht nutzen oder sie umgehen?“ - kann eine Answering Session gestartet werden, damit der KI-Agent (oder ein menschlicher Mitwirkender) diese Fragen vor der Implementierung klärt. Die Answering Session erhält die Liste der offenen Fragen und erzeugt strukturierte Antworten, die dann in den Implementierungslauf weitergegeben werden. Dies verhindert, dass Agenten falsche Annahmen über mehrdeutige Anforderungen treffen.

Einzelne Issues können durch das Erstellen eines Laufs mit dem vorgeschlagenen Prompt ausgeführt oder zu Work Chainsgruppiert werden, die mehrere Issues sequenziell gegen denselben Branch abarbeiten.

Sprint Chains

Sprint Chains sind ein Batch-Orchestrierungs-Mechanismus zum Ausführen mehrerer Workflow-Läufe über eine Reihe geplanter Sprints hinweg. Sie unterscheiden sich von Work Chains (die Issue-Fixes auf einem einzelnen Branch verketten), indem jeder Sprint in einer Sprint Chain eine unabhängige Arbeitseinheit mit eigenem Branch und Pull Request ist.

Struktur einer Sprint Chain

Eine Sprint Chain verfolgt:

• Sprint-Bereich- Die Gesamtzahl der Sprints, die in der Chain definiert sind (z. B. „Sprints 1 bis 8“)
• Aktueller Sprint-Index - Welcher Sprint aktuell ausgeführt oder zuletzt abgeschlossen wurde
• PR-Tracking pro Sprint - Jeder Sprint verfolgt seine eigene Pull-Request-URL, seinen Branch-Namen und seinen PR-Status unabhängig
• Sprint-Prompts - Jeder Sprint in der Chain kann seinen eigenen Prompt haben oder von der Vorgabe der Chain erben

Sprint Chains eignen sich gut zur Ausführung einer Roadmap von Features, bei denen jedes Feature unabhängige Prüfung und Merging benötigt. Die Chain schreitet je nach Konfiguration automatisch oder nach manueller Freigabe durch die Sprints fort.

Wiederkehrende Aufgaben

Mit wiederkehrenden Aufgaben können Sie jeden CodeCourier-Workflow planen, damit er automatisch in einem wiederkehrenden Takt ausgeführt wird. Das ist nützlich für nächtliche Builds, wöchentliche Code-Qualitäts-Audits, tägliche Abhängigkeitsprüfungen oder jeden Workflow, den Ihr Team ohne manuelles Auslösen automatisieren möchte.

Frequenzoptionen

Die unterstützten Frequenzwerte sind:

• daily - Wird jeden Tag zur konfigurierten Stunde und Minute ausgeführt
• every_other_day - Wird abwechselnd ausgeführt
• weekly - Wird einmal pro Woche am konfigurierten Tag ausgeführt
• biweekly - Wird einmal alle zwei Wochen ausgeführt
• monthly - Wird einmal pro Monat am konfigurierten Tag ausgeführt

Zeitzone und Zeitplanung

Wiederkehrende Aufgaben speichern eine Zeitzone, eine Stunde und eine Minute der Ausführung. Die Plattform verwendet diese, um die nächste Ausführungszeit (nextRunAt) zu berechnen, und stößt den Lauf automatisch an, wenn die geplante Zeit erreicht ist. Alle geplanten Zeiten werden intern in UTC gespeichert, können aber in jeder IANA-Zeitzone konfiguriert und angezeigt werden.

Evaluator- und Judge-Rollen

CodeCourier enthält zwei spezialisierte Agent-Rollen zur Qualitätsbeurteilung, die über das Standard-Checker-Muster hinausgehen:

Evaluator

Ein Evaluator-Agent bewertet die Output-Qualität eines Laufs oder Lauf-Schritts über die sechs Qualitätsdimensionen (siehe Qualitätsbewertung unten). Evaluatoren sind nützlich in langen Pipelines, in denen Sie nach der Implementierung und vor der finalen Prüfung einen dedizierten Qualitätsbeurteilungs-Durchgang wünschen. Die Evaluator-Ausgabe ist strukturiert - sie erzeugt numerische Bewertungen und eine Zusammenfassung, nicht ein binäres Pass/Fail-Urteil.

Judge

Ein Judge-Agent vergleicht die Ausgaben paralleler Branches oder mehrerer Lauf-Versuche und wählt den besten aus. Judges sind nützlich, wenn Sie denselben Prompt gegen mehrere Konfigurationen gleichzeitig ausführen (unterschiedliche Modelle, unterschiedliche Personas, unterschiedliche Skill-Sets) und einen objektiven Schiedsrichter wünschen, der entscheidet, welches Ergebnis vorangetrieben wird. Der Judge erhält alle Kandidaten- Ausgaben und erzeugt einen strukturierten Vergleich mit Sieger und Begründung.

Qualitätsbewertung

CodeCourier verfolgt die Output-Qualität auf Ebene des Lauf-Schritts über ein strukturiertes Qualitätsbewertungs-Objekt. Das gibt Teams ein objektives, konsistentes Signal, wie gut jeder Agent-Aufruf performt hat - jenseits des bloßen „hat er es abgeschlossen?“.

Bewertungs-Dimensionen

Jede Qualitätsbewertung eines Lauf-Schritts enthält sechs Dimensionen, jede auf einer Skala von 0–100 bewertet:

• Korrektheit - Setzt die Ausgabe die Anforderungen korrekt um?
• Typsicherheit - Sind TypeScript-Typen korrekt, ohne implizites any oder Typfehler?
• Code-Stil - Befolgt der Code die Projekt-Konventionen und Style-Guidelines?
• Testabdeckung - Sind Tests vorhanden, aussagekräftig und decken sie den geänderten Code ab?
• Vollständigkeit - Hat der Agent alle Teile des Prompts adressiert?
• Gesamtwert - Ein gewichteter Aggregat-Wert der fünf obigen Dimensionen

Die Bewertungen einzelner Lauf-Schritte werden zu einem Gesamt-qualityScore auf dem Lauf-Datensatz aggregiert. Damit können Läufe in Analytics-Ansichten nach Qualität gefiltert und sortiert werden, und Sie können erkennen, welche Workflow-Konfigurationen konsistent höherwertige Ausgaben produzieren.

CI-Checks

Läufe verfolgen den CI-Check-Status über ein ciChecks-Objekt, das aktualisiert wird, während Ihre CI-Pipeline den agenten-generierten Code verarbeitet. Das Objekt enthält:

• status - Gesamt-CI-Status: pending, running, passing, failing oder skipped
• checks - Ein Array einzelner Check-Ergebnisse, jedes mit Name, Status und optionaler Details-URL
• checkedAt - Zeitstempel der jüngsten CI-Status-Abfrage

CI-Check-Daten erscheinen auf der Run-Detailseite, sodass Sie die Code-Qualität beurteilen können, ohne zur Oberfläche Ihres CI-Providers zu wechseln.

Learnings

Learnings sind das Wissensmanagement-System in CodeCourier. Jedes Mal, wenn ein KI-Agent einen Fehler macht, ein Muster entdeckt oder auf eine projektspezifische Anforderung stößt, kann dieses Wissen als strukturierter Learning-Datensatz erfasst werden.

Learning-Struktur

Jedes Learning enthält:

• Beschreibung - Was gelernt wurde
• Trigger - Welche Situation dieses Learning auslöst
• Korrektes Verhalten - Was der Agent tun sollte, wenn der Trigger eintritt
• Schweregrad - Critical, important oder minor
• Kategorie - Preference, pattern, gotcha, tool oder architecture
• Confidence - Ein numerischer Wert, der anzeigt, wie verlässlich dieses Learning ist
• Quelle - Ob es von einem Agenten während eines Laufs erstellt oder im Nachhinein aus einer Session extrahiert wurde

Learning-Lebenszyklus

Learnings durchlaufen einen dreistufigen Review-Prozess:

1. Pending - Neu erstellt, wartet auf menschliche Prüfung
2. Approved - Von einem Teammitglied verifiziert und in zukünftige Sessions aufgenommen
3. Rejected - Als falsch oder nicht nützlich verworfen

Learning-Versionen

Freigegebene Learnings werden in versionierte Markdown-Dokumente kompiliert, die Learning-Versionen genannt werden. Jede Version ist auf ein Projekt und einen Rollentyp beschränkt, enthält das kompilierte Markdown und referenziert, welche einzelnen Learning-Datensätze enthalten sind. Wenn eine neue Sandbox bereitgestellt wird, wird die aktive Learning-Version automatisch in den Kontext des Agenten eingespeist.

Das Echtzeit-Datenmodell

CodeCourier verwendet Convex als Datenbank und Backend-Runtime. Das bedeutet, dass jede Query eine reaktive Subscriptionist: Wenn sich Daten auf dem Server ändern, aktualisiert jeder verbundene Client, der diese Daten liest, sofort - ohne Polling oder manuelles Aktualisieren.

Diese Architektur hat wichtige Auswirkungen auf die CodeCourier-Erfahrung:

• Lauf-Status-Updates (pending zu running zu completed) erscheinen sofort in den Browsern aller Teammitglieder
• Sandbox-Nachrichten streamen in Echtzeit, während der Agent sie erzeugt
• Qualitätsbewertungen und CI-Check-Status aktualisieren sich live, während Evaluatoren ihre Beurteilungen abschließen und CI-Pipelines zurückmelden
• Neue Learnings, Workflow-Änderungen und Mitglieder-Zugänge breiten sich sofort aus
• Dashboard-Zähler und Analytics aktualisieren sich live ohne Seitenaktualisierungen

Die gesamte Geschäftslogik - Authentifizierung, Autorisierung, Validierung und Daten-Mutationen - läuft in Convex-Server-Funktionen. Das Frontend spricht nie direkt mit der Datenbank; es ruft Convex-Queries (die reaktiv abonnieren) und Mutations (die Daten über validierte serverseitige Funktionen ändern) auf.

Wie die Konzepte zusammenhängen

So hängen die wichtigsten Konzepte zusammen:

• Ein Projekt enthält Workflows, Personas, Kontexte, Assets, Pläne, Issues, Learnings, wiederkehrende Aufgaben, Sprint Chains und Teammitglieder
• Ein Workflow referenziert ein Projekt und definiert einen Blueprint für Läufe
• Eine Persona gehört zu einem Projekt und trägt ihren eigenen Satz an Assets (Skills, Commands, Scripts) und ihre Kontext-Bindung; sie kann von Persona-Pipeline-Workflow-Schritten referenziert werden
• Ein Kontext gehört zu einem Projekt, ist auf einen Session-Typ beschränkt und wird automatisch in Sandboxes dieses Typs eingespeist
• Assets (Skills, Commands, Scripts) gehören zu einem Projekt und werden pro Persona und pro Session-Typ ausgewählt
• Ein Lauf gehört zu einem Projekt, referenziert optional einen Workflow, erstellt eine oder mehrere Sandboxes und verfolgt Qualitätsbewertungen und CI-Check-Status
• Eine Sandbox gehört zu einem Lauf (oder existiert eigenständig) und enthält Nachrichten
• Eine Issue-Session gehört zu einem Projekt und erzeugt Issues, die Läufe, Work Chains oder Answering Sessions auslösen können
• Eine Sprint Chain gehört zu einem Projekt und orchestriert eine Reihe von Läufen über geplante Sprints, jeder mit eigenem Branch und PR
• Eine wiederkehrende Aufgabe gehört zu einem Projekt und stößt Läufe nach einem konfigurierbaren Zeitplan an
• Learnings werden aus Sandboxes extrahiert, von Teammitgliedern geprüft, in Versionen kompiliert und in zukünftige Sandboxes eingespeist

Nächste Schritte