From f94cfb41e6b66ba2b45db6e2c44f838a2a1a348a Mon Sep 17 00:00:00 2001 From: OpenClaw Date: Sun, 10 May 2026 20:37:13 +0000 Subject: [PATCH] feat: pipeline improvements + remove deployment phase - Complexity Gate: S/M/L in Phase 1, S skips QA, L needs Martin approval - Max 3 fix cycles, then pause and ask Martin - KI self-review disclaimer in Code Review - Removed Phase 7 (Deployment) entirely - Renumbered: 7 phases instead of 9 - Updated all skills with new phase numbers --- memory/email-check.log | 1 + skills/gitea-abnahme-validierung/SKILL.md | 24 +++--- skills/gitea-analyse-architektur/SKILL.md | 17 +++- skills/gitea-code-review/SKILL.md | 18 ++++- skills/gitea-deployment/SKILL.md | 89 --------------------- skills/gitea-dokumentation-closing/SKILL.md | 10 +-- skills/gitea-fix-refactoring/SKILL.md | 24 +++++- skills/gitea-issue-resolver/SKILL.md | 89 ++++++++++++--------- skills/gitea-merge-release/SKILL.md | 11 ++- skills/gitea-test-qa/SKILL.md | 11 ++- 10 files changed, 131 insertions(+), 163 deletions(-) delete mode 100644 skills/gitea-deployment/SKILL.md diff --git a/memory/email-check.log b/memory/email-check.log index f1c5972..96d4829 100644 --- a/memory/email-check.log +++ b/memory/email-check.log @@ -2640,3 +2640,4 @@ ERROR: AGENTMAIL_API_KEY not set ERROR: AGENTMAIL_API_KEY not set ERROR: AGENTMAIL_API_KEY not set ERROR: AGENTMAIL_API_KEY not set +ERROR: AGENTMAIL_API_KEY not set diff --git a/skills/gitea-abnahme-validierung/SKILL.md b/skills/gitea-abnahme-validierung/SKILL.md index bf42e1b..95b1008 100644 --- a/skills/gitea-abnahme-validierung/SKILL.md +++ b/skills/gitea-abnahme-validierung/SKILL.md @@ -5,10 +5,10 @@ description: Abnahme- & Validierungs-Agent für Gitea Issues. Validiert Anforder # Abnahme- & Validierungs-Agent -Rolle: Siebte Phase – nach erfolgreichem Deployment. Stellt sicher, dass die Lösung das Problem wirklich löst. +Rolle: Phase 6 – nach gemergtem Code. Stellt sicher, dass die Lösung das Problem wirklich löst. ## Eingang -- Deployte Anwendung in Zielumgebung +- Gemergter PR / Release-Tag - Spezifikation: `memory/gitea-specs/issue-.md` - Original-Issue von Gitea @@ -51,31 +51,29 @@ Rolle: Siebte Phase – nach erfolgreichem Deployment. Stellt sicher, dass die L - Lizenzpflichtige Dependencies dokumentiert? ### Freigabetests durchführen -- Endgültiger Smoke Test auf Production/Staging +- Finaler Check des gemergten Stands - Keine Regressions in bestehenden Features -- Performance akzeptabel unter realen Bedingungen -- Keine Error-Spikes in Monitoring +- Keine offensichtlichen Fehler ### Stakeholder-Feedback auswerten - Falls Martin bereits getestet hat: Feedback einarbeiten -- Bei neuen Anforderungen: Neues Issue erstellen (nicht scope creepen) +- Bei neuen Anforderungen: Neues Issue erstellen (kein Scope Creep) ### Produktionsverhalten kontrollieren -- Logs auf Unexpected Errors prüfen -- Metriken stabil? -- Keine Alarme ausgelöst? -- Nutzer-Reports prüfen falls vorhanden +- Code-Stand auf `main` nach Merge prüfen +- Build/CI-Status grün? +- Keine Warnungen die übersehen wurden ### Release-Abnahme dokumentieren - Validierungsbericht in `memory/gitea-specs/issue--validation.md` - Ergebnis: **ACCEPTED** oder **REJECTED** - Bei ACCEPTED: Freigabe für Dokumentation -- Bei REJECTED: Begründung + ⏩ zurück zum Implementierungs-Agent +- Bei REJECTED: Begründung + ⏩ zurück zum Implementierungs-Agent (Phase 2) ## Ausgang - Validierungsbericht: `memory/gitea-specs/issue--validation.md` -- Status: **ACCEPTED** → ⏩ Dokumentations- & Closing-Agent -- Status: **REJECTED** → ⏩ Implementierungs-Agent mit Begründung +- Status: **ACCEPTED** → ⏩ Dokumentations- & Closing-Agent (Phase 7) +- Status: **REJECTED** → ⏩ Implementierungs-Agent (Phase 2) mit Begründung ## Regeln - Immer aus Nutzersicht prüfen, nicht aus Entwicklersicht diff --git a/skills/gitea-analyse-architektur/SKILL.md b/skills/gitea-analyse-architektur/SKILL.md index 0fc86f8..c5edcbc 100644 --- a/skills/gitea-analyse-architektur/SKILL.md +++ b/skills/gitea-analyse-architektur/SKILL.md @@ -5,12 +5,24 @@ description: Analyse- & Architektur-Agent für Gitea Issues. Analysiert Anforder # Analyse- & Architektur-Agent -Rolle: Erste Phase der Gitea Issue Pipeline. Analysiert das Issue und erstellt die Grundlage für alle folgenden Phasen. +Rolle: Erste Phase der Gitea Issue Pipeline. Analysiert das Issue, bewertet die Komplexität und erstellt die Grundlage für alle folgenden Phasen. ## Eingang - Gitea Issue **nur** mit Label `KI` - Issue-Body, Kommentare, verlinkte Ressourcen +## Complexity Gate + +**Pflicht am Anfang:** Bewerte die Komplexität des Issues: + +| Level | Kriterien | Auswirkung auf Pipeline | +|---|---|---| +| **S** (Small) | Typo-Fix, Config-Änderung, einfacher Bugfix, < 30min geschätzt | Überspringt Phase 4 (Test & QA). Nach Review direkt zu Merge. | +| **M** (Medium) | Neues Feature, Refactoring, API-Änderung, 30min–4h | Volle Pipeline. | +| **L** (Large) | Architektur-Änderung, neues Modul, DB-Migration, > 4h | Volle Pipeline + Martin muss Analyse freigeben bevor Implementierung startet. | + +Komplexität ins Issue schreiben und im Spezifikationsdokument festhalten. + ## Aufgaben ### Anforderungen analysieren @@ -83,7 +95,7 @@ Rolle: Erste Phase der Gitea Issue Pipeline. Analysiert das Issue und erstellt d ## Ausgang - Spezifikationsdokument: `memory/gitea-specs/issue-.md` -- **Issue aktualisieren** mit allen Erkenntnissen (Architektur, Teilaufgaben, Akzeptanzkriterien, etc.) +- **Issue aktualisieren** mit allen Erkenntnissen (Komplexität, Architektur, Teilaufgaben, Akzeptanzkriterien, etc.) - Spezifikation als Kommentar ins Issue geschrieben - Dem Issue den Tag **`ReadyForDev`** hinzufügen: ```bash @@ -99,3 +111,4 @@ curl -s -X POST "https://git.home.kies-media.de/api/v1/repos///issu - Spezifikation muss für den Implementierungs-Agent ohne Rückfragen umsetzbar sein - 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 diff --git a/skills/gitea-code-review/SKILL.md b/skills/gitea-code-review/SKILL.md index 445c760..1dd3ed4 100644 --- a/skills/gitea-code-review/SKILL.md +++ b/skills/gitea-code-review/SKILL.md @@ -5,7 +5,16 @@ description: Code-Review-Agent für Gitea Issues. Prüft Codequalität, Sicherhe # Code-Review-Agent -Rolle: Dritte Phase der Gitea Issue Pipeline. Qualitätssicherung vor dem Test. +Rolle: Phase 3 der Gitea Issue Pipeline. Qualitätssicherung vor dem Test. + +## Wichtiger Hinweis: KI reviewt KI + +Dieser Agent führt ein **Self-Review** durch – die KI prüft ihren eigenen Code. Das ist besser als kein Review, aber **kein echter Gatekeeper**. + +- Bei **kritischen Änderungen** (Sicherheit, Finanzen, Auth, DB-Schema): Martin bitten, selbst zu reviewen +- Bei **Komplexität L**: Martin muss den Review bestätigen bevor weitergegangen wird +- Self-Review fängt offensichtliche Bugs, Style-Issues und Sicherheitsbasics ab +- Subtile Logikfehler können durchgehen ## Eingang - Feature Branch mit Implementierung @@ -82,10 +91,13 @@ Rolle: Dritte Phase der Gitea Issue Pipeline. Qualitätssicherung vor dem Test. ## Ausgang - Review-Ergebnis dokumentiert in `memory/gitea-specs/issue--review.md` - Status: **APPROVED** oder **CHANGES_REQUESTED** -- Bei APPROVED: ⏩ Übergabe an **Test- & QA-Agent** -- Bei CHANGES_REQUESTED: ⏩ Übergabe an **Fix- & Refactoring-Agent** +- Bei APPROVED: + - Komplexität **S**: ⏩ direkte Übergabe an **Merge- & Release-Agent** (Phase 5) + - Komplexität **M/L**: ⏩ Übergabe an **Test- & QA-Agent** (Phase 4) +- Bei CHANGES_REQUESTED: ⏩ Übergabe an **Fix- & Refactoring-Agent** (Phase 4-fix) ## Regeln - Immer konstruktiv – Review ist Hilfe, nicht Kritik - Keine stilistischen Nitpicks als Blocker - Sicherheitsprobleme sind immer 🔴 Must-Fix +- Bei kritischen Änderungen: Martin zur Review-Bestätigung auffordern diff --git a/skills/gitea-deployment/SKILL.md b/skills/gitea-deployment/SKILL.md deleted file mode 100644 index bd5456c..0000000 --- a/skills/gitea-deployment/SKILL.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -name: gitea-deployment -description: Deployment-Agent für Gitea Issues. Deployt Anwendungen, konfiguriert Infrastruktur und überwacht den Rollout. Teil der Gitea Issue Pipeline. ---- - -# Deployment-Agent - -Rolle: Sechste Phase – nach Merge und Release. Kümmert sich um das Deployment in die Zielumgebung. - -## Eingang -- Gemergter PR / Release-Tag -- Release Notes -- Zielumgebung (dev/staging/production) - -## Aufgaben - -### Anwendungen deployen -- Deployment-Methoden: Docker, Docker Compose, K8s, Direct Deploy -- Blue-Green oder Rolling Update wo möglich -- Deployment-Befehl ausführen und überwachen - -### Infrastruktur konfigurieren -- Umgebungsvariablen setzen -- Konfigurationsdateien aktualisieren -- Service-Abhängigkeiten prüfen (Datenbank, Cache, etc.) -- Netzwerk/Firewall-Regeln falls nötig - -### Container verwalten -- Neues Image bauen: `docker build -t : .` -- Image pushen: `docker push /:` -- Container starten/neustarten -- Health des Containers prüfen - -### Rollbacks durchführen -- Bei Fehlern: sofortiges Rollback auf vorherige Version -- Vorherige Version/Image bereithalten -- Rollback-Befehl dokumentiert -- Martin bei Rollback sofort informieren - -### Secrets verwalten -- Neue Secrets in die Zielumgebung eintragen -- Keine Secrets in Config-Dateien oder Images -- Secrets rotieren falls nötig -- `.env`-Dateien nicht im Repo - -### Umgebungen synchronisieren -- Konfigurationsdrift vermeiden -- Staging vor Production deployen -- Prod-Parität des Staging sicherstellen - -### Datenbankmigrationen ausführen -- Migrationen automatisch oder manuell laufen lassen -- Backup vor Migration -- Migration-Output prüfen -- Bei Fehler: Rollback + Martin informieren - -### Monitoring aktivieren -- Logs prüfen nach Deployment -- Metriken/Alermts aktualisieren -- Dashboards bei neuen Metriken erweitern -- Error-Rate nach Deploy überwachen - -### Skalierung konfigurieren -- Ressourcenlimits anpassen falls nötig -- Auto-Scaling-Regeln aktualisieren -- Load Balancer Konfiguration prüfen - -### Deployment-Logs analysieren -- Logs auf Errors/Warnungen scannen -- Anomalien erkennen -- Erfolgreiches Deployment bestätigen - -### Health Checks durchführen -- Endpoint-Health prüfen (`/health`, `/ready`) -- Datenbankverbindung testen -- Externe API-Erreichbarkeit testen -- Smoke Tests ausführen - -## Ausgang -- Deployment erfolgreich und verifiziert -- Health Checks bestanden -- Martin informiert über erfolgreiches Deployment -- ⏩ Übergabe an **Abnahme- & Validierungs-Agent** - -## Regeln -- **Immer** Staging vor Production -- **Immer** Backup vor Migration -- **Immer** Rollback-Plan bereit -- **Sofort** Martin informieren bei Problemen diff --git a/skills/gitea-dokumentation-closing/SKILL.md b/skills/gitea-dokumentation-closing/SKILL.md index 924a11e..1b56e1c 100644 --- a/skills/gitea-dokumentation-closing/SKILL.md +++ b/skills/gitea-dokumentation-closing/SKILL.md @@ -5,13 +5,13 @@ description: Dokumentations- & Closing-Agent für Gitea Issues. Erstellt Dokumen # Dokumentations- & Closing-Agent -Rolle: Letzte Phase – nach erfolgreicher Abnahme. Dokumentiert alles und schließt den Kreis. +Rolle: Phase 7 – nach erfolgreicher Abnahme. Dokumentiert alles und schließt den Kreis. ## Eingang - Validierungsbericht: ACCEPTED - Spezifikation: `memory/gitea-specs/issue-.md` - Review, QA-Reports -- Deployte und validierte Lösung +- Gemergter und validierter Code ## Aufgaben @@ -42,7 +42,7 @@ Rolle: Letzte Phase – nach erfolgreicher Abnahme. Dokumentiert alles und schli - Breaking Changes hervorgehoben ### Betriebsdokumentation schreiben -- Deploy-Prozess beschrieben +- Deploy-/Start-Prozess beschrieben - Umgebungsvariablen dokumentiert - Backup/Restore-Verfahren - Monitoring & Alerting @@ -75,12 +75,12 @@ curl -s -X PATCH "https://git.home.kies-media.de/api/v1/repos///iss - Neue Erkenntnisse in `memory/` speichern - Lessons Learned festhalten - Best Practices aktualisieren -- `MEMORY.md` bei relevanten learnings updaten +- `MEMORY.md` bei relevanten Learnings updaten ### Abschlussberichte generieren - Zusammenfassung des gesamten Issue-Lebenszyklus - Was wurde gemacht, warum, mit welchem Ergebnis -- Aufwand (Zeit/Commits/Reviews) +- Aufwand (Commits/Reviews/Zyklen) - In `memory/gitea-specs/issue--final.md` ### Tickets schließen diff --git a/skills/gitea-fix-refactoring/SKILL.md b/skills/gitea-fix-refactoring/SKILL.md index a6f4f28..4f91b44 100644 --- a/skills/gitea-fix-refactoring/SKILL.md +++ b/skills/gitea-fix-refactoring/SKILL.md @@ -11,6 +11,23 @@ Rolle: Wird bei Bedarf eingeschaltet – nach Code Review mit Änderungswünsche - Feature Branch mit Änderungswünschen - Review-Kommentare: `memory/gitea-specs/issue--review.md` (CHANGES_REQUESTED) - oder QA-Report: `memory/gitea-specs/issue--qa.md` (FAIL) +- Zyklus-Counter (wie oft bereits Fix → Review/QA durchlaufen) + +## Zyklus-Limit + +**Maximal 3 Fix-Zyklen.** Danach: + +1. Fix-Zyklus abbrechen +2. Zusammenfassung erstellen was hängt: + - Welche Probleme sind offen? + - Woran scheitert es? + - Was wurde schon versucht? +3. **Martin informieren und auf seine Entscheidung warten:** + - Weitere 3 Zyklen genehmigen + - Issue manuell übernehmen + - Issue zurückstellen / schließen + +Zyklus-Counter dokumentieren in `memory/gitea-specs/issue--fix-cycles.md`. ## Aufgaben @@ -78,11 +95,14 @@ Rolle: Wird bei Bedarf eingeschaltet – nach Code Review mit Änderungswünsche ## Ausgang - Alle Fixes auf Feature Branch committet - Änderungen dokumentiert +- Zyklus-Counter inkrementiert - ⏩ Zurück an den Agent der das Feedback gegeben hat: - - Bei Review-Feedback → **Code-Review-Agent** - - Bei QA-Fail → **Test- & QA-Agent** + - Bei Review-Feedback → **Code-Review-Agent** (Phase 3) + - Bei QA-Fail → **Test- & QA-Agent** (Phase 4) +- Bei Zyklus > 3: ⏸ Pause + Martin informieren ## Regeln - Ein Fix = ein Commit (atomic) - Kein Refactoring ohne klaren Grund - Bei Unsicherheit: Martin fragen +- Zyklus-Limit **strikt** einhalten – keine Endlosschleifen diff --git a/skills/gitea-issue-resolver/SKILL.md b/skills/gitea-issue-resolver/SKILL.md index 7d280ee..867db04 100644 --- a/skills/gitea-issue-resolver/SKILL.md +++ b/skills/gitea-issue-resolver/SKILL.md @@ -1,11 +1,11 @@ --- name: gitea-issue-resolver -description: Pipeline-Orchestrator für Gitea Issues. Koordiniert die 9 Agenten-Phasen von der Analyse bis zum Closing. Use when checking or working on issues in Martin's Gitea repos (git.home.kies-media.de). Triggers on mentions of "issues", "Gitea issues", or when checking repos for open issues. +description: Pipeline-Orchestrator für Gitea Issues. Koordiniert die 7 Agenten-Phasen von der Analyse bis zum Closing. Use when checking or working on issues in Martin's Gitea repos (git.home.kies-media.de). Triggers on mentions of "issues", "Gitea issues", or when checking repos for open issues. --- # Gitea Issue Resolver – Pipeline Orchestrator -Koordiniert die gesamte Issue-Pipeline. Holt Issues ab und steuert sie durch die 9 Phasen. +Koordiniert die gesamte Issue-Pipeline. Holt Issues ab und steuert sie durch die Phasen. ## Authentication @@ -21,7 +21,17 @@ Gitea API token: `$GITEA_TOKEN` (in `.bashrc`): GITEA_TOKEN="568841…2e34" ``` -## Pipeline – 9 Phasen +## Complexity Gate + +Phase 1 bewertet die Komplexität. Das bestimmt den Pipeline-Verlauf: + +| Komplexität | Pipeline | +|---|---| +| **S** (Small) | Phase 1 → 2 → 3 → 5 → 6 → 7 *(überspringt QA)* | +| **M** (Medium) | Phase 1 → 2 → 3 → 4 → 5 → 6 → 7 *(volle Pipeline)* | +| **L** (Large) | Phase 1 → **Martin-Freigabe** → 2 → 3 → 4 → 5 → 6 → 7 *(Analyse muss freigegeben werden)* | + +## Pipeline – 7 Phasen ### Issue-Filter Phase 1 (Analyse) holt Issues **nur** mit Tag `KI`: @@ -34,9 +44,10 @@ curl -s "https://git.home.kies-media.de/api/v1/repos///issues?state Ab Phase 2 (Implementierung) werden nur Issues mit **beiden** Tags `KI` + `ReadyForDev` weiterverarbeitet (wird von Phase 1 gesetzt). ### Phase 1: Analyse- & Architektur-Agent → `gitea-analyse-architektur` -- Anforderungen analysieren -- Architektur entwerfen -- Spezifikation erstellen +- Complexity Gate: S / M / L bewerten +- Anforderungen analysieren, Architektur entwerfen +- Spezifikation erstellen + ins Issue schreiben +- Tag `ReadyForDev` hinzufügen (bei L: erst nach Martins Freigabe) - Output: `memory/gitea-specs/issue-.md` ### Phase 2: Implementierungs-Agent → `gitea-implementierung` @@ -47,35 +58,32 @@ Ab Phase 2 (Implementierung) werden nur Issues mit **beiden** Tags `KI` + `Ready ### Phase 3: Code-Review-Agent → `gitea-code-review` - Codequalität & Sicherheit prüfen +- Self-Review (bei kritischen Änderungen: Martin bitten) - Review-Kommentare erstellen - Output: APPROVED oder CHANGES_REQUESTED -### Phase 4: Test- & QA-Agent → `gitea-test-qa` +### Phase 4: Test- & QA-Agent → `gitea-test-qa` *(übersprungen bei S)* - Unit-, Integration-, E2E-Tests - QA-Report erstellen - Output: PASS oder FAIL -### Phase 5: Fix- & Refactoring-Agent → `gitea-fix-refactoring` *(bei Bedarf)* +### Phase 4-fix: Fix- & Refactoring-Agent → `gitea-fix-refactoring` *(bei Bedarf, max. 3 Zyklen)* - Review-Feedback umsetzen - Bugs korrigieren +- Nach max. 3 Zyklen: Martin informieren - Danach zurück zur jeweiligen Phase (Review oder QA) -### Phase 6: Merge- & Release-Agent → `gitea-merge-release` +### Phase 5: Merge- & Release-Agent → `gitea-merge-release` - PR erstellen - Release Notes & Versionierung -- Warten auf Martins Freigabe +- **Wartet auf Martins Freigabe** -### Phase 7: Deployment-Agent → `gitea-deployment` -- Anwendungen deployen -- Health Checks -- Bei Problemen: Rollback - -### Phase 8: Abnahme- & Validierungs-Agent → `gitea-abnahme-validierung` +### Phase 6: Abnahme- & Validierungs-Agent → `gitea-abnahme-validierung` - Anforderungen validieren - Akzeptanzkriterien abhaken - Output: ACCEPTED oder REJECTED -### Phase 9: Dokumentations- & Closing-Agent → `gitea-dokumentation-closing` +### Phase 7: Dokumentations- & Closing-Agent → `gitea-dokumentation-closing` - Dokumentation erstellen - Issue schließen - Abschlussbericht @@ -83,48 +91,51 @@ Ab Phase 2 (Implementierung) werden nur Issues mit **beiden** Tags `KI` + `Ready ## Pipeline-Fluss ``` -Issue (KI + ReadyForDev) +Issue (Label: KI) │ ▼ -[1] Analyse & Architektur +[1] Analyse & Architektur ──→ Complexity: S / M / L + │ │ │ │ + │ (setzt ReadyForDev) S M L → Martin freigeben + │ │ │ │ + ▼ ▼ ▼ ▼ +[2] Implementierung ────────────────────────────────── │ ▼ -[2] Implementierung +[3] Code Review ──── CHANGES_REQUESTED ──→ [fix] Fix & Refactoring ──→ [3] + │ APPROVED (max. 3 Zyklen, dann Martin fragen) │ - ▼ -[3] Code Review ──── CHANGES_REQUESTED ──→ [5] Fix & Refactoring ──→ [3] - │ APPROVED - ▼ -[4] Test & QA ────── FAIL ──────────────→ [5] Fix & Refactoring ──→ [4] + ├─ S ──────────────────────────────────→ [5] Merge & Release + │ + ▼ (M, L) +[4] Test & QA ────── FAIL ──────────────→ [fix] Fix & Refactoring ──→ [4] │ PASS ▼ -[6] Merge & Release ( wartet auf Martins Freigabe ) +[5] Merge & Release (wartet auf Martins Freigabe) │ ▼ -[7] Deployment - │ - ▼ -[8] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung +[6] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung │ ACCEPTED ▼ -[9] Dokumentation & Closing → Issue geschlossen ✅ +[7] Dokumentation & Closing → Issue geschlossen ✅ ``` ## Orchestrierung Für jedes Issue: 1. Spezifikations-Verzeichnis erstellen: `mkdir -p memory/gitea-specs` -2. Phasen sequenziell durchlaufen -3. Bei Rücksprüngen (Fix-Phase) den Zyklus wiederholen +2. Komplexität aus Phase 1 berücksichtigen für Pipeline-Verlauf +3. Fix-Zyklen zählen, bei >3 abbrechen und Martin informieren 4. Martin bei wichtigen Meilensteinen informieren: - - Spezifikation fertig (Phase 1) - - PR erstellt (Phase 6) - - Deployment erfolgreich (Phase 7) - - Issue geschlossen (Phase 9) + - Spezifikation fertig + Komplexität (Phase 1) + - PR erstellt (Phase 5) + - Issue geschlossen (Phase 7) ## Regeln -- **Nur** Issues mit Tags `KI` + `ReadyForDev` +- Phase 1 filtert auf **nur** `KI` +- Ab Phase 2: **nur** Issues mit `KI` + `ReadyForDev` - **Nie** ohne Martins Freigabe mergen -- **Nie** Issue selbst schließen (nur Phase 9 darf das) +- **Nie** Issue selbst schließen (nur Phase 7 darf das) - **Nie** direkt auf `main` pushen +- **Max. 3** Fix-Zyklen, dann Martin fragen - Bei Blockern: sofort Martin informieren diff --git a/skills/gitea-merge-release/SKILL.md b/skills/gitea-merge-release/SKILL.md index d7634b1..7c5f762 100644 --- a/skills/gitea-merge-release/SKILL.md +++ b/skills/gitea-merge-release/SKILL.md @@ -5,11 +5,11 @@ description: Merge- & Release-Agent für Gitea Issues. Verwaltet Pull Requests, # Merge- & Release-Agent -Rolle: Fünfte Phase – nach erfolgreichem Review und QA. Kümmert sich um Merge und Release-Vorbereitung. +Rolle: Phase 5 – nach erfolgreichem Review und QA. Kümmert sich um Merge und Release-Vorbereitung. ## Eingang -- Feature Branch mit APPROVED Code und PASS-Status im QA -- QA-Report: `memory/gitea-specs/issue--qa.md` (PASS) +- Feature Branch mit APPROVED Code und PASS-Status im QA (oder APPROVED bei Komplexität S ohne QA) +- QA-Report: `memory/gitea-specs/issue--qa.md` (PASS) – falls vorhanden - Spezifikation: `memory/gitea-specs/issue-.md` ## Aufgaben @@ -67,13 +67,12 @@ git push origin v ### CI/CD-Pipelines überwachen - Pipeline-Status nach Push prüfen - Bei Fehlern: Logs analysieren und beheben -- Bei Erfolg: Deployment-Phase einleiten +- Bei Erfolg: weiter zur Abnahme ### Build-Artefakte validieren - Build erfolgreich? - Artefakt-Größe plausibel? - Checksummen verifizieren -- Signaturen wo nötig ### Release-Freigaben koordinieren - Martin über Release informieren @@ -83,7 +82,7 @@ git push origin v ## Ausgang - PR erstellt und Martin informiert - Warte auf Martins Merge-Freigabe -- Nach Freigabe: ⏩ Deployment-Agent +- Nach Freigabe: ⏩ Abnahme- & Validierungs-Agent (Phase 6) ## Regeln - **NIEMALS** ohne Martins Freigabe mergen diff --git a/skills/gitea-test-qa/SKILL.md b/skills/gitea-test-qa/SKILL.md index 62de775..3b55252 100644 --- a/skills/gitea-test-qa/SKILL.md +++ b/skills/gitea-test-qa/SKILL.md @@ -5,7 +5,10 @@ description: Test- & QA-Agent für Gitea Issues. Erstellt und führt Tests durch # Test- & QA-Agent -Rolle: Vierte Phase der Gitea Issue Pipeline. Stellt sicher, dass die Implementierung korrekt und robust ist. +Rolle: Phase 4 der Gitea Issue Pipeline. Stellt sicher, dass die Implementierung korrekt und robust ist. + +## Wird übersprungen bei +- **Komplexität S:** Test & QA wird übersprungen, direkt nach Review (APPROVED) → Merge ## Eingang - Feature Branch mit APPROVED Code @@ -24,7 +27,7 @@ Rolle: Vierte Phase der Gitea Issue Pipeline. Stellt sicher, dass die Implementi - Modulgrenzen testen - Datenbank-Integration prüfen - API-End-to-End innerhalb des Services -- externe API-Mocks nutzen +- Externe API-Mocks nutzen ### E2E-Tests durchführen - Nutzerflows durchspielen @@ -82,8 +85,8 @@ Rolle: Vierte Phase der Gitea Issue Pipeline. Stellt sicher, dass die Implementi ## Ausgang - Test-Code auf Feature Branch committet - QA-Report: `memory/gitea-specs/issue--qa.md` -- Status: **PASS** → ⏩ Merge- & Release-Agent -- Status: **FAIL** → ⏩ Fix- & Refactoring-Agent +- Status: **PASS** → ⏩ Merge- & Release-Agent (Phase 5) +- Status: **FAIL** → ⏩ Fix- & Refactoring-Agent (Phase 4-fix) ## Regeln - Keine Tests nur für die Statistik – jeder Test muss einen Wert haben