[Fluory]

Warum

Fixes #110

Arbeitsstand

• Ziel: Ein externer Check ruft /api/health der Showcase regelmäßig auf und alarmiert bei Ausfall.
• Nicht-Ziele: Monitoring der Kundenumgebung, Fehlerraten-Alarme aus Log-Aggregation.
• Erledigt: Workflow uptime.yml, Doku in operations.md, CHANGELOG.
• Offen: Alarmtest (Test-Plan des Issues) nach Merge, weil Schedule/Dispatch erst auf main laufen; Benachrichtigungseinstellungen des Owners prüfen.
• Annahmen: Alarm = GitHub-Benachrichtigung über fehlgeschlagene Workflows an den Repo-Owner (Rolle Orchestrator); aiService: starting ist kein Fehler.
• Nächster kleinster Schritt: Review; nach Merge den Workflow einmal manuell starten und den Alarm mit falscher SHOWCASE_URL testen.

Was ist passiert (Klartext)

Bisher schaute niemand auf den Gesundheits-Endpunkt der Showcase. Jetzt ruft ein geplanter GitHub-Workflow ihn alle 15 Minuten von außen auf. Antwortet die Seite nicht, mit einem Fehlercode oder mit einem Status ungleich „ok“, wird der Lauf rot und GitHub benachrichtigt den Repo-Owner. In der Zusammenfassung jedes Laufs stehen die wichtigsten Zahlen: Datenbank, Speicher, KI-Dienst und wartende Aufträge. Der Zustand „KI-Dienst startet“ (Kaltstart) löst bewusst keinen Alarm aus. Die Doku sagt, wer alarmiert wird und was dann zu tun ist.

Plan-Pflicht (SYSTEM.md §4)

• Kein Auslöser – keine Modulgrenze, öffentliche API, Migration, Auth/Rechte, kein Zahlungs-/Daten-/Infrapfad, höchstens zwei Module, keine Architekturvarianten, umkehrbar
• Auslöser zutreffend – Impact Manifest ausgefüllt (Plan vor Code)

Geändert

• .github/workflows/uptime.yml: neuer Cron-Workflow (15 min + manuell), contents: read, 20 s Timeout, 2 Retries, curl + jq, Kennzahlen im Job-Summary.
• docs/technical/operations.md: Abschnitt „Uptime monitor (showcase)“ (Monitor, Intervall, Empfänger-Rolle, Vorgehen bei Alarm, Link zu Frequent failures).
• CHANGELOG.md: Eintrag unter Unreleased.

Nachweis (SYSTEM.md §11)

• verify: grün – CI check Run 38006615607 am PR-Kopf b173c05 (nur Workflow + Doku, keine Code-Änderung); Workflow-Skript lokal gegen die Live-URL: OK-Fall Exit 0, falscher Pfad 404 → Exit 1. Die Gesundheits-Tests (kein Leck von Verbindungsdetails) sind unberührt.
• verify:full / E2E-Spec: nicht betroffen
• Manueller Prüfnachweis: Das Skript aus dem Workflow-Schritt lokal gegen https://requestflow-doc-edit.vercel.app/api/health ausgeführt (jq 1.7.1) → Exit 0, Tabelle: status ok, database ok, storage ok, aiService ok, request-process 0, request-export 0. Negativfall (falscher Pfad) → HTTP 404, ::error::, Exit 1. YAML mit PyYAML geparst (gültig). actionlint nicht verfügbar. Der Workflow selbst lief noch nicht auf GitHub (Schedule/Dispatch erst auf main); der echte Alarmtest steht aus.
• Frischer Review: noch offen

Doku-Entscheidung (genau eine)

• Keine langlebige Doku betroffen – Begründung: <…>
• Doku betroffen und im selben PR aktualisiert:
  • Produktdoku (P0: README): -
  • Technische Doku: docs/technical/operations.md
  • Architekturkarte: -
  • ADR: -
  • CHANGELOG [Unreleased] (sichtbares Feature oder Verhalten – im selben PR, nie „später")

Entferntes oder Umbenanntes: nichts entfernt

Dateigrößen und neue Bausteine (SYSTEM.md §7)

Dateien über 500 Zeilen im Diff:

• keine

Über 800 Zeilen mit neuer Fachlogik oder über 1000 Zeilen (P1/P2): nicht betroffen

Neue Shared-Komponente, Utility-Datei, Adapter oder fachlicher Service:

• nein

Subagent-Einsätze

Keine

Risiken / offene Punkte

• Alarmempfang hängt an den GitHub-Benachrichtigungseinstellungen des Owners (keine Adresse im Repo).
• GitHub kann geplante Läufe verzögern oder bei 60 Tagen Repo-Inaktivität pausieren.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
requestflow	Ready	Preview	Oct 10, 2026 11:29am UTC
requestflow-ai	Error		Oct 10, 2026 11:29am UTC