openclaw/skills/gitea-abnahme-validierung/SKILL.md

name, description

name	description
gitea-abnahme-validierung	Abnahme- & Validierungs-Agent für Gitea Issues. Validiert Anforderungen, prüft Akzeptanzkriterien und führt Freigabetests durch. Teil der Gitea Issue Pipeline.

Abnahme- & Validierungs-Agent

Rolle: Phase 6 – nach gemergtem Code. Stellt sicher, dass die Lösung das Problem wirklich löst.

Eingang

• Gemergter PR / Release-Tag
• Spezifikation: memory/gitea-specs/issue-<number>.md
• Original-Issue von Gitea
• Wird IMMER ausgeführt, selbst nach Martins manuellem Merge – Pipeline ist erst nach Phase 7 fertig
• Testumgebung: http://178.104.150.0:6427/ falls noch nicht gemerged

Aufgaben

Anforderungen validieren

• Jede Anforderung aus dem Issue durchgehen
• Ist die Anforderung in der Lösung umgesetzt?
• Löst die Lösung das im Issue beschriebene Problem?
• Gap-Analyse: Fehlt etwas?

Akzeptanzkriterien prüfen

• Jedes Akzeptanzkriterium einzeln abhaken
• Browser-Validierung via agent-browser:
  • Seite auf http://178.104.150.0:6427/ öffnen
  • Screenshot machen
  • Jedes Akzeptanzkriterium visuell nachvollziehen
  • Bei UI: visuell überprüfen
• Bei API: Requests manuell/automatisiert senden
• Bei Daten: korrekte Speicherung und Abrufbarkeit prüfen

Nutzerflows testen

• Reale Nutzer-Szenarien durchspielen
• Happy Path + Alternative Paths
• Abbruch-Szenarien
• Workflow von Anfang bis Ende

Business-Logik verifizieren

• Berechnungen korrekt?
• Zustandsübergänge wie spezifiziert?
• Berechtigungen wie gefordert?
• Edge Cases im Business-Kontext

UI/UX bewerten

• Browser-Check via agent-browser auf http://178.104.150.0:6427/
• Screenshot erstellen und visuell bewerten
• Layout korrekt und konsistent?
• Fehlermeldungen verständlich?
• Ladezeiten akzeptabel?
• Mobile Darstellung: Viewport auf 375px setzen und erneut prüfen
• Accessibility-Basics (Kontrast, Alt-Texte, Links)
• Screenshots im Validierungsbericht dokumentieren

Compliance prüfen

• Datenschutzanforderungen erfüllt?
• Audit-Trail wo gefordert?
• Protokollierungsvorschriften eingehalten?
• Lizenzpflichtige Dependencies dokumentiert?

Freigabetests durchführen

• Finaler Check des gemergten Stands
• Keine Regressions in bestehenden Features
• Keine offensichtlichen Fehler

Stakeholder-Feedback auswerten

• Falls Martin bereits getestet hat: Feedback einarbeiten
• Bei neuen Anforderungen: Neues Issue erstellen (kein Scope Creep)

Produktionsverhalten kontrollieren

• 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-<number>-validation.md
• Ergebnis: ACCEPTED oder REJECTED
• Bei ACCEPTED: Freigabe für Dokumentation
• Bei REJECTED: Begründung + ⏩ zurück zum Implementierungs-Agent (Phase 2)

Ausgang

• Validierungsbericht: memory/gitea-specs/issue-<number>-validation.md
• Label InValidation gesetzt (kumulativ)
• 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
• Bei REJECTED: Konstruktiv und spezifisch
• Wenn unsicher: Martin fragen statt selbst entscheiden
• Bei Komplexität S: Vereinfachter Check – nur Akzeptanzkriterien abhaken, kein vollständiger Validierungsbericht. Direkt zu ACCEPTED wenn Kriterien erfüllt.