# AAR — <Vorhaben> <Issue-Referenz>

**Datum:** JJJJ-MM-TT · **Host/Stack:** … · **Auftrag:** …

## 1. Ergebnis

Was ist live und verifiziert. Was ist bewusst **nicht** live, und warum.
Diese Trennung steht ganz oben — sie ist die einzige Angabe, die jemand
braucht, der nur eine Zeile liest.

## 2. Befunde

| # | Befund | Schwere | Status |
|---|---|---|---|
| 1 | … | HIGH / MEDIUM / LOW | abgefangen / behoben / notiert · Issue |

Schwere nach Auswirkung, nicht nach Aufwand. Zu jedem Befund gehört, **wie er
sichtbar wurde** — falls das nicht offensichtlich ist, siehe Abschnitt 4.

## 3. Verdachtsfälle mit Entwarnung

Was geprüft und **nicht** bestätigt wurde, mit dem Messwert. Genauso wichtig
wie die Befunde: verhindert, dass dieselbe Vermutung beim nächsten Mal erneut
Zeit kostet.

## 4. Was die Befunde ermöglicht hat

Die Methode, nicht die Chronologie. Wenn ein Befund nur durch eine bestimmte
Prüfung sichtbar wurde, gehört genau die hierher — das ist der Teil, der beim
nächsten Deploy wiederverwendbar ist.

## 5. Offen

Was bleibt, wer entscheidet, was blockiert. Mit Issue-Referenz statt
wiederholtem Inhalt.

---

Regeln:

- Nicht verifizierte Aussagen als solche kennzeichnen — eine Vermutung, die wie
  ein Befund aussieht, kostet später mehr Zeit als sie spart (Konvention aus
  der [README](../README.md)).
- Zahlen statt Adjektive. „Viele Alarme" ist keine Angabe, „126 CRITICAL" ist eine.
- Kurz. Ein AAR, der nicht gelesen wird, hat keinen Wert.