docs(issues): #0104 - every scheduled check is permanently red

Decision sorb. AGENTS.md makes a red pipeline the alarm, with no second channel by
design. That only works while green is the normal state, and right now none of the
three scheduled checks reach it: canonize_rotation was red for nine days,
gruppenpruefung is red daily on 20 findings of which 17 are deliberately deferred,
and stillstandspruefung aborts daily for a missing GITEA_TOKEN. The management
pipeline has failed every day since at least 2026-08-12.

canonize_rotation is the proof rather than the anecdote: it failed for nine days on
a conflict touching both TURN secrets and the client image tag, and nobody noticed,
because one more red cross among red crosses is invisible. It surfaced only because
someone looked for an unrelated reason.

The issue asks how "known and deferred" gets distinguished from "new" without the
deferred work blocking the channel, and recommends acknowledging #0053's findings
with an expiry date while fixing #0031 outright. Acceptance requires showing a
freshly introduced finding still turns the pipeline red - demonstrated, not assumed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

STATUS.md

@@ -2,9 +2,9 @@
 
 <!-- Generated by scripts/gen_status.py — do not edit. -->
 
-## Issues (63 open, 34 closed)
+## Issues (64 open, 34 closed)
 
-Verteilung: M1 17 · M2 16 · M3 4 · M4 11 · M5 15
+Verteilung: M1 18 · M2 16 · M3 4 · M4 11 · M5 15
 
 | Issue | Status | Meilenstein | Priorität | Title |
 |---|---|---|---|---|
@@ -71,6 +71,7 @@ Verteilung: M1 17 · M2 16 · M3 4 · M4 11 · M5 15
 | [0101](docs/issues/0101-threadnet-call-4-kaputtes-paket-0-19-2-threadnet-6-in-der-regi.md) | open | M4 | low | Kaputtes Paket 0.19.2-threadnet.6 in der Registry — Herkunft ungeklärt |
 | [0102](docs/issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md) | open | M1 | medium | DMARC der Plattform-Zone `axion1337.chat` steht auf p=none — und gehört IONOS, nicht uns |
 | [0103](docs/issues/0103-wiki-zugang-ohne-gruppe-endet-stumm.md) | open | M1 | medium | Wiki: Anmeldung ohne Gruppe endet stumm — `wiki-anwender` hat null Mitglieder |
+| [0104](docs/issues/0104-daueralarme-melden-nichts-mehr.md) | open | M1 | high | Alle geplanten Prüfungen sind dauerhaft rot — damit meldet keine mehr etwas |
 
 ## Active design docs (0)
 

docs/issues/0104-daueralarme-melden-nichts-mehr.md

@@ -0,0 +1,91 @@
+---
+type: issue
+id: "0104"
+status: open
+created: 2026-08-18
+milestone: M1
+priority: high
+area: infrastructure
+related:
+  - "docs/issues/0031-stillstandspruefung-gitea-token-und-authentik.md"
+  - "docs/issues/0053-historien-durchgang-nicht-kanonische-commits.md"
+---
+# 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.