Files
management/docs/issues/0104-daueralarme-melden-nichts-mehr.md
T
2026-08-18 12:00:00 +00:00

4.3 KiB
Raw Blame History

type, id, status, created, milestone, priority, area, related, gitlab_iid
type id status created milestone priority area related gitlab_iid
issue 0104 open 2026-08-18 M1 high infrastructure
docs/issues/0031-stillstandspruefung-gitea-token-und-authentik.md
docs/issues/0053-historien-durchgang-nicht-kanonische-commits.md
41

Alle geplanten Prüfungen sind dauerhaft rot — damit meldet keine mehr etwas

Aufgefallen 2026-08-18 bei der Frage nach der Produktionsreife. Der auslösende Einzelfall ist behoben; dieses Issue führt das Muster dahinter.

Befund

Die Plattform hat drei geplante Prüfungen, und ihr Alarmprinzip steht ausdrücklich in AGENTS.md: „Seine rote Pipeline ist der Alarm — es gibt bewusst keinen zweiten Meldeweg." Gemessen am 2026-08-18:

Prüfung Zeitplan Zustand Grund
canonize_rotation (gitops) täglich 05:17 war 9 Tage rot (09.18.08.) liegengebliebener Rotationszweig, behoben 14cf931/ccf0460
gruppenpruefung (management) täglich 00:42 rot, täglich 20 Befunde, davon 17 bewusst vertagt (#0053)
stillstandspruefung (management) täglich 00:42 rot, täglich GITEA_TOKEN fehlt → Abbruch (#0031)

Die management-Pipeline ist nachweislich seit mindestens dem 12.08. jeden Tag rot. Keine dieser Prüfungen kann derzeit etwas Neues melden: Rot ist ihr Normalzustand.

Warum das die schwerste Klasse ist

Der canonize_rotation-Fall ist der Beweis, nicht die Anekdote. Neun Tage lang scheiterte der Job an einem Merge-Konflikt, der ausgerechnet coturn-secret.yaml, synapse-turn-secret.yaml und element-server-suite.yaml betraf — und niemand hat es bemerkt, weil ein weiteres rotes Kreuz neben den anderen nicht auffällt. Gefunden wurde es nur, weil jemand aus einem anderen Anlass hinsah. Genau das ist die mrtc-Lehre, nur an anderer Stelle: Der Zustand war die ganze Zeit sichtbar und trotzdem unsichtbar.

Ein Alarm, der immer schrillt, ist kein Alarm. Die Regel „rote Pipeline = Alarm" funktioniert nur, solange Grün der Normalfall ist — und das ist derzeit bei keiner der drei Prüfungen so.

Zu entscheiden

Die eigentliche Frage ist, wie „bekannt und vertagt" von „neu" unterschieden wird, ohne dass Vertagtes den Kanal verstopft:

  1. Bekannte Befunde quittieren. Die Prüfungen bekommen eine gepflegte Liste akzeptierter Befunde (nach Muster von sha_ausnahmen.tsv); quittierte Befunde erscheinen weiterhin im Log, färben aber nicht rot. Rot wird, was nicht auf der Liste steht. Vorteil: Grün ist wieder erreichbar und bedeutet etwas. Risiko: eine Ausnahmeliste, die niemand aufräumt, ist die nächste Blindstelle — sie braucht ein Verfallsdatum je Eintrag.
  2. Vertagtes wegräumen statt quittieren. #0053 abarbeiten und #0031 mit Tokens versorgen, dann sind beide Prüfungen von selbst grün. Ehrlicher, aber es macht die Alarmfähigkeit von Aufräumarbeit abhängig, die bewusst niedrige Priorität hat.
  3. Beides: #0031 sofort (kleiner Aufwand, siehe dort), #0053 quittiert mit Verfallsdatum bis zum Historien-Durchgang.

Empfehlung: 3. Er stellt Grün kurzfristig her, ohne eine Entscheidung vorwegzunehmen, die zu #0053 gehört.

Acceptance

  • Alle drei geplanten Prüfungen laufen an einem gewöhnlichen Tag grün durch.
  • Ein neu eingeführter Befund färbt nachweislich rot — an einem absichtlich erzeugten Beispiel gezeigt, nicht abgeleitet.
  • Quittierte Befunde bleiben im Log sichtbar und tragen einen Grund plus ein Datum, ab dem sie wieder rot färben.
  • In AGENTS.md steht neben „die rote Pipeline ist der Alarm" die Bedingung, unter der das gilt: dass Grün der Normalzustand ist.

Bereits erledigt

canonize_rotation ist grün (2026-08-18). Zwei Befunde dabei, beide behoben und hier festgehalten, weil sie dieselbe Klasse betreffen:

  • Ein überholter Rotationszweig ließ den Job konfliktieren statt ihn zu überspringen. Die Fehlermeldung riet zum Auflösen von Hand — was das TURN-Shared-Secret hätte zurückdrehen können, womit Synapse und coturn uneins und TURN tot gewesen wäre.
  • git fetch lief ohne --prune, der Runner recycelt seinen Workspace: Nach dem Löschen des Zweigs auf beiden Remotes meldete der Job ihn weiter. Löschen wäre also gar kein Ausweg aus dem Dauer-Rot gewesen — live beobachtet an Pipeline 492.