Anvil CoderAnmelden

2026-08-26

Ein Epic, vier Tracker, ein Handgriff

Der Einstieg in die autonome Fertigung war von Anfang an ein einziger Handgriff: eine Story auf den Trigger-Zustand ziehen, den Rest übernimmt das System. Seit heute gilt derselbe Handgriff eine Ebene höher — für das Epic. Und er gilt überall: auf YouTrack, Jira Cloud, GitHub Issues und GitLab Issues gleichermassen.

Vier Zuführbahnen, ein Tor: identische Blöcke laufen aus vier Richtungen in dieselbe Esse und verlassen sie als eine Reihe gleicher Barren

Der Handgriff

Ein Epic ist bei Anvil Coder ein gewöhnliches Ticket mit einer Epic-Markierung — bei GitHub das Label df:type/epic, bei GitLab df::type::epic, bei YouTrack und Jira der Ticket-Typ beziehungsweise ein Label. Zieht ein Mensch dieses Epic auf den Trigger-Zustand (Start-Status am Board, oder das Ready-Label), startet kein Lauf. Stattdessen zerlegt sich das Epic:

  1. Das System liest die Grundlagen-Dokumente des Projekts — Vision, Architektur, Kontext — frisch aus dem Repository.
  2. Es härtet die Anforderung nach: Mehrdeutigkeiten werden entschieden und als Annahmen festgehalten, bevor geschnitten wird. Ein Fehler, der hier durchrutscht, würde sich sonst in jede Story fortpflanzen.
  3. Es schneidet User Stories — klein genug, dass jede für sich planbar ist — und legt sie als echte Tickets im selben Tracker an: mit dem Epic verknüpft, im Anlage-Zustand, bewusst ungetriggert.
  4. Das Epic bekommt einen Kommentar mit dem Ergebnis und wechselt in den Bearbeitungs-Zustand. Schlägt der Schnitt fehl, wechselt es stattdessen in den Fehler-Zustand — mit dem Grund als Kommentar; erneutes Ziehen wiederholt den Schnitt.

Warum kein Lauf startet

Das ist der Kern der Sache, kein Versäumnis: die Zerlegung ist billig, die Ausführung ist kostenwirksam. Zwischen beiden steht die Freigabe durch einen Menschen — Story für Story. Wer das Epic zieht, bestellt einen Vorschlag in Ticketform; wer eine Story zieht, bestellt Arbeit. Beides ist derselbe Handgriff, aber es sind zwei Entscheidungen, und sie bleiben getrennt.

Vier Tracker, ein Verhalten

Hinter dem gleichen Handgriff liegt pro Tracker ein anderer Transport: GitHub und GitLab liefern per Webhook in Sekunden — bei GitLab neuerdings mandanten-adressiert, mit einem eigenen Geheimnis pro Projekt-Webhook, das nur als Prüfsumme gespeichert wird. YouTrack und Jira werden gepollt. Doppelte Zustellungen, Echo-Ereignisse (das System entfernt beim Übernehmen selbst das Ready-Label — das darf keinen Abbruch auslösen) und parallele Trigger werden auf allen Wegen gleich behandelt: ein Epic ist entweder in Zerlegung oder nicht, nie zweimal.

Für die Arbeit heisst das: das Werkzeug richtet sich nach dem Team, nicht umgekehrt. Wer heute in Jira plant, plant weiter in Jira. Wer GitHub-Labels zieht, zieht Labels. Der Weg vom Vorhaben zum reviewten Merge Request ist überall derselbe — ein Epic, viele Stories, ein Repository.