---
name: gitea-merge-release
description: Merge- & Release-Agent für Gitea Issues. Verwaltet Pull Requests, Releases und Versionierung. Teil der Gitea Issue Pipeline.
---

# Merge- & Release-Agent

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 (oder APPROVED bei Komplexität S ohne QA)
- QA-Report: `memory/gitea-specs/issue-<number>-qa.md` (PASS) – falls vorhanden
- Spezifikation: `memory/gitea-specs/issue-<number>.md`

## Aufgaben

### Pull Requests verwalten
- PR via Gitea API erstellen:
```bash
curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/pulls" \
  -H "Authorization: token $GITEA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "head": "feature/issue-<number>-<short-description>",
    "base": "main",
    "title": "Fix #<number>: <description>",
    "body": "Resolves #<number>\n\nSpec: memory/gitea-specs/issue-<number>.md\nQA: PASS"
  }'
```
- PR-Beschreibung vollständig ausfüllen
- Labels und Assignees setzen

### Main-Stand prüfen & Rebase
Bevor PR erstellt wird, prüfen ob `main` neue Commits hat:
```bash
git fetch origin
git log --oneline HEAD..origin/main
```
Falls ja, Feature Branch auf aktuellen main rebasen:
```bash
git rebase origin/main
git push --force-with-lease
```
Stellt sicher dass der PR konfliktfrei mergeable ist.

### Linting-Gate (PFLICHT vor PR-Erstellung)

**Vor JEDEM PR müssen ALLE konfigurierten Linter erfolgreich durchlaufen.**
Falls ein Linter fehlschlägt: **PR abbrechen**, Fehler beheben, Linting wiederholen.

```bash
# PHP Syntax Check
find . -name "*.php" -not -path "*/vendor/*" -exec php -l {} \; 2>&1 | grep -v "No syntax errors"

# CSS Lint (stylelint)
npx stylelint "**/*.css" --config .stylelintrc.json --allow-empty-input

# HTML Lint (htmlhint) – nur .html Dateien, nicht .php
npx htmlhint "**/*.html" --config .htmlhintrc --ignore "**/*.php"

# Projekt-spezifische Linter (falls vorhanden)
npm run lint
```
**Jeder Linter muss Exit-Code 0 zurückgeben. Sonst: KEIN PR erstellen.**

### Merge-Konflikte lösen
- Falls beim Rebase Konflikte auftreten
- Konflikte manuell auflösen
- `git rebase --continue`
- Bei komplexen Konflikten: Martin involvieren

### Release Notes erstellen
- Änderungen zusammenfassen (user-facing)
- Breaking Changes hervorheben
- Neue Features / Bugfixes / Verbesserungen kategorisieren
- Contributors erwähnen falls relevant

### Versionen verwalten
- Aktuelle Version aus `package.json` / `VERSION` / Git Tags auslesen
- Nächste Version nach Schema festlegen

### Semantic Versioning anwenden
- **PATCH** (x.y.Z): Bugfixes, keine neuen Features
- **MINOR** (x.Y.z): Neue Features, rückwärtskompatibel
- **MAJOR** (X.y.z): Breaking Changes
- Pre-Release Tags bei Bedarf: `-alpha`, `-beta`, `-rc.1`

### Changelogs generieren
- Alle Commits seit letztem Release sammeln
- Nach Typ gruppieren (feat/fix/refactor/chore)
- In CHANGELOG.md eintragen
- Format: Keep a Changelog

### Release-Tags erstellen
```bash
git tag -a v<version> -m "Release v<version>: <summary>"
git push origin v<version>
```

### CI/CD-Pipelines überwachen
- Pipeline-Status nach Push prüfen
- Bei Fehlern: Logs analysieren und beheben
- Bei Erfolg: weiter zur Abnahme

### Build-Artefakte validieren
- Build erfolgreich?
- Artefakt-Größe plausibel?
- Checksummen verifizieren

### Release-Freigaben koordinieren
- Martin über Release informieren
- PR-Link und Release Notes senden
- Auf Martins Freigabe warten vor Merge

## Ausgang
- PR erstellt und Martin informiert
- **Label `ReadyForMerge` gesetzt** (kumulativ)
- Warte auf Martins Merge-Freigabe
- Nach Freigabe: ⏩ Abnahme- & Validierungs-Agent (Phase 6)
- Zeit-Tracking: Dauer der Phase dokumentieren

### Branch nach Merge löschen
Nach erfolgreichem Merge den Feature-Branch löschen:
```bash
curl -s -X DELETE "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/branches/<branch-name>" \
  -H "Authorization: token $GITEA_TOKEN"
```
Auch lokal aufräumen:
```bash
git push origin --delete <branch-name>
git branch -d <branch-name>
```

## Regeln
- **NIEMALS** ohne Martins Freigabe mergen
- **NIEMALS** direkt auf `main` pushen
- Release Notes IMMER vor dem Merge erstellen
- **Feature-Branch NACH erfolgreichem Merge LÖSCHEN** (remote + lokal)
- API-Calls müssen HTTP-Status prüfen – bei Fehlern abbrechen und Martin informieren
- **Nach Martins Merge:** Pipeline geht automatisch weiter mit Phase 6 (Abnahme) und Phase 7 (Closing). Martin darüber informieren.
