TLS-Gate: Monitor für offene Buchungen (offered)

Von: Branko → OZMAI, Crew
Stand: 11. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3, keine automatische Geltung, kein Brain-Status)
Charakter: NACHTRAG. Ersetzt eine Aussage in 2026-10-10_TLS-GATE-USER-TEST-AKTIVIEREN-… §1: „MonitorExport kennt heute nur Zertifikate, keine Buchungen“ → kennt jetzt offene Buchungen. Bezug: Brankos Vorgabe vom 10.10., der bewusst offene Prozess (offered bis zur Aktivierung) gehört in den Monitor.
Quelle: Repo TLS-Gate-Mock-Pipeline, main b23baa4, ohne eigenen Tag (nach v3.13.0 = 00bad35).
Belege: lokal 36 von 36 Suiten grün, neu tests/test_open_bookings.sh (26). VM nach docker_vm/build.sh aus b23baa4 (dirty=0): run 91, p3 48, p4 54, p5 31, p6 22, p7 53 (+3). Monitor-Seite im Browser mit einem Demo-Export angesehen, Konsole ohne Fehler.

Legende: ✅ real/gebaut · 🧪 gebaut, getestet, nicht live · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN

Keine Zugangsdaten, keine Kunden-Domains, keine Ausgaben aus echten Läufen. Demo-Konten synthetisch (*.test).

1. Was gebaut ist

  • 🧪 Eine Abfrage, drei Wege nach draußen (Bookings::open): Alle Buchungen im Zustand offered, die älteste zuerst. Je Buchung: Gruppe, Konto als user_id + Rolle, Produkt, Kategorie, Grundprodukt (parent), offen seit (since, days), waiting_on: inhaber.
  • 🧪 Sackgasse sichtbar: freigabe_aktiv oder produkt_aktiv ist false. Der Inhaber sieht die Buchung, kann sie aber nicht sinnvoll nutzen, weil die Quelle abgeschaltet ist. Der Monitor sagt das ausdrücklich, statt nur „offen“ zu zeigen.
  • 🧪 Monitor-Export (bin/export.php): neues Feld open_bookings im Vertrag tlsgate.monitor. Es ist ein Zusatzfeld, die Version bleibt 1. Meldung und Audit cli.export nennen die Anzahl.
  • 🧪 Monitor-Seite (sample.html?data=…): Tabelle „Offene Buchungen (offered)“. Unter 1 Tag türkis, ab 1 Tag gelb, ab 7 Tagen rot, Sackgasse rot. Ein alter Export ohne das Feld wird als solcher benannt. Die Seite behauptet dann nicht „keine offenen Buchungen“.
  • 🧪 Bash: booking_cli.php open [<gruppe>] [--older-than <tage>] [--json], auch in der VM über instance-cli.sh. Der Text zeigt die E-Mail (Operator, nur root/sudo). --json hat dieselbe Form wie der Export, ohne E-Mail, und lässt sich weiterreichen.

2. Festlegungen (Annahmen des Entwicklers, nicht von der Crew bestätigt)

Festlegung Grund
Was die Gruppe verlässt (Export, --json), trägt keine E-Mail, Systemakte, Anker, Preis oder Schätzung Datenschutz; die Systemakte sieht ohnehin nur der Inhaber
„offen seit“ = Anlage der Buchung (created_at), nicht available_from der Freigabe Gemessen wird das Warten auf den Inhaber
Farbschwellen 1 und 7 Tage Anzeige, keine Regel. Kein Alarm
Vertrag bleibt Version 1 Das Feld kommt nur dazu, alte Leser ignorieren es

3. Was NICHT belegt bzw. nicht gebaut ist

  • 🧪 Auf MariaDB lief die Abfrage in p7 gegen null offene Buchungen (ozm01). Einmal von Hand auf ozm03 mit echten Daten geprüft: Eine Buchung wurde kurz auf offered gesetzt, Text und JSON stimmten, danach wurde sie wieder auf active gesetzt. Das PHP-Fehlerlog blieb leer.
  • ⬜ Kein Alarm, keine Benachrichtigung der Crew, kein Cron, der den Export regelmäßig schreibt.
  • ⬜ In der VM gibt es export.php und die Monitor-Seite nicht (Spiegel native_php ohne MonitorExport). Dort gibt es nur booking_cli.php open.
  • ❓ Ob „offen seit“ mit dem Anlegen oder erst mit available_from (30-Minuten-Regel) beginnen soll, entscheidet die Crew.

4. Einordnung als Prüffall (Branko, nicht OZMAI-Geltung)

Ein offener Zustand ist kein Fehler. Er wird aber erst dann zur Aussage, wenn jemand ihn sieht. Der Monitor zeigt offered als Selbstmeldung der DB zu einem Zeitpunkt (generated_at, lokale Uhr), nicht als Beobachtung, dass der Inhaber nicht will. „Wartet auf den Inhaber“ beschreibt den Prozess, nicht die Person.