Nach dem Deploy der CVE-Pipeline (gitops#47) als Verfahren festgehalten. Der Stand war korrekt und gelintet; der Blocker entstand erst aus der Datenmenge, gegen die er lief -- eine Alarm-Instanz pro CVE, real 126 CRITICAL und 1222 HIGH. So etwas faellt in keinem Diff auf, nur beim Messen vor dem Deploy. Neu: - .gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml -- Uebergabe-Issue mit Pflichtfeldern Mengengeruest, vollstaendiges Deploy-Kommando, Verifikation im laufenden Dienst, Aussenwirkung samt Not-Aus, Rollback - verfahren/deploy-uebergabe.md -- Ablauf und Pruefliste - verfahren/aar-vorlage.md -- AAR-Vorlage - verfahren/aar/2026-08-01-cve-pipeline-gitops47.md -- der ausloesende AAR Abgrenzung im README ergaenzt: hosts/ und shared/ halten offene Punkte, verfahren/ haelt, wie wir arbeiten. Die Uebergabe-Issues laufen bewusst hier statt im Projekt-Repo, weil das Verfahren repo-uebergreifend gilt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Verfahren
Wiederkehrende Abläufe zwischen Personen und Hosts — dort festgehalten, wo sie nicht an einem einzelnen Projekt-Repo hängen.
| Datei | Inhalt |
|---|---|
| deploy-uebergabe.md | Ablauf und Prüfliste für „einer baut, ein anderer rollt aus" |
| aar-vorlage.md | Vorlage für den After Action Report nach einem Deploy |
| aar/ | Abgelegte AARs, benannt JJJJ-MM-TT-<vorhaben>.md |
Die zugehörige Issue-Vorlage liegt unter
.gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml und erscheint beim Anlegen eines
Issues in diesem Repo als Deploy-Übergabe.
Abgrenzung zum Rest des Repos: hosts/ und shared/ halten offene Punkte,
dieses Verzeichnis hält wie wir arbeiten. Ein Verfahren wird hier nur
aufgenommen, wenn es mindestens einmal an einem echten Vorfall gescheitert
oder bewährt ist — der auslösende AAR wird jeweils verlinkt.