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
2026-08-02 12:00:00 +00:00
parent 164d96dddd
commit 3fe05e7bd1
11 changed files with 120 additions and 138 deletions
@@ -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
@@ -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"
@@ -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
-  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
+- **Ausnahme** (bewusst entschieden, nur noch eine): 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** —
@@ -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
-Gitea-Mirror-Tracker, weil Hosts außerhalb des Labs `git.lab` historisch nicht
-erreichten. Seit 2026-08-01 **steht das Site-to-Site-VPN**
-([ADR-0004](decisions/0004-site-to-site-vpn-hetzner-lab.md)) — bei eingeschaltetem
-Tunnel erreicht CFGMON git.lab. Der Umzug der Übergabe-Issues und der Rückbau
-dieser Ausnahme sind Folgearbeit.
+**Keine Ausnahmen mehr.** Die **Deploy-Übergabe-Issues** liefen bis 2026-08-02 auf
+dem Gitea-Tracker, weil Hosts außerhalb des Labs `git.lab` nicht erreichten. Mit dem
+Site-to-Site-VPN ([ADR-0004](decisions/0004-site-to-site-vpn-hetzner-lab.md)) ist der
+Grund entfallen — bei eingeschaltetem Tunnel erreicht CFGMON git.lab. Sie sind
+umgezogen (LABNET-03), der Gitea-Tracker ist leer, die Vorlage liegt als
+GitLab-Issue-Template. **Alle Issues leben auf git.lab.**

 ## Struktur

@@ -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
-  von `sorb/management`, weil CFGMON git.lab (noch) nicht erreicht. Diese
-  Ausnahme wird durch das Site-to-Site-VPN (ADR-0004) abgelöst — sie war der
-  Auslöser für die ADR-Pflicht bei Ausnahmen (siehe `decisions/README.md`).
+- ~~**Befristete Ausnahme:** Deploy-Übergabe-Issues laufen auf dem Gitea-Tracker
+  von `sorb/management`, weil CFGMON git.lab (noch) nicht erreicht.~~
+  ✅ **Zurückgebaut am 2026-08-02** (LABNET-03, [#13](https://git.lab/axion1337.chat/management/-/issues/13)):
+  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
@@ -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
-  in einem Folge-Issue zurückgebaut.
+- ✅ **Eingelöst am 2026-08-02 (LABNET-03, [#13](https://git.lab/axion1337.chat/management/-/issues/13)):**
+  Ü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
@@ -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
-Ausnahme für Deploy-Übergabe-Issues, siehe
-[LABNET-03](https://git.lab/axion1337.chat/management/-/issues/13).
+die Aufzählung „Noch auf Gitea" gilt nicht mehr. Die zunächst verbliebene Ausnahme
+für Deploy-Übergabe-Issues ist am 2026-08-02 mit LABNET-03 ebenfalls zurückgebaut.

 ---

@@ -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
-([ADR-0002](../decisions/0002-issues-und-management-ins-lab.md)); einzige Ausnahme
-sind die Deploy-Übergabe-Issues auf dem Gitea-Tracker `sorb/management`, bis
-[LABNET-03](https://git.lab/axion1337.chat/management/-/issues/13) sie nachholt.
+**Issues nicht mehr** — die sind am 2026-08-01/02 nach git.lab gewandert
+([ADR-0002](../decisions/0002-issues-und-management-ins-lab.md)). Die letzte Ausnahme,
+die Deploy-Übergabe-Issues auf dem Gitea-Tracker `sorb/management`, ist am 2026-08-02
+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,
@@ -9,8 +9,9 @@

 ### Betrieb & Sicherheit (axion1337.chat-Stack)

-1. **CVE-Meldeweg v2 live** — aggregierte Alarme deployen (Übergabe-Issue auf
-   dem Gitea-management-Tracker), Grafana-CVE-Dashboard, Security-Raum-Widget
+1. **CVE-Meldeweg v2 live** — aggregierte Alarme deployen
+   ([Ü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)**
-   — Übergabe-Issues ins Lab, Gitea-Ausnahme zurückbauen.
+   zwei AARs). Ernte daraus: ✅ **LABNET-03 (#13)** — Übergabe-Issues sind am
+   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).
@@ -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
-Issues in diesem Repo als **Deploy-Übergabe**.
+`.gitlab/issue_templates/Deploy-Übergabe.md` und erscheint beim Anlegen eines
+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
@@ -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**
-   (`.gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml`).
+1. Wer baut, öffnet **auf git.lab** ein Issue aus der Vorlage **Deploy-Übergabe**
+   (`.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