was ist das hier
Ein kontrollierter Nacht-Lauf, der die immergleichen Wartungsaufgaben erledigt. Linting, Log-Aufräumen, kleine Sync-Jobs, Changelog-Pflege. Jede Nacht in gleicher Reihenfolge, mit einem Quality-Gate dazwischen — damit kein kaputter Commit automatisch ins Repo rutscht.
Warum das gebaut wurde
Die ehrliche Version: jeden Morgen fielen dieselben Kleinigkeiten an. Lint-Warnungen, die aufgelaufen waren. Logs, die niemand gelesen hatte. Ein Changelog, der nachgezogen werden musste. Das hat vielleicht zehn Minuten gekostet — aber es war der erste geistige Akt des Tages. Und genau das ist teuer.
Wiederholbare Arbeit am Morgen frisst den produktiven Kopf. Nicht wegen der Zeit, sondern wegen des Kontextwechsels.
Also: in die Nacht verschieben. Aber nicht blind und nicht im Cron ohne Gedächtnis. Mit einer klaren Plan-Phase, einer Ausführungsphase und einem Review, den ich am Morgen in einer Minute lesen kann.
Wie ein Lauf abläuft
- 1
Plan-Phase
Was soll heute Nacht passieren? Welche Lanes laufen überhaupt? Welche Aufgaben sind "report only", welche dürfen auto-committen? Dieser Plan ist getrennt von der Ausführung und lesbar, bevor irgendetwas ausgeführt wird.
- 2
Execute-Phase
Die geplanten Aufgaben laufen in festgelegter Reihenfolge. Jede Aufgabe erzeugt ein Artefakt — einen Patch, ein Log, einen Score. Nichts passiert still.
- 3
Quality-Gate
Bevor etwas ins Repo rutscht, prüft ein Gate die Artefakte: baut das Projekt noch? Sind Tests grün? Hat sich die Changelog-Qualität nicht unterirdisch verschlechtert? Nur wer besteht, darf durch.
- 4
Review-Snapshot
Am Morgen liegt ein kurzer Bericht: was lief, was wurde committet, was ist aufgefallen. Kein Scrollen durch Rohlogs — der Bericht ist das Interface.
Der Moment, in dem das Gate geliefert hat
warum das Gate nötig ist
Ohne Quality-Gate hätte eine bestimmte Nachtautomation einen kaputten Auto-Commit produziert — formal korrekt, inhaltlich Unsinn. Das Gate hat ihn abgefangen, und am Morgen lag statt eines Problems nur eine Warnung: "diese Lane hat nicht committet, hier ist der Grund". Das ist der Unterschied zwischen Automation und autonomem Chaos.
Das ist kein spektakuläres Ereignis. Aber es ist genau der Punkt, an dem sich Automation entscheidet: entweder sie produziert heimlich Müll, der Tage später auffällt — oder sie hält an einer Stelle an, die reparierbar ist.
Plan und Ausführung strikt trennen
Der entscheidende Griff ist nicht das Gate selbst, sondern die Reihenfolge. Ein System, das erst plant, dann ausführt, lässt sich prüfen. Ein System, das beides in einem Rutsch macht, erzeugt nur Ergebnisse — keine Möglichkeit, vorab Nein zu sagen.
klassischer Cron
- Ein Skript läuft nachts, macht was es macht.
- Output landet in Logs, die niemand liest.
- Fehler werden erst sichtbar, wenn etwas bricht.
Night Action
- Plan ist lesbar, bevor irgendetwas läuft.
- Quality-Gate entscheidet, ob committet wird.
- Jeder Morgen beginnt mit einem Ein-Minuten-Review.
Was aktuell läuft
- Plan- und Execute-Phase sind strikt getrennt, mit Review-Snapshot dazwischen.
- Das Gate blockiert kaputte Auto-Commits zuverlässig.
- Die Score-Historie der letzten Nächte fließt zurück in die Planung der nächsten.
- "Report only"-Lanes und "Auto-Apply"-Lanes sind inzwischen explizit markiert — statt beides im gleichen Job zu mischen.
Public Cut
Diese Seite zeigt den Prozess, die Guardrails und warum sie nötig sind. Sie zeigt keine echten Cron-Tokens, keine Secrets, keine vollständigen Runtime-Logs und keine konkreten privaten Payloads. Fehlerklassen werden abstrahiert benannt, nicht im Rohformat gezeigt.