FunktionRoadmap
Jeder Prompt wird ein Ticket. Nichts passiert außerhalb der Akte.
Roadmap-Tickets für KI-Coding-Agenten machen aus einer Woche voller Prompts eine Woche Arbeit, die ihr nachlesen könnt. Jeder Befehl führt ein Ticket aus, und ein Prompt ohne Ticket bekommt eines. Jedes Ticket trägt seine eigene Vorgabe, und keines rückt ohne Beleg vor.
Zuletzt aktualisiert:
Zwei Wege hinein
Plant es, oder sagt es einfach
Die meisten Backlogs sterben daran, dass sie Zeremonie vor der Arbeit verlangen. Dieser nimmt euer Ticket, wenn ihr eines habt, und schreibt es, wenn nicht.
| Was ihr tut | Was die Roadmap tut |
|---|---|
| Ihr schreibt ein Ticket in euren eigenen Worten | Daraus wird ein Umsetzungsticket mit gefüllter Vorgabe: Ziel, Absicht, Grenzen, Akzeptanzkriterien. Eure Formulierung bleibt, die Struktur kommt dazu. |
| Ihr tippt einen Prompt, der zu einem offenen Ticket passt | Der Run bindet an dieses Ticket. Wochen später zeigen Arbeit und Grund noch aufeinander. |
| Ihr tippt einen Prompt, der zu nichts passt | Aus eurem Satz entsteht ein Ticket, verbunden mit dem Run. Der Eintrag existiert, ob ihr in Planungslaune wart oder nicht. |
| Ihr seid fertig, und die Checks laufen durch | Das Ticket rückt vor und trägt den Beleg mit, der das erlaubt hat. Ohne Beleg bewegt es sich nicht. |
Das Ticket
Ein Ticket, das die Vorgabe hält, nicht einen Titel und eine Hoffnung
Ein Ticket nützt nur, wenn es sagt, was fertig heißt. Dieses muss es, denn dieselben Felder entscheiden über das Ergebnis.
RG-CHECKOUT-VALIDATION-1
Beispiel – illustratives Ticket, keine echten Registry-Datenid RG-CHECKOUT-VALIDATION-1
status validiert
quelle Prompt, 2026-08-11 14:19
goal Validierungsfehler im Checkout beheben, Zahlungen unberührt
intent bugfix
allowed src/checkout/validation.py, tests/
protected src/payments/**, alembic/versions/**
accepts leere Postleitzahl ergibt einen Feldfehler, keinen 500er
tests/test_checkout_validation.py läuft grün
runs rg-4f2a verdict BLOCKED geschützter Pfad geändert
rg-5b81 verdict VERIFIED pytest -q exit 0
evidence Beleg rc-77e (Digest geprüft)Die zwei gescheiterten Anläufe bleiben im Ticket. Genau darum geht es: Ein Backlog, der nur die Fassung festhält, die funktioniert hat, bringt euch nichts bei, und der blockierte Run ist der, den zu erinnern sich lohnt.
Status
Jeder Schritt nach vorn wird verdient
Die Statusmaschine prüft jeden Übergang, und die Zustände unten verweigern sich ohne Evidenzreferenz.
| Zustand | Was es dafür braucht |
|---|---|
| implementiert | Einen Run, der die deklarierten Dateien geändert hat, aus Git gelesen statt berichtet. |
| validiert | Die freigegebenen Checks, ausgeführt, mit den Exit-Codes, die Reality Graph beobachtet hat. |
| reviewt | Ein Trust Review, das an diesen Run gebunden ist, mit Ergebnis und Einschränkungen. |
| abgenommen | Ein Mensch hat entschieden, und die Entscheidung steht gegen Run, HEAD und Scope, für die sie getroffen wurde. |
| committet · gepusht · released | Die zugehörige Evidenzreferenz. Reality Graph erledigt nichts davon für euch und hält jedes davon fest, wenn ihr es tut. |
Die Registry ist append-only, die Historie eines Tickets ist also die Historie und nicht die aktuelle Meinung darüber. Zusammen mit dem Ergebnis und seinen Belegen ist ein fertiges Ticket etwas, das ihr einer Reviewerin geben könnt, die nicht dabei war.
Bewusst so gebaut
Wo die Roadmap aufhört
Eine Planungsschicht mit Schreibrechten auf eurem Repository ist ein Risiko. Diese hat keine.
Was sie macht
- Jeden Befehl an ein Ticket binden und aus eurem Prompt eines anlegen, wenn nichts passt.
- Die Vorgabe im Ticket tragen, damit Plan und Maßstab dasselbe Artefakt sind.
- Jeden Statusübergang prüfen und die zurückweisen, die ohne Beleg ankommen.
- Einen append-only Eintrag führen, damit der gescheiterte Anlauf so lesbar bleibt wie der gelungene.
Was sie nie macht
- Euren Quellcode, eure Laufzeitspeicher, eure .env oder eure Tool-Ordner anfassen.
- Einen Sprint aktivieren, euren Backlog umpriorisieren oder entscheiden, was als Nächstes zählt.
- Für euch committen, pushen oder releasen.
- Jira oder Linear ersetzen. Sie hält fest, was im Repository wirklich passiert ist, und das ist eine andere Aufgabe.
Die Vorgabe im Ticket ist dasselbe Artefakt, das die Seite zur prüfbaren Vorgabe dokumentiert, und das Board selbst liegt in dem lokalen Dashboard.
Fragen, die wirklich gestellt werden
- Muss ich erst Tickets schreiben, bevor ich arbeiten kann?
- Nein. Schreibt sie, wenn ihr planen wollt, und lasst sie weg, wenn ihr loslegen wollt. Ein Prompt ohne Ticket bekommt eines, gebaut aus eurem eigenen Satz und verbunden mit dem Run, den er erzeugt hat. Vorausplanen ist eine Möglichkeit; einen Eintrag zu hinterlassen nicht.
- Was steht in einem Ticket?
- Die Vorgabe: Ziel, deklarierte Absicht, Pfade, die sich ändern dürfen, Pfade, die gesperrt bleiben, und die Akzeptanzkriterien. Das ist dasselbe Artefakt, an dem der Run gemessen wird, Ticket und Maßstab sind also eine Sache statt zweier, die auseinanderlaufen.
- Kann ein Ticket ohne Beleg auf fertig gesetzt werden?
- Nein. Implementiert, validiert, reviewt, abgenommen, committet, gepusht und released verlangen alle eine Evidenzreferenz, und die Statusmaschine weist jeden Übergang ohne sie zurück. Ein Ticket kann nicht auf Zuruf fertig werden.
- Fasst die Roadmap mein Repository an?
- Sie schreibt in ihre eigene Registry und sonst nirgendwohin. Euer Quellcode, euer Laufzeitzustand, eure .env und eure Tool-Ordner sind bauartbedingt tabu, sie aktiviert von sich aus keinen Sprint, und sie committet nie.
Schaut nach, was euer Team im letzten Sprint geliefert hat
Nicht die Commits. Die Gründe. Wenn ihr die nicht rekonstruieren könnt, ist genau das die Lücke, die das hier schließt.
Weiterlesen
Schritt 8 von 9