Anbindung
Anvil Coder ist an drei Stellen mit eurer Landschaft verbunden: vorn nehmen Tickets die Aufträge entgegen, hinten landet das Ergebnis als Commit in einem Git-Repository, und in der Mitte ist die Modell-Anbindung austauschbar. Alles drei ist so gebaut, dass es sich einzeln ersetzen lässt — die fachliche Logik kennt keine dieser Anbindungen.
Der Einstieg ist auf jedem Tracker derselbe Handgriff: ein Mensch zieht eine Story auf den Trigger-Zustand, das System übernimmt sie, plant, führt aus und meldet das Ergebnis in den Ticket-Zustand zurück. Bei YouTrack und Jira Cloud ist der Trigger der Start-Status des Boards, bei GitHub und GitLab ein Label (df:status/ready bzw.df::status::ready) — GitHub und GitLab liefern per Webhook in Sekunden, YouTrack und Jira werden gepollt. Ein geschlossenes oder zurückgezogenes Ticket bricht die laufende Arbeit ab, auf allen vier Wegen gleich.
Auch eine Ebene höher gilt der Handgriff: ein Epic, das auf den Trigger-Zustand gezogen wird, startet keinen Lauf, sondern zerlegt sich selbst — das System liest die Grundlagen-Dokumente des Projekts, härtet die Anforderung nach und legt die User Stories als echte Tickets an, mit dem Epic verknüpft und bewusst ungetriggert. Welche Story tatsächlich läuft, entscheidet weiterhin ein Mensch, Story für Story. Das funktioniert auf allen vier Trackern gleich.
Separat (zuschaltbar) lässt sich ein Kommentar-Rückkanal aktivieren, der ausschliesslich in den Review-Zuständen Folgeläufe auslöst; im betriebenen Dienst ist er eingeschaltet.
Wer nicht im Ticket arbeiten will, hat einen zweiten Arbeitsort, ebenfalls(zuschaltbar): den Kommentar am Pull-Request. Der Dienst liest die Kommentare mit, und aus einer Anweisung darin wird ein inkrementeller Folgelauf — der Kommentar ist dann die Anforderung. Auch dieser Kanal ist im betriebenen Dienst eingeschaltet.
Ein zweiter Einstieg ist er nicht, und das ist keine Feinheit: der Dienst sieht dort ausschliesslich die Pull-Requests, die er selbst eröffnet hat, und ein Projekt wird über seinen Ticket-Schlüssel registriert. Der erste Lauf eines Projekts kommt aus dem Ticket; ab dem Pull-Request könnt ihr dort bleiben.
Das ist der Punkt, an dem sich das System in einen bestehenden Prozess einfügt statt einen neuen zu verlangen: wer heute Stories zieht, zieht sie weiterhin — und wer im Pull-Request reviewt, bleibt dort.
Jeder abgeschlossene Arbeitsschritt hinterlässt seinen eigenen Commit. Am Ende steht kein Textblock, den jemand herauskopiert, sondern ein Repository mit Historie — lesbar für Menschen, prüfbar für eine Pipeline.
Im betriebenen Dienst kommt das Ergebnis dort an, wo ohnehin geprüft wird: als Entwurf eines Pull-Requests gegen den Hauptzweig, in einem privaten Repository. Es gibt also nichts zu importieren — der erste Blick darauf fällt im gewohnten Review-Werkzeug.
Als Repository-Hoster stehen GitHub, GitLab undBitbucket Cloud zur Verfügung; bei GitLab und Bitbucket heisst das Gegenstück Merge Request statt Pull Request, der Ablauf ist derselbe. GitHub wird über die App-Installation der Organisation verbunden, GitLab und Bitbucket über OAuth 2.0 (GitLab zusätzlich mit PKCE) — GitLab heute wählbar für gitlab.com, Self-Managed-Instanzen sind serverseitig vorbereitet, aber in der Verbindung noch nicht als Ziel wählbar. Die nötigen Webhooks richtet das System selbst ein: pro Projekt, mit eigenem Geheimnis, das nur als Prüfsumme gespeichert wird — bei GitLab und Bitbucket gibt es keinen manuellen Webhook-Handgriff mehr.
Ein Projekt kann seinen Tracker bei der Anlage wählen. Das Interne Issue Boardliegt direkt im Cockpit und braucht keine externe Tracker-Instanz. Für bestehende Prozesse stehen außerdem YouTrack, GitHub Issues,Jira Cloud, GitLab Issues und — für Bestandsprojekte mit aktiviertem Issue-Tracker — Bitbucket zur Verfügung. Der Tracker ist eine Projekteigenschaft; er wird nach der Anlage nicht still gewechselt.
Alle Tracker arbeiten in beide Richtungen: der Trigger-Zustand startet Läufe (und Epics zerlegen sich in Stories, s. oben), Ergebnisse, Kommentare und Verknüpfungen fliessen zurück. Jira und GitLab werden über OAuth 2.0 verbunden (GitLab zusätzlich mit PKCE) und laden ihre Projekt- und Status-Metadaten live. Vor dem ersten Lauf prüft einBoard-Check, ob das Tracker-Board alle Zustände anbietet, die die Fertigung braucht — fehlende Zustände schlägt er samt Synonymen zur Bestätigung vor, statt still ins Leere zu laufen. Welche Verbindung ein Projekt nutzt, lässt sich zusätzlich als primäre oder sekundäre Projektbindung festlegen.
Die Details stehen in den freigegebenen Anleitungen:internes Ticketing,GitHub verbinden undJira Cloud verbinden.
Als geplante Karten im Cockpit sichtbar, aber noch nicht verbindbar:Trello und Linear.
Für die Slice-Generierung lassen sich drei lesende Kontext-Server zuschalten: einer für YouTrack-Stories, einer für GitHub-Pull-Requests und einer für einen kuratierten Textkorpus. Sie liefern dem Agenten Zusammenhang, den die Anforderung selbst nicht mitbringt.
Alle drei sind (zuschaltbar), standardmässig aus und strikt lesend. Beim Textkorpus gibt es keinen Rückfall auf allgemeine Zugangsdaten: ein nicht zugeordneter Mandant bekommt nichts — nicht die Daten eines anderen Mandanten, sondern gar nichts. Bei GitHub gilt dasselbe, solange kein gemeinsamer Standard-Zugang hinterlegt ist — auch das ist eine Konfigurationsentscheidung je Betreiber. Für YouTrack lässt sich zusätzlich eine gemeinsame Standard-Instanz einrichten, auf die ein noch nicht zugeordneter Mandant dann zurückfällt — eine Konfigurationsentscheidung je Betreiber, keine Ausnahme von der Regel.
Jede Organisation verwaltet ihre eigenen Projekte, Verbindungen, Mitglieder und Schlüssel. Ein OWNER oder Plattform-Admin kann Einladungen als teilbaren Link ausstellen; Berechtigungen und Daten bleiben dabei organisationsbezogen. Ein Projekt kann seine primäre Repository- und Tracker-Verbindung verwenden und weitere SECONDARY-Bindungen ergänzen.