105 lines
3 KiB
Markdown
105 lines
3 KiB
Markdown
# Ticket Workflow
|
||
|
||
Jede Aufgabe aus einem Implementierungsplan wird als eigenständiges Ticket unter `.tasks/` abgelegt.
|
||
Tickets folgen dem Jira-Stil (Story, Task, Bug, Spike) und durchlaufen einen festen Lebenszyklus.
|
||
|
||
## Verzeichnisstruktur
|
||
|
||
```
|
||
.tasks/
|
||
todo/ ← Backlog: fertig beschrieben, noch nicht begonnen
|
||
processing/ ← Aktiv in Bearbeitung (max. 1–2 gleichzeitig)
|
||
done/ ← Abgeschlossen (zur Referenz aufbewahren)
|
||
```
|
||
|
||
## Ticket-Lebenszyklus
|
||
|
||
```
|
||
todo/ → processing/ → done/ → nächstes Ticket
|
||
```
|
||
|
||
Die `.md`-Datei wird beim Statuswechsel physisch in den entsprechenden Ordner verschoben.
|
||
Niemals den Status nur im Dateiinhalt ändern — der Ordner **ist** der Status.
|
||
|
||
## Ticket-ID-Konvention
|
||
|
||
```
|
||
TT-<dreistellige Nummer>-<kurzer-slug>.md
|
||
```
|
||
|
||
Beispiel: `TT-018-quick-access-grid.md`
|
||
|
||
Die nächste freie Nummer ermitteln:
|
||
|
||
```bash
|
||
ls .tasks/done/ .tasks/processing/ .tasks/todo/ | grep -oP 'TT-\d+' | sort -t- -k2 -n | tail -1
|
||
```
|
||
|
||
## Ticket-Template
|
||
|
||
```markdown
|
||
# TT-XXX — Titel
|
||
|
||
**Type:** Story | Task | Bug | Spike
|
||
**Priority:** Highest | High | Medium | Low
|
||
**Labels:** komma, getrennt
|
||
**Depends on:** TT-XXX, …
|
||
**Blocks:** TT-XXX, …
|
||
|
||
---
|
||
|
||
## Summary
|
||
Ein Absatz: Was wird gemacht und warum.
|
||
|
||
## Background
|
||
Kontext, der zum Verständnis nötig ist (optional).
|
||
|
||
## Acceptance Criteria
|
||
- [ ] …
|
||
|
||
## Steps
|
||
1. …
|
||
|
||
## Files to create / modify
|
||
- `lib/…`
|
||
|
||
## Notes
|
||
Hinweise, Fallstricke, verwandte Tickets (optional).
|
||
```
|
||
|
||
## Regeln für den Agenten
|
||
|
||
1. **Implementierungsplan → Tickets**: Jeder Schritt eines Plans wird zu einem eigenen Ticket in `.tasks/todo/`.
|
||
2. **Ein Ticket auf einmal**: Immer nur ein Ticket nach `processing/` verschieben — erst abschließen, dann das nächste beginnen.
|
||
3. **Ticket schließen**: Datei nach `done/` verschieben, bevor das nächste Ticket geöffnet wird.
|
||
4. **Keine impliziten Aufgaben**: Alles, was getan wird, muss einem Ticket zugeordnet sein. Entsteht Arbeit ad-hoc, zuerst ein Ticket anlegen.
|
||
5. **Abhängigkeiten respektieren**: `Depends on`-Felder beachten — blockierte Tickets nicht vor ihren Voraussetzungen beginnen.
|
||
6. **`.tasks/README.md` aktualisieren**: Nach jedem neuen Ticket die Übersichtstabelle dort ergänzen.
|
||
|
||
## Beispiel-Workflow
|
||
|
||
```
|
||
# 1. Implementierungsplan analysieren → Tickets anlegen
|
||
touch .tasks/todo/TT-018-quick-access-grid.md
|
||
touch .tasks/todo/TT-019-frequent-projects-provider.md
|
||
|
||
# 2. Erstes Ticket in Bearbeitung nehmen
|
||
mv .tasks/todo/TT-018-quick-access-grid.md .tasks/processing/
|
||
|
||
# 3. Implementierung durchführen …
|
||
|
||
# 4. Ticket abschließen
|
||
mv .tasks/processing/TT-018-quick-access-grid.md .tasks/done/
|
||
|
||
# 5. Nächstes Ticket beginnen
|
||
mv .tasks/todo/TT-019-frequent-projects-provider.md .tasks/processing/
|
||
```
|
||
|
||
## Verwandte Dateien
|
||
|
||
| Datei | Inhalt |
|
||
|---|---|
|
||
| `.tasks/README.md` | Übersichtstabelle aller Tickets mit aktuellem Status |
|
||
| `.tasks/todo/` | Offene Tickets |
|
||
| `.tasks/processing/` | Tickets in Bearbeitung |
|
||
| `.tasks/done/` | Abgeschlossene Tickets (Referenz) |
|