Schnittstellen, API & Automationen › Konsistenz-Prüfung (Cron)
Konsistenz-Prüfung (Cron)
AutomationTeilweise✓ Geprüft am Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)Prüft die Datenbank automatisch auf Widersprüche (z.B. Aufträge in unmöglichen Zuständen) und meldet sie.
Bild folgt
Der Lauf prüft die Datenbank gegen zehn feste Regeln — etwa einen Auftrag ohne Kunde oder Fahrzeug, zwei Aufträge gleichzeitig auf derselben Bühne, einen als bezahlt markierten Auftrag ohne Zahlungseintrag, einen abgerechneten Auftrag, der nie freigegeben wurde, oder eine Lücke in der fortlaufenden Belegnummernkette. Jeder Treffer wird als Befund festgehalten und erscheint in der Störungsliste. Läuft die Prüfung zeitgesteuert, schreibt sie die Befunde dauerhaft weg; von Hand über die Oberfläche ausgelöst, liefert sie dieselben Ergebnisse nur zur Ansicht, ohne die Störungsliste mit Wiederholungen zu füllen. Der Lauf antwortet dabei bewusst immer normal, selbst wenn er Widersprüche findet — nur wenn ein gefundener Befund gar nicht gespeichert werden konnte, meldet er einen echten Fehler, weil sonst ein stiller Ausfall der Überwachung selbst unbemerkt bliebe.
- Nie Befunde, obwohl bekannte Widersprüche existieren → prüfen, ob die Prüfung überhaupt zeitgesteuert läuft; ein früherer Betriebs-Check fand sie ganz ohne aktiven Zeitplan, nur von Hand auslösbar.
Liest
Geregelt durch
- Ist der tägliche Zeitplan (3:45 Uhr laut Deploy-Plan) inzwischen wirklich aktiv, oder läuft die Prüfung weiterhin nur von Hand?
- app/api/cron/konsistenz-check/route.ts
- lib/messung/konsistenz.ts
- docs/SERVER-DEPLOY-PROMPT.md
| zeitplan | geplant täglich um 3:45 Uhr (Bearer-Auth), laut Audit vom 2026-08-24 aber nicht zuverlässig aktiv — nur von Hand über die Oberfläche ausgelöst |
|---|---|
| ausloeser | zehn feste Prüfregeln gegen die Datenbank, z.B. Auftrag ohne Kunde, doppelte Bühnenbelegung, abgerechnet ohne Freigabe, Lücke in der Belegnummernkette |
| benachrichtigt | niemanden per Mail — Befunde landen in der Störungsliste, ein nicht gespeicherter Befund meldet sich als eigener Fehler |
| beruehrt | Auftrags-Zustandsmaschine |
| vault_filter | nicht geprüft — die Prüfregeln laufen über eigene SQL-Abfragen, nicht über den üblichen Datenzugriff |
| nein |
Beleg: MEM e2e-betriebsbereitschaft-2026-08-24: Audit fand konsistenz-check in keinem aktiven crontab, nur von Hand mit 200 ausgeloest. docs/SERVER-DEPLOY-PROMPT.md:240 (Stand 2026-08-20, davor) sieht dagegen taeglich 3:45 Uhr vor — welcher Stand auf dem Server gilt, ist damit ungeklaert. (Skeptiker-Korrektur, vorher: live)
Tiefer fragen
Kontext aus dem KFZ-Bozo-Handbuch
Knoten: auto-konsistenz-check (Automation · Schnittstellen, API & Automationen · teilweise · geprüft Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit) @ 0f0406a1)
Kurz: Prüft die Datenbank automatisch auf Widersprüche (z.B. Aufträge in unmöglichen Zuständen) und meldet sie.
Lies zuerst (Lesebereich, nicht der ganze Baum):
app/api/cron/konsistenz-check/route.ts
lib/messung/konsistenz.ts
docs/SERVER-DEPLOY-PROMPT.md
Hängt zusammen mit:
data-status-maschine-auftrag (lib/db/jobs.ts) · sec-cron-auth (app/api/cron)
Offene Fragen der Seite:
Ist der tägliche Zeitplan (3:45 Uhr laut Deploy-Plan) inzwischen wirklich aktiv, oder läuft die Prüfung weiterhin nur von Hand?
Hausregel 2: Vault-Daten sind für diese Session unsichtbar; Quellpfade auf Vault-Code sind keine Freigabe.
Frage: {{DEINE FRAGE}}
Antworte nur mit Belegen: nenne Datei und Zeile für jede Aussage.
Wenn die Quellen die Frage nicht beantworten, sag das und nenne, was du zusätzlich lesen müsstest.
Weicht die Seite vom Code ab, schlage den Seiten-Patch vor (wiki/seiten/schnittstellen-automation/auto-konsistenz-check.md).