LABNET-03: Uebergabe-Issues nach git.lab, Gitea-Ausnahme zurueckgebaut

Die letzte Ausnahme von ADR-0002 ist erledigt. Sie bestand, weil CFGMON git.lab
nicht erreichte; mit dem Site-to-Site-Tunnel (ADR-0004) ist der Grund weg.

Umgezogen mit dem Werkzeug der ersten Migration (verfahren/issue-migration/
migrate.py), damit derselbe Fusstext und dieselbe Idempotenz gelten:
- sorb/management#1 (offen)      -> management#25
- sorb/management#2 (geschlossen) -> management#26, mit allen 11 Kommentaren

Original-Autor und -Zeitstempel sind erhalten (der Admin-Token darf created_at
setzen); die Gitea-Issues sind geschlossen und verweisen auf ihr Gegenstueck.
Der Gitea-Tracker ist damit leer.

Issue-Vorlage konvertiert statt kopiert: Gitea nutzt YAML-Issue-Forms, GitLab
Markdown-Templates. Die Feld-Begruendungen - der eigentliche Wert der Vorlage,
weil jedes Feld fuer eine real schiefgegangene Uebergabe steht - sind als
Kommentare erhalten. .gitea/ ist entfernt, damit dort keine neuen Uebergaben
mehr angelegt werden koennen.

Nachgezogen: README, roadmap, CLAUDE.md, ADR-0002 (Ausnahme durchgestrichen +
als zurueckgebaut markiert), ADR-0004 (Ernte eingeloest), hosts/overmind.md,
hosts/cfgmon.md, verfahren/README.md, verfahren/deploy-uebergabe.md.
55 relative Links geprueft, keiner tot.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
This commit is contained in:
Thore Cimbal
2026-08-02 12:00:00 +00:00
co-authored by Claude Fable 5
parent 164d96dddd
commit 3fe05e7bd1
11 changed files with 120 additions and 138 deletions
@@ -0,0 +1,80 @@
<!--
Für die Übergabe „ich habe gebaut — du rollst aus".
Ausführlich: verfahren/deploy-uebergabe.md
Die Felder sind die Punkte, an denen Übergaben real schiefgegangen sind.
Wo nichts zutrifft, `-` eintragen statt den Abschnitt zu löschen.
Titel bitte mit [DEPLOY] beginnen.
-->
## Stand
<!-- Repo, Branch und Commit, der ausgerollt werden soll.
Beispiel: axion1337.chat/threadnet-operating @ main, b6007c5 -->
## Testtiefe
<!-- Ehrlich einordnen — „ungetestet" ist eine brauchbare Angabe,
„läuft" ohne Beleg nicht. Zutreffendes ankreuzen: -->
- [ ] ungetestet — nur gelintet / statisch geprüft
- [ ] teilweise getestet — Details unten
- [ ] getestet gegen echte Daten
## Mengengerüst
<!-- Wenn der Stand irgendetwas erzeugt (Nachrichten, Alarme, Zeitreihen, Dateien,
Requests): Wie viel davon beim ersten Lauf? Geschätzt oder gemessen — bitte
dazuschreiben, was von beidem.
Genau hier entstehen die Überraschungen: „ein Alarm pro Fund" ist harmlos bei
5 Funden und ein Ausfall bei 126.
Beispiel:
Alarme: ~1 pro CVE pro Image. An 3 von 29 Images gemessen: 27 CRITICAL / 126 HIGH.
Zeitreihen: ~2000. Matrix-Nachrichten: 1 pro Alarm. -->
## Vollständiges Deploy-Kommando
<!-- Inklusive aller Reload-, Restart- und Recreate-Schritte. Ein `up -d`, das
„Running" meldet und nichts tut, ist der häufigste stille Fehlschlag. -->
```bash
```
## Woran erkennt man, dass es wirklich greift
<!-- Konkrete Prüfung dort, wo der Dienst liest — im Container, in der API, in der
laufenden Config. Ein grüner Linter belegt, dass die Datei gültig ist, nicht
dass sie geladen wurde.
Beispiel:
docker exec prometheus grep -c axion-cve /etc/prometheus/alerts.yml # erwartet: 1
curl -s localhost:9090/api/v1/rules | grep -c axion-cve # erwartet: >0 -->
```bash
```
## Außenwirkung und Not-Aus
<!-- Was verlässt beim ersten Lauf das System — Matrix-Räume, Mails, Webhooks,
fremde APIs? Und wie schaltet man NUR diesen Kanal stumm, ohne den ganzen
Deploy zu verschieben?
Datensammlung und Zustellung getrennt scharf zu schalten ist fast immer
möglich und macht aus einer Blockade einen normalen Deploy. -->
## Rollback
<!-- Was tun, wenn es schiefgeht — und was davon ist *nicht* zurückholbar
(gesendete Nachrichten, externe Writes)? -->
## Bewusst offen gelassen
<!-- Bekannte Lücken, Nebenfunde, Abgrenzungen. Verhindert, dass die Gegenseite
Zeit mit dem Nachweis von etwas verbringt, das schon bekannt ist. -->
/label ~"area:infrastructure"