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

.gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml

@@ -1,107 +0,0 @@
-name: "Deploy-Übergabe"
-about: "Ein gebauter, noch nicht ausgerollter Stand wird zum Deploy übergeben"
-title: "[DEPLOY] "
-body:
-  - type: markdown
-    attributes:
-      value: |
-        Für die Übergabe „ich habe gebaut — du rollst aus".
-        Ausführlich: [verfahren/deploy-uebergabe.md](../src/branch/main/verfahren/deploy-uebergabe.md)
-
-        Die Felder sind die Punkte, an denen Übergaben real schiefgegangen sind.
-        Wo nichts zutrifft, `-` eintragen statt das Feld zu löschen.
-
-  - type: input
-    id: stand
-    attributes:
-      label: Stand
-      description: Repo, Branch und Commit, der ausgerollt werden soll
-      placeholder: "sorb/threadnet-operating @ main, b6007c5"
-    validations:
-      required: true
-
-  - type: dropdown
-    id: testtiefe
-    attributes:
-      label: Testtiefe
-      description: Ehrlich einordnen — „ungetestet" ist eine brauchbare Angabe, „läuft" ohne Beleg nicht
-      options:
-        - "ungetestet — nur gelintet / statisch geprüft"
-        - "teilweise getestet — Details unten"
-        - "getestet gegen echte Daten"
-    validations:
-      required: true
-
-  - type: textarea
-    id: mengengeruest
-    attributes:
-      label: Mengengerüst
-      description: |
-        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.
-      placeholder: |
-        Alarme: ~1 pro CVE pro Image. An 3 von 29 Images gemessen: 27 CRITICAL / 126 HIGH.
-        Zeitreihen: ~2000. Matrix-Nachrichten: 1 pro Alarm.
-    validations:
-      required: true
-
-  - type: textarea
-    id: kommando
-    attributes:
-      label: Vollständiges Deploy-Kommando
-      description: |
-        Inklusive aller Reload-, Restart- und Recreate-Schritte.
-        Ein `up -d`, das „Running" meldet und nichts tut, ist der häufigste stille Fehlschlag.
-      render: bash
-      placeholder: |
-        cd /opt/<repo> && git pull
-        cd <stack> && docker compose up -d
-        docker compose up -d --force-recreate <dienste-mit-geaenderter-config>
-    validations:
-      required: true
-
-  - type: textarea
-    id: verifikation
-    attributes:
-      label: Woran erkennt man, dass es wirklich greift
-      description: |
-        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.
-      render: bash
-      placeholder: |
-        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
-    validations:
-      required: true
-
-  - type: textarea
-    id: aussenwirkung
-    attributes:
-      label: Außenwirkung und Not-Aus
-      description: |
-        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.
-      placeholder: |
-        Kanal: Matrix-Raum „Security" über Label room=security.
-        Stumm: in alertmanager.yml route room="security" -> receiver "null".
-    validations:
-      required: true
-
-  - type: textarea
-    id: rollback
-    attributes:
-      label: Rollback
-      description: Was tun, wenn es schiefgeht — und was davon ist *nicht* zurückholbar (gesendete Nachrichten, externe Writes)?
-    validations:
-      required: true
-
-  - type: textarea
-    id: offen
-    attributes:
-      label: Bewusst offen gelassen
-      description: Bekannte Lücken, Nebenfunde, Abgrenzungen. Verhindert, dass die Gegenseite Zeit mit Nachweisen von etwas verbringt, das schon bekannt ist.
-    validations:
-      required: false

.gitlab/issue_templates/Deploy-Übergabe.md

@@ -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"

CLAUDE.md

