Auto-commit: 2026-05-20 21:35
This commit is contained in:
@@ -25,6 +25,23 @@ Komplexität ins Issue schreiben und im Spezifikationsdokument festhalten.
|
||||
|
||||
## Aufgaben
|
||||
|
||||
### Abhängigkeiten analysieren
|
||||
- Gibt es andere offene Issues, die dieses Issue blockieren oder die davon abhängen?
|
||||
- Typische Abhängigkeiten:
|
||||
- JS-Rewrite (#19 jQuery entfernen) sollte VOR Accessibility (#18) passieren
|
||||
- Infrastruktur-Änderungen VOR Feature-Implementierung
|
||||
- API-Änderungen VOR Frontend-Anpassungen
|
||||
- Abhängigkeiten im Spezifikationsdokument festhalten
|
||||
- **Als Kommentar ins Issue schreiben** mit `🔗 **Abhängigkeit:**` Prefix
|
||||
- Gitea Dependency-API nutzen falls verfügbar:
|
||||
```bash
|
||||
# Issue N hängt von Issue M ab
|
||||
POST /repos/<owner>/<repo>/issues/N/dependencies {"index": M}
|
||||
# Issue N blockiert Issue M
|
||||
POST /repos/<owner>/<repo>/issues/N/blocks {"index": M}
|
||||
```
|
||||
- Falls API nicht funktioniert: Als Kommentar dokumentieren
|
||||
|
||||
### Anforderungen analysieren
|
||||
- Issue-Body vollständig lesen und verstehen
|
||||
- Stakeholder-Intention erkennen
|
||||
@@ -93,11 +110,23 @@ Komplexität ins Issue schreiben und im Spezifikationsdokument festhalten.
|
||||
- Rollback-Strategie festlegen
|
||||
- Datenverlust-Risiko bewerten
|
||||
|
||||
### API-Calls absichern
|
||||
Alle Gitea API-Calls müssen den HTTP-Status prüfen:
|
||||
```bash
|
||||
HTTP_STATUS=$(curl -s -o /tmp/response.json -w "%{http_code}" ...)
|
||||
if [ "$HTTP_STATUS" -ge 400 ]; then
|
||||
echo "API-Fehler: $HTTP_STATUS"
|
||||
cat /tmp/response.json
|
||||
# Abbrechen und Martin informieren
|
||||
fi
|
||||
```
|
||||
Bei Fehlern: Vorgang abbrechen, Fehlermeldung dokumentieren, Martin informieren.
|
||||
|
||||
## Ausgang
|
||||
- Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
|
||||
- **Issue aktualisieren** mit allen Erkenntnissen (Komplexität, Architektur, Teilaufgaben, Akzeptanzkriterien, etc.)
|
||||
- Spezifikation als Kommentar ins Issue geschrieben
|
||||
- Dem Issue den Tag **`ReadyForDev`** hinzufügen:
|
||||
- Dem Issue das Label **`ReadyForDev`** hinzufügen (kumulativ – bestehende Labels bleiben):
|
||||
```bash
|
||||
curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues/<number>/labels" \
|
||||
-H "Authorization: token $GITEA_TOKEN" \
|
||||
@@ -112,3 +141,4 @@ curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issu
|
||||
- Sicherheitsrelevante Entscheidungen dokumentieren und Martin zur Freigabe vorlegen
|
||||
- Tag `ReadyForDev` **erst** hinzufügen, wenn Analyse & Architektur vollständig abgeschlossen
|
||||
- **Bei Komplexität L:** Martin muss die Analyse freigeben bevor `ReadyForDev` gesetzt wird
|
||||
- **Bei Subscription-Limit / Rate-Limit:** Sofort pausieren, Martin informieren, nicht weiterarbeiten
|
||||
|
||||
Reference in New Issue
Block a user