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