@@ -45,10 +45,7 @@ Widerspruch gilt für Arbeitsweise und Prozess **diese** Datei.
   verweisen dorthin. ⚠️ gitops-Nummern haben sich beim Umzug verschoben
   (Gitea zählte PRs mit; z. B. Gitea#48 → GitLab#46) — alte „gitops#N"-Verweise
   meinen die Gitea-Nummer; verbindlich ist der Migrations-Fußtext im Issue.
-- **Ausnahmen** (beide bewusst entschieden): Deploy-Übergabe-Issues laufen auf
+- **Ausnahme** (bewusst entschieden, nur noch eine): der
-  dem Gitea-Tracker `sorb/management`, bis [LABNET-03](https://git.lab/axion1337.chat/management/-/issues/13)
-  sie umzieht (das VPN dafür steht seit 2026-08-01,
-  [ADR-0004](decisions/0004-site-to-site-vpn-hetzner-lab.md)); der
   TURN-Rotations-CronJob schreibt weiter nach Gitea, weil er im Cluster läuft und
   git.lab nicht erreicht.
   **Die Rotation nicht von Hand nachziehen und den PR nie auf Gitea mergen** —

README.md

@@ -19,12 +19,12 @@ pushen** — solche Commits gehen beim nächsten Mirror-Lauf verloren (Rettung:
 `.patch` von Gitea ziehen + `git am`, siehe
 [Kanonisierung](verfahren/deploy-uebergabe.md)).
 
-**Eine auslaufende Ausnahme:** Die **Deploy-Übergabe-Issues** laufen noch auf dem
+**Keine Ausnahmen mehr.** Die **Deploy-Übergabe-Issues** liefen bis 2026-08-02 auf
-Gitea-Mirror-Tracker, weil Hosts außerhalb des Labs `git.lab` historisch nicht
+dem Gitea-Tracker, weil Hosts außerhalb des Labs `git.lab` nicht erreichten. Mit dem
-erreichten. Seit 2026-08-01 **steht das Site-to-Site-VPN**
+Site-to-Site-VPN ([ADR-0004](decisions/0004-site-to-site-vpn-hetzner-lab.md)) ist der
-([ADR-0004](decisions/0004-site-to-site-vpn-hetzner-lab.md)) — bei eingeschaltetem
+Grund entfallen — bei eingeschaltetem Tunnel erreicht CFGMON git.lab. Sie sind
-Tunnel erreicht CFGMON git.lab. Der Umzug der Übergabe-Issues und der Rückbau
+umgezogen (LABNET-03), der Gitea-Tracker ist leer, die Vorlage liegt als
-dieser Ausnahme sind Folgearbeit.
+GitLab-Issue-Template. **Alle Issues leben auf git.lab.**
 
 ## Struktur
 

decisions/0002-issues-und-management-ins-lab.md

@@ -18,10 +18,16 @@ Verweis); das Backlogs-Repo zieht als `axion1337.chat/management` ins Lab
 
 - ⚠️ gitops-Issue-Nummern haben sich verschoben (Gitea zählte PRs mit); die
   verbindliche Zuordnung steht im Migrations-Fußtext jedes GitLab-Issues.
-- **Befristete Ausnahme:** Deploy-Übergabe-Issues laufen auf dem Gitea-Tracker
+- ~~**Befristete Ausnahme:** Deploy-Übergabe-Issues laufen auf dem Gitea-Tracker
-  von `sorb/management`, weil CFGMON git.lab (noch) nicht erreicht. Diese
+  von `sorb/management`, weil CFGMON git.lab (noch) nicht erreicht.~~
-  Ausnahme wird durch das Site-to-Site-VPN (ADR-0004) abgelöst — sie war der
+  ✅ **Zurückgebaut am 2026-08-02** (LABNET-03, [#13](https://git.lab/axion1337.chat/management/-/issues/13)):
-  Auslöser für die ADR-Pflicht bei Ausnahmen (siehe `decisions/README.md`).
+  Das Site-to-Site-VPN (ADR-0004) hat den Grund beseitigt; beide Übergabe-Issues
+  sind nach git.lab gewandert ([#25](https://git.lab/axion1337.chat/management/-/issues/25),
+  [#26](https://git.lab/axion1337.chat/management/-/issues/26)), der Gitea-Tracker ist
+  leer, die Vorlage liegt als `.gitlab/issue_templates/`. **Damit gilt diese ADR
+  ohne Ausnahme.** Die Ausnahme war seinerzeit der Auslöser für die ADR-Pflicht bei
+  Ausnahmen (siehe `README.md`) — dass sie befristet war und die Frist gehalten hat,
+  ist der Beleg, dass die Regel trägt.
 - Releases bleiben auf Gitea (öffentlicher Download-Pfad), ebenso das gitops-Wiki.
 
 ## Verworfene Alternativen

decisions/0004-site-to-site-vpn-hetzner-lab.md

@@ -33,8 +33,12 @@ Client". Die Richtung wurde deshalb gedreht:
 
 ## Konsequenzen
 
-- Übergabe-Issues können jetzt nach git.lab umziehen; die Ausnahme aus ADR-0002 wird
+- ✅ **Eingelöst am 2026-08-02 (LABNET-03, [#13](https://git.lab/axion1337.chat/management/-/issues/13)):**
-  in einem Folge-Issue zurückgebaut.
+  Übergabe-Issues können nicht nur umziehen — sie sind umgezogen
+  ([#25](https://git.lab/axion1337.chat/management/-/issues/25),
+  [#26](https://git.lab/axion1337.chat/management/-/issues/26)), der Gitea-Tracker ist
+  leer, die Vorlage liegt als GitLab-Issue-Template, und die Ausnahme aus ADR-0002 ist
+  zurückgebaut. Damit hat dieser Tunnel seinen ersten inhaltlichen Zweck erfüllt.
 - Abschaltung wirkt in **unter 4 s**, Rückkehr nach dem Einschalten in **~8 s** ohne
   Eingriff auf der Hetzner-Seite (gemessen 2026-08-01 23:21–23:23).
 - Ein kompromittierter Hetzner-Host sieht bei offenem Tunnel nur git.lab:443 und den

hosts/cfgmon.md

@@ -178,9 +178,8 @@ neuen Absender bauen.
 ✅ **Umgesetzt am 2026-08-01/02**: Die Migration ist durch — 62 Issues liegen auf
 git.lab, die Gitea-Issues sind geschlossen und tragen einen Migrations-Fußtext.
 Alles darunter ist der **Stand vor dem Umzug** und bleibt als Historie stehen;
-die Aufzählung „Noch auf Gitea" gilt nicht mehr. Bestehen blieb allein die
+die Aufzählung „Noch auf Gitea" gilt nicht mehr. Die zunächst verbliebene Ausnahme
-Ausnahme für Deploy-Übergabe-Issues, siehe
+für Deploy-Übergabe-Issues ist am 2026-08-02 mit LABNET-03 ebenfalls zurückgebaut.
-[LABNET-03](https://git.lab/axion1337.chat/management/-/issues/13).
 
 ---
 

hosts/overmind.md

@@ -30,10 +30,11 @@ threadnet-operating, axion1337.chat-gitops) **und `management`, also dieses Repo
 Push-Mirrors nach rohana/Gitea, direkte Gitea-Pushes tabu.
 
 Gitea bleibt: Flux-Source (via Mirror beliefert), Registry, Packages.
-**Issues nicht mehr** — die sind am 2026-08-01-02 nach git.lab gewandert
+**Issues nicht mehr** — die sind am 2026-08-01/02 nach git.lab gewandert
-([ADR-0002](../decisions/0002-issues-und-management-ins-lab.md)); einzige Ausnahme
+([ADR-0002](../decisions/0002-issues-und-management-ins-lab.md)). Die letzte Ausnahme,
-sind die Deploy-Übergabe-Issues auf dem Gitea-Tracker `sorb/management`, bis
+die Deploy-Übergabe-Issues auf dem Gitea-Tracker `sorb/management`, ist am 2026-08-02
-[LABNET-03](https://git.lab/axion1337.chat/management/-/issues/13) sie nachholt.
+mit LABNET-03 zurückgebaut: beide umgezogen (#25, #26), der Tracker ist leer.
+**Ohne Ausnahme: Issues leben auf git.lab.**
 
 *(Bis 2026-08-01 stand hier „Backlogs (dieses Repo, ungespiegelt)" — das Repo heißt
 seit der Umwidmung zum Management-Repo `management` und wird seither gespiegelt,

roadmap.md

@@ -9,8 +9,9 @@
 
 ### Betrieb & Sicherheit (axion1337.chat-Stack)
 
-1. **CVE-Meldeweg v2 live** — aggregierte Alarme deployen (Übergabe-Issue auf
+1. **CVE-Meldeweg v2 live** — aggregierte Alarme deployen
-   dem Gitea-management-Tracker), Grafana-CVE-Dashboard, Security-Raum-Widget
+   ([Übergabe-Issue #25](https://git.lab/axion1337.chat/management/-/issues/25)),
+   Grafana-CVE-Dashboard, Security-Raum-Widget
    (Follow-up-Wunsch sorb). [gitops#45](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/issues/45),
    [#49](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/issues/49)
 2. **Zertifikats-Risiko entschärfen** vor Ende September —
@@ -23,8 +24,8 @@
 
 1. ✅ **Site-to-Site-VPN** Hetzner ↔ Lab — erledigt 2026-08-01
    ([#12](https://git.lab/axion1337.chat/management/-/issues/12), ADR-0004 akzeptiert,
-   zwei AARs). Ernte daraus: **[LABNET-03 (#13)](https://git.lab/axion1337.chat/management/-/issues/13)**
+   zwei AARs). Ernte daraus: ✅ **LABNET-03 (#13)** — Übergabe-Issues sind am
-   — Übergabe-Issues ins Lab, Gitea-Ausnahme zurückbauen.
+   2026-08-02 ins Lab gewandert, die Gitea-Ausnahme ist zurückgebaut.
 2. GAME-01-Erreichbarkeit + vSwitch-Aufnahme —
    [#2](https://git.lab/axion1337.chat/management/-/issues/2) (Silences bis 2026-08-04!)
 3. Roadmap-/Board-Ausbau in GitLab (Rest von gitops#46: Milestones, Boards).

verfahren/README.md

@@ -10,8 +10,9 @@ nicht an einem einzelnen Projekt-Repo hängen.
 | [aar/](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
+`.gitlab/issue_templates/Deploy-Übergabe.md` und erscheint beim Anlegen eines
-Issues in diesem Repo als **Deploy-Übergabe**.
+Issues in diesem Repo im Auswahlfeld *Description template* 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

verfahren/deploy-uebergabe.md

@@ -8,8 +8,8 @@ Eingeführt am 2026-08-01 nach dem Deploy der CVE-Pipeline (`gitops#47`), siehe
 
 ## Ablauf
 
-1. Wer baut, öffnet ein Issue aus der Vorlage **Deploy-Übergabe**
+1. Wer baut, öffnet **auf git.lab** ein Issue aus der Vorlage **Deploy-Übergabe**
-   (`.gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml`).
+   (`.gitlab/issue_templates/Deploy-Übergabe.md`, im Feld *Description template*).
 2. Wer ausrollt, arbeitet die Prüfliste unten ab und deployt.
 3. Wer ausrollt, hängt den **AAR** als Kommentar an dasselbe Issue
    (Vorlage: [aar-vorlage.md](aar-vorlage.md)). Bei Befunden ab MEDIUM