---
name: pre-release-gate
description: >
  Release-Freigabe vor einem Deploy: übernimmt gültige Prüfstempel, lässt nur fehlende
  Baseline-Prüfungen laufen, wertet die ASVS-light-Checkliste aus und liefert ein Urteil
  Go / Go mit Auflagen / No-Go. Schreibt nach dem Deploy das Release-Protokoll und den Tag.

  TRIGGER WENN der User sagt: "deployen", "Release", "live stellen", "ist das bereit",
  "Go/No-Go", "Release-Check", "/pre-release-gate", oder bevor ein Agent einen Deploy anstößt.

  Ergebnis: Urteil mit Begründung und den drei wichtigsten Befunden, nach dem Deploy
  docs/releases/<datum>-<commit>.md und Tag release-<datum>.
---

# pre-release-gate

Ein Deploy ohne dieses Gate ist nicht freigegeben. Das Gate deployt **nicht** selbst; der Deploy
braucht danach die ausdrückliche Freigabe des Users.

Grundsatz: **Was für genau diesen Commit schon grün war, läuft nicht noch einmal.** Das belegen
die Prüfstempel der Baseline (`reports/stamps/`, `scripts/security/stamp.py`). Ein Stempel gilt nur,
wenn der Arbeitsbaum beim Lauf sauber war und der Commit derselbe ist (danach nur Doku-Commits
sind erlaubt).

## A. Vor dem Deploy (im App-Repo)
1. **Stand festhalten:** Branch, Commit, letzter Release-Tag (`git describe --tags --match 'release-*' --abbrev=0`),
   Delta `git log --oneline <tag>..HEAD`. Kein Tag → erstes Release mit Gate, Delta = alles.
   Arbeitsbaum muss sauber sein (`make stamp` zeigt es). Unsauber → erst committen, nicht weiter.
2. **Prüfungen:**
   ```bash
   make release-checks                   # check + mutation, nur ohne gültigen Stempel
   make release-checks IMAGE=<image:tag> # zusätzlich container, falls Container-Deploy
   ```
   Ältere Baseline ohne `release-checks` → `make check`, `make mutation`, `make container` von Hand.
   Ergebnis je Prüfung notieren: grün (frisch / aus Stempel von <commit>) | rot | **nicht anwendbar** + Grund
   (kein `security-mutations.toml`, kein Container-Deploy). Nicht anwendbar ist kein „nicht ausgeführt“.
3. **Checkliste** `security-review/references/asvs-light.md`: jeder **K**-Punkt braucht einen Beleg
   (Test, Scan, Konfiguration). Kein Beleg = offen. Ein K-Punkt ist nur dann **nicht anwendbar**, wenn
   `docs/THREATMODEL.md` das als Design-Entscheidung festhält (z. B. B1/B2 bei bewusst teamweit geteilten
   Objekten, im Test als `idorGap`/`idor_gap` sichtbar), mit Begründung und wer entschieden hat. Ohne
   diesen Eintrag bleibt er offen; `idorGap` allein ist kein Beleg. Beim Folge-Release nur K-Punkte neu bewerten, die das
   Delta aus Schritt 1 berührt; die übrigen Belege aus dem letzten Protokoll (`docs/releases/`) übernehmen
   und darauf verweisen.
4. **Ausnahmen:** `docs/RELEASE-AUSNAHMEN.md` der App lesen. Ein H-/M-Punkt, der dort mit Begründung
   steht und dessen „Prüfen bis“ nicht überschritten ist, ist **akzeptiert**: keine Auflage, im Urteil nur
   als „akzeptiert (A<n>)“ nennen. Abgelaufen oder ohne Datum → wieder offen. K-Punkte nie als Ausnahme.
   Datei fehlt → Vorlage `templates/docs/RELEASE-AUSNAHMEN.md` aus der Baseline vorschlagen, nicht
   selbst Ausnahmen eintragen (Entscheidung Julian bzw. Christian).
5. **Deploy-Konfiguration:** App-Port nicht am Proxy vorbei erreichbar (Compose `ports:`), Debug aus,
   Secrets aus Secret-Store/Env, Backup vor Migrationen.
6. Lag seit dem letzten Review ein größerer KI-Diff an Auth/Rollen? → `security-review` im frischen
   Kontext, falls noch nicht geschehen.

## Urteil
- **No-Go**, wenn eins zutrifft: ein K-Punkt offen, Secrets gefunden, Tests rot, High/Critical in
  Dependencies oder Image ohne dokumentierte Ausnahme, Mutation überlebt, Arbeitsbaum unsauber.
- **Go mit Auflagen**: neue oder abgelaufene H-/M-Punkte offen, jeder mit Entscheidung
  (fixen/akzeptieren) und Termin, oder eine anwendbare Pflichtprüfung aus A.2 nicht ausgeführt.
  Auflagen als Issues im Repo der App vorschlagen. Wird eine Auflage
  akzeptiert, schlägt das Gate die Zeile für `docs/RELEASE-AUSNAHMEN.md` vor, damit sie beim nächsten
  Release nicht wieder auftaucht.
- **Go**: alle anwendbaren Prüfungen aus A.2 grün (frisch oder per gültigem Stempel), alle K-Punkte
  belegt, offene H-/M-Punkte nur als gültige Ausnahme.
- ZAP, Fuzzing und Playwright laufen **nach** dem Deploy (Teil B) und beeinflussen dieses Urteil nicht.
  Ihr Ergebnis geht ins Protokoll; Funde werden Issues und Prüfpunkte fürs nächste Release.

## Ausgabe
```
Urteil: No-Go | Go mit Auflagen | Go
Stand: <branch>@<commit>, seit release-<datum>: <n> Commits
Prüfungen: check ✅ (Stempel 10:42) | mutation ✅ frisch 10/10 | container: nicht anwendbar (kein Image)
Akzeptiert: A1, A3 (docs/RELEASE-AUSNAHMEN.md)
Top-3-Befunde:
1. [K] ... (Datei:Zeile, Beleg)
2. ...
Auflagen / nächste Schritte: ...
```

## B. Nach dem Deploy (nur mit Freigabe deployt)
1. Gegen die eigene Live-Instanz, nie fremde Hosts:
   `make zap TARGET=<url>` und, falls OpenAPI vorhanden, `make fuzz TARGET=<url>`.
   Nicht möglich (z. B. Login vor allem) → „nicht ausgeführt, Grund“ ins Protokoll.
2. **Protokoll** nach Vorlage `templates/docs/release-protokoll.md` der Baseline:
   `docs/releases/<YYYY-MM-DD>-<shortsha>.md`, Prüfungstabelle aus `make release-report`.
   Als reiner Doku-Commit committen; der Stempel des deployten Commits bleibt dadurch gültig.
3. **Tag** auf den deployten Commit (nicht auf den Protokoll-Commit):
   `git tag -a release-<YYYY-MM-DD> <commit> -m "Release <datum>, Urteil <...>"`, zweites Release am
   selben Tag `release-<YYYY-MM-DD>-2`. Push von Tag und Protokoll nach `make prepush` (Doku → nur Secrets).
4. `AGENTS.md` der App: Abschnitt „Letztes Release“ mit Datum, Tag, Urteil, offenen Auflagen.