<img src="banner.png" width="100%" alt="rotation-check banner">

Rotation-Check — ein Ziel pro Lauf, faire Abdeckung, Gedächtnis

Zweck

Wer eine Pipeline mit vielen Projekten periodisch prüfen will (Quellen, Stil, Gesundheit, Sicherheit, Übersetzungen, …), steht vor einem Verteilungsproblem: Alle Projekte pro Lauf zu prüfen ist zu teuer; ohne Gedächtnis prüft jeder Lauf zufällig dasselbe. Das Rotations-Muster löst beides: genau ein Ziel pro Lauf, Auswahl nach „am längsten ungeprüft", Registry als Gedächtnis. So deckt auch ein seltener Takt (täglich/wöchentlich) über Wochen die ganze Pipeline ab — nachweisbar und ohne Doppelarbeit.

Bewährt als Rückgrat eines gewachsenen Bestands produktiver Automationen über mehrere Projekt-Pipelines hinweg.

Bausteine

1. Zwei Dateien pro Pipeline (einmalig anlegen)

| Datei | Inhalt | Charakter | | --- | --- | --- | | CHECKED-REGISTRY.md | eine Kompaktzeile pro Check: Ziel, Datum, Checktyp, Ergebnis, nächster Schritt | Zustandsübersicht — wird VOR jeder Zielauswahl gelesen | | CHECKS-LOG.txt | kurzer Verlaufseintrag pro Lauf mit Details/Evidenz | Journal — append-only |

Beide liegen im Pipeline-Root (nicht im Einzelprojekt), damit ein Lauf sie mit einem Read erfassen kann. Registry-Zeilenformat:

text
| <ziel> | <YYYY-MM-DD> | <checktyp> | <ok|befund|übersprungen> | <nächster schritt> |

2. Auswahlregel

1. Registry und Log lesen (Pflicht, VOR der Auswahl — sonst Doppelprüfung).
2. Kandidaten: Ziele, die für DIESEN Checktyp noch nie oder am längsten nicht geprüft wurden.
3. Ausweichen, wenn das Ziel kürzlich von einem eng verwandten Check angefasst wurde

(z. B. Zitations-Check direkt nach Quellencheck bringt nichts) oder gerade gesperrt/in Bearbeitung ist (Locks respektieren). Geschwister-Cooldown: Laufen mehrere verwandte Checks über dieselbe Zielmenge (z. B. Entwicklung, Bugsuche und Review derselben Pipeline), eine Karenzzeit vereinbaren (Erfahrungswert: ~24 h), in der ein von einem Geschwister-Check bearbeitetes Ziel nicht erneut gewählt wird — verhindert Kollisionen und widersprüchliche Parallel-Änderungen.

1. Vorziehen außer der Reihe nur mit gutem Grund (z. B. große Überarbeitung seit letztem

Check) — den Grund im Log nennen.

3. Check durchführen — mit Read-only-Exit

Den eigentlichen Check (frei definierbar: Quellencheck, Style-Check, Security-Audit, …) auf das EINE gewählte Ziel anwenden. Zwei gültige Ausgänge:

• Befund: beheben was in den Scope passt; Größeres als Folgeaufgabe in die projektlokale

TODO/AUFGABEN-Datei eintragen (der Check muss nicht alles selbst lösen).

• Nichts zu tun: kurz dokumentieren und enden. Ein Leerlauf ist ein Ergebnis, kein

Scheitern — keinesfalls den Scope ausweiten, um „etwas gefunden zu haben".

4. Dokumentieren

• Registry-Zeile ergänzen (kompakt), Log-Eintrag schreiben (Details/Evidenz).
• Log-Hygiene: Werden Registry/Log unübersichtlich (Erfahrungswert: mehrere hundert

Zeilen), alten Stand nach _archiv/ verschieben, frische Datei anlegen, im Kopf auf den Vorgänger verweisen (Pfad + Datum).

• Pfad-Drift: Zeigt ein erwarteter Pfad ins Leere (Ziel verschoben/umbenannt), NICHT neu

anlegen — über die maßgebliche Statusdatei/Registry der Pipeline korrigieren und den Fehlpfad in einem Failure-Log festhalten.

5. Takt

Frequenz an die Änderungsrate des Geprüften koppeln: Rotations-Checks über stabile Bestände laufen gut wöchentlich (ein Ziel pro Lauf ≈ ganze Pipeline pro Quartal bei ~12 Zielen); schnelllebige Checks (z. B. auf aktive Arbeit) täglich. Praxiserfahrung: anfangs stündliche Checks wurden fast alle auf täglich/wöchentlich reduziert — die Abdeckung blieb, die Kosten fielen.

Prompt-Vorlage (für Scheduler/Automation)

text
VORBEREITUNG: Lies <PIPELINE_ROOT>/<POLICY-DOKUMENTE> sowie <REGISTRY> und <LOG>.

AUFGABE: Wähle genau ein Ziel aus <ZIELMENGE>. Bevorzuge Ziele, die für den Check
"<CHECKTYP>" noch nie oder am längsten nicht geprüft wurden. Wurde ein Ziel kürzlich
von diesem oder einem eng verwandten Check geprüft oder ist es gesperrt: ausweichen
oder read-only mit Logeintrag enden.

CHECK: <konkrete Prüf-/Pflegeaufgabe und was bei Befund zu tun ist; Folgearbeiten in
die projektlokale TODO-Datei>.

Wenn keine Arbeit anfällt: kurz dokumentieren, Lauf beenden.

DOKUMENTATION: Registry-Zeile in <REGISTRY> (Ziel, Datum, Checktyp, Ergebnis, nächster
Schritt) + Verlaufseintrag in <LOG>. Bei Überlänge: alten Stand nach _archiv/ und
frische Datei mit Verweis.

ABSCHLUSS: Kurzbericht (Ziel | getan | Ergebnis | Folgeaufgaben).

Red Flags

| Gedanke | Realität | | --- | --- | | „Ich wähle einfach ein interessantes Projekt" | Auswahl nur über die Registry — sonst Lieblingsprojekt-Bias und blinde Flecken. | | „Registry lese ich nach dem Check" | Vorher. Sie ist das Auswahlkriterium, nicht nur das Protokoll. | | „Mehrere Ziele pro Lauf schaffen mehr" | Ein Ziel hält Läufe kurz, idempotent und abbrechbar; Menge kommt über die Rotation. | | „Der Leerlauf war umsonst" | Ein dokumentierter Leerlauf aktualisiert das Gedächtnis — das ist der halbe Wert des Systems. |

Verwandte Skills

• workflow-extract — baut aus Sessions/Fremd-Automationen Automatisierungen; nutzt dieses

Gerüst als Standard-Baustein.

• pipeline-optimizer — für den strukturellen Umbau einer Pipeline (Rotation-Check pflegt,

Optimizer renoviert).

Changelog

1.1.0 (2026-07-03)

• Geschwister-Cooldown als Auswahlregel ergänzt (Anti-Kollision zwischen verwandten

Checks über dieselbe Zielmenge; Befund aus der Vollklassifikation des Automations-Bestands).

1.0.0 (2026-07-03)

• Initiale Version. Abstrahiert aus dem Codex-Automations-Bestand (Rotations-Muster in

~40 von 77 Automationen: Research-/Software-/Roblox-Checks mit CHECKED-REGISTRY/CHECKS-LOG).